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 inevitable that someone will want to template something that isn't well formed, but can combine into a well formed thing. And then you are stuck trying to find how to do it. (Or correlated entities on a page that are linked, but not on the same tree, as it were. Think "label" and "for" as an easy example in plain markup.)
If I could wave my magic wand, what we need is fewer attempts to make templates all fit in with the rube goldberg that is the standard document layout for markup. People will go through obscene lengths to recreate what judicious use of absolute positioning can achieve fairly well. Sure, you might have to do math to get things to fit, but why do we feel that is something that we have to force the machine to do again and again and again on the same data?
> 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 over was that it's a real DSL, and a declarative, pure, functional DSL at that. People like to talk a big game about DSLs, but inevitably they're simplistic syntactic exercises that don't actually abstract the underlying procedural semantics of popular host languages. When faced with a well-designed DSL that makes difficult tasks trivial... people can't be bothered to learn.
The thing most people never got about XSLT is that it is really about production rules -- and production rules (e.g. the major path to "expert systems") are one of the most solidly rejected technologies in software engineering.
I didn't understand this until I spent a few years going down a rabbit hole asking questions like "why don't people like production rules?" In the case of templating people expect to make a template with a top-down organization that looks like the output, whereas XSLT really wants you build transformations from the bottom-up. On some level the bottom-up part is clear, particularly if you want to code-generate your rules (towards the end I was writing production rules that write production rules) but what is not clear is how the parts all fit together: you can't visually tell between an XSLT that builds the structure you want vs one that doesn't.
I think the most fun I ever had with XSLT was when I used an XSLT engine with user-defined procedures and had them create side effects, such as matching certain patterns in an XML document and making SQL inserts, though that was a long time ago when we were still using terrible XML parsing libraries.
I’m a big fan of XHTML (strictness is good) and feel like XSLT could be a great addition, but I hate the syntax. I’d love to build a Jinja to XSLT compiler one day.
XSLT's weaknesses are the extension of its strengths. It's the first homoiconic, purely functional language that enjoyed widespread adoption among "normal" developers, not type theory wonks.
But XML's syntax sucks, and so inevitably does XSLT's, because XSLT is just XML. Were it s-expressions, the syntax could suck slightly less. It was (is!) a small price to generate XSLT using XSLT, which makes XSLT very powerful and expressive if you hold it right, almost like a Lisp. This saved me a few times around year 2000 or so.
I wouldn't say it had widespread adoption. We used XSLT in my day job at the time to do client-side updates, even had a special SQL API that turned sql queries into XML automatically by naming the columns with a special syntax and it was virtually unheard of (2007?).
It was actually great when you got it, but the learning curve was so steep many developers couldn't use it effectively to begin with. For complex pages only certain developers could make changes or fix the bugs. Precisely because it was functional and most developers at the time really only understood imperative.
In fact, I remember the DailyWTF had a WTF about using XSLT as client-side transforms a few years later:
But doing something like that was in fact so much faster than doing it in js, and when you groked it (deliberate throwback), it was so much simpler. I actually wrote a pivot table control in XSLT which completely blew away the performance of the pre-v8 javascript one. Pre-V8 javascript was so slow most developers wouldn't believe you now. A 10,000 iteration loop of even basic operations was often enough to cause IE6 to show a pop-up saying the page wasn't responding.
The pivot table in javascript would crash with just a few hundred lines of data, in XSLT it was instant with even 10,000s.
A really interesting use of XSLT on the web at the time was the WoW character viewer. You could view (and share) your character on Blizzard's website, with all their gear, skills, etc. It was blazingly fast for the time and it was all written in XSLT.
CSS and HTML have a dual relationship. You could certainly write CSS with an XML-like syntax but people would always get confused at whether they are looking at style or markup. Because HTML and CSS look completely different you never have that problem.
XSLT shares the same problem with the RDF specs coming out at the same time that it hid the production rules/logical nature of the system, had it looked more like
it could have been quite different. But production rules never really sold (got told that by the marketing chief of vendor at a hotel bar after a conference they sponsored) and it's an interesting question why. They can do all kind of neat things like manage asynchronous processes that happen over a long period of time (like having a loan officer approve a loan) but nobody ever tried to use them to deal with the async comm problem in Javascript as far as I can tell.
I barely used xslt, but as a fp head I wanted to try, the most confusing part to me were terminology / semantics / decoupling. Seemed like matching templates could be anywhere making difficult to understand the meaning of a script.
In some sense that's a strength. When things can happen in any order you can mash together two things and they work together.
When I was looking for my own revolution in software engineering I saw one part of the low code/no code puzzle was that conventional tools force you to determine what order events happen which was something laymen shouldn't be bothered to do. Some counters are: spreadsheets (they figure out what order to calculate it), make (does a topological sort), dependency injection tools like Spring (writing a FactoryFactoryFactory isn't so bad, but maintaining it is a disaster when a "small" change means you have to reorder the order in which you construct everything)
There is a "freedom is slavery" problem here. People saw the semantic web as "you're going to exhaust yourself arguing with people about standards and ontologies before you even start coding" and not "if my data is properly namespace I can throw data from 10 different sources together into my RDF database and start writing queries".
The node pattern matching was ok, but as far as i can recall, there could be multiple matching patterns scattered in lots of places (a 180deg turn compared to most FP pattern matching that aim for exhaustiveness ?)
Exhaustiveness is only relevant for the compiler-managed pattern matching of a traditional FP type system, where you need to write an implementation (patterns that will be used at matching usage sites) for everything that your types promise.
XSLT pattern matching is the plain kind: here is a pattern, look for it in the input and process every match. If some part of the input document is ignored, it's just not useful; if some part of the input document is processed several times, it's perfectly well defined.
The problem here is runtime includes, especially the "drop source in place" style includes, coupled with dynamic dispatch at runtime. These two things in combination make static analysis of execution flow anywhere from really hard to impossible
If by "hard to track" you mean not knowing what template is producing an observed bad output, the modularity of self-contained templates and XPath expression is likely to help with debugging.
here on HN I dare to out myself as a DSSSL lover, the scheme based predecessor of xslt.
I still can't wrap my head around how the neat and clean dsssl syntax, a real programming language, was replaced by an xml notation for the same: for cuntional code and a framework. because semantically, that's what xslt is: a functional language with a framework, geared at transforming xml instances.
but that syntax... and of course a much inferior and more obscure language than scheme underneath dsssl.
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 XML. This is convenient, because user interfaces are created manually. (I am not mentioning text markup, it is well known.)
Yet XML was often used as a notation for machine-to-machine exchange. For example, the ONIX book description standard. Here data are moved between two computers, yet for some reason they have to form grammatically correct phrases according to a set of grammar rules. Computers do not need grammar. They do just fine with non-grammatical data, like a set of tables. It is way simpler for them; parsing or generating grammar, even explicit, is pure overhead for data exchange and is only necessary when data enters or leaves the computed pipeline.
So, to your examples: configuration in XML is actually fine, but IPC is not. Configuration is written by hand, IPC happens between machines. IPC specification, on the other hand, is also a good fit for XML.
That said, XML and thus XSLT has another flaw: it is way too verbose and has no good way to format it. Conciseness was an explicit no-goal but now we can say it was a mistake.
I thought Tim Bray's XML spec was one of the most beautiful tech documents I'd every seen when I saw it for the first time. Adding namespaces at that point in history though was a disaster. Back then developers just weren't used to that kind of rigor (when I first started coding Java I had to go to a website run by frickin' NASA to get a clear explanation of how namespaces worked.)
It didn't help that Microsoft dropped a stick of over-complicated standards that tried to bring RPC into XML. RPC has always been a cursed concept because between (1) trying to be intellectually coherent and (2) caring about performance RPC systems become incomprehensible and it doesn't matter if it is Sun RPC, DCOM, CORBA, "Web Services", Protocol Buffers, etc.
The fact that the "REST economy" is intellectually incoherent and could care less about performance seems to have helped it succeed. Right now I just wrote a javascript function that looks like
const get_item = async (item_id) => {...}
and it does
GET /item/{item_id}
and I have a Java function on the server that looks like
Item getItem(String item_id)
and is tagged with some annotations that make it get called when that GET request. Jackson lets me write an Item as an "anemic domain object" that gets turned into the exact JSON I want and the only real complaint I have is that the primitive types are anemic so representing dates is a hassle.
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.)
XML needs another syntax that isn't so verbose. Sort of like how OWL has XML, Manchester, Functional, and Turtle syntaxes for the same data structures.
XSLT needs a Turtle-style syntax.
XML in general (the data structure, not the syntax) needs a Turtle-style syntax.
> but languished where it shined, as a markup language with an amazing transformation capability in XSLT
I choose to look at this a little differently.
An XML application using XSLT is so much better (faster load times, faster to write, easier to make correct) than a JavaScript application with a JSON api, that XML is basically a secret weapon.
I only care enough that it stays in browsers, but otherwise I'd prefer nobody know about it because it means less competition on things that matter (faster load times, faster to write, fewer bugs, etc). And I've got a half-baked JavaScript-based "renderer" I can finish in case some Google VP asshat goes looking for things to delete...
> 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.
How do you come to this conclusion? It seems to me that what you mean is a general gripe with HTML+CSS, not with how it's generated.
And why do you bring up absolute positioning?
I hear this take on HN again and again and sure, absolute positioning has its place, and is needed for many things.
But when it's used for page/app layout, most of the time I came across this it was an absolute nightmare, falling apart at the slightest content (even text!) or screen size changes.
Even print newspaper layout can't work like this, because typography is involved, although it's probably a lot closer to what I imagine you are describing.
Maybe I'm misunderstanding you.
But when I was doing more CSS-intensive work (I still do a fair bit), developing something on a basis when someone created a layout based on absolute positioning that looked like it was "almost ready", it was a terrible time sink to try to fix it and recreating it using flex, flow et al for layout (I'm not that fond of grid outside of some scenarios, and at the time I didn't use it due to browser support) was always faster because the problems with absolute positioning as the main layout tool were basically unfixable.
Maybe there are techniques using calc() and viewport units where it makes sense, but absolute positioning is not suitable for any layout outside of completely static content and viewport dimensions, in my experience.
I've been in the opposite, where people will go through lengths to try and make it so that the defaultish dom layout makes things "fall into place" so that they had a very specific layout of elements. When a fairly simple set of elements with somewhat minimal styling would get what you wanted surprisingly easy. Provided you did a lot of up front calculation on your own.
Basically, my assertion used to be to draw out what you have in mind on grid paper. Then start creating the elements. I don't see how that flow could land you with the 100ish divs that you wind up with on something like a single blue sky post.
Is it a panacea? No. Of course not. Can a constraint language help? I think so.
I'll add that the flex layouts seem like an improvement over what used to be there. Even if I find it rather amusing that we seem to have settled back on tables for layout. :D (I suppose it is more like some of the layout managers from Java days, truthfully.)
But, fundamentally, the problem appears to be that the drop to symbolic text is just not something that everyone does the same way. As such, it is very easy to get into a lot of trouble with the number of cooks in the kitchen, as it were.
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 tiny bit faster than flex centering, or avoids layout calculations when elements are added in a virtualized list.
Virtualized lists are also a good example for falling back to specifying exact pixel positions and dimensions for performance reasons, but these are usually determined with help of JS. I think the transform I saw was a translateX(-50%) one, so centering.
I totally get the canvas-like approach, but in a way the constraint-based flex layouts fall into the same line of thinking for me.
The issue with absolute positioning is the need to manually specify positions and dimensions for elements, which makes it useless unless you are working within a fixed box or only relating to the corners of one rectangle.
It is explicitly meant to remove elements from the normal layout flow so they overlap each other by default.
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 get styles such as "css-g5y9jx" and this isn't the worst examples I've seen. But I am curious on why so many nested divs seem to be needed all of the time.
I am not clear what you mean by canvas-like approach? I think folks should still use elements. Just fewer of them, all told.
Direct to my claim, though; my argument is just that templates/designs are visual things. I don't think people are thinking in terms of nested div elements. They largely don't even think of sections of their template as parent/child relationships. They have a visual thing and want it filled in with whatever data.
The badge on something is a good example for using absolute positioning exactly for what it's meant for imho.
With "canvas-like approach", I meant this part of your comment (not the web technology):
> Basically, my assertion used to be to draw out what you have in mind on grid paper.
I guess we were talking past each other because you equate templates and designs, and I didn't think of this usage of the term (the post also is not about this).
Templating is not necessarily for full pages always, that defeats the purpose of templating languages in the first place to me.
> Direct to my claim, though; my argument is just that templates/designs are visual things. I don't think people are thinking in terms of nested div elements.
Agree. And using modern CSS is a great way to reduce the number of "div"s.
> But I am curious on why so many nested divs seem to be needed all of the time.
I fought many these battles in my jobs, and often it's just for flexibility, because different components are written in a modular fashion.
Minimizing the DOM tree size is my goal too, but often the version with less nesting requires a bit more thinking and breaks more easily when elements are added or changed.
CSS gris vs nesting flex containers is a great example for that.
Other times it's just laziness / people don't care.
Another poster was pointing out that this is not necessarily what is meant by templates in the post. I can see the distinction, but not really sure it changes my view. Since the post is largely more javascript literals for dom objects, it is hard for me not to bring that back to the design implications? Literally comes back to "people love JSX" many times. Why? Because it lets them get things to the presentation layer that is their browser.
I took some time to dive into how extensive JavaScript has made the word template in their world. I confess it reads a bit excessive to me. More than a bit, really. Tagged templates, in particular, look like one of the biggest foot guns I've ever seen.
I took it to design because I don't know of any other real reason to template the DOM other than for design purposes. Indeed, reading on the linked proposal, this is to make reactive things on a page. And that will have to be married to a design at some point. Often the entire point of introducing names that are exported from data to a rendered document is for the presentation implications of it. Otherwise, you'd just output the data?
I'm not sure if I can contribute anything more here.
Tagged template literals, aka "template string literals" are yet another technology adjacent to JS and HTML using the word "template". But it doesn't have much to do with the submission.
It's just a fancy name for advanced string interpolation in JS, and has no inherent connection to DOM elements or fragments.
But it is used by some technologies such as styled-components and Lit (the web component library).
styled-components is probably also where the obfuscated CSS-in-JS class names in the bluesky markup originate.
There is also a `<template>` element that is used by ShadowDOM and web components.
But nothing of that is the essence of the post, these are just things that coincidentally use the word "template" (and, less coincidentally, the concept).
As far as I see, it is about the wish to standardize declarative data-binding to DOM trees.
Basically, a React-like API built into the browser, but less detached from native rendering algorithms.
I only mentioned tagged template literals, as they were called out by the article as an unsung hero. Presumably, they are an example of what a good template language looks like. If so, they don't give me hope that we know what a good template language looks like.
The idea of the post seems to be encapsulated in the web components issue and discussion. Agreed that it looks largely about data binding to DOM trees. To paraphrase you, "seems like advanced DOM interpolation in JS." Which, I just can't bring myself to agree that this looks good. Happy to be proven wrong in time.
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.
> People will go through obscene lengths to recreate what judicious use of absolute positioning can achieve fairly well
the web has the requirement that the 'document' look good no matter what device size/dimension, orientation, and/or capability.
In regular apps (say, a windows app), you don't have this requirement. In mobile apps, there's a standardized set of sizes. Only on web do we have both!
Not really? People impose the idea that they can make this work. Yet no sites looked good on the Nintendo DS browser, and people were largely ok with that. Few sites look genuinely good on phones. People are largely ok with that.
The Nintendo DS browser was not good enough to use as a daily driver. My phone, on the other hand, I spend more time browsing on that than I do my computer. Some sites aren't great on it, but the vast majority are fine (reader mode will get you through 99% of the rest). I'd argue most sites don't "look good" on any device. It's really not that hard these days to make a site work on mobile, the navbar often is the most challenging part of it.
I'd also argue that there are only superficial similarities between, say, React and Svelte. Yes, they both have a syntax based heavily on HTML, but they work very differently. React is the only major framework that works by having (mostly) normal JavaScript functions return lazy representations of markup (in the form of JSX). React has no template-level notion of looping or conditional rendering, because you use normal JavaScript for that.
> 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 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).
It's good when someone advocates for what they believe to be progress on the web platform, but it's not necessarily clear that this would be progress. And that line in particularly is amusing because we absolutely don't know what good syntax for templating looks like — that's why there's so many different options.
JSX is certainly the most popular because it's used in the most popular framework, but it has some very clear weaknesses. In particular, it has very clear semantics for a React-like, VDOM-based framework, but those semantics do not work as well for other kinds of framework.
For example, you mention control flow via ternaries/`.map`. This works great in React, where the entire template will be reevaluated every time any input changes. However, frameworks like SolidJS or Vue in Vapor mode work very differently, and typically evaluate JSX only once at component mount (or at least, as seldom as possible). To support these, these frameworks need to use either special components like `For`/`Show`, or directives like `v-if`.
There's also the issue of how to evaluate JSX. In theory, JSX is flexible, in that `<Cpt prop={expr} />` can be converted to any call of the form `h(Cpt, {prop: expr})`. Again, that's not true for SolidJS or Vapor mode Vue — in both of these frameworks, `expr` cannot be eagerly evaluated, so the traditional transforms just don't work. Both of these frameworks therefore have to include their own custom plugins for handling JSX correctly.
The author's suggestion to also use signals as a state mechanism suggests they're imagining something more along the lines of SolidJS. That's an odd choice (it's my personal go-to framework, but it's also very niche), but it also implies, as discussed, that JSX-in-the-browser wouldn't behave like JSX-in-React. From experience, that will cause problems! I've worked with React developers before who've really struggled to use SolidJS because of precisely this issue.
> 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:
<ul>
<li v-for="item in items">
{{ item.message }}
</li>
</ul>
Svelte uses text-based templates like this:
<ul>
{#each items as item}
<li>{item.message}</li>
{/each}
</ul>
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:
<ul>
{% for item in items %}
<li>{{ item.message }}</li>
{% endfor %}
</ul>
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.
> 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.
I'm the last person to vouch for React and the horrors it has inflicted upon web development, but the one thing it definitely got right compared to Angular (and Vue) is the use of JS for control flow, rather than fake attributes and whole new language.
JSX is as much a new language as Vue’s templating. JSX extends JavaScript syntax; Vue extends HTML syntax.
If you’re working on generating markup, it makes more sense to do that at the markup level than constantly switch between markup and imperative JavaScript.
It might use JavaScript for control flow, but does it really count when it uses it in a way that is not idiomatic at all? It’s not idiomatic JavaScript to use map instead of for everywhere, and it’s not idiomatic JavaScript to use ternaries instead of if everywhere. Writing JSX looks very different to writing normal JavaScript.
The difference is that JSX is using control flow from an actual programming language, whereas Vue is shoehorning control flow into declarative markup. This is the single reason React won the frontend framework market: they got the templating right.
PS: in modern JavaScript, using map rather than for loops is more idiomatic!
> This is the single reason React won the frontend framework market
Don’t be silly, the front-end landscape is a lot richer than you make it out to be. React hasn’t “won”, the last time there was a clear winner in front-end, it was jQuery.
> PS: in modern JavaScript, using map rather than for loops is more idiomatic!
No, it’s not, and this is exactly what I was talking about. for loops and map() serve distinct purposes.
for iterates through a series of elements.
map() transforms a series of elements.
It’s possible to use them both for the same things, but there is a very clear semantic difference between them. One doesn’t replace the other, they mean different things.
In the context of “I have a bunch of elements I want to iterate over and output”, what you want is a for loop. The reason why React devs have been convinced map() replaces for loops is that React has to force you into making everything an expression, so instead of writing for when it’s appropriate and map() when it’s appropriate, they have to write map() everywhere.
It’s good you ended on the one thing JSX got right: everything is an expression. It’s that simple. There’s nothing imperative about evaluating a template, it’s entirely covered by functional programming techniques. You’re just producing a value.
And yes, modern JavaScript uses tons of concept from functional programming, where it is understood that mutating values and triggering side effects should be a last resort. This is why a good js programmer uses ten times more maps then he uses for loops.
> mutating values and triggering side effects should be a last resort.
Output is a side-effect.
> This is why a good js programmer uses ten times more maps then he uses for loops.
This is a) massively overstating things, and b) not relevant to a case where zero for loops can be used.
> Maybe you don’t know how dominant React is today? Two third of JavaScript developers use React at work
I checked those figures before I posted that comment to double-check my memory. Two thirds is not anywhere close to “React won the market”. Android has ~72% global market share, but I’m sure you wouldn’t say that Android has won the smartphone market.
> It feels like you’re out of touch, have you used JavaScript lately?
We disagree, that doesn’t mean I’m out of touch. Try not to be so insulting.
It’s not an insult, if you think for loops are commonplace in modern JavaScript and React isn’t the dominant frontend framework by far (twice more used than the next in line, vue), you’re out of touch, it’s just a statement.
How can you not realize that producing a string or a tree of elements is a purely functional operation? There’s no side effect here. Are you familiar with the concepts of functional programming?
You are being insulting because every time we disagree, you ignore half of what I am saying to assume I don’t know what I am talking about. Two informed people can disagree but you don’t seem to get that. A conversation is not a competition where one person gets to prove the other person is ignorant.
Take “React winning”. We disagree that React won because I don’t think 66% of a market is “won”. But you jumped to the conclusion that I just didn’t know what I was talking about. Then I clarified that the difference in our opinion is not the knowledge of the market share but our judgment of it, and I gave the example of Android not having “won” the smartphone market with ~72% of the market… and you just ignored that and doubled down on calling me out of touch.
Take the use of map(). I am very clearly distinguishing between common usage and defined semantics. The gap between the two was what I was complaining about. But you ignored what I was saying and decided that I don’t know map() is used a lot in modern JavaScript, when that was the core of my complaint!
And for functional programming techniques, we disagree in how we think about the operation. You see it as data processing, I see it as I/O. I very specifically pointed out that I/O is a side-effect. This is a mainstream viewpoint in functional programming. But you ignored what we actually disagree about and assumed it’s just because I don’t know anything about functional programming.
Your approach to disagreeing with me is to ignore half the things I say so that you can attack me for being clueless. You need to do better.
I still think you’re misunderstanding what React is optimizing for. When you say "React has to force you into making everything an expression", you’re describing its core philosophy, not a constraint. JSX is built around the idea that rendering is just data transformation. It's UI as a function of state. That’s why using map() is idiomatic here. You’re building trees, not iterating imperatively.
Also, it bears repeating that React isn’t just slightly dominant. 82% of JS developers have used it according to the 2024 State of JS survey, and for good reason. It shaped the modern frontend mindset in a way that Vue or Angular haven’t, despite their own merits. For instance, many frameworks came up with their own version of hooks. It's telling that most new frontend frameworks are aiming for the "better React" position.
I realize we just have different interpretations of what "winning" means in a fragmented ecosystem, but it’s worth acknowledging how much React has set the tone for modern web development. UI as a function of state (and using map() a lot...) is here to stay.
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 can already guess most would consider it a fault to manually place either of those on the page. Yes, the sheet has a limitation on how big your name can be. No, you can't really avoid that.
JSX is what happens when you no longer have a design and a dev team. It is great at that, even. But if you have a workflow where a designer makes a template and sends it over to a dev, it no longer really helps. You are much better off making something that can pick at artifacts that are handed off.
Instead, we seem to be aiming for an idea that will have to replace learning of everyone involved.
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.
We don't know what good syntax for templating looks like because HTML is complex enough and many have tried making it more complex with things like Blade for PHP or HTMX for example.
For some reason I've always preferred JS to HTML. React components with JSX is a good balance. Not everyone agrees but that's OK.
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.)
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.
So, no? You don't have any examples by which to demonstrate what a good templating language is?
You seem to have gone on a tangent that "good" is a general topic in my question. I meant do we have specifically good examples of templates. Surely if we know what good templating syntax is, we can share examples of it? Even if you can't describe it directly.
I provided a good template language, at least given what was good at the time it was introduced. As good is necessarily a moving target, one can never really satisfy your request as by the time the submission has round-tripped it is quite possible that what is good has already been redefined.
So, yes, I understand you are trying to call attention to my 'loosey-goosey' usage earlier. But I am saying that when I said "good", it was relative to the temporal position it found itself in.
I still consider the templating language I shared before, even at the time of this comment, to be good.
But, as recognized earlier, others may find it doesn't hold up to today's standards. "Good" is not only not a constant, but is also subjective. Do I really have to explain the entire universe here? Man.
You didn't share a templating language, though? You shared an example of a formatting/templating string, but didn't even indicate what level of format string it supported. Such that I don't know if you are sharing C's printf, bash's printf, PHP's... I can presume you don't intend to include CL's FORMAT. Even if I do have a softspot for it, myself.
> You shared an example of a formatting/templating string
Which is, you guessed it, a language! Okay, yeah, I didn't dive in so deep as to provide a formal specification for the language, or whatever it is you were hoping for, but if you really want to take this to silly town, I'm going to tell you that what you saw is the only valid input for this language and only specify that, so, maybe, unless you are having fun with this comedy routine (in which case, carry on; I'm certainly still entertained!), you can read between the lines? The question asking if I need to explain the universe was rhetorical, implying that I am not going to do that.
> Hard not to laugh out loud at "We know what good syntax for templating looks like." We don't.
The article fails to accept that performance and security aren’t addressed by vanity layers. This is a mistake repeated by web technologies when popular demand eventually crushes common sense, because hiring is more important than training/maintenance when the lowest levels of the work force can’t tell the difference and drives all design decisions.
If you want better performance or security you have to measure things, not wear a pretty dress and look the other way.
A basic lesson we've learned over and over is that API/ABIs aren't final. Application needs are never permanently fulfilled by a stable API, with all future problems considered to be app-level issues.
This proposal is a good example of how common issues with the platform are solved on top (React etc.) until we recognize them as a problem and then push them down. Polyfills are another example.
If a proposal like this succeeds, it lives a time in the sun, but then spends most of its useful life being the old thing that people are trying to work around, just like the DOM API, just like ECMA versions, just like old browsers, just like every other useful bit of tech that is part of the system but can't be touched.
Is it possible to think about entropy, extension and backcompat as primary use cases?
It's also the case that every feature in web standards means extra code that needs to be painstakingly maintained, and extra code that anyone trying to create a standards-compliant browser must implement. I want to see projects like https://servo.org/ actually have a chance to catch up over time, not always be chasing an expanding scope.
I want the web platform to have every possible capability that native platforms have (subject to privacy and sandboxing constraints, of course). And I want the developer experience of web developers to be incredible.
But these need to be balanced against the consequences of added complexity. And in this case, does native templating really improve developer experience? I'm not convinced the benefits outweigh the costs.
> A basic lesson we've learned over and over is that API/ABIs aren't final
I dunno --- getElementById has been stable for, what, 25 years? "There's no such thing as a stable API" is something said by people unable or unwilling to create interfaces that last. It's a statement of personal resignation, not cosmic impossibility. There are tons of counterexamples.
Application needs, like other needs, are infinite. You satisfy these needs by adding new APIs, not breaking working ones.
I think you'll find that even the most unstable APIs have extremely stable parts to them.
At the same time I don't think there is actually anything that most people would consider an API that is open to public usage that has maintained that kind of stability that getElementById has, which after all is something most people would describe as a method of an API.
If you valued your sanity when developing complex Web UIs, React was a lifesaver.
DOM sucks though, it's slow, it's heavyweight, it lacks transactions. We're stuck with it, and frameworks like React have to do the DOM diffing + patching thing, explicitly, in JS.
Agree that react isn’t the best implementation of the concept, both in terms of ergonomics and efficiency. But a react-like framework is still very much needed to create complex apps in the browser. So IMHO react is a solution to a very current problem, only not an ideal one.
Not really? `useSignal` is just another hook React needs as a replacement/augment for `useState` and maybe `useEffect`. Signals aren't that special. Arguably that's part of why a lot of people like Signals as a proposal.
(I'm still of the sort that thinks Signals are just worse Observables, so it's not a proposal I'm particularly thrilled about, but were it to be adopted Signals are easy to use in Observable contexts as well, they are just uglier half-implemented BehaviorSubjects, though maybe with a few extra lint rules to prefer Observable behaviors over Signal ones.)
The part about Signals is telling and illustrates well why the idea while laudable is practically unfeasible.
I get why OP likes signals. In every large enough project there is a half baked implementation of a DAG calc tree and it makes sense that a language could standardize one.
But these abstractions have a huge mental / implementation cost.
The problem, as with most engineering things is a tradeoff problem. The react model - where you just update the global state and re-render everything - is slower but easier on the brain. The signals model is faster, but so much effort.
Most apps out there don’t need to be crazy fast, and people will choose react because it’s just simpler.
But signals don’t really have anything to do with templating, do they? So why do we have to choose, could we have templating and signals as separate things?
Well OP thought about templating and realized you do need a way to tell the dom how to fit your templated node where it belongs and update it when things change.
And this is where these proposals fail. There needs to be a choice here. The API must pick a side (well technically it could allow for both, but ugh), and developers won’t ever agree which side it should go.
The big problem of UIs has always been how they update, not how they’re defined. Microsoft tried (and failed) at defining a ton of models, MVC, MVP, MVVM, and what not, all of them were painful AF. Then imgui come and say, well what if UIs didn’t have state at all. Ooh this is nice, but kind of hard on the cpu, so what do we do?
Well, perhaps one of the biggest reason for the success of web apps is in fact that the dom didn’t impose a way to bind data to its view. And so we may be doomed to framework hell.
> The react model - where you just update the global state and re-render everything - is slower but easier on the brain. The signals model is faster, but so much effort.
there are multiple frameworks now that do fine-grained diffing without relying on signals, proxies, or any other reactive primitives. they basically have the top-down react model but much faster and without the weird concepts like hooks and manual/wasteful dependency arrays.
it's just 8% slower than the fastest / ugliest / imperative / unmaintainable vanilla js you can eventually arrive at if all you care about is winning benchmarks.
Just want to add that even though ivi is using tagged templates, I am strongly against using tagged templates to describe UIs as a Web Standard.
One of the most useful features that could make a lot of incremental computation problems easier is "value types"[1], but unfortunately it seems that isn't going to happen anytime soon. The biggest constraint when developing an efficient UI framework with good DX is JavaScript. Also, it would be nice to have `Node.prototype.insertAfter()` :)
> The biggest constraint when developing an efficient UI framework with good DX is JavaScript.
for perf, s/JavaScript/DOM, i think.
good DX comes from ecosystem and amount of time invested in making good tooling. JSX would be a non-starter without IDEs helping autocomplete, linting/format, syntax coloring, and webpack/babel to do the compilation.
tagged templates could reach at least the same level of DX as JSX if the community invested the resources to make that better. i'm not saying it's the right solution for a standard, but it would be way better than jsx, since tagged templates are already a standard.
> JSX would be a non-starter without IDEs helping autocomplete, linting/format, syntax coloring, and webpack/babel to do the compilation.
and then you immediately go on to say this:
> tagged templates could reach at least the same level of DX as JSX if the community invested the resources to make that better.
So, tagged templates are also non-starters without IDEs helping autocomplete, linting/format, syntax coloring.
> i'm not saying it's the right solution for a standard, but it would be way better than jsx, since tagged templates are already a standard.
They are strings. There's no magic in tagged templates that somehow make them immediately better for some custom non-standard syntax compared to JSX.
You can't just plop a string containing lit's custom non-standard syntax into an IDE (or a browser) and expect it to just work because "it's tagged templates are standard".
For the purpose of templating in the browser there's literally no difference between standardizing a custom syntax based with JSX or tagged templates.
> There's no magic in tagged templates that somehow make them immediately better for some custom non-standard syntax compared to JSX.
they're marginally better since they have a platform-defined way to deliniate static from dynamic parts. ivi _can_ work without a runtime or build-time JS parser, while JSX cannot (because jsx has to be parsed out of full blobs of js)
on the dx/ide side, sure there's not a huge amount of difference if both had the same effort invested.
In the context of "let's create a native templating syntax for the browser" those differences between JSX and tagged templates don't matter. You still need something that the browser needs to parse and understand, you still need something for libs/frameworks to handle/understand/compile to.
My feeling is that tagged templates would actually be a worse fit in this scenario because now you would have to distinguish between "regular" tagged templates and "templating" tag templates.
If I understand it correctly, the main argument in favor of tagged templates is that it doesn't require any changes to the js engine and that is why it will be way much easier to push forward. Browser implementation should be quite straightforward and it will be possible to implement a semi-efficient polyfill.
Personally, I don't think that it will have any significant impact, everyone will continue using React,Vue,Svelte and it is highly unlikely that they are going to adapt this new API.
Instead of adopting JSX, I would really like the syntax for this to be more like the way Kotlin uses receivers and builders to provide a generalized syntax for DSLs that happens to be good for describing component hierarchies. It would be broadly useful far beyond just HTML templating, it would also be great for expressing configurations and all kinds of other things.
The actual semantics for templating and data binding could just be a set of standard functions that use those syntactic feature, much like what you see in Jetpack Compose.
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.
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 declarative ways for this 15 years ago
It's "recklessly". "reck" is a very old word meaning "to care, heed, have a mind, be concerned about"; so "reckless" means "without taking heed".
I actually thought it was directly related to "reckon" (meaning "to think or calculate"), but when I looked it up it turned out not to be the case (except much further back in the etymological tree).
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 browser vendors’ lives easier, not web developers. That’s often excused with “web components excel at ‘leaf‘ components” when what is actually meant is “web components are bad at everything else”.
I would expect an actually good solution that fits in with the web’s architecture to come from the direction of HTMX, not web components.
> Safari argued that there should be a declarative ways for this 15 years ago
True, but they were equally able to propose and deploy alternative solutions and mostly just went along with web components (with exceptions of course).
> True, but they were equally able to propose and deploy alternative solutions and mostly just went along with web components (with exceptions of course).
Safari doesn't have as many engineers (a shame) and definitely doesn't have as many people whose apparent job is just to sit on standards committees and generate specs (like Alex Russel, Justin Fangnani etc.).
That looks interesting – certainly a lot simpler and closer to web developers’ needs than what ended up getting standardised.
It really is a shame Apple don’t invest more in WebKit and the web standards process. Although they’ve been doing a lot better over the past few years.
You absolutely can. It's the primary purpose of the DSD (Declarative Shadow DOM), one of the many new specifications people complain incessantly about.
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.
You mean other than the 20+ web specs they added to platform (often to "fix" problems that they themselves introduced and/or that no one else has)? https://w3c.github.io/webcomponents-cg/2022.html (this list appeared after half a dozen or more specs had already been rammed through)
Or that their mere existence infects nearly every spec in existence delaying and needlessly complicating actual useful specs like Scoped CSS?
- doesn't forget and then scramble to fix the most basic expected functionality like form participation
- doesn't pollute the space so badly that actual useful specs like Scoped CSS are delayed for years because now they have to deal with all the web coponent shenanigans
- hopefully doesn't take 15 years to barely do what others have been doing since time immemorial
First off, what’s with the pointless JavaScript? There’s no need for imperative code here. All web components have a dash in the name; this can be inferred. But even if you want it to be explicit, this could be done with markup not imperative code. But no, it doesn’t work without the pointless JavaScript ritual.
Now, I’ve noticed that since the text is a caption for the image, I should actually use <figure> and <figcaption>. So let’s do that:
Wait a sec! The nice round corners on the image have turned into ugly square ones. Why is that?
It’s because web components can’t style anything other than their direct children. You can style the <img> when it’s a direct child of the web component, but as soon as you need anything more complex than an entirely flat hierarchy, you run into problems. Even if it’s something as simple as wrapping an <img> in a <figure> to associate it with a <figcaption>.
What’s the “official” way of getting things like this done when you bring it up with the people working on the specs? Make a custom property to fake the real one and then set a global style that listens to the fake property to set it on the real one:
Now let’s say I want to put a second <cool-dog> element on the page. What does that look like? You define the template once and then just use <cool-dog> a bunch of times? That would be the obvious thing to do, right? Since it’s a template?
Nope. Every instance of the web component needs its own <template>. The best you can do is write some JavaScript to copy the template into each one.
The developer ergonomics of this stuff is terrible. It’s full of weird limitations and footguns.
> First off, what’s with the pointless JavaScript? There’s no need for imperative code here.
Exactly, I'm not sure why you've included the JS. The whole point of the Declarative Shadow DOM is to create shadow roots declaratively, rather than imperatively. To quote web.dev "This gives us the benefits of Shadow DOM's encapsulation and slot projection in static HTML. No JavaScript is needed to produce the entire tree, including the Shadow Root." [1]
You clearly have an axe to grind, and I'm not particularly interested in proselytizing. If you don't find the Declarative Shadow DOM useful, that's fine!
The example I was responding to was using the Declarative Shadow DOM. My comment was intended to point out the simple fact that the imperative component definition the author was complaining about is superfluous, meaning you can safely remove that entire script from the example.
I'm so fascinated by the few people online who show up to anything web component related just to flame and complain. It's always the same things too.
DSD is useful for SSRing web components, which allows them to render and work without JS. But honestly, I don't get the obsession with doing stuff without JS, it's part of the html/css/js trifecta.
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 handle that, but this starts to break down really quickly when you share mutable state between components.
I think part of this is React folks think its a cardinal sin to invoke the dom apis directly. Sometimes it's just fine to capture a ref (and dare I say, query a component by a id) and do the work directly. In fact this is what most libraries that are "fast" and low-rerenders do (like the form ones).
I don’t like React but I disagree with this sentiment. First of all you can already opt out of declarative DOM and knock yourself out with innerHTML and ref.
Second, what can you do with imperative control of the DOM that is less practical with the declarative one? I can only think of certain methods (attachShadow(), showModal()) but even then you're a 10-line component away from making it declarative.
> 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 with signals. I don’t think userland exploration of this space has entirely finished, and further innovation may be possible.
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.
I 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:
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.
The article does link to the DOM part proposal, which would be one useful low-level API. It wouldn't work so well for VDOM-based frameworks, but for other frameworks it could simplify how they work and provide additional room for optimisations. It would also be useful for projects without a framework, particularly if the signals proposal was also adopted.
> If the Records and Tuples proposal were progressing, JSX could maybe create Records with boxes, but that proposal has been stalled, especially on the record identity and box parts that would make it suitable for a JSX semantics.
I would argue that the proliferation of frontend frameworks is evidence is that we -don't- know what the optimal abstraction is for building frontend applications. We're all still trying to figure that out.
Just look at what happened with Web Components. It didn't take over or become the foundation of everyone's software. It just became yet another competitor [0].
I wish the standards committees would focus their efforts on improving JavaScript the language. That has a much greater and more lasting return on investment.
I would love to see Web platform become more similar to JVM or .NET CLR - just a bytecode JIT with access to rich layout/rendering engine. Then build whatever you want on top of it.
This is exactly the kind of high-level feature we need to stop putting standardisation efforts towards, and focus instead on low-level features that provide value for high-level user land abstractions.
There is no value this provides over making a tagged template function and exposing it as a library. If that library is stable with ubiquitous adoption for 5-10 years then maybe there's something to talk about.
God I love lithtml’s tagged template literals so much more than react’s JSX or Vue’s 3-in-one thing. It’s just html, in strings, in JavaScript. Lit is just a way to make custom elements easier. Man it’s gonna suck when I have to move on from my current gig and get my hands dirty with react again.
Yep, `lit` is contaminating the browser API with their ideas just because their group of people writes the code for the browsers. They should be competing from the outside. Instead of pushing this kind of apis that only fit their mental models.
It’s similar enough to html that anybody familiar with html and JS can pick it up. Quirks it has, but I like that using it mostly just feels like building a huge html string.
"Similar enough" is a far cry from "It’s just html, in strings, in JavaScript"
> anybody familiar with html and JS can pick it up
Just like JSX. But no one calls JSX "just HTML" (and in React, with rules of hooks, it's no longer "just JS"). In Solid JSX returns actual DOM nodes btw.
> it mostly just feels like building a huge html string.
Because that's what you essentially do. lit runtime parses your custom string, converts it to proper HTML, concatenates that into a string, and then dumps into the document with innerHTML (it does set up data bindings etc. , so it's more than just thay of course)
functional in the sense that it uses method calls on objects and javascript has higher order functions.
It is a spectrum.
I know DOM nodes are objects that use inheritance but I also know javascript is not deemed a "traditional" functional PL of course.
People want this because JSX is all they are capable of.
One reason why things like this have never happened before is because the people who need this are only barely capable of working with HTML. The DOM supports a wide variety of technologies far outside and unrelated to HTML.
There is still innovation happening in frameworks. I do wonder if it is too early to start adding things like this to the browser. Web components landed way too early and now we’re stuck with them.
Chrome implemented a prototype, then the spec changed and they removed it, then they implemented the new version. I should have been clearer and said Chrome Canary and Firefox Nightly. Not sure when it will reach stable but probably some point this year, they’ve been working on it for ages and Safari is onboard.
What exactly is the problem with having the higher levels of web development supported through libraries (React, Vue etc) rather than directly in the browser? Why does this need to happen?
> Developers need to reach for a library, and thus tools like npm or a CDN, to do many basic things. This adds to the overhead of getting started. It makes simple static files and devtools less useful than they could be. There's no fundamental templating knowledge that's portable between stacks, and native DOM creation APIs like innerHTML are unsafe by default.
Remember when you could just drag an html file into your browser, and it would work? No build step, no package install, no web server, just vanilla html+css+javascript?
It would be nice to get to do that again, and the more we move things like .querySelector out of libraries like jQuery and into native browser APIs the better, imo.
That should ideally be the highest calling of frameworks like Lit and packages like Lodash - to be so good that they prove indispensable, and ultimately go native.
Seems like a comment comes up about XUL every few years and I can't help but be sniped by it. A xulrunner app was my first job out of college in '08, good memories, fun dev environment!
My company, me as a solo dev, back in 2003-04 built a "single page app" using XUL and iframes.
Still has some 200 monthly users, the poor bastards. They have to download Firefox 3.6 iirc, and it only works in an 800x600 window.
It's a full management app for recruiting companies.
There are still 3 companies that use it (since 2008), so their employees don't have a choice really. The app does a lot, so to stop using it the companies would need to hire and migrate to 3-4 other services. I reckon SAP and the kind could do everything as well, but these companies are too small for that.
There isn't a website or anything anymore for me to show, and I haven't been involved in it for over 10 years.
> React doesn't provide a way to explicitly bind to properties and events of DOM elements, or provide directives that apply to an element.
I didn't understand this part, can anyone shed light? What is different between what's being described here and what React does with event listeners, etc?
I think this is referring to the fact that React uses synthetic event listeners - it's cheaper to bind an event listener once at the root and do your own element matching than it is to continuously bind and unbind listeners.
> React doesn't provide a way to explicitly bind to properties and events of DOM elements
We can nitpick this point because react has had a ref API for at least 5 years now. Given a ref, all DOM API are available. For events, SyntheticEvent will refer to a native event if it exists.
The SyntheticEvent abstracts vendor discrepancy. Under the hood, react can apply some optimization too.
The synthetic event also adds its own abstractions though. For example, the `onChange` handler in React behaves very differently to the native DOM `change` event.
Yes, it's weird that Browsers were so fast to ship CSP rules to prevent XSS attacks by limiting the use of inline scripts but so slow to ship a templating mechanism which would largely solve the problem.
It's like creating regulations which require a specific solution before that solution exists.
> There are in-flight proposals for very low-level DOM update primitives, like DOM Parts, which target framework implementations, but I think higher-level APIs like full declarative templating can take even more load off, help prove out and complete the lower-level API proposals, and be really impactful for developers and users.
no point pushing declarative sugar again into a system that's already kinda moved on. native templating not fixing real pain = state sync, fine grained reactivity, perf edge cases. we might need a browser level primitives that let lib authors build better abstractions without the payload tax. we maynot need another xsl reboot
The web platform is over bloated. The proper solution would be a minimum set of APIs and set of reusable by many sites JS/Wasm libraries.
For example, most of Web Audio (thing like filters and oscillators except for actually sending audio to audio card) could be implemented in Wasm making a browser simpler and not allowing to use it for fingerprinting. Also, base64 encoding/decoding, URL handling function, most of canvas code etc. Imagine how less work for browser developer it would be.
I think web needs an “actually standard” library. Something that vendors could ship with browsers but could be also updated to higher version of a site requires it (and cached forever).
That would allow us to not download a bunch of code every time.
DOM 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 escape this stupidity only because it is not a part of JavaScript. Java people ignorant of JavaScript desirous of features to make JavaScript feel more like Java has no bearing on the DOM, for example, because they are separate technologies managed by unrelated organizations.
None of the ergonomic reasoning mentioned in the article are qualified. Just because many people lack confidence in the technology and knowingly make poor design decisions doesn’t mean a familiar vanity layer will fix anything. Declarative comfort, for example, is not a resolution to performance and security problems just because other knowingly bad design decisions are worse. Two wrongs don’t make a right.
Furthermore the DOM already has a slow unnecessary declarative abstraction layer insecure people cannot live without called querySelectors. In other words this proposal is to React as querySelectors are to jquery, and classes are to Java. These are/were trends and trends die over time. We really should move past vanity as an alternative to an absence of training.
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.
String interpolation is so ridiculously slow. Epic slow.
Perhaps just as importantly is that is a crutch for many to avoid accessing the DOM in steps. You can read from the DOM with querySelectors but you cannot modify the DOM with them. If querySelectors is all you can do then you must use some third party template system because you have no idea how any of this works even though it provides maximal expressive freedom.
Is anything preventing JS from compiling the proper stepwise dom access if the querySelector parameter is a literal? That would basically push the interpolation into the parsing step.
A native virtual DOM implementation would also drastically reduce memory overhead since browser engines could optimize diffing algorithms at the C++ level instead of requiring megabytes of JavaScript framework code to be downloaded, parsed and executed on every page load.
The linked proposal has many "features" that would be "needed" if you frame the problem in terms of a "template api", centered around "binding" variables, and what not.
Doesn't your proposal implicitly introduce the concept of a virtual DOM, which the browser does not have?
You'd need to spec out what that looks like. It adds one new API from the users perspective but much more from the browsers perspective.
Additionally the next generation of Frameworks do not use virtual DOM. Solid and svelte do not. Vue is moving away from it. Signals are directionally where they're all heading.
The API surface I propose only includes one function. No type needed.
It does not even require the target node to be created with a virtual dom in the first place. Just diff the node with the given tree structure efficiently.
Internally the browser might need to create a few accelerator data structures, but that's an implementation detail.
Depends where the platform boundary is for Web. As much as we hate JS fatigues and so many frameworks, choice is good. Maybe if the browser can make it easy for these frameworks to be performant and integrate more deeply (not part of the JS bundle but more like a deeper JS 'plugin' with bonus of sometimes having a cache hit from another site) we could just carry on using React et. al.
one trouble is that systems that work at the DOM tree level are an order or two magnitudes slower than string-based templating systems. Hypothetically you could do some interesting things like hygenic macros and merge together arbitrary documents, rewriting the CSS classes and such. But by and large people find string-based templates to be good enough and don't way to pay the price for something more expensive.
Currently <slot>s only have automatic behavior when attaching a <template> to the Shadow DOM to a node with existing "Light" DOM children, which mostly only happens with Web Components (and for now Web Components require JS).
So it is not yet a full, generic templating solution.
Also, this article goes on at length about how the templating needs to be "reactive" and not just "builds a DOM tree", and <slot> doesn't do that yet at all, even in the automatic behavior scenarios, it's a one time "merge".
Kicking the can along the road of the complexity of "reactive" components is a large part of how we've got the (quite basic) <template> and <slot> tags that we got, and I think why the article is still currently impractical. There needs to be more agreement on what "reactive" means. The article mentions the signals proposal, and that's one possibility that a lot of frameworks are pushing for right now, but it's still a process before browsers agree to support something like that, and something like that is a dependency before agreeing on what a "reactive" template language can be/how it would work out of the box.
As mentioned, the DOM API is a stinker. Does this address that root issue?
I'd love to see something that builds on the work of hyperscript and HAST. They are great models of the DOM. It would be exciting if a template language were syntax sugar.
JSX is easy to reason about because its elements are 1:1 with a single, uniform function call. That feature means JSX is always optional. Sometimes it is even more verbose or less-performant to use JSX than a hyperscript API like specifying optional properties. I think errors and call stacks are clearer than during string interpolation, but that's possibly BS.
Web components offer limited data binding and the hyperscript approach has clear control flow. The templates seem to be a source of confusion in the GH discussions.
There is still something special and pleasant about jquery because its API was a reflection of the domain. As a developer, I want to query for a node (CSS selector, xpath, etc.) to affect change and traverse to other nodes. After a beer or two I'm convinced emacs and org mode approaches are worth emulating in the web.
Great article and linked discussions. Thanks for sharing.
> 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.
If you built React into the web platform, what I'd expect is everyone would stop using it the moment a big new version of React came out, and it'd eventually get deprecated and removed.
There has been long running complaints about how many UI frameworks there are, and how often they change. It's settled down some, but I don't expect that situation to change for a long while.
> If you built React into the web platform, what I'd expect is everyone would stop using it the moment a big new version of React came out, and it'd eventually get deprecated and removed
Not related to the templating thing but I have the impression we are witnessing the last React big change with RSC. This change made them lose a good % of developers, a next one would kill it.
I disagree on the general principle of adding APIs -- the platform suffers not from lack of APIs, when you really think about it, but from "another API to rule them all". It's frankly a similar fallacy that struck Microsoft where they were for a long time stuck having to support every API their seniors and interns ever invented -- none of which seem to be sufficient, apparently.
The solution to the "bro, just one more API, please" is to design a _transparent_ platform that is well able to "delegate" programming of new features (e.g. one implementing your favourite templating API) to third-parties in a manner that maintains their "first class citizen" status. WebAssembly was a move in that direction because it's a generic platform that in part supercedes and otherwise supplants the mess that JavaScript has to manage bridging the originally "kiddie script" application software domain, with the native functionality the browser may be encapsulating (also for performance).
Case in point: FFMpeg may be compiled to a WebAssembly module, which gives you arbitrary video/audio encoding/decoding -- pending correct design of bit-blitting so the decoded output can be efficiently transferred to the screen/speakers (which, for much of the reasons I am trying to outline, _is_ the bottleneck of the entire solution).
We need more of the same kind of thinking. Stop begging Web browser vendors / w3C / WHATWG for more features that are just lipstick on a pig -- sit down, think about what kind of feature(s) would allow the Web platform to finally escape the death spiral it's been in since its inception -- albeit one with a large enough radius it's meant to never actually resemble a spiral.
I don't know if I am making myself clear here, but in much simpler terms: why should there be another piece of code that caters to "most" (because you happen to be a FP/React zealot, for better or for worse) when these people can ostensibly write such templating system themselves, publish it on e.g. NPM and/or pull it and use it from there?
> its API was a reflection of the domain. As a developer, I want to query for a node (CSS selector, xpath, etc.) to affect change and traverse to other nodes
> So you are saying that Array.from(querySelectorAll) gets you there? What are you missing then?
Array.from adds friction. The need to wrap querySelector in null checks adds friction. The fact that they are not composable in any way, shape, or form, with any DOM methods (and that DOM methods are not composable) adds friction.
jQuery was the fore-runner of fluid interface design. Nothing in the DOM before, then, or since ever thought about it. Even the new APIs are all the same 90s Java-style method calls with awkward conversions and workarounds to do anything useful.
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
- 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).
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.
You don't need Array.from if you are using `for (const x of document.querySelectorAll(selector) { }` loops anyway or have a library like IxJS handy.
ES2025 added map, filter, flatMap, reduce, forEach, and several other methods to all iterators (including NodeList directly, I believe, but definitely its entries(), keys(), values(), if not) [1]. It'll be a year or two at current pace before that is "widely accepted baseline" in browsers, but it's great progress on these sorts of complaints.
You missed [Symbol.iterator] as a public method. I prefer the aesthetics of for/of over forEach in most cases, but it's as much personal preference as anything.
I did briefly forget the distinction between Iterable (has [Symbol.iterator]) and Iterator (the thing [Symbol.iterator]() returns). You can use the Iterator helpers "directly" on the NodeList with `someNodeList[Symbol.iterator]().map(…)` or `Iterator.from(someNodeList).map(…)`. There are advantages to that over `Array.from` but not many advantages over `someNodeList.entries().map(…)`.
(I partly forgot because I assumed MDN hadn't been updated with the new Iterator helpers, but of course it has [1], they are marked as "Baseline March 2025" [all browsers updated since March 2025 support them] and there is a lot of green in the browser compatibility tables. caniuse suggests Iterator.prototype.map is ~84% globally available.)
[Symbol.iterator] is more the for/of API (protocol, more accurately) than a DOM API. It's an improvement today that the DOM APIs pick up niceties like direct [Symbol.iterator] in addition to Iterator methods like entries().
It's nice that there is syntax sugar for [Symbol.iterator] in both for/of and also the spread operator/deconstruction/rest operator (things like [...someNodeList] and const [item1, item2, ...rest] = nodeList).
In theory, the only missing piece is syntax sugar for Iterator.from() if you wanted to direct chain any iterable to the iterator helperrs. But in practice, that's also part of why the explicit iterator methods like entries() already exist and those are surprisingly well implemented (and have been for a while), including on NodeList.
Templates are great until they need to be dynamic. Then you're right back to the current situation where frameworks like React are just the better way.
In fact, you could call JSX a "Dynamic Templating System" and that's a reasonable summary of what it is (in addition to other things of course).
There might be some ways that React itself could, internally, notice the special cases and special times where it _could_ be slightly more performant from using a lower level of templating, as an optimization, but I'd certainly prefer that to be abstracted away and buried deep inside React, rather than ever having to think about it myself, at the JSX layer.
Someone can let me know if React is already leveraging this for browsers that support it, I didn't research that.
"If I could wave my magic wand..." at least 2 of 3 of the changes I'd made about the way frontend web is developed, would be about `<template>`s:
1. Making it possible to do something like <template src="..."> and being able to load them from an external source
2. Making them "dynamic"
3 (and the most controversial one) that all CSS, HTML and Javascript (if you don't hate it) could be written natively like QML - one syntax to rule them all.
As a web dev you probably already know but #1 is slightly similar to `Web Components` but you're right we cannot load a web component right in the HTML where we use it. It makes sense though because if you use an Element in multiple places it wouldn't make sense to have 'src' in multiple places, so ultimately some kind of 'loading' at the top of the page is needed, and that's how WebComponents work, but I still like how you think.
#3 is a tricky one syntactically because HTML needs to be used by mere mortals and JS is a programming language used by us gods, so unifying all three would br tricky, but again I agree with you that would be awesome. Maybe some flavor of LISP would be both "powerful like a language" and "easy like a document".
The system described in the article is very React-like, and could be used by future versions of React. In both, functions return a description of HTML to render, which can be applied either to create new HTML or to update previously rendered HTML.
I skimmed part of it, but unless I missed some huge caveat I think you’re backwards and GP is definitely right. The article mentions React, then sort of dismisses it later saying the other two strategies are better to implement instead of diffing.
I don’t see any reason a browser level “here’s new DOM you diff and apply it” couldn't exist and be a huge win for React and other libraries, with React so much more popular than every other framework combined, and that being a pretty low level API, it makes sense to start there.
Building the overly abstracted thing first is a mistake web API authors have made too many times (see web components).
I still have hope for Web Components to take off in the figure. I'm a React dev so I don't "need" them, but they may end up being some kind of capability that React can secretly, quietly embed into React core as some kind of optimization if that ever makes sense. Web Components is a great idea, but like I said it's just not quite as convenient as React, so it's currently somewhat irrelevant at least for me.
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 inevitable that someone will want to template something that isn't well formed, but can combine into a well formed thing. And then you are stuck trying to find how to do it. (Or correlated entities on a page that are linked, but not on the same tree, as it were. Think "label" and "for" as an easy example in plain markup.)
If I could wave my magic wand, what we need is fewer attempts to make templates all fit in with the rube goldberg that is the standard document layout for markup. People will go through obscene lengths to recreate what judicious use of absolute positioning can achieve fairly well. Sure, you might have to do math to get things to fit, but why do we feel that is something that we have to force the machine to do again and again and again on the same data?
> 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 over was that it's a real DSL, and a declarative, pure, functional DSL at that. People like to talk a big game about DSLs, but inevitably they're simplistic syntactic exercises that don't actually abstract the underlying procedural semantics of popular host languages. When faced with a well-designed DSL that makes difficult tasks trivial... people can't be bothered to learn.
The thing most people never got about XSLT is that it is really about production rules -- and production rules (e.g. the major path to "expert systems") are one of the most solidly rejected technologies in software engineering.
I didn't understand this until I spent a few years going down a rabbit hole asking questions like "why don't people like production rules?" In the case of templating people expect to make a template with a top-down organization that looks like the output, whereas XSLT really wants you build transformations from the bottom-up. On some level the bottom-up part is clear, particularly if you want to code-generate your rules (towards the end I was writing production rules that write production rules) but what is not clear is how the parts all fit together: you can't visually tell between an XSLT that builds the structure you want vs one that doesn't.
I think the most fun I ever had with XSLT was when I used an XSLT engine with user-defined procedures and had them create side effects, such as matching certain patterns in an XML document and making SQL inserts, though that was a long time ago when we were still using terrible XML parsing libraries.
I’m a big fan of XHTML (strictness is good) and feel like XSLT could be a great addition, but I hate the syntax. I’d love to build a Jinja to XSLT compiler one day.
I also have a simple playground for XSLT: https://xsltbin.ale.sh/
XSLT's weaknesses are the extension of its strengths. It's the first homoiconic, purely functional language that enjoyed widespread adoption among "normal" developers, not type theory wonks.
But XML's syntax sucks, and so inevitably does XSLT's, because XSLT is just XML. Were it s-expressions, the syntax could suck slightly less. It was (is!) a small price to generate XSLT using XSLT, which makes XSLT very powerful and expressive if you hold it right, almost like a Lisp. This saved me a few times around year 2000 or so.
I wouldn't say it had widespread adoption. We used XSLT in my day job at the time to do client-side updates, even had a special SQL API that turned sql queries into XML automatically by naming the columns with a special syntax and it was virtually unheard of (2007?).
It was actually great when you got it, but the learning curve was so steep many developers couldn't use it effectively to begin with. For complex pages only certain developers could make changes or fix the bugs. Precisely because it was functional and most developers at the time really only understood imperative.
In fact, I remember the DailyWTF had a WTF about using XSLT as client-side transforms a few years later:
https://thedailywtf.com/articles/Sketchy-Skecherscom
But doing something like that was in fact so much faster than doing it in js, and when you groked it (deliberate throwback), it was so much simpler. I actually wrote a pivot table control in XSLT which completely blew away the performance of the pre-v8 javascript one. Pre-V8 javascript was so slow most developers wouldn't believe you now. A 10,000 iteration loop of even basic operations was often enough to cause IE6 to show a pop-up saying the page wasn't responding.
The pivot table in javascript would crash with just a few hundred lines of data, in XSLT it was instant with even 10,000s.
A really interesting use of XSLT on the web at the time was the WoW character viewer. You could view (and share) your character on Blizzard's website, with all their gear, skills, etc. It was blazingly fast for the time and it was all written in XSLT.
Homiconicity can get you into trouble.
CSS and HTML have a dual relationship. You could certainly write CSS with an XML-like syntax but people would always get confused at whether they are looking at style or markup. Because HTML and CSS look completely different you never have that problem.
XSLT shares the same problem with the RDF specs coming out at the same time that it hid the production rules/logical nature of the system, had it looked more like
it could have been quite different. But production rules never really sold (got told that by the marketing chief of vendor at a hotel bar after a conference they sponsored) and it's an interesting question why. They can do all kind of neat things like manage asynchronous processes that happen over a long period of time (like having a loan officer approve a loan) but nobody ever tried to use them to deal with the async comm problem in Javascript as far as I can tell.Can you generate XSLT from s-expressions though? :thinking:
I barely used xslt, but as a fp head I wanted to try, the most confusing part to me were terminology / semantics / decoupling. Seemed like matching templates could be anywhere making difficult to understand the meaning of a script.
In some sense that's a strength. When things can happen in any order you can mash together two things and they work together.
When I was looking for my own revolution in software engineering I saw one part of the low code/no code puzzle was that conventional tools force you to determine what order events happen which was something laymen shouldn't be bothered to do. Some counters are: spreadsheets (they figure out what order to calculate it), make (does a topological sort), dependency injection tools like Spring (writing a FactoryFactoryFactory isn't so bad, but maintaining it is a disaster when a "small" change means you have to reorder the order in which you construct everything)
There is a "freedom is slavery" problem here. People saw the semantic web as "you're going to exhaust yourself arguing with people about standards and ontologies before you even start coding" and not "if my data is properly namespace I can throw data from 10 different sources together into my RDF database and start writing queries".
It's sort of similar to regular pattern-matching, but sadly not built for ergonomics :(
The node pattern matching was ok, but as far as i can recall, there could be multiple matching patterns scattered in lots of places (a 180deg turn compared to most FP pattern matching that aim for exhaustiveness ?)
Exhaustiveness is only relevant for the compiler-managed pattern matching of a traditional FP type system, where you need to write an implementation (patterns that will be used at matching usage sites) for everything that your types promise.
XSLT pattern matching is the plain kind: here is a pattern, look for it in the input and process every match. If some part of the input document is ignored, it's just not useful; if some part of the input document is processed several times, it's perfectly well defined.
The problem here is runtime includes, especially the "drop source in place" style includes, coupled with dynamic dispatch at runtime. These two things in combination make static analysis of execution flow anywhere from really hard to impossible
I get it, but it's hard to track
If by "hard to track" you mean not knowing what template is producing an observed bad output, the modularity of self-contained templates and XPath expression is likely to help with debugging.
here on HN I dare to out myself as a DSSSL lover, the scheme based predecessor of xslt.
I still can't wrap my head around how the neat and clean dsssl syntax, a real programming language, was replaced by an xml notation for the same: for cuntional code and a framework. because semantically, that's what xslt is: a functional language with a framework, geared at transforming xml instances.
but that syntax... and of course a much inferior and more obscure language than scheme underneath dsssl.
Why not implement a DSSSL-to-XSLT compiler?
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 XML. This is convenient, because user interfaces are created manually. (I am not mentioning text markup, it is well known.)
Yet XML was often used as a notation for machine-to-machine exchange. For example, the ONIX book description standard. Here data are moved between two computers, yet for some reason they have to form grammatically correct phrases according to a set of grammar rules. Computers do not need grammar. They do just fine with non-grammatical data, like a set of tables. It is way simpler for them; parsing or generating grammar, even explicit, is pure overhead for data exchange and is only necessary when data enters or leaves the computed pipeline.
So, to your examples: configuration in XML is actually fine, but IPC is not. Configuration is written by hand, IPC happens between machines. IPC specification, on the other hand, is also a good fit for XML.
That said, XML and thus XSLT has another flaw: it is way too verbose and has no good way to format it. Conciseness was an explicit no-goal but now we can say it was a mistake.
I thought Tim Bray's XML spec was one of the most beautiful tech documents I'd every seen when I saw it for the first time. Adding namespaces at that point in history though was a disaster. Back then developers just weren't used to that kind of rigor (when I first started coding Java I had to go to a website run by frickin' NASA to get a clear explanation of how namespaces worked.)
It didn't help that Microsoft dropped a stick of over-complicated standards that tried to bring RPC into XML. RPC has always been a cursed concept because between (1) trying to be intellectually coherent and (2) caring about performance RPC systems become incomprehensible and it doesn't matter if it is Sun RPC, DCOM, CORBA, "Web Services", Protocol Buffers, etc.
The fact that the "REST economy" is intellectually incoherent and could care less about performance seems to have helped it succeed. Right now I just wrote a javascript function that looks like
and it does and I have a Java function on the server that looks like and is tagged with some annotations that make it get called when that GET request. Jackson lets me write an Item as an "anemic domain object" that gets turned into the exact JSON I want and the only real complaint I have is that the primitive types are anemic so representing dates is a hassle.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.)
It's been a long number of years, but XUL (Mozilla/Firefox's UI layer) combined with XSLT was an incredible stack to build entire applications.
I regularly work with APIs in shell that return XML and XSLT is a goddamn super power. I adore it.
XSLT was cool.
XML needs another syntax that isn't so verbose. Sort of like how OWL has XML, Manchester, Functional, and Turtle syntaxes for the same data structures.
XSLT needs a Turtle-style syntax.
XML in general (the data structure, not the syntax) needs a Turtle-style syntax.
Its annoying that support stopped at earlier versions, it grew so much more later.
> but languished where it shined, as a markup language with an amazing transformation capability in XSLT
I choose to look at this a little differently.
An XML application using XSLT is so much better (faster load times, faster to write, easier to make correct) than a JavaScript application with a JSON api, that XML is basically a secret weapon.
I only care enough that it stays in browsers, but otherwise I'd prefer nobody know about it because it means less competition on things that matter (faster load times, faster to write, fewer bugs, etc). And I've got a half-baked JavaScript-based "renderer" I can finish in case some Google VP asshat goes looking for things to delete...
XSLT is just not a good language. Every single attempt of making XML executables (and there were many) failed badly, always for this one good reason.
> 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.
How do you come to this conclusion? It seems to me that what you mean is a general gripe with HTML+CSS, not with how it's generated.
And why do you bring up absolute positioning?
I hear this take on HN again and again and sure, absolute positioning has its place, and is needed for many things.
But when it's used for page/app layout, most of the time I came across this it was an absolute nightmare, falling apart at the slightest content (even text!) or screen size changes.
Even print newspaper layout can't work like this, because typography is involved, although it's probably a lot closer to what I imagine you are describing.
Maybe I'm misunderstanding you.
But when I was doing more CSS-intensive work (I still do a fair bit), developing something on a basis when someone created a layout based on absolute positioning that looked like it was "almost ready", it was a terrible time sink to try to fix it and recreating it using flex, flow et al for layout (I'm not that fond of grid outside of some scenarios, and at the time I didn't use it due to browser support) was always faster because the problems with absolute positioning as the main layout tool were basically unfixable.
Maybe there are techniques using calc() and viewport units where it makes sense, but absolute positioning is not suitable for any layout outside of completely static content and viewport dimensions, in my experience.
I've been in the opposite, where people will go through lengths to try and make it so that the defaultish dom layout makes things "fall into place" so that they had a very specific layout of elements. When a fairly simple set of elements with somewhat minimal styling would get what you wanted surprisingly easy. Provided you did a lot of up front calculation on your own.
Basically, my assertion used to be to draw out what you have in mind on grid paper. Then start creating the elements. I don't see how that flow could land you with the 100ish divs that you wind up with on something like a single blue sky post.
Is it a panacea? No. Of course not. Can a constraint language help? I think so.
I'll add that the flex layouts seem like an improvement over what used to be there. Even if I find it rather amusing that we seem to have settled back on tables for layout. :D (I suppose it is more like some of the layout managers from Java days, truthfully.)
But, fundamentally, the problem appears to be that the drop to symbolic text is just not something that everyone does the same way. As such, it is very easy to get into a lot of trouble with the number of cooks in the kitchen, as it were.
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 tiny bit faster than flex centering, or avoids layout calculations when elements are added in a virtualized list.
Virtualized lists are also a good example for falling back to specifying exact pixel positions and dimensions for performance reasons, but these are usually determined with help of JS. I think the transform I saw was a translateX(-50%) one, so centering.
I totally get the canvas-like approach, but in a way the constraint-based flex layouts fall into the same line of thinking for me.
The issue with absolute positioning is the need to manually specify positions and dimensions for elements, which makes it useless unless you are working within a fixed box or only relating to the corners of one rectangle.
It is explicitly meant to remove elements from the normal layout flow so they overlap each other by default.
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 get styles such as "css-g5y9jx" and this isn't the worst examples I've seen. But I am curious on why so many nested divs seem to be needed all of the time.
I am not clear what you mean by canvas-like approach? I think folks should still use elements. Just fewer of them, all told.
Direct to my claim, though; my argument is just that templates/designs are visual things. I don't think people are thinking in terms of nested div elements. They largely don't even think of sections of their template as parent/child relationships. They have a visual thing and want it filled in with whatever data.
The badge on something is a good example for using absolute positioning exactly for what it's meant for imho.
With "canvas-like approach", I meant this part of your comment (not the web technology):
> Basically, my assertion used to be to draw out what you have in mind on grid paper.
I guess we were talking past each other because you equate templates and designs, and I didn't think of this usage of the term (the post also is not about this).
Templating is not necessarily for full pages always, that defeats the purpose of templating languages in the first place to me.
> Direct to my claim, though; my argument is just that templates/designs are visual things. I don't think people are thinking in terms of nested div elements.
Agree. And using modern CSS is a great way to reduce the number of "div"s.
> But I am curious on why so many nested divs seem to be needed all of the time.
I fought many these battles in my jobs, and often it's just for flexibility, because different components are written in a modular fashion. Minimizing the DOM tree size is my goal too, but often the version with less nesting requires a bit more thinking and breaks more easily when elements are added or changed.
CSS gris vs nesting flex containers is a great example for that.
Other times it's just laziness / people don't care.
Another poster was pointing out that this is not necessarily what is meant by templates in the post. I can see the distinction, but not really sure it changes my view. Since the post is largely more javascript literals for dom objects, it is hard for me not to bring that back to the design implications? Literally comes back to "people love JSX" many times. Why? Because it lets them get things to the presentation layer that is their browser.
I took some time to dive into how extensive JavaScript has made the word template in their world. I confess it reads a bit excessive to me. More than a bit, really. Tagged templates, in particular, look like one of the biggest foot guns I've ever seen.
I took it to design because I don't know of any other real reason to template the DOM other than for design purposes. Indeed, reading on the linked proposal, this is to make reactive things on a page. And that will have to be married to a design at some point. Often the entire point of introducing names that are exported from data to a rendered document is for the presentation implications of it. Otherwise, you'd just output the data?
I'm not sure if I can contribute anything more here.
Tagged template literals, aka "template string literals" are yet another technology adjacent to JS and HTML using the word "template". But it doesn't have much to do with the submission.
It's just a fancy name for advanced string interpolation in JS, and has no inherent connection to DOM elements or fragments.
But it is used by some technologies such as styled-components and Lit (the web component library).
styled-components is probably also where the obfuscated CSS-in-JS class names in the bluesky markup originate.
There is also a `<template>` element that is used by ShadowDOM and web components.
But nothing of that is the essence of the post, these are just things that coincidentally use the word "template" (and, less coincidentally, the concept).
As far as I see, it is about the wish to standardize declarative data-binding to DOM trees.
Basically, a React-like API built into the browser, but less detached from native rendering algorithms.
I only mentioned tagged template literals, as they were called out by the article as an unsung hero. Presumably, they are an example of what a good template language looks like. If so, they don't give me hope that we know what a good template language looks like.
The idea of the post seems to be encapsulated in the web components issue and discussion. Agreed that it looks largely about data binding to DOM trees. To paraphrase you, "seems like advanced DOM interpolation in JS." Which, I just can't bring myself to agree that this looks good. Happy to be proven wrong in time.
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.
> People will go through obscene lengths to recreate what judicious use of absolute positioning can achieve fairly well
the web has the requirement that the 'document' look good no matter what device size/dimension, orientation, and/or capability.
In regular apps (say, a windows app), you don't have this requirement. In mobile apps, there's a standardized set of sizes. Only on web do we have both!
Not really? People impose the idea that they can make this work. Yet no sites looked good on the Nintendo DS browser, and people were largely ok with that. Few sites look genuinely good on phones. People are largely ok with that.
The Nintendo DS browser was not good enough to use as a daily driver. My phone, on the other hand, I spend more time browsing on that than I do my computer. Some sites aren't great on it, but the vast majority are fine (reader mode will get you through 99% of the rest). I'd argue most sites don't "look good" on any device. It's really not that hard these days to make a site work on mobile, the navbar often is the most challenging part of it.
I'd also argue that there are only superficial similarities between, say, React and Svelte. Yes, they both have a syntax based heavily on HTML, but they work very differently. React is the only major framework that works by having (mostly) normal JavaScript functions return lazy representations of markup (in the form of JSX). React has no template-level notion of looping or conditional rendering, because you use normal JavaScript for that.
> 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 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).
It's good when someone advocates for what they believe to be progress on the web platform, but it's not necessarily clear that this would be progress. And that line in particularly is amusing because we absolutely don't know what good syntax for templating looks like — that's why there's so many different options.
JSX is certainly the most popular because it's used in the most popular framework, but it has some very clear weaknesses. In particular, it has very clear semantics for a React-like, VDOM-based framework, but those semantics do not work as well for other kinds of framework.
For example, you mention control flow via ternaries/`.map`. This works great in React, where the entire template will be reevaluated every time any input changes. However, frameworks like SolidJS or Vue in Vapor mode work very differently, and typically evaluate JSX only once at component mount (or at least, as seldom as possible). To support these, these frameworks need to use either special components like `For`/`Show`, or directives like `v-if`.
There's also the issue of how to evaluate JSX. In theory, JSX is flexible, in that `<Cpt prop={expr} />` can be converted to any call of the form `h(Cpt, {prop: expr})`. Again, that's not true for SolidJS or Vapor mode Vue — in both of these frameworks, `expr` cannot be eagerly evaluated, so the traditional transforms just don't work. Both of these frameworks therefore have to include their own custom plugins for handling JSX correctly.
The author's suggestion to also use signals as a state mechanism suggests they're imagining something more along the lines of SolidJS. That's an odd choice (it's my personal go-to framework, but it's also very niche), but it also implies, as discussed, that JSX-in-the-browser wouldn't behave like JSX-in-React. From experience, that will cause problems! I've worked with React developers before who've really struggled to use SolidJS because of precisely this issue.
> 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:
Svelte uses text-based templates like this: Angular uses markup-based templates like this: 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: 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.> 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.
I'm the last person to vouch for React and the horrors it has inflicted upon web development, but the one thing it definitely got right compared to Angular (and Vue) is the use of JS for control flow, rather than fake attributes and whole new language.
JSX is as much a new language as Vue’s templating. JSX extends JavaScript syntax; Vue extends HTML syntax.
If you’re working on generating markup, it makes more sense to do that at the markup level than constantly switch between markup and imperative JavaScript.
It might use JavaScript for control flow, but does it really count when it uses it in a way that is not idiomatic at all? It’s not idiomatic JavaScript to use map instead of for everywhere, and it’s not idiomatic JavaScript to use ternaries instead of if everywhere. Writing JSX looks very different to writing normal JavaScript.
The difference is that JSX is using control flow from an actual programming language, whereas Vue is shoehorning control flow into declarative markup. This is the single reason React won the frontend framework market: they got the templating right.
PS: in modern JavaScript, using map rather than for loops is more idiomatic!
> This is the single reason React won the frontend framework market
Don’t be silly, the front-end landscape is a lot richer than you make it out to be. React hasn’t “won”, the last time there was a clear winner in front-end, it was jQuery.
> PS: in modern JavaScript, using map rather than for loops is more idiomatic!
No, it’s not, and this is exactly what I was talking about. for loops and map() serve distinct purposes.
for iterates through a series of elements.
map() transforms a series of elements.
It’s possible to use them both for the same things, but there is a very clear semantic difference between them. One doesn’t replace the other, they mean different things.
In the context of “I have a bunch of elements I want to iterate over and output”, what you want is a for loop. The reason why React devs have been convinced map() replaces for loops is that React has to force you into making everything an expression, so instead of writing for when it’s appropriate and map() when it’s appropriate, they have to write map() everywhere.
It’s good you ended on the one thing JSX got right: everything is an expression. It’s that simple. There’s nothing imperative about evaluating a template, it’s entirely covered by functional programming techniques. You’re just producing a value.
And yes, modern JavaScript uses tons of concept from functional programming, where it is understood that mutating values and triggering side effects should be a last resort. This is why a good js programmer uses ten times more maps then he uses for loops.
Maybe you don’t know how dominant React is today? Two third of JavaScript developers use React at work (https://2024.stateofjs.com/en-US/libraries/front-end-framewo...).
It feels like you’re out of touch, have you used JavaScript lately?
> mutating values and triggering side effects should be a last resort.
Output is a side-effect.
> This is why a good js programmer uses ten times more maps then he uses for loops.
This is a) massively overstating things, and b) not relevant to a case where zero for loops can be used.
> Maybe you don’t know how dominant React is today? Two third of JavaScript developers use React at work
I checked those figures before I posted that comment to double-check my memory. Two thirds is not anywhere close to “React won the market”. Android has ~72% global market share, but I’m sure you wouldn’t say that Android has won the smartphone market.
> It feels like you’re out of touch, have you used JavaScript lately?
We disagree, that doesn’t mean I’m out of touch. Try not to be so insulting.
It’s not an insult, if you think for loops are commonplace in modern JavaScript and React isn’t the dominant frontend framework by far (twice more used than the next in line, vue), you’re out of touch, it’s just a statement.
How can you not realize that producing a string or a tree of elements is a purely functional operation? There’s no side effect here. Are you familiar with the concepts of functional programming?
You are being insulting because every time we disagree, you ignore half of what I am saying to assume I don’t know what I am talking about. Two informed people can disagree but you don’t seem to get that. A conversation is not a competition where one person gets to prove the other person is ignorant.
Take “React winning”. We disagree that React won because I don’t think 66% of a market is “won”. But you jumped to the conclusion that I just didn’t know what I was talking about. Then I clarified that the difference in our opinion is not the knowledge of the market share but our judgment of it, and I gave the example of Android not having “won” the smartphone market with ~72% of the market… and you just ignored that and doubled down on calling me out of touch.
Take the use of map(). I am very clearly distinguishing between common usage and defined semantics. The gap between the two was what I was complaining about. But you ignored what I was saying and decided that I don’t know map() is used a lot in modern JavaScript, when that was the core of my complaint!
And for functional programming techniques, we disagree in how we think about the operation. You see it as data processing, I see it as I/O. I very specifically pointed out that I/O is a side-effect. This is a mainstream viewpoint in functional programming. But you ignored what we actually disagree about and assumed it’s just because I don’t know anything about functional programming.
Your approach to disagreeing with me is to ignore half the things I say so that you can attack me for being clueless. You need to do better.
I still think you’re misunderstanding what React is optimizing for. When you say "React has to force you into making everything an expression", you’re describing its core philosophy, not a constraint. JSX is built around the idea that rendering is just data transformation. It's UI as a function of state. That’s why using map() is idiomatic here. You’re building trees, not iterating imperatively.
Also, it bears repeating that React isn’t just slightly dominant. 82% of JS developers have used it according to the 2024 State of JS survey, and for good reason. It shaped the modern frontend mindset in a way that Vue or Angular haven’t, despite their own merits. For instance, many frameworks came up with their own version of hooks. It's telling that most new frontend frameworks are aiming for the "better React" position.
I realize we just have different interpretations of what "winning" means in a fragmented ecosystem, but it’s worth acknowledging how much React has set the tone for modern web development. UI as a function of state (and using map() a lot...) is here to stay.
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 can already guess most would consider it a fault to manually place either of those on the page. Yes, the sheet has a limitation on how big your name can be. No, you can't really avoid that.
JSX is what happens when you no longer have a design and a dev team. It is great at that, even. But if you have a workflow where a designer makes a template and sends it over to a dev, it no longer really helps. You are much better off making something that can pick at artifacts that are handed off.
Instead, we seem to be aiming for an idea that will have to replace learning of everyone involved.
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.
We don't know what good syntax for templating looks like because HTML is complex enough and many have tried making it more complex with things like Blade for PHP or HTMX for example. For some reason I've always preferred JS to HTML. React components with JSX is a good balance. Not everyone agrees but that's OK.
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.
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?
At the time, this was good:
It might not hold up to today's standards, but "good" isn't a constant.So, no? You don't have any examples by which to demonstrate what a good templating language is?
You seem to have gone on a tangent that "good" is a general topic in my question. I meant do we have specifically good examples of templates. Surely if we know what good templating syntax is, we can share examples of it? Even if you can't describe it directly.
I provided a good template language, at least given what was good at the time it was introduced. As good is necessarily a moving target, one can never really satisfy your request as by the time the submission has round-tripped it is quite possible that what is good has already been redefined.
So, yes, I understand you are trying to call attention to my 'loosey-goosey' usage earlier. But I am saying that when I said "good", it was relative to the temporal position it found itself in.
Then take my question as, "then what is a good templating example today?"
Dodging the obvious question in favor of discussing if we can make progress... feels less than good faith.
I still consider the templating language I shared before, even at the time of this comment, to be good.
But, as recognized earlier, others may find it doesn't hold up to today's standards. "Good" is not only not a constant, but is also subjective. Do I really have to explain the entire universe here? Man.
You didn't share a templating language, though? You shared an example of a formatting/templating string, but didn't even indicate what level of format string it supported. Such that I don't know if you are sharing C's printf, bash's printf, PHP's... I can presume you don't intend to include CL's FORMAT. Even if I do have a softspot for it, myself.
> You shared an example of a formatting/templating string
Which is, you guessed it, a language! Okay, yeah, I didn't dive in so deep as to provide a formal specification for the language, or whatever it is you were hoping for, but if you really want to take this to silly town, I'm going to tell you that what you saw is the only valid input for this language and only specify that, so, maybe, unless you are having fun with this comedy routine (in which case, carry on; I'm certainly still entertained!), you can read between the lines? The question asking if I need to explain the universe was rhetorical, implying that I am not going to do that.
My question to you, then, is if you think you contributed anything at all to this? Because, yeah, nothing there.
Yes, it contributed to my enjoyment. I mean, that is all that can be contributed, fundamentally, so...
> Hard not to laugh out loud at "We know what good syntax for templating looks like." We don't.
The article fails to accept that performance and security aren’t addressed by vanity layers. This is a mistake repeated by web technologies when popular demand eventually crushes common sense, because hiring is more important than training/maintenance when the lowest levels of the work force can’t tell the difference and drives all design decisions.
If you want better performance or security you have to measure things, not wear a pretty dress and look the other way.
A basic lesson we've learned over and over is that API/ABIs aren't final. Application needs are never permanently fulfilled by a stable API, with all future problems considered to be app-level issues.
This proposal is a good example of how common issues with the platform are solved on top (React etc.) until we recognize them as a problem and then push them down. Polyfills are another example.
If a proposal like this succeeds, it lives a time in the sun, but then spends most of its useful life being the old thing that people are trying to work around, just like the DOM API, just like ECMA versions, just like old browsers, just like every other useful bit of tech that is part of the system but can't be touched.
Is it possible to think about entropy, extension and backcompat as primary use cases?
It's also the case that every feature in web standards means extra code that needs to be painstakingly maintained, and extra code that anyone trying to create a standards-compliant browser must implement. I want to see projects like https://servo.org/ actually have a chance to catch up over time, not always be chasing an expanding scope.
I want the web platform to have every possible capability that native platforms have (subject to privacy and sandboxing constraints, of course). And I want the developer experience of web developers to be incredible.
But these need to be balanced against the consequences of added complexity. And in this case, does native templating really improve developer experience? I'm not convinced the benefits outweigh the costs.
> A basic lesson we've learned over and over is that API/ABIs aren't final
I dunno --- getElementById has been stable for, what, 25 years? "There's no such thing as a stable API" is something said by people unable or unwilling to create interfaces that last. It's a statement of personal resignation, not cosmic impossibility. There are tons of counterexamples.
Application needs, like other needs, are infinite. You satisfy these needs by adding new APIs, not breaking working ones.
I think you'll find that even the most unstable APIs have extremely stable parts to them.
At the same time I don't think there is actually anything that most people would consider an API that is open to public usage that has maintained that kind of stability that getElementById has, which after all is something most people would describe as a method of an API.
> A basic lesson we've learned over and over is that API/ABIs aren't final.
On the web they are. Once something is out in the open on the web, there will be people depending on this, in this exact form, forever.
That's why there are still APIs that end up in "smooshgate" because of decisions from 20 years ago: https://developer.chrome.com/blog/smooshgate
> spends most of its useful life being the old thing that people are trying to work around
But in the process, the base functionality has been propped up another level.
Incremental updates aren't worthwhile just because of userland requirements that will always discover new gaps, use-cases and blindspots.
Isn't that why you have versions and maintains backward compatibility with older versions, and don't change the "old" interfaces?
The web really needs native templating, reactivity, and data binding.
I can't even begin to imagine how much CPU and bandwidth is wasted with billions of users downloading, parsing, and executing something like React.
That's alright now LLM and crypto make this waste seem minuscule
With the TC39 signals proposal, part of that is making progress.
Except React.....
Was react ever about progress?
If you valued your sanity when developing complex Web UIs, React was a lifesaver.
DOM sucks though, it's slow, it's heavyweight, it lacks transactions. We're stuck with it, and frameworks like React have to do the DOM diffing + patching thing, explicitly, in JS.
Nah.
https://svelte.dev/blog/virtual-dom-is-pure-overhead
https://news.ycombinator.com/item?id=43971164
React appeared in 2013, Svelte, in 2016. Three years is a lot. What comes next can see and avoid some pitfalls of earlier designs.
1. I'm referring to the comment that the DOM is slow/bad. It is not. Moreover, VDOM is ON TOP OF the DOM.
2. We're currently living in 2025. React (and SPAs) is not even slightly necessary.
React was a solution to a ten years ago problem
You can downvote it but it doesn’t make it any less true
Alex Russell has written swathes of arguments about Reacts performance issues https://infrequently.org/2024/11/if-not-react-then-what/
The DOM has become much faster since React started over a decade ago, the VDOM really isn’t needed anymore even for app like experiences
React is about developer preference over user experience
Agree that react isn’t the best implementation of the concept, both in terms of ergonomics and efficiency. But a react-like framework is still very much needed to create complex apps in the browser. So IMHO react is a solution to a very current problem, only not an ideal one.
if (when?) Signals become a standard, React will be in a tight corner if they decide to ignore them
Not really? `useSignal` is just another hook React needs as a replacement/augment for `useState` and maybe `useEffect`. Signals aren't that special. Arguably that's part of why a lot of people like Signals as a proposal.
(I'm still of the sort that thinks Signals are just worse Observables, so it's not a proposal I'm particularly thrilled about, but were it to be adopted Signals are easy to use in Observable contexts as well, they are just uglier half-implemented BehaviorSubjects, though maybe with a few extra lint rules to prefer Observable behaviors over Signal ones.)
Two way data binding and a jsx clone is kind of all anyone really needs.
React isn’t templating though.
That's kind of like saying React isn't just a bunch of a functions (it is). What do the JSX templates compile down to?
Respect for focusing on semantics but not contesting the CPU and bandwidth waste. That takes honesty.
[dead]
The part about Signals is telling and illustrates well why the idea while laudable is practically unfeasible.
I get why OP likes signals. In every large enough project there is a half baked implementation of a DAG calc tree and it makes sense that a language could standardize one.
But these abstractions have a huge mental / implementation cost.
The problem, as with most engineering things is a tradeoff problem. The react model - where you just update the global state and re-render everything - is slower but easier on the brain. The signals model is faster, but so much effort.
Most apps out there don’t need to be crazy fast, and people will choose react because it’s just simpler.
But signals don’t really have anything to do with templating, do they? So why do we have to choose, could we have templating and signals as separate things?
Well OP thought about templating and realized you do need a way to tell the dom how to fit your templated node where it belongs and update it when things change.
And this is where these proposals fail. There needs to be a choice here. The API must pick a side (well technically it could allow for both, but ugh), and developers won’t ever agree which side it should go.
The big problem of UIs has always been how they update, not how they’re defined. Microsoft tried (and failed) at defining a ton of models, MVC, MVP, MVVM, and what not, all of them were painful AF. Then imgui come and say, well what if UIs didn’t have state at all. Ooh this is nice, but kind of hard on the cpu, so what do we do?
Well, perhaps one of the biggest reason for the success of web apps is in fact that the dom didn’t impose a way to bind data to its view. And so we may be doomed to framework hell.
> The react model - where you just update the global state and re-render everything - is slower but easier on the brain. The signals model is faster, but so much effort.
there are multiple frameworks now that do fine-grained diffing without relying on signals, proxies, or any other reactive primitives. they basically have the top-down react model but much faster and without the weird concepts like hooks and manual/wasteful dependency arrays.
my favorite one is ivi-js: https://github.com/localvoid/ivi
it's just 8% slower than the fastest / ugliest / imperative / unmaintainable vanilla js you can eventually arrive at if all you care about is winning benchmarks.
https://krausest.github.io/js-framework-benchmark/2025/table...
Just want to add that even though ivi is using tagged templates, I am strongly against using tagged templates to describe UIs as a Web Standard.
One of the most useful features that could make a lot of incremental computation problems easier is "value types"[1], but unfortunately it seems that isn't going to happen anytime soon. The biggest constraint when developing an efficient UI framework with good DX is JavaScript. Also, it would be nice to have `Node.prototype.insertAfter()` :)
1. https://github.com/tc39/proposal-record-tuple
> The biggest constraint when developing an efficient UI framework with good DX is JavaScript.
for perf, s/JavaScript/DOM, i think.
good DX comes from ecosystem and amount of time invested in making good tooling. JSX would be a non-starter without IDEs helping autocomplete, linting/format, syntax coloring, and webpack/babel to do the compilation.
tagged templates could reach at least the same level of DX as JSX if the community invested the resources to make that better. i'm not saying it's the right solution for a standard, but it would be way better than jsx, since tagged templates are already a standard.
I would prefer a more expressive language like Kotlin[1] that makes it easier to work with many different domains instead of JSX hacks :)
1. https://developer.android.com/develop/ui/compose/kotlin
> JSX would be a non-starter without IDEs helping autocomplete, linting/format, syntax coloring, and webpack/babel to do the compilation.
and then you immediately go on to say this:
> tagged templates could reach at least the same level of DX as JSX if the community invested the resources to make that better.
So, tagged templates are also non-starters without IDEs helping autocomplete, linting/format, syntax coloring.
> i'm not saying it's the right solution for a standard, but it would be way better than jsx, since tagged templates are already a standard.
They are strings. There's no magic in tagged templates that somehow make them immediately better for some custom non-standard syntax compared to JSX.
You can't just plop a string containing lit's custom non-standard syntax into an IDE (or a browser) and expect it to just work because "it's tagged templates are standard".
For the purpose of templating in the browser there's literally no difference between standardizing a custom syntax based with JSX or tagged templates.
> There's no magic in tagged templates that somehow make them immediately better for some custom non-standard syntax compared to JSX.
they're marginally better since they have a platform-defined way to deliniate static from dynamic parts. ivi _can_ work without a runtime or build-time JS parser, while JSX cannot (because jsx has to be parsed out of full blobs of js)
on the dx/ide side, sure there's not a huge amount of difference if both had the same effort invested.
In the context of "let's create a native templating syntax for the browser" those differences between JSX and tagged templates don't matter. You still need something that the browser needs to parse and understand, you still need something for libs/frameworks to handle/understand/compile to.
My feeling is that tagged templates would actually be a worse fit in this scenario because now you would have to distinguish between "regular" tagged templates and "templating" tag templates.
If I understand it correctly, the main argument in favor of tagged templates is that it doesn't require any changes to the js engine and that is why it will be way much easier to push forward. Browser implementation should be quite straightforward and it will be possible to implement a semi-efficient polyfill.
Personally, I don't think that it will have any significant impact, everyone will continue using React,Vue,Svelte and it is highly unlikely that they are going to adapt this new API.
that's a better distillation :)
> Microsoft tried (and failed) at defining a ton of models, MVC, MVP, MVVM, and what not,
Microsoft used those at various times, but the only one it defined was MVVM.
MVC was Xerox PARC, MVP was Taligent.
> The react model - where you just update the global state and re-render everything - is slower but easier on the brain.
I would gladly take easier on our hardware, bandwidth and planet even if a bit harder on the developers' brains. (as a developer).
> Most apps out there don’t need to be crazy fast
I wish we recognized that we need apps to be lean.
> and people will choose react because it’s just simpler.
I think you are right, and I dislike React for this.
Instead of adopting JSX, I would really like the syntax for this to be more like the way Kotlin uses receivers and builders to provide a generalized syntax for DSLs that happens to be good for describing component hierarchies. It would be broadly useful far beyond just HTML templating, it would also be great for expressing configurations and all kinds of other things.
The actual semantics for templating and data binding could just be a set of standard functions that use those syntactic feature, much like what you see in Jetpack Compose.
You don't even need much: loops, conditionals on attributes, and conditionals on nodes.
In fact, we could have that cross-language.
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 declarative ways for this 15 years ago
> wrecklessly
<pedantic>
It's "recklessly". "reck" is a very old word meaning "to care, heed, have a mind, be concerned about"; so "reckless" means "without taking heed".
I actually thought it was directly related to "reckon" (meaning "to think or calculate"), but when I looked it up it turned out not to be the case (except much further back in the etymological tree).
</pedantic>
As I get older my brain and my fingers get more and more divorced from each other :)
My brain knows it "reckless", my fingers type "wreckless". Same happens to a few other words, too.
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 browser vendors’ lives easier, not web developers. That’s often excused with “web components excel at ‘leaf‘ components” when what is actually meant is “web components are bad at everything else”.
I would expect an actually good solution that fits in with the web’s architecture to come from the direction of HTMX, not web components.
> Safari argued that there should be a declarative ways for this 15 years ago
True, but they were equally able to propose and deploy alternative solutions and mostly just went along with web components (with exceptions of course).
> True, but they were equally able to propose and deploy alternative solutions and mostly just went along with web components (with exceptions of course).
Safari doesn't have as many engineers (a shame) and definitely doesn't have as many people whose apparent job is just to sit on standards committees and generate specs (like Alex Russel, Justin Fangnani etc.).
They did end up proposing declarative template instantiation in 2017: https://github.com/WICG/webcomponents/blob/gh-pages/proposal... but that mostly went nowhere
That looks interesting – certainly a lot simpler and closer to web developers’ needs than what ended up getting standardised.
It really is a shame Apple don’t invest more in WebKit and the web standards process. Although they’ve been doing a lot better over the past few years.
It should have been possible to declare and use simple web-components - which use a template and a CSS class - without any Javascript.
You can with DSD.
You can’t. At minimum you need to call customElements.define().
You absolutely can. It's the primary purpose of the DSD (Declarative Shadow DOM), one of the many new specifications people complain incessantly about.
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.
You mean other than the 20+ web specs they added to platform (often to "fix" problems that they themselves introduced and/or that no one else has)? https://w3c.github.io/webcomponents-cg/2022.html (this list appeared after half a dozen or more specs had already been rammed through)
Or that their mere existence infects nearly every spec in existence delaying and needlessly complicating actual useful specs like Scoped CSS?
I don't think it's surprising that a feature like web components would require new specs, isn't that how standard web features work?
Usually a new feature:
- doesn't require 20+ web specs
- doesn't forget and then scramble to fix the most basic expected functionality like form participation
- doesn't pollute the space so badly that actual useful specs like Scoped CSS are delayed for years because now they have to deal with all the web coponent shenanigans
- hopefully doesn't take 15 years to barely do what others have been doing since time immemorial
Let’s take this example:
First off, what’s with the pointless JavaScript? There’s no need for imperative code here. All web components have a dash in the name; this can be inferred. But even if you want it to be explicit, this could be done with markup not imperative code. But no, it doesn’t work without the pointless JavaScript ritual.Now, I’ve noticed that since the text is a caption for the image, I should actually use <figure> and <figcaption>. So let’s do that:
Wait a sec! The nice round corners on the image have turned into ugly square ones. Why is that?It’s because web components can’t style anything other than their direct children. You can style the <img> when it’s a direct child of the web component, but as soon as you need anything more complex than an entirely flat hierarchy, you run into problems. Even if it’s something as simple as wrapping an <img> in a <figure> to associate it with a <figcaption>.
What’s the “official” way of getting things like this done when you bring it up with the people working on the specs? Make a custom property to fake the real one and then set a global style that listens to the fake property to set it on the real one:
Now let’s say I want to put a second <cool-dog> element on the page. What does that look like? You define the template once and then just use <cool-dog> a bunch of times? That would be the obvious thing to do, right? Since it’s a template?Nope. Every instance of the web component needs its own <template>. The best you can do is write some JavaScript to copy the template into each one.
The developer ergonomics of this stuff is terrible. It’s full of weird limitations and footguns.
> First off, what’s with the pointless JavaScript? There’s no need for imperative code here.
Exactly, I'm not sure why you've included the JS. The whole point of the Declarative Shadow DOM is to create shadow roots declaratively, rather than imperatively. To quote web.dev "This gives us the benefits of Shadow DOM's encapsulation and slot projection in static HTML. No JavaScript is needed to produce the entire tree, including the Shadow Root." [1]
[1] https://web.dev/articles/declarative-shadow-dom#how_to_build....
> The whole point of the Declarative Shadow DOM is to create shadow roots declaratively, rather than imperatively.
It's a pipe dream that doesn't work in practice. Because on its own declarative shadow dom is useless.
You clearly have an axe to grind, and I'm not particularly interested in proselytizing. If you don't find the Declarative Shadow DOM useful, that's fine!
The example I was responding to was using the Declarative Shadow DOM. My comment was intended to point out the simple fact that the imperative component definition the author was complaining about is superfluous, meaning you can safely remove that entire script from the example.
I'm so fascinated by the few people online who show up to anything web component related just to flame and complain. It's always the same things too.
DSD is useful for SSRing web components, which allows them to render and work without JS. But honestly, I don't get the obsession with doing stuff without JS, it's part of the html/css/js trifecta.
What were these 20 new specs?
After multiple specs had already been pushed through, they finally decided to write down a list of what is still needed.
22 items: https://w3c.github.io/webcomponents-cg/2022.html
In those things like ARIA are not a single spec. It's now close to five different proposals and a huge ARIA Object Model proposal.
Similar thing with Form Associated Controls: it's not one spec. It's a bunch of specs fixing idiotic issues like this: https://github.com/WICG/webcomponents/issues/814
Note: easily half of these only exist because of web components and for web components. Literally nothing else has these issues.
Right but what were these required specs for the existing implementation?
I couldn't parse your question
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 handle that, but this starts to break down really quickly when you share mutable state between components.
I think part of this is React folks think its a cardinal sin to invoke the dom apis directly. Sometimes it's just fine to capture a ref (and dare I say, query a component by a id) and do the work directly. In fact this is what most libraries that are "fast" and low-rerenders do (like the form ones).
I don’t like React but I disagree with this sentiment. First of all you can already opt out of declarative DOM and knock yourself out with innerHTML and ref.
Second, what can you do with imperative control of the DOM that is less practical with the declarative one? I can only think of certain methods (attachShadow(), showModal()) but even then you're a 10-line component away from making it declarative.
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.
> 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 with signals. I don’t think userland exploration of this space has entirely finished, and further innovation may be possible.
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.
I 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.
The article does link to the DOM part proposal, which would be one useful low-level API. It wouldn't work so well for VDOM-based frameworks, but for other frameworks it could simplify how they work and provide additional room for optimisations. It would also be useful for projects without a framework, particularly if the signals proposal was also adopted.
> If the Records and Tuples proposal were progressing, JSX could maybe create Records with boxes, but that proposal has been stalled, especially on the record identity and box parts that would make it suitable for a JSX semantics.
That proposal hasn’t just stalled, it’s been withdrawn. https://github.com/tc39/proposal-record-tuple/issues/394
It has been replaced by https://github.com/tc39/proposal-composites
I would argue that the proliferation of frontend frameworks is evidence is that we -don't- know what the optimal abstraction is for building frontend applications. We're all still trying to figure that out.
Just look at what happened with Web Components. It didn't take over or become the foundation of everyone's software. It just became yet another competitor [0].
I wish the standards committees would focus their efforts on improving JavaScript the language. That has a much greater and more lasting return on investment.
[0]: https://xkcd.com/927/
Is there really a proliferation? At this point it’s 90% React.
I would love to see Web platform become more similar to JVM or .NET CLR - just a bytecode JIT with access to rich layout/rendering engine. Then build whatever you want on top of it.
DOM + CSS is a hugely rich layout / rendering engine. The problem is that it's heavyweight.
This is exactly the kind of high-level feature we need to stop putting standardisation efforts towards, and focus instead on low-level features that provide value for high-level user land abstractions.
There is no value this provides over making a tagged template function and exposing it as a library. If that library is stable with ubiquitous adoption for 5-10 years then maybe there's something to talk about.
The author was a core contributor of Google's Lit project: https://github.com/lit/lit
Lit my beloved
God I love lithtml’s tagged template literals so much more than react’s JSX or Vue’s 3-in-one thing. It’s just html, in strings, in JavaScript. Lit is just a way to make custom elements easier. Man it’s gonna suck when I have to move on from my current gig and get my hands dirty with react again.
> It’s just html, in strings, in JavaScript.
It's not. It's a custom HTML-like syntax with lots of custom and weird rules.
Yep, `lit` is contaminating the browser API with their ideas just because their group of people writes the code for the browsers. They should be competing from the outside. Instead of pushing this kind of apis that only fit their mental models.
It’s similar enough to html that anybody familiar with html and JS can pick it up. Quirks it has, but I like that using it mostly just feels like building a huge html string.
> It’s similar enough to html that
"Similar enough" is a far cry from "It’s just html, in strings, in JavaScript"
> anybody familiar with html and JS can pick it up
Just like JSX. But no one calls JSX "just HTML" (and in React, with rules of hooks, it's no longer "just JS"). In Solid JSX returns actual DOM nodes btw.
> it mostly just feels like building a huge html string.
Because that's what you essentially do. lit runtime parses your custom string, converts it to proper HTML, concatenates that into a string, and then dumps into the document with innerHTML (it does set up data bindings etc. , so it's more than just thay of course)
I don't quite understand. The DOM is/needs a functional API. Why bolt another DSL on top?
Now you have to find a way for javascript to interact with your template language.
While functions are sufficient. That doesn't look like orthogonal language design.
> I don't quite understand. The DOM is/needs a functional API. Why bolt another DSL on top?
There are no parts of DOM APIs that are functional. It's all 90s-era Java OOP-style.
functional in the sense that it uses method calls on objects and javascript has higher order functions. It is a spectrum. I know DOM nodes are objects that use inheritance but I also know javascript is not deemed a "traditional" functional PL of course.
Javascript being a decent functional language does not make DOM API functional.
DOM API is 90-s era OOP
People want this because JSX is all they are capable of.
One reason why things like this have never happened before is because the people who need this are only barely capable of working with HTML. The DOM supports a wide variety of technologies far outside and unrelated to HTML.
There is still innovation happening in frameworks. I do wonder if it is too early to start adding things like this to the browser. Web components landed way too early and now we’re stuck with them.
> There's no fundamental templating knowledge that's portable between stacks, and native DOM creation APIs like innerHTML are unsafe by default.
setHTML() is already implemented in Chrome/Edge and Firefox so this point is a bit outdated - there is a safe alternative to innerHTML.
MDN and caniuse say otherwise. I think there might've been an older specification that got implemented, but it's been revised since
Chrome implemented a prototype, then the spec changed and they removed it, then they implemented the new version. I should have been clearer and said Chrome Canary and Firefox Nightly. Not sure when it will reach stable but probably some point this year, they’ve been working on it for ages and Safari is onboard.
What exactly is the problem with having the higher levels of web development supported through libraries (React, Vue etc) rather than directly in the browser? Why does this need to happen?
FTA, which I agree with:
> Developers need to reach for a library, and thus tools like npm or a CDN, to do many basic things. This adds to the overhead of getting started. It makes simple static files and devtools less useful than they could be. There's no fundamental templating knowledge that's portable between stacks, and native DOM creation APIs like innerHTML are unsafe by default.
Remember when you could just drag an html file into your browser, and it would work? No build step, no package install, no web server, just vanilla html+css+javascript?
It would be nice to get to do that again, and the more we move things like .querySelector out of libraries like jQuery and into native browser APIs the better, imo.
That should ideally be the highest calling of frameworks like Lit and packages like Lodash - to be so good that they prove indispensable, and ultimately go native.
> It would be nice to get to do that again
The answer to this is both "never gonna happen" and "you already can."
You already can ship a React app in pure JS and even import modules via ESM in the browser from CDN. Performance will suck but you can.
You'll never be able to actually have a complex web app that you can just drag into the browser. As the base API expands, so do the ambitions.
Heck we've had PHP 4 years after HTML just to fill in some blanks, people will always want more than static code.
I miss mozilla's XUL language (and XBL!), those were awesome.
Seems like a comment comes up about XUL every few years and I can't help but be sniped by it. A xulrunner app was my first job out of college in '08, good memories, fun dev environment!
My company, me as a solo dev, back in 2003-04 built a "single page app" using XUL and iframes. Still has some 200 monthly users, the poor bastards. They have to download Firefox 3.6 iirc, and it only works in an 800x600 window.
XUL was beastly back then though.
> Still has some 200 monthly users, the poor bastards. They have to download Firefox 3.6 iirc, and it only works in an 800x600 window.
Out of curiosity, what does that app do to convince people to jump through such hoops? Would you mind sending a link to it?
It's a full management app for recruiting companies.
There are still 3 companies that use it (since 2008), so their employees don't have a choice really. The app does a lot, so to stop using it the companies would need to hire and migrate to 3-4 other services. I reckon SAP and the kind could do everything as well, but these companies are too small for that.
There isn't a website or anything anymore for me to show, and I haven't been involved in it for over 10 years.
Quite common, lots of old software that is custom written lives on, be it java apps, old vb stuff, etc
there-is-only-XUL
There is no data!
https://www.mozilla.org/keymaster/gatekeeper/there.is.only.x...
Good old time.
> React doesn't provide a way to explicitly bind to properties and events of DOM elements, or provide directives that apply to an element.
I didn't understand this part, can anyone shed light? What is different between what's being described here and what React does with event listeners, etc?
I think this is referring to the fact that React uses synthetic event listeners - it's cheaper to bind an event listener once at the root and do your own element matching than it is to continuously bind and unbind listeners.
https://react.dev/reference/react-dom/components/common#reac...
> React doesn't provide a way to explicitly bind to properties and events of DOM elements
We can nitpick this point because react has had a ref API for at least 5 years now. Given a ref, all DOM API are available. For events, SyntheticEvent will refer to a native event if it exists.
The SyntheticEvent abstracts vendor discrepancy. Under the hood, react can apply some optimization too.
https://legacy.reactjs.org/docs/events.html https://react.dev/reference/react-dom/components/common#reac...
The synthetic event also adds its own abstractions though. For example, the `onChange` handler in React behaves very differently to the native DOM `change` event.
And then some. Switching to react-native or other render targets can also be a doozy. Hopefully the references clarify all the features.
Yes, it's weird that Browsers were so fast to ship CSP rules to prevent XSS attacks by limiting the use of inline scripts but so slow to ship a templating mechanism which would largely solve the problem.
It's like creating regulations which require a specific solution before that solution exists.
> There are in-flight proposals for very low-level DOM update primitives, like DOM Parts, which target framework implementations, but I think higher-level APIs like full declarative templating can take even more load off, help prove out and complete the lower-level API proposals, and be really impactful for developers and users.
There is an alternative suggestion to DOM parts which might be a better bet: https://github.com/whatwg/dom/issues/736
no point pushing declarative sugar again into a system that's already kinda moved on. native templating not fixing real pain = state sync, fine grained reactivity, perf edge cases. we might need a browser level primitives that let lib authors build better abstractions without the payload tax. we maynot need another xsl reboot
The web platform is over bloated. The proper solution would be a minimum set of APIs and set of reusable by many sites JS/Wasm libraries.
For example, most of Web Audio (thing like filters and oscillators except for actually sending audio to audio card) could be implemented in Wasm making a browser simpler and not allowing to use it for fingerprinting. Also, base64 encoding/decoding, URL handling function, most of canvas code etc. Imagine how less work for browser developer it would be.
I think web needs an “actually standard” library. Something that vendors could ship with browsers but could be also updated to higher version of a site requires it (and cached forever).
That would allow us to not download a bunch of code every time.
Nit: The post keeps referring to "standard JSX" as though trying to will such a thing into existence.
I thought one of the main points the article is making about JSX is that it currently isn’t standardized.
DOM 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 escape this stupidity only because it is not a part of JavaScript. Java people ignorant of JavaScript desirous of features to make JavaScript feel more like Java has no bearing on the DOM, for example, because they are separate technologies managed by unrelated organizations.
None of the ergonomic reasoning mentioned in the article are qualified. Just because many people lack confidence in the technology and knowingly make poor design decisions doesn’t mean a familiar vanity layer will fix anything. Declarative comfort, for example, is not a resolution to performance and security problems just because other knowingly bad design decisions are worse. Two wrongs don’t make a right.
Furthermore the DOM already has a slow unnecessary declarative abstraction layer insecure people cannot live without called querySelectors. In other words this proposal is to React as querySelectors are to jquery, and classes are to Java. These are/were trends and trends die over time. We really should move past vanity as an alternative to an absence of training.
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.
How classes could be better? I don't think it's missing something that would make me use it
I’m curious. What is actually wrong with querySelector?
String interpolation is so ridiculously slow. Epic slow.
Perhaps just as importantly is that is a crutch for many to avoid accessing the DOM in steps. You can read from the DOM with querySelectors but you cannot modify the DOM with them. If querySelectors is all you can do then you must use some third party template system because you have no idea how any of this works even though it provides maximal expressive freedom.
Is anything preventing JS from compiling the proper stepwise dom access if the querySelector parameter is a literal? That would basically push the interpolation into the parsing step.
What we need is not templating. What we need is a native implementation of a virtual dom.
More specifically, a native implementation of the "patch" function:
Where `virtual_dom` is just a plain-data description of the DOM.Most of the "slowness" of the DOM come from its requirement to be a 90's era Java style object hierarchy.
Don't call it "templating". Just call it "virtual dom". Everyone knows what that means.
A native virtual DOM implementation would also drastically reduce memory overhead since browser engines could optimize diffing algorithms at the C++ level instead of requiring megabytes of JavaScript framework code to be downloaded, parsed and executed on every page load.
Virtual DOM is a useless abstraction, there are numerous libs that perform fine without it.
It's a useful abstraction: you just build the full DOM with every change, a bit like a game engine. It makes so many things simpler.
It's not a free abstraction though.
Other than quibbling over the word "template", how does that differ from what TFA is describing?
The linked proposal has many "features" that would be "needed" if you frame the problem in terms of a "template api", centered around "binding" variables, and what not.
https://github.com/WICG/webcomponents/issues/1069
My proposal only adds one native function with nothing else: no new data types, no new apis.
Doesn't your proposal implicitly introduce the concept of a virtual DOM, which the browser does not have?
You'd need to spec out what that looks like. It adds one new API from the users perspective but much more from the browsers perspective.
Additionally the next generation of Frameworks do not use virtual DOM. Solid and svelte do not. Vue is moving away from it. Signals are directionally where they're all heading.
The API surface I propose only includes one function. No type needed.
It does not even require the target node to be created with a virtual dom in the first place. Just diff the node with the given tree structure efficiently.
Internally the browser might need to create a few accelerator data structures, but that's an implementation detail.
Depends where the platform boundary is for Web. As much as we hate JS fatigues and so many frameworks, choice is good. Maybe if the browser can make it easy for these frameworks to be performant and integrate more deeply (not part of the JS bundle but more like a deeper JS 'plugin' with bonus of sometimes having a cache hit from another site) we could just carry on using React et. al.
What about
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
?
The next two documents are part of a set that I made which did DOM-based templating on the back end in Java
https://ontology2.com/the-book/html5-the-official-document-l...
https://ontology2.com/the-book/source-code-transclusion-in-h...
one trouble is that systems that work at the DOM tree level are an order or two magnitudes slower than string-based templating systems. Hypothetically you could do some interesting things like hygenic macros and merge together arbitrary documents, rewriting the CSS classes and such. But by and large people find string-based templates to be good enough and don't way to pay the price for something more expensive.
Currently <slot>s only have automatic behavior when attaching a <template> to the Shadow DOM to a node with existing "Light" DOM children, which mostly only happens with Web Components (and for now Web Components require JS).
So it is not yet a full, generic templating solution.
Also, this article goes on at length about how the templating needs to be "reactive" and not just "builds a DOM tree", and <slot> doesn't do that yet at all, even in the automatic behavior scenarios, it's a one time "merge".
Kicking the can along the road of the complexity of "reactive" components is a large part of how we've got the (quite basic) <template> and <slot> tags that we got, and I think why the article is still currently impractical. There needs to be more agreement on what "reactive" means. The article mentions the signals proposal, and that's one possibility that a lot of frameworks are pushing for right now, but it's still a process before browsers agree to support something like that, and something like that is a dependency before agreeing on what a "reactive" template language can be/how it would work out of the box.
As mentioned, the DOM API is a stinker. Does this address that root issue?
I'd love to see something that builds on the work of hyperscript and HAST. They are great models of the DOM. It would be exciting if a template language were syntax sugar.
JSX is easy to reason about because its elements are 1:1 with a single, uniform function call. That feature means JSX is always optional. Sometimes it is even more verbose or less-performant to use JSX than a hyperscript API like specifying optional properties. I think errors and call stacks are clearer than during string interpolation, but that's possibly BS.
Web components offer limited data binding and the hyperscript approach has clear control flow. The templates seem to be a source of confusion in the GH discussions.
There is still something special and pleasant about jquery because its API was a reflection of the domain. As a developer, I want to query for a node (CSS selector, xpath, etc.) to affect change and traverse to other nodes. After a beer or two I'm convinced emacs and org mode approaches are worth emulating in the web.
Great article and linked discussions. Thanks for sharing.
> 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.
The answer is here on the HN Start-page: XSLT
I would like to posit that it’s actually JSX that people like and not React. JSX was always the friend that she told you not to worry about.
When are we done adding everything into the browser API?
Hopefully never.
Unless you loved IE6 of course, which was when Microsoft declared the web browser to be 'complete'.
When somebody creates something better.
If you built React into the web platform, what I'd expect is everyone would stop using it the moment a big new version of React came out, and it'd eventually get deprecated and removed.
There has been long running complaints about how many UI frameworks there are, and how often they change. It's settled down some, but I don't expect that situation to change for a long while.
> If you built React into the web platform, what I'd expect is everyone would stop using it the moment a big new version of React came out, and it'd eventually get deprecated and removed
Not related to the templating thing but I have the impression we are witnessing the last React big change with RSC. This change made them lose a good % of developers, a next one would kill it.
Go to the what's new page for a react release, and there's quite a bit, with minor releases then adding to that: https://react.dev/blog/2024/12/05/react-19#whats-new-in-reac...
After several releases, it's a lot.
We'd need a good API for UI components to go with it
Stop adding more complexity to the browser and making it even more impossible to build a new browser from scratch.
Need a DOM snapshot API too.
Where's the code?
https://github.com/WICG/webcomponents/issues/1069
I disagree on the general principle of adding APIs -- the platform suffers not from lack of APIs, when you really think about it, but from "another API to rule them all". It's frankly a similar fallacy that struck Microsoft where they were for a long time stuck having to support every API their seniors and interns ever invented -- none of which seem to be sufficient, apparently.
The solution to the "bro, just one more API, please" is to design a _transparent_ platform that is well able to "delegate" programming of new features (e.g. one implementing your favourite templating API) to third-parties in a manner that maintains their "first class citizen" status. WebAssembly was a move in that direction because it's a generic platform that in part supercedes and otherwise supplants the mess that JavaScript has to manage bridging the originally "kiddie script" application software domain, with the native functionality the browser may be encapsulating (also for performance).
Case in point: FFMpeg may be compiled to a WebAssembly module, which gives you arbitrary video/audio encoding/decoding -- pending correct design of bit-blitting so the decoded output can be efficiently transferred to the screen/speakers (which, for much of the reasons I am trying to outline, _is_ the bottleneck of the entire solution).
We need more of the same kind of thinking. Stop begging Web browser vendors / w3C / WHATWG for more features that are just lipstick on a pig -- sit down, think about what kind of feature(s) would allow the Web platform to finally escape the death spiral it's been in since its inception -- albeit one with a large enough radius it's meant to never actually resemble a spiral.
I don't know if I am making myself clear here, but in much simpler terms: why should there be another piece of code that caters to "most" (because you happen to be a FP/React zealot, for better or for worse) when these people can ostensibly write such templating system themselves, publish it on e.g. NPM and/or pull it and use it from there?
The time has been right for Yonkers -
[dead]
Fisrt include jQuery as a whole into the base standard. That would help a lot.
Out of FE for a whole but isn't that done to a great extent.
done, how?
https://developer.mozilla.org/en-US/docs/Web/API/Element/que...
I <3 jQuery but, no.
What no? Why can't we have nice things, like concise, easy to remember, not overly elaborate syntax?
jQuery is large and contains a lot of things. Which specific features do you think the DOM needs?
From bevr1337's comment, above:
> its API was a reflection of the domain. As a developer, I want to query for a node (CSS selector, xpath, etc.) to affect change and traverse to other nodes
That's what I miss about it.
Doesn't querySelector(All) provide this?
Not entirely. There's a reason people do Array.from(querySelectorAll) to do more than just `forEach`
So you are saying that Array.from(querySelectorAll) gets you there? What are you missing then?
Genuinely asking, I have no clue what's being alluded to without being clearly mentioned in this thread.
> So you are saying that Array.from(querySelectorAll) gets you there? What are you missing then?
Array.from adds friction. The need to wrap querySelector in null checks adds friction. The fact that they are not composable in any way, shape, or form, with any DOM methods (and that DOM methods are not composable) adds friction.
jQuery was the fore-runner of fluid interface design. Nothing in the DOM before, then, or since ever thought about it. Even the new APIs are all the same 90s Java-style method calls with awkward conversions and workarounds to do anything useful.
That's why sites like "You don't need jQuery" read like bad parody: https://youmightnotneedjquery.com
E.g. what happens when it's not just one element?
Or: why doesn't NodeList expose an array-like object, but provides an extremely anaemic interface that you always need to convert to array? [1] There's a reason most people avoid DOM APIs like the plague.---
[1] This is the entirety of methods exposed on NodeList https://developer.mozilla.org/en-US/docs/Web/API/NodeList
Instance properties
- length
Instance methods
- entries() // returns an iterator
- forEach()
- item()
- keys()
- values()
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).
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.
You don't need Array.from if you are using `for (const x of document.querySelectorAll(selector) { }` loops anyway or have a library like IxJS handy.
ES2025 added map, filter, flatMap, reduce, forEach, and several other methods to all iterators (including NodeList directly, I believe, but definitely its entries(), keys(), values(), if not) [1]. It'll be a year or two at current pace before that is "widely accepted baseline" in browsers, but it's great progress on these sorts of complaints.
[1] https://2ality.com/2025/06/ecmascript-2025.html#iterator-hel...
> including NodeList directly, I believe,
I listed all public methods and properties of NodeList. It does have a forEach, so there's not much need for `for of`
As for iterator methods, I completely forgot about that :) Yeah, you can/will be able to use them on .entries()
You missed [Symbol.iterator] as a public method. I prefer the aesthetics of for/of over forEach in most cases, but it's as much personal preference as anything.
I did briefly forget the distinction between Iterable (has [Symbol.iterator]) and Iterator (the thing [Symbol.iterator]() returns). You can use the Iterator helpers "directly" on the NodeList with `someNodeList[Symbol.iterator]().map(…)` or `Iterator.from(someNodeList).map(…)`. There are advantages to that over `Array.from` but not many advantages over `someNodeList.entries().map(…)`.
(I partly forgot because I assumed MDN hadn't been updated with the new Iterator helpers, but of course it has [1], they are marked as "Baseline March 2025" [all browsers updated since March 2025 support them] and there is a lot of green in the browser compatibility tables. caniuse suggests Iterator.prototype.map is ~84% globally available.)
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
> with `someNodeList[Symbol.iterator]().map(…)` or `Iterator.from(someNodeList).map(…)`
I always feel like clawing my eyes out with most of the DOM APIs, or workarounds for them :)
[Symbol.iterator] is more the for/of API (protocol, more accurately) than a DOM API. It's an improvement today that the DOM APIs pick up niceties like direct [Symbol.iterator] in addition to Iterator methods like entries().
It's nice that there is syntax sugar for [Symbol.iterator] in both for/of and also the spread operator/deconstruction/rest operator (things like [...someNodeList] and const [item1, item2, ...rest] = nodeList).
In theory, the only missing piece is syntax sugar for Iterator.from() if you wanted to direct chain any iterable to the iterator helperrs. But in practice, that's also part of why the explicit iterator methods like entries() already exist and those are surprisingly well implemented (and have been for a while), including on NodeList.
What do you think is alrite in the current spec?
Templates are great until they need to be dynamic. Then you're right back to the current situation where frameworks like React are just the better way.
In fact, you could call JSX a "Dynamic Templating System" and that's a reasonable summary of what it is (in addition to other things of course).
There might be some ways that React itself could, internally, notice the special cases and special times where it _could_ be slightly more performant from using a lower level of templating, as an optimization, but I'd certainly prefer that to be abstracted away and buried deep inside React, rather than ever having to think about it myself, at the JSX layer.
Someone can let me know if React is already leveraging this for browsers that support it, I didn't research that.
"If I could wave my magic wand..." at least 2 of 3 of the changes I'd made about the way frontend web is developed, would be about `<template>`s:
1. Making it possible to do something like <template src="..."> and being able to load them from an external source
2. Making them "dynamic"
3 (and the most controversial one) that all CSS, HTML and Javascript (if you don't hate it) could be written natively like QML - one syntax to rule them all.
As a web dev you probably already know but #1 is slightly similar to `Web Components` but you're right we cannot load a web component right in the HTML where we use it. It makes sense though because if you use an Element in multiple places it wouldn't make sense to have 'src' in multiple places, so ultimately some kind of 'loading' at the top of the page is needed, and that's how WebComponents work, but I still like how you think.
#3 is a tricky one syntactically because HTML needs to be used by mere mortals and JS is a programming language used by us gods, so unifying all three would br tricky, but again I agree with you that would be awesome. Maybe some flavor of LISP would be both "powerful like a language" and "easy like a document".
> 1. Making it possible to do something like <template src="..."> and being able to load them from an external source
I've done that, requires no build step/npm/whatever. It was posted on HN for discussion a week ago: https://github.com/lelanthran/ZjsComponent
The system described in the article is very React-like, and could be used by future versions of React. In both, functions return a description of HTML to render, which can be applied either to create new HTML or to update previously rendered HTML.
I skimmed part of it, but unless I missed some huge caveat I think you’re backwards and GP is definitely right. The article mentions React, then sort of dismisses it later saying the other two strategies are better to implement instead of diffing.
I don’t see any reason a browser level “here’s new DOM you diff and apply it” couldn't exist and be a huge win for React and other libraries, with React so much more popular than every other framework combined, and that being a pretty low level API, it makes sense to start there.
Building the overly abstracted thing first is a mistake web API authors have made too many times (see web components).
I still have hope for Web Components to take off in the figure. I'm a React dev so I don't "need" them, but they may end up being some kind of capability that React can secretly, quietly embed into React core as some kind of optimization if that ever makes sense. Web Components is a great idea, but like I said it's just not quite as convenient as React, so it's currently somewhat irrelevant at least for me.