Hi Jason, Thanks for taking the time to write such a detailed reply.
> On 31 Oct 2018, at 16:32, Jason E Bailey <j...@apache.org> wrote: > > First there were the initial use cases that didn't make much sense to me. > > 1. There wasn't anything else out there that did this. -> (*cough* *cough* > thymeleaf) > > 2. That it allowed you to separate front end and back end developers so that > back end developers wouldn't be thrown by the complexities of creating html > in the manner that the designer wanted. -> I've never experience that, ever. > If I had a developer who couldn't figure out how to make html he wouldn't be > working for me long. I think that here the logic was the exact opposite - empower a front-end developer to write the presentation code for a component, given that they have some API available for the dynamic part of the component. > > 3. It allowed it to be pure html with no custom tags. So that you could just > take the html that a designer gave you and plug it in -> That didn't last > long. What prevents you from outputting custom tags? Or why should they not be allowed? > > So I was like fine. It'll be a tool in the tool chest and that if it was that > good it would eventually be the thing that everyone uses. Then BAMM all of a > sudden it's the only official way of creating components in AEM. There's > people posting on Stackoverflow how it's "best practices." Throw a stone at > an AEM consultant and he'll yelp "HTL" > > Now, in part I get this. It depends on the use case. If you're a consultant > or a freelancer this makes sense. Your dealing with clients who are throwing > a design to you that they've mocked up in some design software. Where they > want to have you create a set of pages, this kind of feature makes sense that > you could go thrown cut out the html and add functionality to it so that the > final page works with the CSS the designer created. > > That's never been my use case. I've always done long term projects where I'm > building up a suite of components that are re-used across tenants. I don't > get a request for a page. The designers are in the system and are customizing > components that have already been created or working with the authors and > developers to create a very specific component that has all of 2 or 3 layer > of html. > > Having a separate person to just render that structure in a component would > be a waste of time and resources. > > Does that matter? No. Remember the consultants? Remember the only official > way of doing things? If I have a problem with a component... why aren't you > using HTL? Bring in a consultant, "you can save money/time by using HTL", > really I looked at it, it doesn't help me. "But.. but... best practices" > > Then they whip out contextual rendering. Which, quite honestly is great, I > don't need to manually do the encode stuff anymore. That alone makes it a > nice to use and something to consider. Although it could also have been done > in the rewriter and then you would have had encoding done everywhere without > regard to the script creating the html but that's a separate conversation. > > So that's why I resent it. I dislike blind followers who use the phrase "best > practices" because they can't articulate the real reasons to do things. I > resent being told that all of the work that I've been doing should be redone > for reasons that don't logistically or financially make sense. Yet at some > point I'm going to do just that because at some point my team needs to > understand HTL to work with it. > > Heh, the cult of HTL is strong enough I've probably talked myself out of > future job positions. But I've never been one not to state an opinion. > > [/RANT] > > - Jason > I have to agree with you here. HTL should not be in itself named a best practice without a proper guide on how to use it. I’ve seen tons of poorly written HTL, as well as all kinds of hacks (e.g. JSON output through an HTL component, XML, you name it). To play the devil’s advocate here, I think that what consultants tried to say, without being able to fully articulate their opinions, is that HTL is restrictive enough that it forces you to write cleaner code - you cannot mix logic and presentation code in the same file. However, that shouldn’t be interpreted as “use HTL exclusively, JSP is horrible” if your shop is able to produce clean JSP (or whatever you fancy) scripts, with logic provided by say Sling Models. However, I think that there are very few companies that produce 100% scriptlet-free JSPs, hence why some consultants came up with this black and white view of what a best practice for your presentation layer is. There are two great articles about HTL which everybody in this community should read: [0], written by Dan Klco, and [1], written by Jörg Hoh, as a reply to Dan. Cheers, Radu [0] - https://blogs.perficientdigital.com/2018/08/27/a-retrospective-on-htl-the-wrong-solution-for-the-problem/ <https://blogs.perficientdigital.com/2018/08/27/a-retrospective-on-htl-the-wrong-solution-for-the-problem/> [1] - https://cqdump.wordpress.com/2018/09/03/htl-a-wrong-solution-to-the-problem/ <https://cqdump.wordpress.com/2018/09/03/htl-a-wrong-solution-to-the-problem/>
