So I'm not sure I understand the point of the article. Or if I do, then the argument seems unlikely.
Split the Web? On the server side? Or the client side?
Splitting the server seems unnecessary - since servers already let you serve as simple a site as you like. If you want to make simple sites with no javascript you are welcome to do that.
So split the client? Have one app to read some sites and another to read some other sites? That sounds contrarian to literally every program evolution in history. Because all client software strives to read all relevant formats (think Word loading WordPerfect files.) why would a user choose 2 separate apps when 1 would do?
It seems to me that the author misses the point that sites are javascript heavy not because they have to be, but because their makers want them to be (largely so they can make money)
Correction: Sites are javascript heavy because it is easy to accidentally create javascript-heavy sites, and the programmers who do this also do not care that they have done it.
> it is easy to accidentally create javascript-heavy sites
It's definitely not easy by any definition. And also not happening accidentally. Almost all frameworks/libraries mention about how small they are in overhead.
Split the Web? On the server side? Or the client side?
Splitting the server seems unnecessary - since servers already let you serve as simple a site as you like. If you want to make simple sites with no javascript you are welcome to do that.
So split the client? Have one app to read some sites and another to read some other sites? That sounds contrarian to literally every program evolution in history. Because all client software strives to read all relevant formats (think Word loading WordPerfect files.) why would a user choose 2 separate apps when 1 would do?
It seems to me that the author misses the point that sites are javascript heavy not because they have to be, but because their makers want them to be (largely so they can make money)