My modern version of this is browsing with JavaScript disabled. Most of the sites that don’t work weren’t worth my time anyway.
Should be no need for any website to require JavaScript to function.
Ignorance is bliss I suppose.
As for music streaming and instant messaging, not everyone has/needs Discord, Slack, Teams, or anything like that. If you absolutely need it for work, just whitelist it. No problemo. And, not everyone streams music. I barely used Spotify myself until I got an office job and needed something to fill the boredom.
The issue isn't about stopping Javascript as a whole. The issue is about permissions management. Not every site needs it, so not every site should have it. If you need it to work for a webapp, just enable it.
I kind of disagree though, most websites do need javascript even if they simply contain only an article. Extremely few devs will care about the astonishing minority that disables javascript by default and saying that the websites that do this is trash, like so many people that favor this kind of thinking does, is being ignorant.
The javascript hate is strange because it's like people would hate programs written in python for no other reason than the program being written in python. I think it comes down to devs not being able to chose and that the only real choice is already made for them so then they end up hating it.
But even alternatives like Phoenix Liveview / Hotwire that minimizes the usage of javascript requires javascript to work properly. In time I believe most websites will ship a wasm binary and then this debate will be over forever and javascript will become irrelevant.
But what do I know? :)
It is one of those things where in theory if absolutely everything was done right and no other stuff was done differently it can work. E.g. if the only difference between a JS-enabled and a JS-disabled version of the site was the content change and nothing else (no additional JS frameworks, functionality or whatever) then yes it most likely can be faster (though for the difference to be noticeable the site needs to be rather heavy in the first place).
Problem being that in practice this comes with a bunch of other baggage that not only throws the benefit out of the window but introduces a bunch of other issues as well.
The reality is, with node junk, the average site uses 10mb of js, taking 5s to render, to show 1kb of text.
Get rid of that 10mb of js, all those fonts, and you don't need to update only part of a page.
It will load and render in 10ms.
Conditional loading certainly can improve perf. in theory. I've yet to see any evidence it does so in practice. The aggregate of bundle-size, bundle-parse, client-side execution resource-usage & added latency of the plethora of metadata normally bundled with API responses is more than enough to negate any actual perf. gains.
As for "easier to maintain", I've never seen anyone even try to make that argument in theory, nevermind practice. Pretty sure it's widely accepted even by advocates of this architecture that it's a trade-off of perf. gains for ease-of-maintenance losses.
It moves some of the rendering work from the backend (having to query the data and generate markup) to the browser (query the API and generate the content based on the responses).
At my current job, it's made a significant improvement. The server returns compact JSON data instead of HTML, so it's easier to generate the data and uses less bandwidth.
It also looks faster for the user, because they change search parameters and only part of the page changes, rather than reloading the entire page.
As for "easier to maintain", that may be subjective. Code to generate a simple HTML template from results is replaced by JavaScript code to hit the API and generate the DOM. Although HTML5 templates makes that much easier.
If most examples of a strategy make things worse, and only one person uses that strategy to improve things, then going around saying "everyone is doing it wrong" rather than questioning the strategy isn't particularly sound.
I've build plenty of (small) client-side rendered UIs myself that lazy-load content; I know the trade-offs and I even believe I can achieve a performant outcome on my own. But that's anecdotal. In the wild, I have not seen a single major website improve perf. via lazy-fetched content rendering.
> My modern version of this is browsing with JavaScript disabled. Most of the sites that don’t work weren’t worth my time anyway.
I think a lot of sites that require JavaScript are worthwhile.
(Whether they are all well implemented is another matter.)
For the main content, yes, yes, most will. Why are they on the website in the first place?
Especially the main content. Sure, some things you can load later, like comments, etc
Many years ago smart frameworks implemented smart stuff like you can display only what is visible. For example you could have a table with 1 million rows but in your html page you will not create 1 million row elements, you can create GUI widgets only for the visible part, as the user scrolls you can recycle existing widgets.
As a practical example , you go to a yotube channel page and they load only 2 or 3 rows of videos and you have to scroll to force more to appear, this means you can't do a Ctrl+F and seatrch and is also less efficient because as you scroll the items at the top are not recycled and reuse so probably more memory is used.
The json for all the videos is not huge,some strings with title and thumbnails, maybe some numbers but the issue is that is not possible to natively do the best/correct thing, only recently we got lazy loading for example so basicaly html was desibned for documents and frameworks/toolkits designed for apps did the correct thing many years ago... this is an explanation but no excuse why things are such a shit show with pagination today.
Today's Google Maps is a shadow of its original self, which did have a no-JS version, by the way. It has gradually gotten simultaneously heavier, less convenient, more annoying, and less useful, and I've just about had it.
Just off the top of my head, it no longer displays zip codes, takes a long time to load, has missing street names on the map, often promotes features I do not want while taking away features I do want, and is covered so thick with paid-promotion items that I can barely find somewhere to click that isn't an ad.
Strange, it does for me, everywhere where it shows an address.