Is there anyone else who feels kinda like declarative templating is actually kind of worse than jQuery? Don't get me wrong, I've been using React for nearly a decade. But the more complex my SPAs become, the more I wish I had imperative control of the DOM. I think the reason is because the DOM is a leaky abstraction and at some level I would just prefer last write wins. I realize declarative templating is supposed to…
The time is right for a DOM templating API
211–220 of 256 posts
Re: The time is right for a DOM templating API
#212Earlier quoted context omitted.
> Hard not to laugh out loud at "We know what good syntax for templating looks like." First of all, it's not very nice to laugh in the face of someone advocating for progress on the web platform, which benefits everyone. Second of all, yes we do now know what good syntax for templating is, it's basically jsx (and I'm saying this as someone who's really not a fan of React). It took the whole web by storm, it's been ad…
I'm laughing because it just hits so hard. Started playing some role playing with friends again recently and we were looking for a template for the character sheets. You know what they have? A PDF. That is their template. Why? Because they design things that way. And it is funny, because I can already feel the ideas that would go into templating this symbolically. Characters have 6 and 20 numeric attributes. But, I c…
It's in contrast to the imperative `document.createElement(...)` & `parent.appendChild(...)` APIs which you otherwise use in vanilla JS.
Re: The time is right for a DOM templating API
#213Earlier quoted context omitted.
> A thin wrapper can get you there easily if you care enough But that's more and more friction. A wrapper here, a wrapper there, and if here, a try/catch there. At one point you are reinventing significant chunks of jQuery
jQuery's scope is broad¹. It has at least: - a plugin system - its custom selector parser (because it had it before querySelector and is not totally compatible with it) - its abstraction to iron out browser differences (old IE vs standard, notably) that's not relevant anymore - its own custom (DOM) event management - its implementation of methods that are now standard (ajax & trim for instance) I recognize that the D…
Re: The time is right for a DOM templating API
#214> We've explored the reactivity landscape. While early DOM templating proposals didn't include updating, userland systems have thoroughly explored the landscape by now, and discovered good mental models and better and worse implementation approaches. I think we can now zero-in on a system that combines the best features from the different approaches. AFAIK Ryan Carniato/Solid JS is still exploring what’s possible wit…
Re: The time is right for a DOM templating API
#215Earlier quoted context omitted.
But flex layout is fundamentally different from tables, I guess you meant grid with that reference? It's not that every website uses CSS grid for layout. Coincidentally, I took a look at the DOM+CSS of a bluesky post just a few days ago (very weird coincidence, since that was the first time I opned bluesky for months), and it did use old-school tricks like centering using CSS transforms, presumably because renders a…
I did mean grid, there. And don't get me wrong, I don't necessarily want everything absolute positioned. I just find it amusing when people try to get a badge or some such on something and then herculean efforts they will go through to get that badge exactly where they want it. So, with bluesky, the amount of markup that goes into the footer menu of each post would be what I'm looking at. Tools were clearly used to g…
Re: The time is right for a DOM templating API
#216Hard not to laugh out loud at "We know what good syntax for templating looks like." We don't. Not even close. Because I'd hazard a good template is almost certainly more of a visual thing than it is a symbolic one. Is why dreamweaver and such was so successful back in the day. And why so many designers learn with tools like photoshop. Also hard not to feel like this is reaching hard to try and recreate xslt. :( It is…
> Hard not to laugh out loud at "We know what good syntax for templating looks like." First of all, it's not very nice to laugh in the face of someone advocating for progress on the web platform, which benefits everyone. Second of all, yes we do now know what good syntax for templating is, it's basically jsx (and I'm saying this as someone who's really not a fan of React). It took the whole web by storm, it's been ad…
This is not true. For instance:
Vue uses markup-based templates like this:
{{ item.message }}
Svelte uses text-based templates like this:
{#each items as item}
{item.message}
{/each}
Angular uses markup-based templates like this:
{{ item.message }}
And let’s not forget that the world doesn’t begin and end with JavaScript. Most other templating systems are either markup-based or text-based. For instance, Jinja2 is text-based:
{% for item in items %}
{{ item.message }}
{% endfor %}
JSX really isn’t that great. Sometimes it feels like most React devs don’t know how to write a for loop or if statement because they mostly use map(), ternaries, and short-circuiting, which are not very ergonomic compared with markup-based approaches.Re: The time is right for a DOM templating API
#217Earlier quoted context omitted.
jQuery's scope is broad¹. It has at least: - a plugin system - its custom selector parser (because it had it before querySelector and is not totally compatible with it) - its abstraction to iron out browser differences (old IE vs standard, notably) that's not relevant anymore - its own custom (DOM) event management - its implementation of methods that are now standard (ajax & trim for instance) I recognize that the D…
quack quack quack... why reinvent the wheel, why not adopt a good, working system, why the need to do everything in a complicated way? give resig a big black suitcase full of money and implement his complexity reduction framework called jQuery into the standard. And fire the standards guys in the process, because what they do is shit. they most presumably never worked extensively with the shit they produce.
If you are going to use many features of jQuery, then it makes sense to use it, but if it's only a matter of writing one or a with wrappers, then jQuery is overkill.
I don't have a strong opinion on the proposal described in the article.
Re: The time is right for a DOM templating API
#218Earlier quoted context omitted.
I'm laughing because it just hits so hard. Started playing some role playing with friends again recently and we were looking for a template for the character sheets. You know what they have? A PDF. That is their template. Why? Because they design things that way. And it is funny, because I can already feel the ideas that would go into templating this symbolically. Characters have 6 and 20 numeric attributes. But, I c…
I don't think you understand what "template" means here, this has absolutely nothing to do with design or end result on the page. At no point would a designer be involved with templating the DOM. It's in contrast to the imperative `document.createElement(...)` & `parent.appendChild(...)` APIs which you otherwise use in vanilla JS.
I largely get the intent of what you are saying. But the entire point of why developers use templates is so that they can create pages that meet a design. And the entire reason I think they constantly get redone, is that design is inherently a visual process.
This is like trying to use formatting strings to try and handle localization. It just doesn't work. Folks will try and piecemeal all of the different strings in their application, only to find that some languages don't decompose the sentences in the same way. It can work wonders in small demos. It falls on its face when doing large things.
Don't get me wrong, I'm largely sympathetic to the gripes about the `createElement` and related methods. I've hacked on top of them many times with stuff similar to https://taeric.github.io/cube-permutations-1.html. They aren't pretty. But I'm not entirely clear on why template strings would be largely better?
Further, I could be surprised and this new API will usher in a better way of doing things. I'm not opposed to the effort. I just have a low prior on it succeeding. And I heavily disagree that we know what a good templating syntax is. Quite the contrary, until we learn to embrace visual artifacts, I do not think we will solve the templating needs.
Re: The time is right for a DOM templating API
#219Earlier quoted context omitted.
> It’s worth noting this was written by by one of the people wrecklessly barging forward with half-baked specs that introduced significantly more problems than they solved, pushed a "solution" that requires 20+ new web specs to barely do all the things user-space is already doing while completely ignoring and gaslighting anyone who wasn't 100% on board with what they were doing. Safari argued that there should be a d…
Web components were such a big disappointment. 200% the complexity for 20% of the functionality. Everything coming out of that area seems to be hideously over-engineered while failing to solve the problems people wanted them to. My feeling is that they were focused on designing something that is aimed at building form controls, not the kinds of components web developers use in practice. They are designed to make brow…
Re: The time is right for a DOM templating API
#220It’s worth noting this was written by maybe the person with the most experience in the space i can think of—-the primary author of Lit / Polymer working at web components on Google and contributing on many core DOM specs that have become part of the web platform.
> It’s worth noting this was written by by one of the people wrecklessly barging forward with half-baked specs that introduced significantly more problems than they solved, pushed a "solution" that requires 20+ new web specs to barely do all the things user-space is already doing while completely ignoring and gaslighting anyone who wasn't 100% on board with what they were doing. Safari argued that there should be a d…