When are we done adding everything into the browser API?
When somebody creates something better.
The time is right for a DOM templating API
161–170 of 256 posts
Re: The time is right for a DOM templating API
#162> This kind of templating is the cornerstone of all modern web frameworks and rendering libraries these days, all of which let you declaratively combine markup with data
Okay but just because fighting the river has become popular doesn't mean wanting to pave over the river is a good idea. It might be the logical _conclusion_ to fighting the river, but you could also just... stop fighting the river and use it the way it was intended to be used again.
Re: The time is right for a DOM templating API
#163[dead]
Re: The time is right for a DOM templating API
#164Earlier quoted context omitted.
We do know what is good. We may not know what is perfect, but perfect need not be the enemy of good.
What is good, then? Because I'm really not seeing it. Just peek at substack and bluesky to see how the templating ideas in web dev have turned out. (I'm assuming they are decent modern examples. If not, I'm game to see one.)
That which improves upon previous solutions.
I have no idea what substack and bluesky are, but I'll take that to suggest that someone used templating to create a mess. While that is no doubt true — someone can create a mess out of anything — would the same person have avoided the mess if the templating wasn't there? It is just ergonomics, after all, not some fundamentally different idea.
Re: The time is right for a DOM templating API
#165Earlier quoted context omitted.
I agree that DOM lists not being real arrays is a pita. I can understand why for getElementBy* methods which return live lists, but it's less clear for those methods returning fixed lists. But to me, these are minor inconveniences and habits. A thin wrapper can get you there easily if you care enough. I personally dislike this array/element confusion that jQuery adds.
> 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 DOM API could be better, and comes with friction. Back then, ironing out the browser differences and its selector feature were killer features of jQuery. Today, I do not think the quirks of the DOM API warrant importing a library like jQuery.
¹ but indeed, very lightweight compared to modern frameworks like Angular, React and Vue, with all the ecosystem which comes with each of them (react-router, redux, etc).
Re: The time is right for a DOM templating API
#166Earlier quoted context omitted.
> Also hard not to feel like this is reaching hard to try and recreate xslt. I was never a fan of XML, but XSLT was (is!) a killer redeeming feature of the ecosystem. And it's still widely supported in browsers! It was such a shame that XML caught on where it sucked--configuration, IPC, etc--but languished where it shined, as a markup language with an amazing transformation capability in XSLT. I think where XSLT fell…
XSLT is not bad, but XML, unfortunately, is normally misused, so XSLT is tainted as it has to be a part of that misuse. The true role of XML are grammar-based notations. These occur in two places: when a human gives data to a machine and when a machine produces data for a human. This is where XML is used despite its often mentioned shortcomings; for example, many notations to describe the user interface are based on…
The XML abuse I've seen at work is truly horrifying. We use protobuf for most of our inter-service IPC, but for one particular team one of their customers demands the use of XML so that it can be run through some XSLT "security" filters, so they have to transform a fairly large protobuf object into XML, run it through said filters, and then convert it back to protobuf :( I weep every time I think about it.
Re: The time is right for a DOM templating API
#167DOM templating is just like JavaScript classes. Classes in JavaScript were requested since the earliest of times and always rejected until ES6 (2014), because they are/were: * always unnecessary * always artificial * only vanity * only desired by insecure persons not familiar in the technology * only qualified as bad idea but necessary because people were just going to do it anyways So far the DOM has managed to esca…
It is slightly different. Classes ended up being worse than what they were trying to supplement. Templating, if done right at least (a big if, granted), can bring small improvement. If classes were better, we wouldn't see them the same way now.
Re: The time is right for a DOM templating API
#168I like the spirit here, but I would argue we need a few lower level APIs built into browsers first instead.
It will be near impossible to get everyone to agree on a standard template system. What the browser CAN do, however, is provide some lower level APIs on how to apply diffs to the DOM in a performant native way.
I would LOVE for something like this to exist in browsers natively:
element.applyDiff(DocumentFragment | string, { method: 'innerHTML' | 'outerHTML' })
This could apply the diff in a way that would be non-disruptive, i.e. it would keep element focus, input values, states in audio and video players, mutate attributes, etc. There are JavaScript libraries that do this like Idiomorph, but a native solution has the potential to be much more performant.
Re: The time is right for a DOM templating API
#169Earlier quoted context omitted.
XSLT is not bad, but XML, unfortunately, is normally misused, so XSLT is tainted as it has to be a part of that misuse. The true role of XML are grammar-based notations. These occur in two places: when a human gives data to a machine and when a machine produces data for a human. This is where XML is used despite its often mentioned shortcomings; for example, many notations to describe the user interface are based on…
The XML abuse I've seen at work is truly horrifying. We use protobuf for most of our inter-service IPC, but for one particular team one of their customers demands the use of XML so that it can be run through some XSLT "security" filters, so they have to transform a fairly large protobuf object into XML, run it through said filters, and then convert it back to protobuf :( I weep every time I think about it.
It is probably impossible to find a tech stack that has not seen horrible abuse somewhere. :D
Granted, it did seem that XML got more heavily abused than some other options for a while. I am curious if that is just a by product of when it was introduced. That or just the general proliferation of how many front end developers we have. (I hate that I am pushing that to almost be a complaint. I certainly don't mean it that way.)
Re: The time is right for a DOM templating API
#170Earlier quoted context omitted.
What is good, then? Because I'm really not seeing it. Just peek at substack and bluesky to see how the templating ideas in web dev have turned out. (I'm assuming they are decent modern examples. If not, I'm game to see one.)
That which improves upon previous solutions. I have no idea what substack and bluesky are, but I'll take that to suggest that someone used templating to create a mess. While that is no doubt true — someone can create a mess out of anything — would the same person have avoided the mess if the templating wasn't there? It is just ergonomics, after all, not some fundamentally different idea.
substack and bluesky are just newer sites. I don't even think they are bad. Just I question the volume of markup that they use to layout stuff. Knowing that that is the standard.
Do you have examples that are good?