But I guess it's not there yet.

There's this pattern on HN: people value a feature as having 0 utility and then become annoyed that someone has paid time/performance/money for them. Well duh, if you discount the value of something to 0, it will always be a bad idea. But you're never going to understand why people are paying for it if you write off their values.

At my last job there were countless pieces of UX to make things smoother, more responsive, better controlled by keyboard or voice reader, etc.. that required JS. It was not possible to make our site as good as possible with CSS, and it certainly wasn't worth the tradeoffs of loading a big faster (not that it couldn't have had it's loading time improved--just, cutting JS was a nonstarter).

The js is unnecessary if you can achieve the same result with plain css.

But to play devil's advocate: just because you can, doesn't mean you should.

In many scenarios I'd argue CSS would require more bandwidth. It can get quite verbose.

Wikipedia is consulted every day by a lot of people, i guess that a large number of those people are running older browsers.

<dialog> has only been available in Safari for about a year.

https://caniuse.com/dialog

Wikpedia is one of the most popular sites on the internet. It needs to be as compatible as possible so that means using JS.

considering the dominance of few browsers (chrome , safari on iOS) will most users notice any difference? The first one (with that UA) to the site with a new build will have they cache key warmed up ?

All to get rid of a tiny bit of JS.

Plenty of sites aspire to be JS free for a variety of reasons it is worthy goal

Also, if you want to further speed up your site, just like you said, the fastest way to speed up the site is to delete JavaScript, get rid of jQuery.

<details> is completely supported.

But if I can do it with all html, that's better than a function to add / remove a css class and document.onclick = a function to find which recipie you clicked on and adjust the css class.

I assume the author of the blog post just wanted to optimize the current situation, not completely change how these features work (which would most probably be a much more elaborate change).

Same for dropping jQuery - that will probably be a few weeks or months of work in a codebase the size of Wikipedia/Mediawiki.

On Wikipedia's mobile view, collapsed sections are super useful (as the table of contents is not visible via the sidebar) and media viewer makes it possible to view details of an image/thumbnail without navigating away from the page.

Yes and no. On the hand some sort of table of contents is useful (but note that you could also just display it inline, the way it used to be done in previous desktop skins), on the other hand those collapsed sections break scroll position restoring when reloading the page after somebody (your browser or directly the OS) kicked it out of your RAM. This is because your (absolute) scroll position depends on which sections where expanded and which collapsed, and that information gets lost when the page reloads – all sections end up collapsed again and the scroll position your browser remembered no longer makes sense.

(There is some sort of feature that tries to restore the section state, but a) it only works within the current session, but not if the OS low memory killer kicked the whole browser out of your phone's RAM and b) even when it does work, it runs too late in relation to the browser attempting to restore the previous scroll position.)

So now that the mobile Wikipedia's full JavaScript no longer runs on e.g. older Firefoxes (e.g. one of the last pre-Webextension versions), the lack of a TOC is somewhat annoying, but other than that, somewhat ironically my browsing experience has become much, much better now that my browser can finally reliably restore my previous scroll position because now all sections are permanently expanded.

Only if you want fancy animations. I sometimes do, but I think wikipedia can do without(and they don't) and use <details>

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/de...

And media viewer I would naturally do with js as well, but I am certain you can also do it easily with CSS. (Many ways come to mind)

[0] https://caniuse.com/?search=details

[1] https://www.mediawiki.org/wiki/Compatibility#Browser_support...

Good article about some issues (with a link at the top to his previous article about them). https://www.scottohara.me/blog/2022/09/12/details-summary.ht...

(Anyway, if you are using CSS + the relevant semantic HTML elements, it can be more accessible, not less, because you are expressing priority and emphasis, so they can skip over collapsed stuff. Although I have my doubts whether screenreaders etc make any good use of it, given that they apparently still do not do basic things like stripping soft hyphens.)

The fact they’re still using JQuery, probably for similar compatibility reasons is good evidence of that.

Now there are ways to use polyfills that only load when necessary but just about everything is very difficult at wikipedias scale. We can’t solve their problems from an armchair.

I've been developing websites professionally since 1996. HTML/CSS/JS and SQL.

I am still amazed there is the crowd out there who is "anti-JavaScript". They run NoScript to only allow it in certain places, etc.

It's 2023, a small amount of JavaScript on a page isn't going to hurt anyone and will (hopefully) improve the UX.

For the record, the last site I deployed as a personal project had 0 JavaScript. It was all statically generated HTML on the server in C#/Sqlite that was pushed to Github Pages. So I get it, it's not necessary.

For my little personal site. I'm also the senior lead on an enterprise Angular project.

JavaScript is fine, it's not going anywhere.

And yes, there are way too many React (specifically) websites that don't even need a framework at all, but it's become the go-to. That annoys me too. But some JavaScript in 2023 is fine.

It's a signal to noise ratio thing. There's a small reason to have JS switched on and a large reason to block it. I'd love it if the reason to have JS switched on was even smaller, and that is in fact the recommendation (that JS should enhance an otherwise functional site). I enable JS on sites where I regard the reward as worth it, but most of the time it just isn't, and I don't trust all the rubbish that gets included in the average site.