It's not the fault of JavaScript the language, but JavaScript as the name we give to the parts of a web page that are not HTML and not CSS.

And it's not really "living is the leading cause of death"; most of that JavaScript is superfluous garbage - ad scripts, trackers, bloated frameworks. You don't need this for a page to serve a socially useful purpose. You just need someone in your company with enough clout, who's willing to say, "out of respect for our users and for engineering as a practice, we will not partake in the latest iteration of the insanity that is the modern web".

You need to be pretty damn high up in a company to overrule the business reasons for trackers, and perhaps more critically, helpdesk widgets. The size of the very common Zendesk widget is obscene.

You might not be high enough in a large company, but in smaller companies and startups, an employee-level pushback can go a long way.

> You don't need this for a page to serve a socially useful purpose.

You don't need JS to "serve a socially useful purpose" most of the time, as well.

As I said, it seems we decided that everything needs to feel like an app.

95%(yes, I'm probably exaggerating) of the actual value of the today's websites could be plain documents with links to each other.

But try and suggest to anyone you're gonna have a company presence site(or anything for that matter) with no JS at all, and see where it gets you.

I feel it's too late to escape the web browser being established as an application distribution platform - though if you're building a document, then you it to your users and your own dignity, to make it like a document, not an application. Most websites are more like documents than apps.

But my comment applies to apps as well - just because you need to write actual software, doesn't mean you should throw away sensible engineering, and produce a bloated, user-hostile, spying & battery-devouring monster. Yet this is what seems to be coming out of most web shops these days.

It is entirely possible to build rich web apps with very small size. As shown in the article, the main source of bloat are 3rd party scripts: ads, tracking, metrics, retargeting, security...

Everyone here is the choir...

Now convince the client that they don't need to track every single possible click of the user - as they experience their "journey" through the site...

...convince the client that all those experience designers effusing about that "emotional layer" they added to that user journey didn't really result in 30% more engagement with the brand - as evidenced by exactly that same user tracking - convince em XD isn't just mouthing a load of horse shit. I mean - why do all the folks in XD dress in black all the time anyway. Would someone run a focus group on that please?

Funny thing is - I don't even know if they are all full of shit or not. Maybe all this is all necessary - maybe not. I don't even know and I build this stuff for a living. Client seems happy so meh...

But yeah - these large JS bundles aint the cause of these large JS bundles... ahem - I mean these slow sites...

There are these obscure files called "logs" which record every interaction with your server. They might be useful, IDK.

I keep JS disabled so most of this crap don't bother me.

I feel like there is some happy medium. For instance, biasing toward declarative documents as much as possible (HTML and CSS DOM) and perhaps fetching and compiling/linking only needed JS functions with intelligent asset pipelines. I built production web sites with Play Framework's asset pipeline that netted a single first party JS file and no external JS. As could be expected via minimalism it felt faster than almost every site on the internet. Even with third party JS you could cache, compile/perform weak linkage step, and ship a single JS file. No site necessarily needs more than three docs (HTML, CSS, JS) for the first hit plus whatever images, sprites, and fonts load async.

You nailed it. Everything doesn't need to be a rich internet application. One important aspect of this trend is that it based on decisions made by a few for their specific use cases and then copied, without much analytical decision making, by the majority. The assumption that Facebook, Google, Amazon, or Apple know better in all categories tech contributed to widespread adoption of SPA's.

Absolutely. The obsession with trying to turn every part of software engineering into something you can generalise and framework on the frontend is the cause of our current woes.

In the post Flash days I was accepting of pushing JS use as far as possible but the fragmentation and complexity that seems to just have become implicitly accepted is just something I'm much happier looking at from a distance than wanting to ever get involved in again.

The fact that it's more difficult setting up a JS project than it is for, say, Scala which is itself a pain in the ass speaks volumes.

> The fact that it's more difficult setting up a JS project than it is for, say, Scala which is itself a pain in the ass speaks volumes.

JS allows various levels of complexity. From inlining JS inside script tags in an html file or requiring a js file in the script tag to transpiling cutting-edge JS (or dialects/supersets of JS) with sourcemaps, minification, code-splitting, etc.

The latter end of the spectrum is reasonably complex; the former is ridiculously simple. I wonder if same can be said about Scala.

JS should be used only/mostly for SPAs. and here and there to validate forms or other optional small enhancements, most websit6es that are linked here are not SPAs so should work without JS

It is not the fault of JavaScript. The article points out very directly the violator is third-party code. As a result I blame marketing and media for all that spyware/analytics bullshit that is thrust into the page.

EDIT: As I wrote this comment the title here was edited to directly reflect the nature of my comment.

It's the fault of giving every random webpage the ability to run a programming language in the browser.

For 99% of the web a markup language with triggers and async loading could have been enough to implement menus, upvote posts, post login forms, and so on.

Also, JS is cached. First time will be slow, others, not so much

The mainstream libraries are fast and optimizable (Angular/React/Vue/etc). Other, not so much.

> Also, JS is cached. First time will be slow, others, not so much

This is a very weak argument.

  * many 3rd party resources are not cacheable or may have bad policies
  * caches may be more often cold then you expect. most apps still cache large combined blobs, which will invalidate with each release.
  * pure JS size has still it's impact on performance
  * caching won't magically cut all network roundtrips which you need due to architectural reasons

Yes, but you can optimize your website for caching. Your points are valid but they mostly boil down to "people don't know/don't care what they're doing", which won't help even if you don't have JS in your site.

And it is: "still its impact"