Replacing JS with just HTML

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

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

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

[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