 A decade ago, a tribe of JS partisans took the web by the reins, forked HTML and JS syntax, and yeeted userland abstractions into the critical path because "a better user experience". This was premised on the idea that everyone's CPUs/networks would get faster the way their top-end phones did. They could not have been more wrong. JS-first web development has been a planetary-scale exercise in the rich making life harder for the less well-off. 45 comments
Ever since, the frontend community has poured its investment and attention into minor permutations of the same 2008-browser-centric frameworks and approaches. It isn't working. We lost an entire decade on one great branch mispredict. The trends that used to deliver for "everyone" only continued for the rich. For the rest, Moore's Law meant first-time access through hand-me-down CPUs and networks as prices fell. 2014's A53 Core still shows up in new budget phones today. But world-historically rich programmers didn't want to hear about it, and browsers let them get away with UX murder. Frontend's Lost Decade is now a threat to the value of the web to businesses and users. A collective failure to cap JS emissions that has destroyed value at shocking scale: None of this is new, and none of the bad effects have abated at scale enough to relax. New projects are still being started on react and angular. The JS emitters have no shame because they largely don't think they did anything wrong. Something something "interactivity" (for rich users) something something. These folks can't be serious thought leaders because they aren't in touch with reality outside the privilege bubble. It's fine to ignore them. They haven't been right for a decade, and I think that's long enough. Anyway, just a reminder to hire people to solve problems with HTML and CSS, not too make them with JS.  @slightlyoff very good thread. i'm in a position to define frontend environments for our customers (local press mostly) for about a year. finally the first one will get a new page in january with css/html first and minimal - weight light self developed - javascript framework (~ 10 kb with modules on demand if needed) :) the team before me cluttered all with npm/webpack/stimulus/... a real hell...  @slightlyoff I totally agree with the theory here. I'm starting a new project soon. Do you have recommendations for resources with a practical vision that I can share with colleagues? @slightlyoff Personally, the sooner the better. But don't sweat that too much. We'll get by.  @slightlyoff Javascript is like regex. Try to solve a problem with JS... now you have two problems.  it’s bad that it’s slower. it’s bad that it’s harder to reuse. the weird part is that it doesn’t even seem better for development; it seems much harder to debug and get things out the door.  @slightlyoff question: isn’t hydrating meant to be a balanced tradeoff here? @slightlyoff I'm not even sure that we world-historically rich programmers would be giving up much by going with one of the newer, lighter frameworks (e.g. Svelte, Solid, or Lit) instead of React. Or do we need to give up front-end JS frameworks altogether and go back to manual, imperative DOM manipulation? @matt They wouldn't be giving up anything but bankrupt intellectual commitments, and apparently those are the hardest to put down. @slightlyoff You mean they don't want to admit they were wrong to choose React, or something else? @matt It's a whole thing...a series of false premises about what's good vs. bad for frontend; a pile of skills that don't hold their value through a new lens on the problem. @slightlyoff Sounds like a good subject for a blog post, unless you wrote about it already. Especially the pile of skills that don't hold their value. @slightlyoff That said, most of the fun with JS I have is for things you cant SSR anyway: Web-USB, Serial, MIDI, GL, GL2, RTC,NFC, Bluetooth, Workers, etc. All of which generally are accompanied by at least some JS dom manipulation. blanket anti-js seems to miss that nuance. @monteslu You know me – I'm not blanket anti-JS, just blanket anti-BS. Particularly when it harms users. To my Python friends...this thread by Alex is really important. “Outsource our web UI to React" has become a dominant theme. It has a cost to the under-served. It's also a strategic loser. Let's bring HTML, CSS innovation -- the web platform -- back to Python fullstack. @slightlyoff And then there is insanity like this: https://jakelazaroff.com/words/web-components-eliminate-javascript-framework-lock-in/ While the author clarifies that it's not a good idea to "build an app where every single component is written with a different framework", you can be damn sure that someone will try. @dfyx The good news with WC is that (at least today) the frameworks built for them are usually on the order of 1/8-1/4 the weight of React, so you can afford to make more mistakes when your baseline overhead is lower 😅  @slightlyoff can we kill the hell spawn that is electron? there is literally ONE major modern chat client today running natively, ALL others run electron - of which my macbook pro M1 16GB can't handle more than 2-3 of. nevermind everything else that now also runs electron, such as all modern game launchers and note apps. I actually uninstalled all but 1 electron app yesterday (Joplin) because i'm done running at a crawl. It feels like my computer is now inadequate to do simple, modern, tasks. @Beiz @slightlyoff I wonder how much of the weight of those Electron apps is actually due to running a separate Chromium engine per app, and how much is due to React or similar frameworks. @matt @slightlyoff does it matter? electron exists solely as a lazy shortcut anyway and doesn't actually do anything that benefits the end user, only the developers (less effort, same pay, and to hell with anything else). electron is the digital answer to quantity over quality. my intel m3 tablet hybrid can't even handle a single electron app without severely killing overall performance. but then again, neither can it do snaps or flatpaks without screeching to a halt, too.  @Beiz @slightlyoff the electronification will stop when there is one. JUST ONE. cross platform UI framework that is at least on par with it in DX @Beiz @slightlyoff as good a developer experience rust might be, it still can never compete with javascript's ease of use also most of the complaints about electron come from memory/cpu usage, which tauri is only marginally better at. it still uses chromium @Beiz @slightlyoff what about visual studio code? It's very fast and responsive and is an electron app. I think people are blaming the tools too much. The real problem is that no one in the web world knows how to actually care about optimization. Things like how many server round trips you are making to load a page are just ignored @mattcrwi @slightlyoff i think you're just too used to the overall experience of electron. it also helps to have a good computer, and only keep a few electron apps running on your system at any one time. to avoid a system wide slowdown and crashes. @slightlyoff hi, tribe is an indigenous specific word and i do not understand why youre using it in this context. u can always say "group of people" if that's what you mean...  @slightlyoff And how many of those web "applications" could be replaced by plain old HTML+CSS *websites* with little to no clientside active content at all? Your blog or company website most likely doesn't need JS at all to achieve the functionality you're trying to build. I miss the days of fully static sites (or at worst some server side templating) being the de facto standard.     @slightlyoff fascinating piece, and post, and confirms everything I've always suspected. But if you ever badmouth JS people will end you. 😂 |
Gregory's Server
There have, of course, been good reasons to lean on userland abstraction – Safari sandbagged platform advancement, much the way IE6 used to – but repeated warnings didn't cause a change in developer behaviour.
The pushback to this sitrep in 2016 was *furious*:
https://youtu.be/4bZvq3nodf4?si=A7MLssnnn-GKnv8c