On Thu, May 10, 2012 at 8:03 PM, Ian Hickson <ian@hixie.ch> wrote: > I understand that people do this kind of thing all the time, but I've > always at least assumed that everyone agreed that it was a necessarily > evil because the alternatives were even worse. I had hope when we were > discussing Element.create() that maybe we were finally coming up with a > workable alternative, but as far as I can tell that never went anywhere > and now we're actually talking about adding APIs to _support_ string-based > DOM tree generation as if it's an actually sane way of writing code. > I'm not sure why this isn't sane. It's exactly how everyone writes their code on the server, where the majority of their markup is generated. Raw HTML with variables is much more human friendly than structured JavaScript objects and arrays. Developers are already in the mindset of writing HTML fragments. They do it everywhere. In a traditional web model, you never run into the context problem because the server always generates a full page. So even if you're using nested templates on the server, with some of your templates being fragments that might require context (say a <tr>), by the time it reaches the browser it's already concatenated into a full page. As web apps become more advanced and servers start returning fragments (or the fragments are just generated directly on the client), then these issues start to crop up. In the developer's mind, nothing has changed about how to generate the markup. There's little incentive to switch from strings to Element.create(), but there's a lot of incentive to stay with strings.
Received on Friday, 11 May 2012 00:27:23 UTC