> 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.
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.
"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.
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.
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?
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.
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.
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).
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.
> 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.
While I don't agree with other points, things got clearer once I reached the following:
> Marketers, content editors, SEOs, designers – they’re all locked out of the process. Because now, even simple tasks require technical fluency.
I worked in web development in the 2000s and then restarted in 2020s. The power of the tools, the speed of development and the result are all much better. The downside? You need to know more (because you can do more and some required things are more complex and people expect more) and less people might be required (ok, this is a downside for some people only...).
Why are we talking about some megabytes transferred nowadays? Most of us have in our pockets a computer 100 times stronger than the first one that beat a human at chess (not to mention that one was occupying rooms). It is more important to have the flexibility and to be able to scale complexity when you need to (hard and not given even with the frameworks), than to "save" some megabytes.
These articles always suggest that minimal HTML and jQuery is enough. Like, I guess for a blog, but like, not for web apps? That's the other weird thing - they're always framed like the entirety of the internet is blogs or whatever. How many software engineers are working on blogs? Everything is a webapp now, the vast majority of the time most users spend interacting with the internet is through complex applications like Spotify, YouTube, Gmail, Netflix, Google docs, notion, linear, etc etc etc. I guess there's an audience for complaining about react for some reason
I’m a big fan of the web. I think a lot of people misunderstand its design and fail to grasp how important various aspects of its architecture contribute to its success. It’s very common for people to see it as nothing more than a delivery system for imperative code to run without installation on clients. That’s where the overuse of JavaScript comes from.
But JavaScript itself isn’t bad. JavaScript was an incredible improvement to the web. It’s when people pass over the web in favour of writing JavaScript apps that the problems arise. I think it would do good for people who spend all day writing React apps to spend some time working with things like HTMX to break out of that mindset and get a bit of perspective on how the web is supposed to work.
> This isn’t evolution. It’s self-inflicted complexity.
> This isn’t accidental. It’s cultural.
> We’re not innovating. We’re rebuilding broken versions of tools the web already gave us – and doing it badly.
> We’re not iterating toward impact – we’re iterating just to stay afloat.
It's not X, it's Y? Dashes? Question fragments? This style isn't just tedious—it's a hallmark of LLM-generated content.
The whole article feels like low-effort LLM-generated clickbait to fan the eternal flamewar between web developers and web app developers. Yes, you might not need React for a static blog. Yes, React is useful for writing web applications. Can we talk about something else now?
Some people rightly pointed out that it was a bit hypocritical of my site to be loading a bunch of third-party JS and resources(!), which I've now addressed.
In my defence, this was only due to loading ReCAPTCHA on blog posts as a quick protection mechanism from an influx of spam - which I've now replaced with Turnstile (and only lazily trigger the JS+resources for that when the comment form enters the viewport).
Also, no, the post wasn't written by AI / ChatGPT / etc. :)
Language wars tend to get emotional, as clearly suggested by other commenters.
I think the problem is exasperated when developers can’t put emotion aside and recognise issues, it may be as simple as proper training or choosing the proper tools.
But just objectively looking at the point the author is making, he is right.
Case in point, Indiscriminate use of frameworks have made the web bloated. In fact, I bet half the
Links posted in HN won’t even open in slightly older browsers.
But the content they post are interesting. It is not a question of skill, as other commenters here want to point out.
So it seems to argue that these people just don’t care about accessibility or coverage of the tools they use.
Empathy is key. One should be conscious towards their audience, since web is open and far reaching. It is not just a group of developers in their near vicinity or latest conference hosted in a tech city, they should care about.
If you are building something, one should carefully evaluate the tools they use and how it will end up getting consumed by a wide demography of end consumers, who don’t have the same machine as they do.
In 2010, Facebook was one of the best websites to browse. It was everything you wanted a central social media platform to be. You could stay updated about your friends, family and even host pages for your business on it. Everything was just so simple - because they respected what a "hyperlink" actually meant.
Fast forward today, I click on a dropdown on a post with barely 3-4 options, there's a spinner, a dozen requests in the network panel and the menu doesn't even load and gives up. Frontend libraries like React made frontend so needlessly complex that they actually ended up killing the definition of what a hyperlink is.
You click on a link today, it can either take you to where it's supposed to take you, open a dozen random popups or wipe your bank account clean. I miss the good old 2000s era where JS was minimal and the focus was on HYPER TEXT in HTML. We had good content, less frontend complexity. And we had flash for everything else.
Until last year, you could still experience that thanks to the "mbasic" version of Facebook. It was truly blissful, like the good old times. But it was increasingly buggy and they killed it for good last year.
The Facebook iOS app used to be great too when it was developed by one man. Or at least I thought so at the time. I can’t remember if that was the app designed by Joe Hewitt or Adam Ernst.
It’s really weird these posts that come up with this weird fiction that somehow the web was better in the past.
I’ve seen the whole thing, was there every day for it, and it was never better in ye olde days. It was shit.
And I also don’t buy the moaning and bitching about how bad JavaScript is, and how terrible web sites are these days.
These curmudgeons invite you to join in their sad lament for the fabulous days of yore, and how everything’s just awful today.
The truth is it’s an embarrassing wealth of riches on the web. Sites are (mostly) fast, broadband is fast, content is rich, lots is free, and there’s just an unbelievable number of incredible apps and sites.
And it’s all driven by JavaScript, which isn’t a terrible language it turns out to be a warty, weird, inconsistent yet incredibly flexible and powerful language that has grown and stood the test of time.
So when this latest grumbler invites you to grumble with him, maybe instead see reality instead of the fictional past he presents.
> It’s easier to win an argument by citing SSR compatibility issues than it is to ask, “Why are we using React for a blog?”
I've asked myself this a LOT - the past few years especially.
I think the biggest reason, which the author doesn't touch on, is that *React won*. React won vs. alternatives so much and so thoroughly that it started to be used for everything - even in places that it clearly should not be, like static content pages. The reality is that in most frameworks, it's easier to make the whole page with React for the once piece of the page you needed to be interactive than to make the whole page static and do some vanilla JavaScript manually. The React ecosystem is HUGE, and most developers out there are just gluing things together.
Some "interactive islands" frameworks like Astro and Hyperspan (my own project) are starting to finally change this approach and make the "mostly static with JS sprinkles" approach easier, but they are a late reaction to the core problem described in this post. It will take time for these approaches to gain traction.
[+] [-] onion2k|8 months ago|reply
[+] [-] serial_dev|8 months ago|reply
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.
[+] [-] Springtime|8 months ago|reply
[+] [-] norman784|8 months ago|reply
[+] [-] mschuster91|8 months ago|reply
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.
[+] [-] Zealotux|8 months ago|reply
[+] [-] unknown|8 months ago|reply
[deleted]
[+] [-] 1vuio0pswjnm7|8 months ago|reply
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.
[+] [-] nchmy|8 months ago|reply
[+] [-] kachapopopow|8 months ago|reply
[+] [-] rizky05|8 months ago|reply
[deleted]
[+] [-] austin-cheney|8 months ago|reply
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.
[+] [-] hliyan|8 months ago|reply
[+] [-] pyman|8 months ago|reply
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?
[+] [-] zwnow|8 months ago|reply
[+] [-] sir_pepe|8 months ago|reply
[+] [-] Sophira|8 months ago|reply
[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.]
[+] [-] RajT88|8 months ago|reply
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."
[+] [-] CreepGin|8 months ago|reply
There were so many contradictions in the article, I was going to point them out. Don't see a point now.
[+] [-] unknown|8 months ago|reply
[deleted]
[+] [-] nchmy|8 months ago|reply
What stands out most to you?
[+] [-] glutamate|8 months ago|reply
Not sure about that, I'll take Gmail and fastmail any day over outlook and evolution
[+] [-] Lapz|8 months ago|reply
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.
[+] [-] phendrenad2|8 months ago|reply
Since then, things have settled down a LOT.
[+] [-] vasachi|8 months ago|reply
* 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.
[+] [-] al_borland|8 months ago|reply
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.
[+] [-] eitland|8 months ago|reply
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.
[+] [-] dgb23|8 months ago|reply
[+] [-] hakanderyal|8 months ago|reply
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.
[+] [-] onion2k|8 months ago|reply
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.
[+] [-] anonzzzies|8 months ago|reply
[+] [-] Xenoamorphous|8 months ago|reply
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.
[+] [-] farseer|8 months ago|reply
[+] [-] immibis|8 months ago|reply
[+] [-] dudeinjapan|8 months ago|reply
[+] [-] vladms|8 months ago|reply
> Marketers, content editors, SEOs, designers – they’re all locked out of the process. Because now, even simple tasks require technical fluency.
I worked in web development in the 2000s and then restarted in 2020s. The power of the tools, the speed of development and the result are all much better. The downside? You need to know more (because you can do more and some required things are more complex and people expect more) and less people might be required (ok, this is a downside for some people only...).
Why are we talking about some megabytes transferred nowadays? Most of us have in our pockets a computer 100 times stronger than the first one that beat a human at chess (not to mention that one was occupying rooms). It is more important to have the flexibility and to be able to scale complexity when you need to (hard and not given even with the frameworks), than to "save" some megabytes.
[+] [-] gbromios|8 months ago|reply
[+] [-] vikramkr|8 months ago|reply
[+] [-] JimDabell|8 months ago|reply
But JavaScript itself isn’t bad. JavaScript was an incredible improvement to the web. It’s when people pass over the web in favour of writing JavaScript apps that the problems arise. I think it would do good for people who spend all day writing React apps to spend some time working with things like HTMX to break out of that mindset and get a bit of perspective on how the web is supposed to work.
[+] [-] brushfoot|8 months ago|reply
> This isn’t accidental. It’s cultural.
> We’re not innovating. We’re rebuilding broken versions of tools the web already gave us – and doing it badly.
> We’re not iterating toward impact – we’re iterating just to stay afloat.
It's not X, it's Y? Dashes? Question fragments? This style isn't just tedious—it's a hallmark of LLM-generated content.
The whole article feels like low-effort LLM-generated clickbait to fan the eternal flamewar between web developers and web app developers. Yes, you might not need React for a static blog. Yes, React is useful for writing web applications. Can we talk about something else now?
[+] [-] jonoalderson|8 months ago|reply
Some people rightly pointed out that it was a bit hypocritical of my site to be loading a bunch of third-party JS and resources(!), which I've now addressed.
In my defence, this was only due to loading ReCAPTCHA on blog posts as a quick protection mechanism from an influx of spam - which I've now replaced with Turnstile (and only lazily trigger the JS+resources for that when the comment form enters the viewport).
Also, no, the post wasn't written by AI / ChatGPT / etc. :)
[+] [-] potato-peeler|8 months ago|reply
I think the problem is exasperated when developers can’t put emotion aside and recognise issues, it may be as simple as proper training or choosing the proper tools.
But just objectively looking at the point the author is making, he is right.
Case in point, Indiscriminate use of frameworks have made the web bloated. In fact, I bet half the Links posted in HN won’t even open in slightly older browsers.
But the content they post are interesting. It is not a question of skill, as other commenters here want to point out.
So it seems to argue that these people just don’t care about accessibility or coverage of the tools they use.
Empathy is key. One should be conscious towards their audience, since web is open and far reaching. It is not just a group of developers in their near vicinity or latest conference hosted in a tech city, they should care about.
If you are building something, one should carefully evaluate the tools they use and how it will end up getting consumed by a wide demography of end consumers, who don’t have the same machine as they do.
[+] [-] neya|8 months ago|reply
Fast forward today, I click on a dropdown on a post with barely 3-4 options, there's a spinner, a dozen requests in the network panel and the menu doesn't even load and gives up. Frontend libraries like React made frontend so needlessly complex that they actually ended up killing the definition of what a hyperlink is.
You click on a link today, it can either take you to where it's supposed to take you, open a dozen random popups or wipe your bank account clean. I miss the good old 2000s era where JS was minimal and the focus was on HYPER TEXT in HTML. We had good content, less frontend complexity. And we had flash for everything else.
[+] [-] reddalo|8 months ago|reply
[+] [-] sotix|8 months ago|reply
[+] [-] andrewstuart|8 months ago|reply
I’ve seen the whole thing, was there every day for it, and it was never better in ye olde days. It was shit.
And I also don’t buy the moaning and bitching about how bad JavaScript is, and how terrible web sites are these days.
These curmudgeons invite you to join in their sad lament for the fabulous days of yore, and how everything’s just awful today.
The truth is it’s an embarrassing wealth of riches on the web. Sites are (mostly) fast, broadband is fast, content is rich, lots is free, and there’s just an unbelievable number of incredible apps and sites.
And it’s all driven by JavaScript, which isn’t a terrible language it turns out to be a warty, weird, inconsistent yet incredibly flexible and powerful language that has grown and stood the test of time.
So when this latest grumbler invites you to grumble with him, maybe instead see reality instead of the fictional past he presents.
[+] [-] mirekrusin|8 months ago|reply
[+] [-] I_complete_me|8 months ago|reply
[+] [-] cherryteastain|8 months ago|reply
Funny, in the context of Germany's ATC working off some Emacs Lisp cooked up by one dude in just a week back in the 90s [1]
[1] https://old.reddit.com/r/emacs/comments/lly7po/do_you_use_em...
[+] [-] vlucas|8 months ago|reply
I've asked myself this a LOT - the past few years especially.
I think the biggest reason, which the author doesn't touch on, is that *React won*. React won vs. alternatives so much and so thoroughly that it started to be used for everything - even in places that it clearly should not be, like static content pages. The reality is that in most frameworks, it's easier to make the whole page with React for the once piece of the page you needed to be interactive than to make the whole page static and do some vanilla JavaScript manually. The React ecosystem is HUGE, and most developers out there are just gluing things together.
Some "interactive islands" frameworks like Astro and Hyperspan (my own project) are starting to finally change this approach and make the "mostly static with JS sprinkles" approach easier, but they are a late reaction to the core problem described in this post. It will take time for these approaches to gain traction.