> This isn’t about going back to table layouts or banning JavaScript.
It’s about building with intent.
> It’s not about purity. It’s about outcomes.
> Use what works.
I think the website is fast and the majority of that JS is for the comment section+recaptcha (that's also for comments?), website works without it, I can tab through things, and the site is accessible, so I don't think that hundred KB of JS is a big "gotcha!".
However, considering barely any comments, I'd honestly just consider removing them, not because I' mind the couple of hundred KBs, but because nobody uses these anymore. All discussion happens on social platforms and forums.
Solid or Preact are less than 10kb, and captcha is pretty much useless at this point in my experience. There's no reason for this site to have over 70kb of JS. My blog has a similar comment section with less 15kb of JS. The funny thing is that almost half of the 70kb is jQuery which is basically baked into the browser at this point.
However, I think that it's important to keep in mind that a "Hello World" app in NextJS is around 70kb as well, so I think that anything less than 100kb is pretty forgivable on the modern web. That's a rarer achievement than one would like to believe.
To fully clarify my belief, I use a ~$50 budget phone, and it's rarely the JS that makes the web unusable. It's usually when a website loads multiple advertisements that each contain video tags that I actually notice a degradation in experience.
Their site loads fine without JS or cookies/local storage enabled though, which is more than can be said of many sites (and tbh what I was expecting the article to be about given the dramatic headline).
On a wired connection? No problem. On a crowded mobile network? Or when you got only EDGE (hello Germany)? Whoops.
Hacker News however? Blazing fast - one page and only the CSS is actually required for rendering the page, and it is using both a cache-buster in the URL and a 10 year (!) cache life time. The JS uses the same as well but it's only loaded at the end of the page, so after rendering is done.
I find your argument disingenuous, the website is still usable with JS disabled and it's obvious the article is talking about JS-heavy websites that could do without it, not advocating for a complete anti-JS stance. It also uses HTTP3 is seems, so making 13 separate requests isn't much of an issue, it has a good performance score which is almost surprising for a Wordpress website.
Why is good performance surprising for WordPress? It's just html, and I assume it is fully cached since it's not a site that has login, dynamic stuff (that's when WordPress becomes a big problem, but can be surmounted).
"Saying JS broke the web when your website loads 754kB of JS across 13 separate requests makes me wonder if you're very serious about the problem."
Truthfully, _the website_ does not load anything. The so-called "modern" web browser used by many but not all HN commenters auto-loads resources, e.g., processing <script ... src=... > tags, and runs Javascript, e.g., XHR or fetch requests.
As such, by using a different client, not the one used by these HN commenters, this web page can be retrieved with only one HTTP request (initiated by the user) and and read, text-only, with zero Javascript files sourced.
There are of course other strategies to avoid auto-loading resources and running Javascript. IMO, anyone who is "very serious about the problem" would surely be using one of them, and probably unperturbed by yet another blog page that tries to source some standard WorddPress Javascripts.
Nor did Javascript "break the web". Web developers and web marketers did, using Javascript and browsers distributed by advertising companies, and organisations paid by advertising companies to send them data about browser users.
"JS is fine in my case. It's all those other websites that are broken!"
You can implement a captcha without JS. You don't need jQuery or jQuery-migrate in 2025. The site is using Quill for some typography tweaks that could mostly be done in CSS.
FWIW I don't think there's anything wrong with the way the site is built. It looks nice. It loads pretty fast. JS is great - it enables a bunch of capabilities for things that you can't do on a web page without it, and if you're looking for something very specific or hugely interactive it's essential. But I can make that argument because I'm not saying JS is bad. If you say JS is bad and you use it anyway for things you don't really need you're undermining your own point quite a lot.
Bitch about JavaScript all you want but this exact failure has occurred in many languages. It’s not a language failure. It’s a people failure. Nobody trains JavaScript developers properly and employers knowingly hire unqualified people to do the work. Of course the result is shit. It would be just as shitty if this were a different language.
If you want to isolate yourself from so much of the stupid then use a PiHole on your home network and stop working around JavaScript. It works for me as someone with 15 years writing JavaScript.
One theory I have is that JavaScript's originally low entry barrier as an untyped scripting language that works very close to the front end, allowed many programmers who might have found other programming languages too challenging (especially those without a comp sci degree), to be productive. This in itself is a good thing. It democratized programming to some extent. But at the same time, it populated the community with a large number (majority?) of programmers who were not well grounded in computer science or engineering practices. I worked with C++ for ten years before getting into JavaScript, and over the years I have seen some old concepts and solutions being excitedly reinvented in the JavaScript world, often suboptimally.
Except it seems to be the opposite. Over engineered solutions using React and god knows what else for things that can be done in a few lines of JS or CSS and don't need React...
We need to be honest about this. JavaScript created loads of jobs, helped people buy houses and raise families. That's real impact, and I respect that. But I can't help wondering: did we choose it because it was the best tool, or just the least terrible one that was easy enough to learn?
I'm assuming that back then, people chose JS because of its simplicity. But maybe that simplicity came with an ocean of problems. It's like we all showed up to a party because the entrance was free, but no one mentioned that each drink would cost a week’s salary. Why bother though, devs are not the ones paying the bill, right?
If you cannot do the job without things like React, Angular, or jquery you may not be qualified to write that code. On a bigger level if you cannot create an original application from scratch you aren’t a senior developer and if you don’t measure things you aren’t an engineer.
Nearly every other professional line of work has solved for this with some combination of licensing and/or broker/agent model. Developers tend to be scared shitless of industrial baselines of qualification assessments.
Again, I am saying all this as someone who wrote JavaScript for employment for 15 years and still love writing in the language.
Would it be a good thing if a million unemployed devs were employed to just dig a big hole? Or, worse, cut down forests with axes?
Job creation for the sake of it isn't a good thing. What matters is whether it creates actual value, and does so efficiently.
The thrust of this, and many similar articles, is that it JS frameworks were largely a very inefficient, ineffective solution to a nonexistent problem.
The fact that they're ALL now SSR-first - without the robust and comprehensive functionality of longstanding ssr frameworks, cms etc - proves this.
Why not learn from past failures? Then everybody gets a great user experience, not only those of us who know how to set up a pi-hole. Everybody wins! Apart from the framework-industrial complex, that is.
Well, paraphrasing Hegel, we can learn from past failures that the industry as a whole does not learn from past failures. It's just the Eternal September situation, and all we can do is tend our own gardens.
Although I agree that JS is being used incredibly irresponsibly, I also think this article is almost certainly AI-generated with minimal editing based on the way it reads, and I wish that wasn't the case because the topic deserves better than this.
[Edit: Although I recognise that em dashes are what a lot of people use to identify AI-generated text, that isn't what I was doing here. I hadn't even been considering them, to be perfectly honest.]
"At first I thought that this book was going to be like any other programming book; there's going to be some syntax a few examples a list of API's and so on, but as I read this book I realized it was like a Japanese game show - I was cast into this strange world that I didn't understand and I was forced to compete in these games of wit and strength that made no sense."
Holy s@#$! You're right. I didn't catch it at first, probably because it was on the HN frontpage. But yeah, the amount of em dashes (among other things) totally gives it away.
There were so many contradictions in the article, I was going to point them out. Don't see a point now.
As someone who makes a living by writing, this myth about em dashes is annoying. I have always used them. But now I have to avoid them so clients don't think my work is AI-generated.
I don't believe this article is largely AI-generated. It reads to me like the work of every marketer who has learned a list of "best practices" and sticks to them rigorously. It's probably also been edited so it aligns with Grammarly's or Hemingway's view of good writing.
Plus, some people seem to think that any polished, professional writing is LLM-ish because that's the style LLMs often imitate (badly).
You don't need to be an AI to use em-dashes. I actually use them quite a lot (even outside of Word) and AFAIK I am not an AI. I just care about text layout and proper use of characters. — is Alt-0151 on Windows (ok you need a keyboard with numeric pad).
the main reasons for my preference are that: gmail/fastmail are simple, I can use from multiple computers easily, have good defaults and most importantly, they almost always work. Outlook users seem to constantly have something broken.
I do realise that i am reaping the benefits of a centralised system, and in the case of gmail, monetised by advertising, surveillance and user lock-in. Probably the ideal for me would would be a self-hosted web client, e.g. Mailcow
I often see people say “JS is unstable,you’re always rewriting your code for the latest and greatest framework” and I always wonder where do you work? If I told the people I report to I can’t deliver that for you because we’re rewriting the app, I’d be out of the door soon.
The JS ecosystem is like any technology ecosystem, things change over time but you don’t have to chase the trends, be pragmatic about what you follow and trust me your life will be golden.
There was a time between 2015 and 2020 when framework fatigue was a real thing. People were jumping between angular, ember, react, vue, and if you were unlucky enough to choose react, Crazy Mad Scientist Dan Abramov was telling you YoureDoingItWrong(TM) every other tuesday and prompting everyone to rewrite their app in shame (even though they wrote it the way that was trendy LAST tuesday).
> In reality, it's almost always resume-driven development
This is what drives me crazy. I’ve been at my company for a couple decades. I want stability and long term health of the company.
The resume driven development isn’t even from the engineers, it’s from the leadership. An IT leader gets hired from the outside, starts a big project that will look good on the resume, then midway through the project, they are just far enough to try and call it a success and leverage it into a new position. Now we have a leadership change in the middle of a giant foundational shift of the infrastructure. The new leader comes in and does the same thing. I don’t see how a company can survive this long term. It creates such fragility. People like me, with little interest in job hopping, aren’t looking to resume build. I’m looking to have the company’s operations run smoothly so customers have a reliable service, so we retain them as customers… and for a little peace and stability myself. These resume building leaders make that difficult and seem to actively work against the long term health of the company. They aren’t interested in the next 10-20 years, they are only worried about their next job in 3-4 years, with no concern for the mess they leave behind.
I hope this is just a trend and it dies soon. The needless stress it has brought into my once simple life has been rather unpleasant.
It may be resume-driven, but that's the state of the world. If you fail to keep your team members and attract new ones as the team needs to grow, you are fighting a losing battle.
The people I report to are the ones telling me to rewrite the same thing every other year on a new platform and stack. It drives me mad. Challenging these ideas risks my job.
For things they don’t care about, I am using very basic tools that have worked for the last 10+ years and will likely work fine for the next 20 years. This allows me to solve new problems instead of continuing to solve the same problem over again. At least that’s my goal. In reality, it allows the tools I need (but management doesn’t care about) to “just work”, freeing me up to rearrange the deck chairs on the Titanic for them. All of this is for internal tools. We’re just raising operating costs on things that have 0 impact on revenue. I don’t really understand the vision.
In 2017, I met modern frontend. In a few hectic months, I had to learn AngularJS, Gulp, Grunt, and some CSS improvement system (LESS or Sass or something). Then I moved on to Angular and worked with it for a couple of years. For the first time, it actually started to feel worth it. But what a churn in the beginning. Angular 2, 4, 5, 6, and I think up to 9 all dropped while I was still working with it.
Since then, I’ve mostly worked with React, which is blissfully productive and unexciting in the best way possible as long as we prevent people from pulling in CV-padding material like Redux.
Over the past few years, I’ve been hired into places where I’m once again upgrading codebases written in AngularJS (yep, it still exists), Elm, and jQuery. Everything gets rewritten to React, and after that we can hire people right out of school to maintain it (as long as we keep the CV-padding libraries out of it).
I guess this is a long-winded way of saying: even if you’ve been lucky enough to work in a place where people made good technical decisions years ago, and work in a place that treat their devs well enough that someone who still remembers how it works cares to work there —not everyone’s that lucky.
> The result?
Broken back buttons.
Image bloat.
Inaccessible markup.
URLs that don’t behave like URLs.
Metadata that disappears.
Content you can’t copy.
Buttons you can’t keyboard to.
Modals that trap you.
Scroll positions that reset for no reason.
Headlines that shift mid-read.
Analytics that don’t match reality.
Preview environments that lie.
And pages that load… eventually.
--
None of that is the fault of Javascript, it's on the people building them. I'm pretty sure in an alternate universe of no JS, we would see the same articles but about the horrible user experiences of full HTML or native apps.
None of that is the fault of Javascript, it's on the people building them.
This is logically correct, but I don't think it's true in the spirit of the argument. Browsers makes it very easy to deploy a broken website. They're incredibly tolerant of faults. Consequently there's no accountability for problems.
If browsers didn't try to display broken apps in a sort-of-working-but-not-really way there'd be a lot fewer broken apps.
Javascript seems to attract the most horrible frameworks that stimulate this more than in other languages, but agreed, not the fault of the language. It's a horrible language as well, but that's another story.
This is largely because all of these frameworks are a collection of hacks to get Jacascript to do things it was never designed to do.
It seems if we want to have single page application that act like desktop apps, maybe we need a new language/technology that browsers can handle that is designed for this.
Maybe WASM is supposed to be the answer there, but it doesn’t feel like it (I haven’t really looked into it much). These JS frameworks have had way too much time to get out of hand without something coming in to fundamentally change things to make them obsolete. I worry this whole generation was raised on complexity, with nearly unlimited compute, and they lack the limitations which led to some of the more elegant solutions of the past. Though I could just be wearing rose colored glasses.
While a lot of pages would be well served by going back to a more traditional style, there are web apps that require more, and in lieu of a better alternative, people are going to keep hacking more frameworks around JS to make it happen.
I think the fact that it's a horrible language is a big contributor to the frameworks being horrible as well. There's all these incidental sacrifices that have to be made which bleed through into everything else, like handling null and undefined.
The problem is that getting those things right is 4x more difficult in a SPA app than a legacy, server rendered, app.
- No native back and forward button implementation. Now you must listen to an API and emulate the legacy behaviour.
- The concept of links, its also emulated via onClick events. This means that anything can be a link, so in many cases rows become links and their content is not really selectable as text. Legacy HTML has clear limitations for this not to happen.
- Same with buttons. There are no native buttons anymore. Anything can be a button, including any DIV with an event listener. Good luck tabbing through every DIV to get you to a button, that's also another difficult implementation.
Again, none of this is down to SPA frameworks (other than back/forward history APIs, lot of people break this unfortunately, though I've never understood how they manage to as I've never had this problem on projects I worked on). What often happens also is that people embed a bunch of iframes, and history within iframes can act very weirdly.
Links in Vue Router at least are just regular <a> tags. Yes the framework handles navigation when clicking these, but nothing prevents anyone from wrapping anything they want in an <a> tag even with no JS. You could make an entire table be clickable as a link if you wanted to, framework or not. "Legacy" HTML will render these just fine and browsers will make it a regular link, even though HTML validators will fail it.
Literally the first element anyone makes in frameworks will be a generic Button element that is simply a <button> with some styling. People abuse divs as buttons with or without frameworks because again, nothing prevents you from making any arbitrary element in your DOM have an onclick handler and act as a button. Tabbing through can even work with the correct ARIA attributes, and can even be broken on regular plain <button>s if abused hard enough.
I would seriously suggest people try out Vue or especially Svelte, they're about as simple as you can possibly get (especially Svelte 4) while giving you a lot of power and flexibility. I've worked with plenty of server-rendered apps in the past, and trust me, people would butcher things just as badly and easily there.
I wholehartly disagree - all of the mentioned problems are problems created by the developer. All these things work with the common SPA frameworks - developer just tend to forget what an anchor or a button is and use a span or div for it.
Having the proper tool and using the tool properly are two different things - and the web is a place where people forgot to do things the proper way.
Javascript is a platform that gave developers the ability to modify the core UX of web browsers. That's a platform problem, not a builders problem - if you don't want crappy apps on the web that break things, then don't give developers the power to break things.
I find this a strange way of thinking on a site called "hacker" news...
In my opinion there is NO problem. We have powerful tools that give you freedom and the possibility of tinkering. Some people will use it in ways one doesn't like, but as long as you have some possibility to use other products I think it is great.
I wouldn't trust anybody (including myself) to decide for all others what are the powers that should be given or not. The web architecture is amazing exactly because it allows everybody to build without some large body/organization/company imposing most rules.
> At the same time, JavaScript stopped being just a front-end language. With the rise of Node.js, JS moved server-side – and with it came a wave of app developers entering the web ecosystem. These weren’t web designers or content publishers. They were engineers, trained to build applications, not documents. And they brought with them an architecture-first mindset: patterns, state management, dependency injection, abstracted logic. The result? A slow cultural shift from building pages to engineering systems — even when all the user needed was to load an article.
Based on my experience, I think this is wrong. Node.js didn't open the web app gates to non-web devs (those devs more likely than not wouldn't even know JS), it was the other way round: it opened the backend gates to frontend devs, because suddenly they could use the language they know to run code in the server.
That is because the actual alternatives to JS such as Flash, Silverlight and Java Applets were much worse. Native apps are bound by the platform's walled garden and practically undiscoverable, hence the need for web apps.
Native apps. Plain HTML (sometimes with server-side apps). When Javascript was becoming a problem, native apps weren't yet the lock-in ecosystem they were today; arguably that ecosystem is only possible because everything became a web app first.
I was a professional flash/flex/air developer once. And Steve Jobs put me out of a job when he refused flash on the iPhone. The security and performance bottlenecks were real and by the time Adobe mostly fixed them in later version of the flash player, it was too late. Most devs and companies had abandoned the sinking ship.
Readit News
I think the website is fast and the majority of that JS is for the comment section+recaptcha (that's also for comments?), website works without it, I can tab through things, and the site is accessible, so I don't think that hundred KB of JS is a big "gotcha!".
However, considering barely any comments, I'd honestly just consider removing them, not because I' mind the couple of hundred KBs, but because nobody uses these anymore. All discussion happens on social platforms and forums.
However, I think that it's important to keep in mind that a "Hello World" app in NextJS is around 70kb as well, so I think that anything less than 100kb is pretty forgivable on the modern web. That's a rarer achievement than one would like to believe.
To fully clarify my belief, I use a ~$50 budget phone, and it's rarely the JS that makes the web unusable. It's usually when a website loads multiple advertisements that each contain video tags that I actually notice a degradation in experience.
It didn't. Badly engineered sites suck. Nothing new.
Hacker News however? Blazing fast - one page and only the CSS is actually required for rendering the page, and it is using both a cache-buster in the URL and a 10 year (!) cache life time. The JS uses the same as well but it's only loaded at the end of the page, so after rendering is done.
While being completely useless on mobile, with tiny buttons and textarea, which could be fixed while barely making the whole thing larger.
Deleted Comment
Truthfully, _the website_ does not load anything. The so-called "modern" web browser used by many but not all HN commenters auto-loads resources, e.g., processing <script ... src=... > tags, and runs Javascript, e.g., XHR or fetch requests.
As such, by using a different client, not the one used by these HN commenters, this web page can be retrieved with only one HTTP request (initiated by the user) and and read, text-only, with zero Javascript files sourced.
There are of course other strategies to avoid auto-loading resources and running Javascript. IMO, anyone who is "very serious about the problem" would surely be using one of them, and probably unperturbed by yet another blog page that tries to source some standard WorddPress Javascripts.
Nor did Javascript "break the web". Web developers and web marketers did, using Javascript and browsers distributed by advertising companies, and organisations paid by advertising companies to send them data about browser users.
"Websites that use JS are terrible and broken."
"Your website uses a ton of JS."
"JS is fine in my case. It's all those other websites that are broken!"
You can implement a captcha without JS. You don't need jQuery or jQuery-migrate in 2025. The site is using Quill for some typography tweaks that could mostly be done in CSS.
FWIW I don't think there's anything wrong with the way the site is built. It looks nice. It loads pretty fast. JS is great - it enables a bunch of capabilities for things that you can't do on a web page without it, and if you're looking for something very specific or hugely interactive it's essential. But I can make that argument because I'm not saying JS is bad. If you say JS is bad and you use it anyway for things you don't really need you're undermining your own point quite a lot.
Deleted Comment
Dead Comment
If you want to isolate yourself from so much of the stupid then use a PiHole on your home network and stop working around JavaScript. It works for me as someone with 15 years writing JavaScript.
I'm assuming that back then, people chose JS because of its simplicity. But maybe that simplicity came with an ocean of problems. It's like we all showed up to a party because the entrance was free, but no one mentioned that each drink would cost a week’s salary. Why bother though, devs are not the ones paying the bill, right?
https://www.aei.org/carpe-diem/milton-friedman-shovels-vs-sp...
If you cannot do the job without things like React, Angular, or jquery you may not be qualified to write that code. On a bigger level if you cannot create an original application from scratch you aren’t a senior developer and if you don’t measure things you aren’t an engineer.
Nearly every other professional line of work has solved for this with some combination of licensing and/or broker/agent model. Developers tend to be scared shitless of industrial baselines of qualification assessments.
Again, I am saying all this as someone who wrote JavaScript for employment for 15 years and still love writing in the language.
Job creation for the sake of it isn't a good thing. What matters is whether it creates actual value, and does so efficiently.
The thrust of this, and many similar articles, is that it JS frameworks were largely a very inefficient, ineffective solution to a nonexistent problem.
The fact that they're ALL now SSR-first - without the robust and comprehensive functionality of longstanding ssr frameworks, cms etc - proves this.
[Edit: Although I recognise that em dashes are what a lot of people use to identify AI-generated text, that isn't what I was doing here. I hadn't even been considering them, to be perfectly honest.]
https://www.youtube.com/watch?v=D5xh0ZIEUOE
"At first I thought that this book was going to be like any other programming book; there's going to be some syntax a few examples a list of API's and so on, but as I read this book I realized it was like a Japanese game show - I was cast into this strange world that I didn't understand and I was forced to compete in these games of wit and strength that made no sense."
There were so many contradictions in the article, I was going to point them out. Don't see a point now.
… means absolutely nothing. I’ve been heavily using them for decades at this point.
The article itself may or may not be AI-generated, but we cannot penalise folks for simply using a stylish bit of punctuation.
I was focusing more on what you called "among other things". The way that the article uses English is extremely characteristic of, say, ChatGPT.
I don't believe this article is largely AI-generated. It reads to me like the work of every marketer who has learned a list of "best practices" and sticks to them rigorously. It's probably also been edited so it aligns with Grammarly's or Hemingway's view of good writing.
Plus, some people seem to think that any polished, professional writing is LLM-ish because that's the style LLMs often imitate (badly).
Deleted Comment
Deleted Comment
What stands out most to you?
Not sure about that, I'll take Gmail and fastmail any day over outlook and evolution
I do realise that i am reaping the benefits of a centralised system, and in the case of gmail, monetised by advertising, surveillance and user lock-in. Probably the ideal for me would would be a self-hosted web client, e.g. Mailcow
The JS ecosystem is like any technology ecosystem, things change over time but you don’t have to chase the trends, be pragmatic about what you follow and trust me your life will be golden.
Since then, things have settled down a LOT.
Truth being told, Crazy Mad Scientist Dan Abramov is still doing the same thing (React Server Components) but we are not falling for it anymore
* We can't hire specialists for older frameworks.
* We can't generate positive hipe over older technologies.
* New technologies are better, so we will deliver features faster.
In reality, it's almost always resume-driven development.
This is what drives me crazy. I’ve been at my company for a couple decades. I want stability and long term health of the company.
The resume driven development isn’t even from the engineers, it’s from the leadership. An IT leader gets hired from the outside, starts a big project that will look good on the resume, then midway through the project, they are just far enough to try and call it a success and leverage it into a new position. Now we have a leadership change in the middle of a giant foundational shift of the infrastructure. The new leader comes in and does the same thing. I don’t see how a company can survive this long term. It creates such fragility. People like me, with little interest in job hopping, aren’t looking to resume build. I’m looking to have the company’s operations run smoothly so customers have a reliable service, so we retain them as customers… and for a little peace and stability myself. These resume building leaders make that difficult and seem to actively work against the long term health of the company. They aren’t interested in the next 10-20 years, they are only worried about their next job in 3-4 years, with no concern for the mess they leave behind.
I hope this is just a trend and it dies soon. The needless stress it has brought into my once simple life has been rather unpleasant.
For things they don’t care about, I am using very basic tools that have worked for the last 10+ years and will likely work fine for the next 20 years. This allows me to solve new problems instead of continuing to solve the same problem over again. At least that’s my goal. In reality, it allows the tools I need (but management doesn’t care about) to “just work”, freeing me up to rearrange the deck chairs on the Titanic for them. All of this is for internal tools. We’re just raising operating costs on things that have 0 impact on revenue. I don’t really understand the vision.
Since then, I’ve mostly worked with React, which is blissfully productive and unexciting in the best way possible as long as we prevent people from pulling in CV-padding material like Redux.
Over the past few years, I’ve been hired into places where I’m once again upgrading codebases written in AngularJS (yep, it still exists), Elm, and jQuery. Everything gets rewritten to React, and after that we can hire people right out of school to maintain it (as long as we keep the CV-padding libraries out of it).
I guess this is a long-winded way of saying: even if you’ve been lucky enough to work in a place where people made good technical decisions years ago, and work in a place that treat their devs well enough that someone who still remembers how it works cares to work there —not everyone’s that lucky.
None of that is the fault of Javascript, it's on the people building them. I'm pretty sure in an alternate universe of no JS, we would see the same articles but about the horrible user experiences of full HTML or native apps.
This is logically correct, but I don't think it's true in the spirit of the argument. Browsers makes it very easy to deploy a broken website. They're incredibly tolerant of faults. Consequently there's no accountability for problems.
If browsers didn't try to display broken apps in a sort-of-working-but-not-really way there'd be a lot fewer broken apps.
It seems if we want to have single page application that act like desktop apps, maybe we need a new language/technology that browsers can handle that is designed for this.
Maybe WASM is supposed to be the answer there, but it doesn’t feel like it (I haven’t really looked into it much). These JS frameworks have had way too much time to get out of hand without something coming in to fundamentally change things to make them obsolete. I worry this whole generation was raised on complexity, with nearly unlimited compute, and they lack the limitations which led to some of the more elegant solutions of the past. Though I could just be wearing rose colored glasses.
While a lot of pages would be well served by going back to a more traditional style, there are web apps that require more, and in lieu of a better alternative, people are going to keep hacking more frameworks around JS to make it happen.
- No native back and forward button implementation. Now you must listen to an API and emulate the legacy behaviour.
- The concept of links, its also emulated via onClick events. This means that anything can be a link, so in many cases rows become links and their content is not really selectable as text. Legacy HTML has clear limitations for this not to happen.
- Same with buttons. There are no native buttons anymore. Anything can be a button, including any DIV with an event listener. Good luck tabbing through every DIV to get you to a button, that's also another difficult implementation.
Links in Vue Router at least are just regular <a> tags. Yes the framework handles navigation when clicking these, but nothing prevents anyone from wrapping anything they want in an <a> tag even with no JS. You could make an entire table be clickable as a link if you wanted to, framework or not. "Legacy" HTML will render these just fine and browsers will make it a regular link, even though HTML validators will fail it.
Literally the first element anyone makes in frameworks will be a generic Button element that is simply a <button> with some styling. People abuse divs as buttons with or without frameworks because again, nothing prevents you from making any arbitrary element in your DOM have an onclick handler and act as a button. Tabbing through can even work with the correct ARIA attributes, and can even be broken on regular plain <button>s if abused hard enough.
I would seriously suggest people try out Vue or especially Svelte, they're about as simple as you can possibly get (especially Svelte 4) while giving you a lot of power and flexibility. I've worked with plenty of server-rendered apps in the past, and trust me, people would butcher things just as badly and easily there.
Having the proper tool and using the tool properly are two different things - and the web is a place where people forgot to do things the proper way.
All the SPA frameworks handle browser history and links correctly.
Way too many very basic UI affordances cannot be made accessible without JS if they can be implemented at all.
In my opinion there is NO problem. We have powerful tools that give you freedom and the possibility of tinkering. Some people will use it in ways one doesn't like, but as long as you have some possibility to use other products I think it is great.
I wouldn't trust anybody (including myself) to decide for all others what are the powers that should be given or not. The web architecture is amazing exactly because it allows everybody to build without some large body/organization/company imposing most rules.
Based on my experience, I think this is wrong. Node.js didn't open the web app gates to non-web devs (those devs more likely than not wouldn't even know JS), it was the other way round: it opened the backend gates to frontend devs, because suddenly they could use the language they know to run code in the server.