Some dueling articles! You Have Ruined HTML is negative about the "hipster languages" and the mix of HTML destined for the DOM with various controlling structures. The rebuttal is HTML Wasn't Made For Apps.
Among other things, the former article talks about the complexity of the looping filters (sometimes the complexities they introduce in the code to get some sweet, sweet syntactic sugar is a poor tradeoff) and the opacity of the error handling and debugging.
The rebuttal points out, among other thing, how ugly building DOM ala React is. This reminded me of the bad old days of Perl CGI; there were libraries to build a page in code, via structural elements, but it was a much better idea to use Perl's << quote syntax for extended, multiline quotes, embedding HTML as minitemplates, complete with variable substitution. (Sometimes I still feel there's a divide with coders who are closer to backend engineers, and want to avoid making raw DOM, and coders who are closer to designers, who want to make DOM directly, but with the flexibility of looping and conditional structure.)
The answer, as usual, is somewhere in the middle. For a while I had a bias for treating the DOM as a static billboard the Javascript would write to (at carefully predetermined and loosely coupled points) but I've learned how handy a good templating tool can be. I think the best practice is to try to keep your chunks of template as modular as possible, and moving complex logic to code. (Where it's probably easier to test against anyway)
I'm kind of interested in what choice the various frameworks make in terms of tag-like, attribute-based markup (e.g. <div ng-if="somecondition"></div>) vs "out of band" markup (for instance with {{handlebar}} style structure.) Sometimes the former seems a little cluttered to me, because it mixes the semantic levels; your control structures look like DOM content you'd expect the browser to render, and when you inspect elements you see that unrenderable stuff. On the other hand, the {{handlebar}} tags will make a terrible mess if you ever look at code in unprocessed form, and so are a bit less designer-friendly.
No comments:
Post a Comment