<noscript>
<center>
<b>notice</b>
<p>javascript required to view this site</p>
<b>why</b>
<p>measured improvement in server performance</p>
<p>awesome incremental search</p>
</center>
</noscript>They're not exclusive, smaller server loads doesn't mean the experience is better for the client.
For instance the server might just stop doing server-side template rendering. Instead it sends one static page, then the client requests and render the JSON for the article, or maybe the page only contains the JSON for the article instead of the rendered one.
Then the template rendering cost stops showing up on the server, because it's not performed on the client, and serialising to JSON is almost certainly cheaper than rendering an ad-hoc and half-assed template format.
But now the client has to perform a bunch of extra requests (to fetch the javascript and possibly the json) and it pays the cost for the template rendering, and that might be even halfer-assed, and more expensive, because it's out of sight of the server loads / logs.
The result is that the server has gone from, say, 80ms CPU to 40ms CPU per page (which definitely qualifies as a "measured improvement in server performance"), but the client now needs an additional 300ms to reach loading completion.
Depends on your definition of rightfully. This is a ad-free, cost-free website. If they want to reduce server load or prioritize something other than non-JS experience, it’s their prerogative.
Especially when the complaint is “it’s slower on my client” and not “I can no longer access the data without JavaScript”
> Worse, they essentially get taunted.
Please explain?
Much easier to do that supporting both HTTP and JS for both read and write.
Accessibility isn't any more of a problem than it is with HTML. For screen readers, et al it's still something that needs to be deliberately incorporated into the document structure, and modern frameworks are more than capable of handling it. What about older browsers with crappy JS implementations? Front-end frameworks have tools designed to extend support to much older browsers with limited JS support. The percentage of people who have access to a web browser but can't use javascript applications is vanishingly small. When I've worked with people making publicly-funded tools for which accessibility must accommodate people with very limited technical means-- unhoused people, for example-- developers tend to skip the web interface altogether and go with SMS combined with telephone or in-person service. JS is not the barrier.
Obviously that 50MB binary is hyperbole, but the baseline Vue include is 16k. It's certainly easier to make make front-end JS heavy and unreliable than plain static HTML, but it's pretty easy to avoid it, and design that poor would probably fuck up plain-old HTML and CSS just as bad. The fact is that most users do appreciate the dynamic features and responsiveness that is only possible with js. If you don't, and want to exclude yourself from modern web functionality, then be my guest. I think it's pretty strange that you'd expect other people to go out of their way to accommodate your rather uncommon preferences to make an experience most users consider worse and doesn't work towards satisfying any tangible business needs.
I didn't. I said that accessibility is no more of a problem for js-fueled pages than HTML pages, which was not always true.
> Dont even bother telling me that this use case is no longer supported
Then don't say people are making websites wrong when by common practice you're using the wrong tools to interact with them.
> I know that. That doesn't change my technical opinion that JS is way too much of a gun for documents.
Like I said, feel free to opt out of the modern internet. It's your life. It's just flatly absurd to be in your position and accuse developers of having poor practices when they provide an objectively better experience for probably 9999 out of 10000 other users by using widely accepted, standard, reliable practices that often require less development time.
I can’t count the number of SPAs that manage to break basic browser functionality like links, back/forward navigation and scrolling. It’s insane.
No. Not without knowing the use case, the requirements, the users, and all of that. Sometimes I don't need anything beyond a text editor for something I make. Use the right tool for the job.
> I can’t count the number of SPAs that manage to break basic browser functionality like links, back/forward navigation and scrolling. It’s insane.
Yes. With more powerful tools you can fuck more things up, more thoroughly than with less powerful tools. That's not a problem with tools, that's a problem with bad development and design. Assuming that the person who fucked it up that badly would have made a better experience with less powerful tools is almost certainly wrong.
Have a nice day, and enjoy your eye-sight.
I still think it's ridiculous to say that developers are doing something wrong by using modern practices just because it doesn't fit your use case. You can have your opinion all you want to and I can have my opinion about it.
Of course, some people might want additional functionality, and to facilitate that functionality, we have many technological tools at our disposal which make the process of implementing that functionality simpler than not using them. What you deem to be simple enough without being too simple is based on your use case and preferences.
I mostly browse sites with JS disabled (with lots of exceptions of course) to get rid of those awful Euro cookie banners. Are those required in US now for some reason? My browser doesn't save the cookie that says they can save cookies, so they constantly prompt me.
Almost all modern browser compromise is via JS.