Live data from Hacker News

The time is right for a DOM templating API

justinfagnani.com

211–220 of 256 posts

Re: The time is right for a DOM templating API

#211
post #66

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…

Absolutely. I've yet to see a single example which has convinced me that React (etc.) is remotely preferable to writing separate HTML and jQuery.

Re: The time is right for a DOM templating API

#212
post #145

Earlier 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…

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.

Re: The time is right for a DOM templating API

#213
post #165
post #149

Earlier 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…

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.

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…

There is a lot of interesting research outside of the webdev bubble in the incremental computation problem space, and self-adjusting computations (signals) aren't even that interesting.

Re: The time is right for a DOM templating API

#215
post #191

Earlier 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…

The nested divs in modern markup are just signs of lazy bone headed devs. I’m constantly removing them from our own app because with either grid or flex box layout in the browser is stupid easy. Haven’t even been tempted to use the old tricks like floats or absolute positioning in years and years.

Re: The time is right for a DOM templating API

#216
post #34

Hard 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…

> 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 adapted for all kinds of frameworks, and it's undeniable that all js templating systems converged towards common attributes: templates-as-expressions, composition via nesting and control flow with just javascript (instead of specific template syntax).

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

#217
post #165

Earlier 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.

I'm not advocating complicated, I'm advocating lightweight. We should not be importing libraries left and right for our convenience to the detriment of the user.

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

#218
post #145

Earlier 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 confess your comment leaves me even more confused, all told. :D

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

#219
post #96

Earlier 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…

Im not sure what you're referring to, they seem pretty straightforward to me. Create a class that extends HTMLElement, implement stuff in connectedCallback and attributeChangedCallback. Return a list of attributes in static observedAttributes. Or use some extended class if you want, there are plenty and they're easy to create your own.

Re: The time is right for a DOM templating API

#220
post #96
post #73

It’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…

What were these 20 new specs?
Post reply on HN