> Is this just shifting complexity from JS to HTML?

Very well said. This is the problem.

There's an old adage that every "scripting" language starts out small, but then ultimately needs all the features of a full programming language. If we start putting programming features into HTML, we'll eventually turn it into a full turing-complete programming language, with loops, conditionals, variables, and function calls. We'll have recreated javascript, outside of javascript.

CSS is now getting functions as well [0].

[0] https://news.ycombinator.com/item?id=43236126

Horrible. We're going to end up with three separate languages: CSS, HTML, and Javascript, which will each be turing-complete programming languages with completely-overlapping featuresets, and there will be no clear reason to use one over the other.

Browsers will have to implement support for three PL runtimes. Everything will be complicated and confused.

Everything will be even more complicated and confused.

The sky isn't falling, and nearly everything is trending better, not worse. You can use whatever features of browsers that you want.

There are tradeoffs. Further increasing the barrier to entry for new web browsers benefits the entrenched players and hurts end users by yielding fewer alternatives.

The entrenched are the ones deciding the features. This is their goal

That's what people say of C++ too. Too many features makes it harder to learn a language and ramp up on codebases; they'll have different standards on what they use.

Developers can use whatever features they want, but users can only watch as their computer uses up more and more energy because it suddenly has to perform yet another build step that previously was done on the server.

Is there DOOM in CSS already?

There's a Wolfenstein https://css-tricks.com/hacking-css-animation-state-and-playb...

Maybe in ten years they will finally add enough languages to each one of these 3 languages to make them good enough to compete against Delphi.

Already a thing of past http://www.w3.org/Submission/1996/1/WD-jsss-960822 Netscape Communicator 4

JavaScript Style Sheets (JSSS) alternative to CSS, a "Programmable CSS"

Never got spotlight because stubborn people werent ready to let go of css

My prediction: In a few iterations this will have turned into an inferior reinvention of HTMX.

I believe the stated goal of HTMX's developer was to integrate the functionality of HTMX into HTML.

It's not just shifting complexity. It improves locality of behavior (LoB). You can look at a <button> element and immediately know what it does (within the limited domain of "command"s). This is a dramatic improvement to readability.

My long-shot hope is that the page can come to embody most of the wiring on the page, that how things interact can be encoded there. Behavior of the page can be made visible! There's so much allure to me to hypermedia that's able to declare itself well.

This could radically enhance user agency, if users/extensions can rewire the page on the fly, without having to delve into the (bundled, minified) JS layers.

There's also a chance the just-merged (!) moveBefore() capability means that frameworks will recreate HTML elements less, which is a modern regression that has severely hampered extensions/user agency. https://github.com/whatwg/dom/pull/1307

> My long-shot hope is that the page can come to embody most of the wiring on the page, that how things interact can be encoded there.

I would love this. As a Tailwind user the last few years, it’s really been refreshing to have my styles both readable and inline on the elements instead of filed away in SCSS I’ll never see again. Even with scoped styles, some components get large enough that it feels unwieldy

Nah that's good. JS is way too powerful and 99% of pages don't need bloat like webrtc, navigator api or thousands of other points that are almost never used for good but for evil.

Html should be powerful enough on its own to provide basic web page functionality to majority of use cases and only then the user should give explicit permission for the server to rum unrestricted code.

That's why I rather keep HTML limited than embracing something like Svelt (which I haven't heard of before). Looking at it's inline syntax in the example, it is yet another something to learn. Yet another thing with peculiarities to keep track of, solving one kind of problem but introducing more complexity by spreading logic out (taking logic from one place and putting in another creates an additional relationship which is a relationship with that from which the logic was taken: Svelt and JS has to coexist and may for example overlap).

My favorite experience of shifting logic is writing a template engine in PHP. PHP is a template engine. I soon discovered I tried to replicate more and more PHP feestures, like control flow etc. I realize PHP did a way better job being a template engine. (This does not disqualify all use of said things, just that all seemingly good use cases aren't motivated, and may not turn out as expected.)

>> Is this just shifting complexity from JS to HTML?

> Very well said. This is the problem.

It is a problem. Counterintuitively, it is also a solution.

Lifting some complexity out of JS and into HTML solves some problems. Lifting all complexity out of JS and into HTML creates new problems.

For example, I have a custom web-component `<remote-fragment remote-src='...'>`. This "shifts" the complexity of client side includes from "needing a whole build-step with a JS framework" into directly writing a plain html file in notepad that can have client-side includes for headers, footers, etc.

This results in less overall complexity in the page as a whole.

Shifting the "for" loop and "if" conditionals from JS to HTML, OTOH, results in more overall complexity in the page as a whole.

> Abstraction vs. magic: Is this just shifting complexity from JS to HTML? Frameworks already abstract state—how does this coexist?

The same way React or other frameworks can hook into things like CSS animations. If CSS animations didn't exist, the JS framework would have to write all the code themselves. With them existing, they can just set the properties and have it work.

Even if you're writing a basic menu popup directly in React, having these properties to use directly in your JSX means less code and less room for error.

Then if you need to do something special, you may need to do it by hand and not use these properties, just like if you needed a special animation you might have to do it without using the CSS animation properties.

agreed, my sense is that frameworks will update to take advantage as they've done in the past

I'm not a web dev, so I apologize if my questions are naive. Does this mean its a chrome-only thing or does it become a web standard? I ask because I would like to imagine the future isn't tied to Google's whims, graveyard of initiatives, and requirements.

That would be really nice, but, that’s been the way of it for the last few features too… it might not get adopted, but if enough people start using it…

It's already implemented in bleeding edge builds of Firefox and Safari, just behind a feature flag (as it also is in chrome)

https://caniuse.com/mdn-api_commandevent

My experience with anything declarative is that features are gradually bolted on until it eventually just becomes imperative (and ugly). For example HCL.

I believe declarative should stay purely declarative to describe data/documents in a static state (e.g. HTML, JSON) and an imperative “layer” can be used to generate or regenerate it, if needed.