The way to look at it, is that browser is a target runtime platform.
When you write code in a team, you optimize for readability, maintainability etc. You spread your code over 5 directories, 50 subdirectories, 3000 files.
When you want to run this in a browser environment, it needs to be optimized for delivery - faster download, less time-to-be-interactive. You need to split your JS codebase as per routes in your app, and load chunks as per user demand.
Not just JS, you'd have to compile and inline your CSS, base-64 encode your images to data-urls, generate image stripes.
Before all these, you'd have to lint your code, and run unit tests on your code.
I fail to see how you can do all these with just a script tag. You need some sort of a compiler / transpiler; and a task runner that gives you a handy interface to these.
The package manager has no dependency, other than the Node runtime itself.
As for arbitrary toolchain, the metadata is codified with semantic versions in your package.json. You're one install step away from downloading all the necessary packages.
One thing I think lot of Node project misses, is to not add which Node version is to be used. It's not because it's impossible to do that - there are two well documented ways to do that (via .nvmrc and "engines" entry in package.json)
The fundamental issue is that the overwhelming majority of interactive websites today don't actually need to be interactive, and may even be better off as old-fashioned HTML pages served by the server.
But people love over-complicating stuff, and when the end result is complex the toolchain has to be complex too, not just for one person but the whole team. Then you end up with developers who spend more time wrestling with webpack et al than working on actual features.
Can you list any examples? My hunch is that there are good reasons javascript is included on most sites where it is found.
Some of the incentives fueling this trend could be viewed as undesirable (e.g. monstrous ads on news sites as a desperate bid for profitability), but that doesn't negate the fact that the incentives exist, and aren't simply "people love over-complicating stuff".
Most of the web is so-called "content". Formatted text, images, video, audio. These require very little interaction. If you don't have user interaction and are just serving content, you probably need very little javascript. So I would say most major news sites, weather sites, etc. are examples.
To illustrate, hacker news and reddit work fine with javascript disabled, and the javascript they use is simple and just makes some interaction like voting work nicer. Even amazon, which is a pretty bulky and interaction-heavy site, works quite well with javascript disabled.
As for incentives vs over-complication, there's an interaction there. The incentives are to put some fancy whirly whingding on your website because it looks flashy and your target audience has (according to you) fast internet connections and web browsers. The incentives are to do this with the minimum of effort even if that means serving multiple-meg, javascript-heavy pages that don't even have any interaction.
In my experience, even conventional form interactions like a list view with mass actions can be impossible without Javascript, and then unwieldy without some sort of framework to keep the UI consistent and a pleasure to use for users.
I wish this "the web is over complicated" meme would die. The web at one point was only for hypertext. It is still fine for hypertext but it is now also an application platform and the browser a runtime and app container.
Your solution to the JS ecosystem is to make news websites less interactive. I see why you long for simpler times but I don't see how that fixes things.
For those of us who are building applications we need the complexity. It solves problems that come from the fact that the web has evolved from a hypertext system to an application platform.
The issue is not that "the web is over complicated". The bigger issue is that people are allowing themselves to be brainwashed into thinking that everything is a "web application". Some sites offer benefits as web applications; GMail and Pivotal Tracker come to mind right away as good examples. Other websites like CNN should not be applications and would do end users a disservice by over-complicating things by making them JavaScript based.
One of the trends I'm seeing is that a lot of developers once they have built one web site as a SPA they seem to start thinking everything should be built this way. More consideration should be given to deciding which is appropriate.
I think this sums up the most poignant complaint against the javascript/node trend. It's not that we don't need SPA's. SPA's are awesome. But sites like Reddit and Hacker News prove that they don't need to be implemented everywhere.
>>For those of us who are building applications we need the complexity
I'm not saying don't build applications. I'm saying web applications can be server-only and should not spill over into the client.
Again there are exceptions - things like control panels or consoles do benefit from being SPAs. But in a lot of cases there is also nothing wrong or insufficient or unsatisfactory (from a UX perspective) about clicking a link and having the server send you pre-rendered HTML. JavaScript can still be used as icing on the cake to enhance those interactions, such as by displaying a spinner on the submit button and disabling it once the user clicks it.
I think your point stands, but something feels wrong to me about "you optimize for readability [...] You spread your code over 5 directories, 50 subdirectories, 3000 files."
We need lots of tooling to keep our code readable across a zillion files.
And it is worse than you mention. You rarely get 60 files per directory, and, in addition to the files you want, your package manager and build system add a few zillion of their own that all can break your build in 'interesting' ways.
When you write code in a team, you optimize for readability, maintainability etc. You spread your code over 5 directories, 50 subdirectories, 3000 files.
When you want to run this in a browser environment, it needs to be optimized for delivery - faster download, less time-to-be-interactive. You need to split your JS codebase as per routes in your app, and load chunks as per user demand.
Not just JS, you'd have to compile and inline your CSS, base-64 encode your images to data-urls, generate image stripes.
Before all these, you'd have to lint your code, and run unit tests on your code.
I fail to see how you can do all these with just a script tag. You need some sort of a compiler / transpiler; and a task runner that gives you a handy interface to these.
The package manager has no dependency, other than the Node runtime itself.
As for arbitrary toolchain, the metadata is codified with semantic versions in your package.json. You're one install step away from downloading all the necessary packages.
One thing I think lot of Node project misses, is to not add which Node version is to be used. It's not because it's impossible to do that - there are two well documented ways to do that (via .nvmrc and "engines" entry in package.json)