Hacker News Reader

Comment by toomim | Hacker News Reader

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

View on HN

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

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

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

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.

Reply on news.ycombinator.com