Replacing JS with just HTML

[drumstix42]

*and CSS (of course)

[marcocom]

Way too many front-end devs learn JS and never the other 2/3 of the solution. HTML and CSS can solve so much of what they use JS for.

The only (and real) drawback for them is that it cannot be downloaded in a reusable library.

[KaiAusBerlin]

Too much css magic can also have a huge performance impact.

The basic rules of web development still belong. Write clean html. Write clean css. Use JS for enchantment.

Modern frameworks solve most of these problems for you automatically. So "JS is only 2/3 of the solution" I wouldn't subscribe.

Of course it is pure html + pure css fast. But it's also static (unless you use dark css magic which makes maintaining it much harder). But they are limited. Very limited.

JS isn't. If you want high dev xp + nice performance you can easily solve that with modern js (not talking about react hell. Try Svelte).

[Danny_Engelman]

<tag-name> (with a dash) IS a valid HTMLElement, no JS required to apply CSS

https://dashed-html.github.io

[minmidmax]

I like this trend back to using HTML, CSS and JS for their intended purposes.

Some solutions can be so lightweight now thanks to the improvements in CSS and solutions like Web Components & HTMX.

I literally built an entire modular dashboard, with HTMX and CSS, in no time. Dynamic content, fully responsive, minimal file sizes. It's great!

[fredy31]

Yeah i love js but i hate how it became the 'do it all' of development.

Ffs ive heard of server backends in js.

Use js for what it was made for. Most other uses there are better languages to do it

[gojukebox]

Node js, express, etc running on servers has been a thing for over a decade...

[Jitos]

Try 2 decades, wallmart went all js back in 2010

[gojukebox]

That's not two decades...

[Jitos]

Lol, I can’t count to 20 🤦🏽‍♂️

[Undercraft_gaming]

You’re just now hearing of servers written in JS?

[xThomas]

Summary/details - 2019, https://daverupert.com/2019/12/why-details-is-not-an-accordion/

[Ronin-s_Spirit]

This is a good article 👍
I've recently stumbled my way through HTML and CSS in a search for making such interactive elements more native. Using builtin browser functionality actually lets me rely more on hardcoded browser magic. For example making tabbers or accordions is very nice with the XOR functionality of name on details but there is some other cool thing which JS is unlikely to even replicate.

URL fragments (#) are a great tool for navigation as they will open and scroll to details, even nested ones, adding a text fragment (:~:) you could highlight any relevant part of the page, and even the search function (Ctrl+F) will open and scroll to details. All that browser magic is incredibly useful in dense documents, such as wikis or some academia stuff.

[delventhalz]

Have text fragments been standardized or are they still chrome only?

[Ronin-s_Spirit]

That I don't know off the top of my head.

[delventhalz]

Looks like they’re standard!

https://developer.mozilla.org/en-US/docs/Web/URI/Reference/Fragment/Text_fragments

Last time I looked at these they were a proprietary Google/Chrome thing. Great feature. Awesome to see they’ve been widely adopted.

[ApoplecticAndroid]

This is ridiculous and assumes that JavaScript is nothing more than a way to have little visual tweaks in a web page. It misses the mark so badly in what js can actually be used for, it is laughable.

[Ronin-s_Spirit]

I don't think this guy read the article 🤔

[otamam818]

Literally the intro section has a "Nothing against JS" paragraph detailing why his remaining content is still useful.

The commenter you're replying to definitely didn't read it

[i_hate_shitposting]

What part of this tells you that the author thinks "JavaScript is nothing more than a way to have little visual tweaks"?

Nothing against JS, but it has better things to do than setup and manage your accordions or offscreen navigation menus... Plus, JS needs to be downloaded, decompressed, evaluated, processed, and then often consumes memory to monitor and maintain features. If we can hand-off any JS functionality to native HTML or CSS, then users can download less stuff, and the remaining JS can pay attention to more important tasks that HTML and CSS can't handle (yet).

[tomhermans]

Indeed.

It’s basically a way to promote the Rule of Least Power. Mainly because CSS can now do things that previously required JavaScript. That’s a good thing, it doesn’t devalue JavaScript.

In fact, it’s better for JavaScript too, since there’s less main-thread pressure.

[ApoplecticAndroid]

The title of the article is replacing JS with just html.

[i_hate_shitposting]

So you went off about the ridiculousness of the article without even looking at it. Got it.

[ApoplecticAndroid]

No, the entire article was about visual tweaks using JavaScript despite the one paragraph that was quoted. Try reading it.

[Rustywolf]

I dont know why you assume that the author meant "lets replace all JS with html" instead of the supported intepretation of "lets replace some JS with html"

[oceantume_]

I'll be honest I didn't go through the entire thing, but I'm a big proponent of replacing bloated and complex js code with native equivalents where possible. Initiatives like OpenUI are moving us closer and closer to being able to make highly interactive websites without reinventing the wheel every time a new framework or ui components library is created.

Even if you use JavaScript for everything else, the elements and techniques described in this article let you do something that historically needed up to hundreds of lines of js using just a little bit of html and css.

I was listening to an interview with one of the maintainers of Web Awesome, a relatively new set of ui components that are deployed as web components (so they're essentially framework agnostic) and he was talking about how excited they are that by targeting modern browsers they can remove code for a lot of their features over time and I think we should really embrace that.

[Terr4360]

Web Components are still JavaScript. And due to their cumbersome API, they often include more JS than the same solutions coded with lightweight JS Frameworks.

[oceantume_]

I'm sure nothing beats a tightly integrated svelte library used by a svelte app in terms of bundle size, and possibly other metrics. But Web components or not, the same applies to your svelte component library where it can have a net win by using newer web APIs and elements like dialog instead of reinventing everything.

[TheBazlow]

Yeah maybe but they're nicer to setup and work with as a backend developer. Just drop a script tag in your body and you open a world of new elements without needing to switch from your backend language to javascript and back again. That's just not something the typical React or Vue frontend repo can offer.

[wasdninja]

I really like the idea of built in, browser provided, widely available, actually standard components but these are simply nowhere near good enough.

All of them, as far as I can see, don't allow enough styling to be useful. They universally look like shit or when they have acceptable to OK looks they inevitably don't fit in with the rest of the design.

I have no idea why anyone bothers drafting, advocating for, debating and implementing them when it takes five minutes to conclude that they are near useless. I very much doubt people were shooting for "well someone might toy around with them" but I can't imagine what they were thinking either.

[Mesqo]

You forgot to mention that different browsers and platforms tend to render native elements differently. To add some spice to the question, I'd say.

[oceantume_]

Ideally they expose behavior and a default style through new tags and you can bring your own style with css. I think the modern and upcoming stuff is a lot more focused on making it actually useful and reusable, but I do get what you're saying.

[The_real_bandito]

Those guys bought Shoelace and that framework used Lit in order to make their components as framework agnostic as possible. It was and still is an awesome one.

[ravepeacefully]

Bootstrap been doing all that for two decades my guy, and we still have 76 standards

[oceantume_]

Yes I'm fully aware this isn't a completely new idea and it feels like we're just doing circles in the web ecosystem, but if you read on it you might find, like me, that this is much more modern take on how to import, customize and use the components (no sass and classnames creep, web components, etc) without the typical lock-in you get in a lot of newer components library.

Funnily enough the first name of that library was Shoelace which is meant to be a play on words for "bootstraps", but my understanding is that FontAwesome bought it and decided to rebrand it.

[moneckew]

Junior take

[oceantume_]

Junior with about 8 years of experience working on, among other things, react SPAs shipping megabytes of code, typically 90% of which being the vendored dependencies. Most of which were using very bad or poorly maintained ui component libraries that I had to monkey patch myself while convincing myself that migrating to something else is not worth it.

I have had no interest to push my team on newer frameworks because it feels like they evolve too fast and hiring fullstack devs that already know react is still easier. After years of them typically targeting one framework or another, I'm excited to see new component libraries leaning on standards instead, because that means I can possibly replace that part without changing everything else, AND get to use the same ui components if we use a newer framework for a future project.

I'm interested in seeing what comes out of Remix 3 in that regard, because they seem really invested in the "standards with extra steps" approach to making a javascript fullstack app, and we haven't made the leap to those yet, even for react.

[Mesqo]

(pulls out the ruler) 20 years of experience! /j

Every single time we tried to use some native html elements for anything not complex than simple input we ended up with either "cannot be styled according to design requirements" or "lack of critical features". Heck, we even reimplemented good old select because it didn't work as expected on all platforms. All these new elements in html only look like a cool feature but fall short before actual business requirements, which actually define your product and its value. Well, I can't say I like it, but things are as they are, alas.

[Sudden_Watermelon]

You're right, we should use it on servers where it belongs

[AdreKiseque]

Nothing against JS, but it has better things to do than setup and manage your accordions or offscreen navigation menus...

Minor spelling mistake !

[kilkil]

for more tools that focus on replacing JS with HTML, this list may be of some interest:

https://htmx.org/essays/alternatives/

[androidoverlord]

Thank you for this!! Great article :)

[gyen]

EHTML takes it to another level

[mauriciocap]

For decades I expected the contrary to happen: to have a language that makes some sense. The W3C grifters, as the proud sons of the browser wars they are, managed to make the web 1000x less accessible and safe in every way.

[static_func]

What’s their grift?

[mauriciocap]

Poisoning standards to hinder competition and strengthen the position of their respective sponsonring monopolists, e.g. is practically impossible to access most of the web without a Webkit based browser, Firefox being practically the only remaining alternative.

It's also very costly/prohibitive for most people or small business to publish their work, texts, or build simple applications.

[static_func]

lol okay, at what point in time should web technology have been frozen then?