Reasons I will not take your "the web is broken" blogpost seriously (non-exhaustive):
- Does not distinguish between different ways of using tools that are designed to be used in multiple ways
- Does not distinguish between tools and their ecosystems (where those are plausibly separate)
- Recommends as the 'solution' some hyped-up novel thing that fails to clearly explain how it actually solves problems better than previous options
- Recommends as the 'solution' some commercial product
- Assumes that anything that is "standard" (usually for a remarkably narrow definition of the term) is automatically qualitatively better
- Recommends as the 'solution' some sort of strange infrastructure design that seems conveniently designed to fit one specific service provider (looking at you, Netlify)
- Does not recognize or understand the reason that "web apps" exist, and that that is a separate consideration from what web *sites* should look and work like
- Suggests replacing technologies that have nothing to do with the problem being described (usually HTTP is the victim there)
Seriously, there are so many valid criticisms to make, and so many possible paths forward. Do better, people.
Here, have a starter pack of *valid* criticisms to make about the web instead:
1. Standards development is, de facto, controlled by Google; because they are the only implementor with any serious weight to throw around anymore
2. The web development industry, like the broader software development industry, has a serious problem with susceptibility to hype; technology choices are almost entirely marketing-driven
3. Individual developers (again, like the rest of the software industry), especially the well-off and privileged ones, often feel no responsibility whatsoever for the accessibility and effects of what they build
4. The incentives in designing libraries and frameworks are such that it is always more appealing to develop a monolithic difficult-to-maintain framework, even though that is technologically the worst choice; because it gives you a clearly brandable and marketable unit rather than a forgettable tool in the toolbox
5. The educational pathways for web development are almost entirely controlled by large tech corporations (directly or indirectly), and serve as "potential future employee" training courses rather than genuine in-depth education
You will notice that the common factor is "capitalism and kyriarchy", and not "javascript"
@joepie91 The only justifiable reason for complaining about the overuse of javascript and frameworks is that website front-ends should be as lean and performant as possible for the benefit of users on dodgy mobile or super overpriced metered connections.
A bad/slow connection should never be the reason a front-end degrades to barely usable simply because an obscene amount of AJAX requests timeout and fail. >..>
@joepie91 (But obviously the capitalists don't want that, because they want to track every little thing you do on their "apps", which requires constant communication and phoning home to the servers and real-time delivery of advertisements that each all do the same.)
@dragonarchitect Oh, certainly. But unfortunately a lot of the criticisms that *seem* to be that on the surface, actually aren't that either - because there are plenty of ways to use JS responsibly that aren't taken into account in them.
Some cases I've seen people unjustifiedly extend that criticism to:
- Server-side JS (doesn't affect client at all)
- Progressively-enhanced JS (doesn't have the problems)
- Use of UI/state management libraries (including but not limited to React) for things that *need* client-side state, like soft-realtime applications
- Use of JS in narrowly-defined ways where it is verified(!) to improve the situation over a non-JS implementation
Certainly most real-world use of client-side JS is inappropriate, because capitalism, but these sorts of cases *do* actually exist, they *are* actually valid and they *do* actually need to be separated out from the criticism, and most people just don't :/
@dragonarchitect I guess the whole thing summarizes as "throwing the baby out with the bathwater", to sometimes a religious degree
@joepie91 Definitely in solid agreement with all of these points. Though I am curious what cases exist where the use of JS is verified to improve things over a non-JS implementation.
I'm multiple years out of date on the JS side of things because I've never had to build any kind of soft-realtime application before. All of my plinking about has been solid-state presentation of content that barely requires JS if at all.
The chunkiest JS I've recently used has been mathjax.
@dragonarchitect A good example of how JS can significantly improve things is "uncertain search"; there are a lot of cases where people might be searching for something, but be unsure about eg. what keywords it could be found under.
Implementing a JS interactivity layer can help to provide live suggestions/pointers on how to refine the search to actually find the thing that they want, without needing to implement "best guess" autocorrection (and all of the frustration that comes from search engines trying to 'correct' queries).
While technically *possible* without JS, it would make for a pretty poor experience; you would have to constantly submit the search form, wait for a pageload, refocus the search field (because autofocus can break accessibility expectations), and so on
You can see a similar dynamic for form validation; where a form *immediately* tells you when something doesn't pass validation, instead of expecting you to submit the form first.
For freeform classification fields, it can suggest likely known categories to reduce the amount of entries in the database that only differ from others by one character, and so on, and so forth.
These things should still be implemented in a progressively-enhanced manner, of course. But the way that many people complain about JS doesn't leave any space for this either.
(I've validated the first two with user testing; the third is an extrapolation from that that I have yet to test out)
@joepie91 Ahhh, okay. This all falls under the use of JS to improve the user experience of a web interface, in my own opinion.
And when this is the case, it becomes a comparison of how much improvement there is to the user experience to the amount of JS required to implement that improvement.
If very little script is required for a considerable enhancement, then I'd argue that it's worth it, so long as it does not break the base functionality of things.
@joepie91 I blame CSS for killing the web, because it professionalized making web pages, pushing people away from personal web pages towards social media presences instead.
@polyote That's a symptom, not a cause, and if CSS wasn't invented on a standards level then we'd now all be stuck with byzantine build tools to emulate it as a build step
@polyote Like, the whole point of my post is that technology doesn't somehow magically spawn into existence, it is developed by parties with the means and incentive to do so, and the root cause lies in those incentives, and no amount of complaining about the outcomes will solve their cause, it will just cause differently-shaped (and probably worse) things to exist that fulfill the same incentive
@polyote @joepie91 I can kinda see how CSS “professionalized making web pages”. Although I don’t agree that this somehow is contrairy to personal web pages? I mean, it’s a tool to style the content, and doing so can make a lot of sense. Like, regarding personal web pages it could enable creativity and personality in that? So I don’t see the connection why this is pushing people away and towards social media presences?
@joepie91 I think this is what baffles me about things like Gemini. Like... HTTP is fine! And IMO its flexibility is a /good/ thing! You[them, not you] wanna make it inherently /less/ flexible and useful??
Also yes, I have encountered every single one of these in the wild, repeatedly