12 ms·

The time is right for a DOM templating API

• PaulHoule 1y ago
  What about https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/slot 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-language.html https://ontology2.com/the-book/html5-the-official-document-l... https://ontology2.com/the-book/source-code-transclusion-in-html.html 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.
  • WorldMaker 1y ago
    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.
• wg0 1y ago
  Need a DOM snapshot API too.
• insin 1y ago
  We'd need a good API for UI components to go with it
• quantadev 1y ago
  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.
  • Gualdrapo 1y ago
    "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.
    • quantadev 1y ago
      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".
    • lelanthran 1y ago
      > 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 https://github.com/lelanthran/ZjsComponent
• segphault 1y ago
  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.
  • BiteCode_dev 1y ago
    You don't even need much: loops, conditionals on attributes, and conditionals on nodes. In fact, we could have that cross-language.
• mosdl 1y ago
  I miss mozilla's XUL language (and XBL!), those were awesome.
  • latortuga 1y ago
    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!
  • watersb 1y ago
    there-is-only-XUL
    • paulrouget 1y ago
      There is no data! https://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul https://www.mozilla.org/keymaster/gatekeeper/there.is.only.x... Good old time.
  • sabellito 1y ago
    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.
    • Nextgrid 1y ago
      > 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?
      • sabellito 1y ago
        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.
• rs186 1y ago
  The author was a core contributor of Google's Lit project: https://github.com/lit/lit https://github.com/lit/lit
  • mock-possum 1y ago
    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.
    • troupo 1y ago
      > 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.
      • unlog 1y ago
        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.
      • yoz-y 1y ago
        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.
        • troupo 1y ago
          > 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)
• bevr1337 1y ago
  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.
• lofaszvanitt 1y ago
  Fisrt include jQuery as a whole into the base standard. That would help a lot.
  • edoceo 1y ago
    I <3 jQuery but, no.
    • lofaszvanitt 1y ago
      What no? Why can't we have nice things, like concise, easy to remember, not overly elaborate syntax?
      • ameliaquining 1y ago
        jQuery is large and contains a lot of things. Which specific features do you think the DOM needs?
        • lofaszvanitt 1y ago
          What do you think is alrite in the current spec?
        • eszed 1y ago
          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.
          • jraph 1y ago
            Doesn't querySelector(All) provide this?
            • troupo 1y ago
              Not entirely. There's a reason people do Array.from(querySelectorAll) to do more than just `forEach`
• pier25 1y ago
  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.
  • nwienert 1y ago
    React isn’t templating though.
    • n2h4 1y ago
      [dead]
    • ASalazarMX 1y ago
      Respect for focusing on semantics but not contesting the CPU and bandwidth waste. That takes honesty.
    • ivape 1y ago
      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?
      • nwienert 1y ago
        Missed this but - there’s a very meaningful difference between templates and React at least how most people think of templates. React lets you return dynamic tree structures and insert code anywhere inline in that structure. Most templates explicitly don’t allow that for good reason. Further, most but not all templating frameworks have special syntax for conditional logic and loops. If JSX is templating then templating has no meaning. Would createElement() be a template? In that case all functional programming is.
  • strix_varius 1y ago
    With the TC39 signals proposal, part of that is making progress.
• bravesoul2 1y ago
  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.
• ericyd 1y ago
  > 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?
  • krebby 1y ago
    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#react-event-object https://react.dev/reference/react-dom/components/common#reac...
  • bevr1337 1y ago
    > 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://legacy.reactjs.org/docs/events.html https://react.dev/reference/react-dom/components/common#react-event-object https://react.dev/reference/react-dom/components/common#reac...
    • MrJohz 1y ago
      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.
      • bevr1337 1y ago
        And then some. Switching to react-native or other render targets can also be a doozy. Hopefully the references clarify all the features.
• shermantanktop 1y ago
  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?
  • quotemstr 1y ago
    > 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.
    • bryanrasmussen 1y ago
      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.
  • dleeftink 1y ago
    > 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.
• jongjong 1y ago
  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.
• djfivyvusn 1y ago
  Where's the code?
  • exclipy 1y ago
    https://github.com/WICG/webcomponents/issues/1069 https://github.com/WICG/webcomponents/issues/1069
• hsn915 1y ago
  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: patch(target_dom_node, virtual_dom) 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.
  • sethaurus 1y ago
    Other than quibbling over the word "template", how does that differ from what TFA is describing?
    • hsn915 1y ago
      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 https://github.com/WICG/webcomponents/issues/1069 My proposal only adds one native function with nothing else: no new data types, no new apis.
      • WickyNilliams 1y ago
        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.
        • hsn915 1y ago
          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.
• taeric 1y ago
  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?
  • wahern 1y ago
    > 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.
    • marcosdumay 1y ago
      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.
    • 1y ago
• Sophistifunk 1y ago
  When are we done adding everything into the browser API?
  • wewewedxfgdf 1y ago
    Hopefully never. Unless you loved IE6 of course, which was when Microsoft declared the web browser to be 'complete'.
  • lylejantzi3rd 1y ago
    When somebody creates something better.
• nitwit005 1y ago
  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.
  • owebmaster 1y ago
    > 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.
    • nitwit005 1y ago
      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-react-19 https://react.dev/blog/2024/12/05/react-19#whats-new-in-reac... After several releases, it's a lot.
• keepamovin 1y ago
  The time has been right for Yonkers -
• d--b 1y ago
  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.
  • dragonwriter 1y ago
    > 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.
  • leeoniya 1y ago
    > 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 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_chrome_137.0.7151.55.html https://krausest.github.io/js-framework-benchmark/2025/table...
• wavemode 1y ago
  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/ https://xkcd.com/927/
  • jdkoeck 1y ago
    Is there really a proliferation? At this point it’s 90% React.
  • branko_d 1y ago
    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.
    • nine_k 1y ago
      DOM + CSS is a hugely rich layout / rendering engine. The problem is that it's heavyweight.
• tcoff91 1y ago
  Stop adding more complexity to the browser and making it even more impossible to build a new browser from scratch.
• upghost 1y ago
  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.
  • parhamn 1y ago
    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).
  • bapak 1y ago
    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.
  • wackget 1y ago
    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.
• stevage 1y ago
  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?
  • mock-possum 1y ago
    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.
    • bapak 1y ago
      > 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.
• b0a04gl 1y ago
  [dead]
• austin-cheney 1y ago
  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.
  • 9rx 1y ago
    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.
    • owebmaster 1y ago
      How classes could be better? I don't think it's missing something that would make me use it
  • yoz-y 1y ago
    I’m curious. What is actually wrong with querySelector?
• jlukic 1y ago
  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.
  • troupo 1y ago
    > 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
    • JimDabell 1y ago
      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).
      • troupo 1y 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). 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/proposals/Template-Instantiation.md https://github.com/WICG/webcomponents/blob/gh-pages/proposal... but that mostly went nowhere
• llcooliovice 1y ago
  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.
• llcooliovice 1y ago
  > 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.
  • infensus 1y ago
    MDN and caniuse say otherwise. I think there might've been an older specification that got implemented, but it's been revised since
    • llcooliovice 1y ago
      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.
• ukuina 1y ago
  Nit: The post keeps referring to "standard JSX" as though trying to will such a thing into existence.
  • jmull 1y ago
    I thought one of the main points the article is making about JSX is that it currently isn’t standardized.
• aatd86 1y ago
  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.
  • austin-cheney 1y ago
    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.
  • troupo 1y ago
    > 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.
    • aatd86 1y ago
      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.
      • troupo 1y ago
        Javascript being a decent functional language does not make DOM API functional. DOM API is 90-s era OOP
• hackrmn 1y ago
  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?
• notnullorvoid 1y ago
  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.
• llcooliovice 1y ago
  > 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 https://github.com/whatwg/dom/issues/736
• llcooliovice 1y ago
  > 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 https://github.com/tc39/proposal-record-tuple/issues/394 It has been replaced by https://github.com/tc39/proposal-composites https://github.com/tc39/proposal-composites
• ulrischa 1y ago
  The answer is here on the HN Start-page: XSLT
• TheRealPomax 1y ago
  > 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.
• karolinepauls 1y ago
  [dead]
• vlucas 1y ago
  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.
  • MrJohz 1y ago
    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.
• codedokode 1y ago
  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.
  • yoz-y 1y ago
    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.
• llcooliovice 1y ago
  > 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.
  • localvoid 1y ago
    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.
• halis 1y ago
  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.