41–50 of 177 posts
I definitely don't like this proposal. SPA:s is under a heavily innovative period. Standardizing it will only slow downs its' development.
- Angular seems to provide something similar already with its ng-* attributes and directives.
- JavaServer Faces also do the same thing, where a server-side controller is bound to HTML or UI widgets (and skip writing CSS and JS because they're pre-styled, pre-programmed).
This works for simple stuff, but for much more complex stuff (multiple view interactions, custom views), this becomes a pain to write because you start to create workarounds for things it wasn't prepared to do.
Also, while I'm no expert, but let's just leave HTML, CSS and JS as is. You can always create a framework that provides you that same functionality. In fact, Angular has directives, React has JSX, Ember has components. Several other frameworks do it as well.
Reminds me of E4X, where they tried to bake in XML syntax into JS. This time, it's behavior and logic into the markup. Nope.
What - the - fuck
Lots and lots of very bad ideas here -- backwards-incompatibility with previous versions of HTML is always a good litmus test that a proposal hasn't been thought through, as is "hey let's restructure everything around this one currently-fashionable design pattern". (I kind of love how he just casually embeds a SQL interpreter in the browser, too, that's a nice finishing touch.) But the main thing is that this doesn't…
I'm not necessarily opposed to something along these lines, except that it's basically already been tried: XSLT was essentially the inverse of this, where data endpoints were annotated with some static rendering descriptors. To me the XSLT approach seems cleaner, in that the URLs the browser is visiting are for the raw data itself, the URL scheme between machine and human is identical, and so on. XSLT also encouraged…
I think we should keep HTML simple and enforce a strict separation between template and logic. However, I do like the idea of adding a native "model" attribute to the DOM element that can automatically get/parse json and update accordingly.
Have you ever used React? What do you think about the React/Flux methods of mixing template and logic?
I'm not necessarily opposed to something along these lines, except that it's basically already been tried: XSLT was essentially the inverse of this, where data endpoints were annotated with some static rendering descriptors. To me the XSLT approach seems cleaner, in that the URLs the browser is visiting are for the raw data itself, the URL scheme between machine and human is identical, and so on. XSLT also encouraged…
Yep. I used to love XSLT -- working in it finally forced me to understand recursion at, like, a deep cellular level -- but the whole time I was using it I knew it was a doomed language (because most people don't want to have to understand recursion at a deep cellular level just to be able to lay out a damn web page.)
Nowadays, this isn't that different of an approach from using my server-side PHP/python/node/Go to generate JSON, then building my DOM based on client-side templates; since I use ReactJS, my transforms are even still XML. A lot of the best-practices I learned from XSLT transferred over nicely too, e.g. avoiding control logic () in favour of , since good javascript client-side templates should avoid branching control logic in favour of just Array.prototype.map() wherever you can.
I think the real key isn't about understanding recursion, though you will gradually gain an appreciation for it, but understanding composition. Templating is too often done in the style common among poor developers, where they think about building a whole "page", instead of defining the components of that page. XSLT, in theory, would've been great for that, it's just a pain in the butt to actually implement.
tl;dr if there is a need for this proposal, it would be better met by cleaning out all the cruft from XSLT, and building implementations that don't require such arcane syntax nobody can use it.