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.
serial_dev · 4h ago
> 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.
cyanydeez · 2h ago
Someone should write a meta forum that just overlays related posts.
Springtime · 5h ago
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).
norman784 · 5h ago
You are being generous, most sites ships at least few MB of JS garbage.
Zealotux · 4h ago
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.
kachapopopow · 5h ago
Well, it's just wordpress and captcha can only be done in js (half the requests).
onion2k · 5h ago
This is the 'no true Scotsman' argument.
"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.
dudeinjapan · 5h ago
No true Scotsman would ever use Javascript… I guess I need to buy a kilt!
zaphirplane · 4h ago
Absolutely, do as I say not as I do.
josephg · 5h ago
Why does a blog post need a captcha?
serial_dev · 4h ago
I think it's loaded by the comment section.
mschuster91 · 5h ago
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.
gf000 · 5h ago
> Hacker News however?
While being completely useless on mobile, with tiny buttons and textarea, which could be fixed while barely making the whole thing larger.
ale42 · 5h ago
That's not a JS problem. It's a UI problem and you mostly solve it with CSS and adapting the HTML, you don't need to add a 3 MB JS framework for that.
ffsm8 · 4h ago
Maybe we can do the fotm and instead generate it on the fly via an LLM?
Each user can get their own stylesheet and every request will be a small surprise how it looks.
Fantastic idea, right? No? Always these haters...
vachina · 5h ago
Hacker news is perfect on mobile. How often do you vote? It is so content dense it’s perfect for mobile.
gf000 · 6m ago
Have you tried Sync, the reddit client? It's basically the same kind of content and it's night and day how much more usable and readable it is. Meanwhile I have to use a Firefox extension to make HN black-on-orange.
But credit to lobster.rs, they also did an excellent job with the UI on web tech, while still being very reasonable on the css/JS side (though I can't check right now how much they serve)
queenkjuul · 33m ago
The reply, parent, context, and collapse buttons are almost unusably small
reddalo · 4h ago
I agree, it could become way better on mobile with just some small fixes. But in some ways I'm more afraid of a complete redesign.
samat · 5h ago
Life changer for me was discovery of Scaling in iOS Safari.
125% it’s quite nice, actually. Large enough font to read.
nurumaik · 3h ago
Hacker News is the only usable mobile website
gf000 · 4m ago
Maybe that was true when we were using feature phones where you had to navigate up/down link-by-link in some awful UX.
austin-cheney · 6h ago
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.
hliyan · 3h ago
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.
pyman · 4h ago
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?
austin-cheney · 3h ago
JavaScript employment always felt like a spoons versus shovels type story.
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.
zwnow · 6h ago
Agree, been working with Js (frontend only) for a few years now and never had real issues. I wouldn't chose it for my backends though...
sir_pepe · 6h ago
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.
falcor84 · 5h ago
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.
Sophira · 5h ago
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.]
RajT88 · 41m ago
James Mickens on learning Javascript by using the O'Reilly Definitive Guide book:
"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 · 5h ago
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.
eadmund · 4h ago
> the amount of em dashes
… 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.
serial_dev · 4h ago
em dashes are not a crime!
Sophira · 4h ago
I would argue that em dashes themselves are not the giveaway that people think they are, and I wish they weren't discriminated against like this.
I was focusing more on what you called "among other things". The way that the article uses English is extremely characteristic of, say, ChatGPT.
kitten_mittens_ · 5h ago
Why are em dashes a giveaway? They’re auto inserted on Windows for two hyphens still, aren’t they?
tallytarik · 5h ago
LLMs seem to use them at a rate far higher than the average person, same with the words “delve” and “robust” (and many others)
ale42 · 5h ago
Not in every application -- these are two hyphens, Windows didn't touch them.
ale42 · 5h ago
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).
CreepGin · 4h ago
Well, you may need to worry about them now. It's a well-known issue with the mainstream LLMs. Every few days, you see a new post on reddit from people asking how to get rid of em dashes from ChatGPT, etc.
Even when they are not a telltale-sign, folks are afraid of using them now because of AI. I'm not saying em dashes are bad. Our books are littered with them, and that's why LLMs spit them out consistently.
The funny thing is, I wasn't even thinking about the em dashes when I made the initial comment. I had been concentrating on the usage of English in general in the article, which to me is a far more obvious sign of AI generation than the usage of em dashes is.
CreepGin · 4h ago
yup, "em dashes" was just easier for me to type to give an example/heuristic. Everything else would require a tad more effort to explain.
I was scratching my head pretty much the whole time during the first read.
Veen · 4h ago
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).
CreepGin · 4h ago
I feel you. Nowadays I have to use tactical lowercasing and curses here and there to avoid AI-looking responses.
> It reads to me like typical marketing writing.
hmm maybe that's why it rubbed me the wrong way.
glutamate · 6h ago
> Spoiler alert: we didn’t get app-like performance. We didn’t get better user experiences.
Not sure about that, I'll take Gmail and fastmail any day over outlook and evolution
jxjnskkzxxhx · 5h ago
Is your problem with outlook specifically or with email apps in general? Wanna tell us more about it?
glutamate · 4h ago
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
Lapz · 5h ago
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.
phendrenad2 · 5h ago
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).
Since then, things have settled down a LOT.
RedShift1 · 5h ago
Yeah true especially if you were trying to use Typescript. Every npm update broke things.
owebmaster · 2h ago
> 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
vasachi · 5h ago
Usual arguments for "upgrading" are:
* 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 · 4h ago
> 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.
brulard · 5h ago
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.
al_borland · 4h ago
Maybe all these needless technology shifts are the reason the team members are leaving.
brulard · 2h ago
I didn't see many needless ones, but I've seen many team members not wanting to hear about any change. It's hard enough to push a greatly needed change through management. Maybe there are places where they do it just for fun.
al_borland · 5h ago
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.
eitland · 5h ago
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.
dgb23 · 5h ago
To contrast: JS _the language_ is one of the most stable languages out there.
hakanderyal · 5h ago
> 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.
onion2k · 5h ago
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.
anonzzzies · 4h ago
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.
al_borland · 4h ago
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.
anonzzzies · 3h ago
> Though I could just be wearing rose colored glasses.
> al_borland
Borland had a nice and not complex solution. Which made for very fast, low latency interfaces. Everyone starts crying when you don't have the react, downward reactive (well, for some definition of this leaky abstraction thing they call reactive because javascript doesn't support anything to help), but with simple events, getters and setters it was much much clearer what was happening every tick and you could optimise, even as junior, accordingly because everyone gets it all after 10 minutes of tutorial of how it works. I have seniors asking me (every few days) why something doesn't or does update in react or why it's so slow to input something in a field in react (we fix or patch horrible software for a living, so we see 100s of different companies over the months / years; these are not the same seniors asking me this; there are very very few people actually understanding how it works and how not to crash and burn because it LOOKS like you can do something in 'this way' (even on the official react site), but when you do it, you machine gun yourself in your legs).
Not to mention that you would end up with a consistent UI with shortcuts that every user could use immediately instead of the shitshow of 'designer' choices.
seanparsons · 4h ago
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.
dgb23 · 5h ago
> Inaccessible markup
Way too many very basic UI affordances cannot be made accessible without JS if they can be implemented at all.
helloguillecl · 5h ago
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.
sensanaty · 4h ago
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.
chrisandchris · 4h ago
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.
gherkinnn · 5h ago
The problem is that it is at least 4x easier get everything wrong using an SPA.
All the SPA frameworks handle browser history and links correctly.
Taek · 5h ago
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.
vladms · 5h ago
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.
LunaSea · 5h ago
This is nonsense, any language makes it possible to crash a program but somehow it's only an issue for JavaScript
Xenoamorphous · 4h ago
> 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.
neya · 4h ago
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.
sotix · 1h ago
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.
reddalo · 4h ago
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.
bitbasher · 25m ago
If anyone is interested in building resilient websites that don't require JavaScript (but can use it to enhance the experience), here's your gateway drug: https://resilientwebdesign.com/
vlucas · 1h ago
> 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.
farseer · 6h ago
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.
immibis · 4h ago
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.
dudeinjapan · 5h ago
Come on now. Flash, security holes aside, was way better! It even had ActionScript which was essentially JavaScript.
farseer · 1h ago
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.
gbromios · 6h ago
I wish that it did actually break the web so I didn't have to see this same dumbass article every two weeks
ale · 4h ago
Brought to you by chatGPT this time!
agos · 5h ago
seriously. add to it the endless streams of comment in the same vein every time something related to frontend development is announced
fabianmg · 5h ago
As soon as I read "award-winning SEO consultant" I stopped reading, another marketing guy...
vladms · 5h ago
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.
wffurr · 5h ago
The fast pocket computer might be fairly common in fully developed countries, but bandwidth is not. It’s trivial to run into use cases with limited network bandwidth regardless of how fast your iPhone is.
And if you broaden your idea of your user base a bit, even the fast computers aren’t ubiquitous. Try using a low end Android phone sometime, or a hand me down iOS device still on iOS 12.
em-bee · 3h ago
bandwidth is not the problem. latency is.
a site where every interaction requires an http request and a reload of the page performs much worse over low latence than an SPA that is designed with a local first approach where all interaction is local and data requests happen in the background.
not all SPAs are designed like that. but none of the traditional sites are designed like that either because they can't.
take hackernews as an example. in order to write a reply i have to click a link, wait for the page to load, click submit, wait for the submission to complete and for the updated page to load.
i live with bad internet. submissions and pageloads on hackernews frequently time out.
with an SPA the first click would open a text field without any server request at all, and submit would happen in the background while i can keep reading. and it can be repeated if it fails without me noticing and having to worry about it.
likewise updating for new messages could happen in the background without me having to wait for a page load. on top of that new messages could show up in a different color without having to track that in the server.
immibis · 4h ago
A low-end Android phone that is 100 times as fast as a Cray 1, yet still can't load a blog post.
jauntywundrkind · 4m ago
There's a lot of good deep questions and challenges here. There's a lot of general anger and rage against the web, against JavaScript, but there's specific complaints that are much more real here:
> It doesn’t matter if you’re publishing a blog post or an ecommerce site – the stack is the same. Heavy, abstract, engineered to the edge of usefulness. And nobody understands it. Not fully.
That so many folks are using the same stack seems much much more likely to mean that people do understand it. Pax Reactus feels absurd but the reason it's so saturated is because it's what we know, because it's what's done elsewhere. It's done because lots of people do know it.
> And the worst part? Most of this complexity exists just to retrofit things we used to get by default: routing, metadata, caching, templating, layout.
We didn't get a lot of these by default though. We built those http services. We build template/layout engines for the server side. To a lesser extend we build routers, caches (those have been part of httpd services for a long time).
But it's still very near to me that our frameworks for SPAs (single page apps) often make us bring these concerns in each time. URL routing should be super super super common, to avoid degrading the user experience, but so often it's an afterthought. And it's not really the developers/company's fault entirely, if it's not foremost in the framework design. Its not an add-on its core to having good web architecture.
There was a defense for many years that react wasnt a framework, that it was a library. It only wanted to concern itself with rendering aspects. It left you to do a lot on your own, like state. That's both true, but it's wild how much negative space we haven't seen well integrated, how few good examples we have of a batteries included thoughtful well constructed front end.
To steer towards some kind of closing… it does feel tumultuous and chaotic. Technically we've been in transition and not making a ton of real visible progress since 2020 (react suspense is a good technique but feels obvious in retrospect, rsc is a huge slow shift), transition towards handling the SPA well.
But I'm so happy we are here. This is so different, so much more than what programming has been. HTML, CSS and JS are such an rich and capable platform, an interesting rich front end that displays anywhere on any device with secure and interesting interconnection to the world, that we can architect apps out of however we might dream. Very little seems to hold us back beyond our craft, beyond how we might imagine making these machines. So far in our lurching forward we have created such a richer connected world,… and fairly impressively direct toolkits that have shifted us from craftsmen who understood every little bit and every tool, to an industrialized workforce using advanced React Compilers. I don't love this hyper industrialization, but it's still amazing & powerful; I resist the part of me that wants to pastoralize the web, that has any sympathies for the very ardent very loud clambor against the web, that wants to see only simple pages again, that thinks it should all be torn down.
I really worry that the rage and disdain spreads so readily, on so many topics, & here where I still feel a glow of hope, even as things escalate & go unresolved, even as it feels mostly not to be honing in on really good answers (why are we still so broadly doing all work on the main thread?!). The anti-vocates pile into comments again and again, with endless energy to blast and destroy. I want to chime in to say, yes, it's complicated, but I love and cherish Dynamic HTML still, and I look forward to seeing ongoingly how we architect apps out of this base material.
jonoalderson · 2h ago
Thanks for all the delightful feedback, folks!
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 · 5h ago
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.
cherryteastain · 3h ago
> We’ve rebuilt the web like an air traffic control system – just to serve a few kilobytes of text.
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]
> 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?
JimDabell · 5h ago
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.
vikramkr · 5h ago
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
immibis · 4h ago
You might not be able to make your web app with zero, but chances are it needs a lot less.
Look at Old Reddit for example; it used Javascript for inline comment reply textboxes and for expanding sections of the tree. With it turned off, everything else still worked. Of course, that's gone now.
Do you really need three megabytes of JS to replace the whole page with the video player when I click on a video, or is <a href="/video/foo"> enough?
vikramkr · 4h ago
I mean obviously it depends, a lot of that 3mb is probably doing all sorts of ad and tracking stuff which, well, welcome to the internet. There's a point where trying to avoid JavaScript and build tools is just plain harder (especially with large teams) than like, a basic react app with typescript. You can use astro or just render out HTML and serve that. No reason to not use the tools you're already familiar with. If it's a webapp, the demands of complexity on the app mean you almost certainly need a framework (especially working with a team) to manage that. If it's a blog, if you make the active choice to make it slow and painful to load as a developer and put in the work to add all that bloat, it doesn't matter that much anyway?
karel-3d · 5h ago
JavaScript is named JavaScript because it was intended to "bridge browser and Java applets"
if you read all the old press releases, they try to push the Java applet connection a lot.
The original plan was to run Java applets everywhere and JavaScript as a "glue". I think we are much better off now than with Java applets. It could have been much, much worse.
Aldipower · 5h ago
Initially it was called Mocha or LiveScript and not intended to bridge Java applets. It really was invented to make HTML more dynamic. But eventually Netscape and Sun did a license agreement. Sun owned Java. From this point on, the name JavaScript was born and it was marketed to bridge browser and Java applets.
karel-3d · 4h ago
Ah, okay then. I gave too much weight to old press releases then.
Anyway Java applets (and ActiveX) was expected to be the main thing; write once, run anywhere; and that world would be much much worse than what we got.
exiguus · 4h ago
> Not just slow – awful. Bloated, fragile, over-engineered disasters. They load slowly, render erratically, and hide their content behind megabytes of JavaScript. They glitch on mobile. They frustrate users and confuse search engines. They’re impossible to maintain. And somehow, we’re calling this progress.
I have the slight feeling that JavaScript is not the problem, bad engineering is. Then I can agree to some of the statements in the article. But most of them suggest a simple solution without any context. Programming is one thing, software development another.
anonzzzies · 4h ago
Nothing to do with the language, but yeah, js/py, becasue both popular, seem to attract the most worthless devs and that includes framework devs/authors. Ah well, we make money with systems crashing, being slow, losing money (literally, people are using floating point in js and others to do money and losing money that way, and it's not rare either), etc, so please the more js/py we see vs c#/java in enterprise systems, the more we make.
mirekrusin · 5h ago
Browsers/HTML should support markdown natively, that would be even cooler.
I_complete_me · 5h ago
pure.md proves that it is possible maybe even straightforward by prefixing a URL with pure.md/. No affiliation whatsoever and IANAJSD.
djoldman · 3h ago
All of this may be true. It raises the question: why has a better way not won out?
It seems to me that the better user experience that would be gained by a different approach has not been worth the (perceived or actual) hit to developer experience.
Or in a sentence: users do not seem to care enough to make it worthwhile.
flohofwoe · 5h ago
The problem of the web as application platform isn't mainly Javascript (just use a proper linter and/or TS, or even WASM), but the adhoc-designed web API layer stack (e.g. the 3D rendering API should sit below the DOM, and there should be a couple of medium level APIs between the low-level rendering API and the DOM (such as text- and shape-rendering, a rectangle-layout API, a compositor API and an accessibility API which then the DOM is built on top - but which could also be used on their own), also WebAudio is just bad:
...and don't get me started about 'trivial' things like copy-paste, fullscreen, input handling and filesystem access. These are all not programming language problems, but API design problems.
...e.g. the web could be so much more when there wouldn't be this schism between the 'document-view orthodoxy' and the 'app-platform protestants' ;)
efitz · 4h ago
I don’t think that the issue is that we changed to designing web sites for developers. I think that the problem is that we started designing web sites for monetization. And this required adding a language and ecosystem that far exceeded the capabilities of the original WWW hypertext vision.
Ad based monetization means that there are going to be all sorts of business requirements to optimize for the monetization case: detailed surveillance metrics, various design requirements related to branding and to fulfill the designers’ “vision“, paywalls allowing search engines to peek through, etc. oh, and a chat assistant, preferably AI powered, because OMG why would we possibly expend the resources to communicate with a customer.
Ad based monetization is just evil; 50 years from now people will look back on the last couple of decades as a lesson on what not to do. It’s not that ads are evil or that monetization is evil, it’s that optimizing the web for ad based monetization causes people to do so many things that are bad for humans.
darepublic · 4h ago
At my first intern job I was experimenting with javascript. HTML 5 was a buzz word. The crusty old guy who wrote C# ASP.NET told me he'd never fool with javascript. Who is laughing now.
bradley13 · 5h ago
This. So much this.
I have a website for my students, with various content they need for assigned projects. HTML and CSS. The webserver itself is a small, simple Java application that sends files requested by the browsers.
KISS.
CreepGin · 5h ago
Looks like that article was AI generated by a SEO consultant. Ironically, if anything "broke" the web, it's ADs and SEO...
Sorry, the article itself was really painful for me to read.
nicklaf · 4h ago
Rather amusingly, the author recently espoused the viewpoint that bloggers who wanted to stand out should avoid using tools like ChatGPT: https://youtu.be/avASDgtw9k0?t=678
It's not obvious to me that this blog post was synthesized whole cloth from an LLM. On the other hand, in that same interview, the author encourages the use of LLMs for idea exploration, and it's entirely possible that this is what he did.
In fact, using an LLM in this way may itself may be an SEO trick, in the sense that he simply wanted to boost his search rank (inasmuch as it's still the case that longer articles are more highly ranked) by beefing up what would have otherwise been a very short article.
CreepGin · 4h ago
The Clickbaity title certainly did the trick!
phendrenad2 · 5h ago
The problem is the web sucks. CSS sucks. HTML sucks. Javascript is perfectly fine, actually. Browser security sucks. CORS sucks. CSP sucks. SVG sucks. Favicons suck. Shadow DOM sucks. Video controls suck. Web audio sucks. WebGPU sucks. W3C sucks. Chromium sucks.
You know what I'd do to be able to build a website using SwiftUI or GTK?
Given the terribleness of the web, naturally people will use bloated UI frameworks and build tools to even slightly avoid using them directly.
orwin · 4h ago
HTML5 is Okay (maybe need an upgrade). Scss is Okay. Svg is Okay. JavaScript is Okay. The rest do suck, but aren't the reason why we use bloated framework.
I personally use React because i like reducers reacting to state changes (I think finite state machines are the best thing since sliced bread), and my bosses don't like it when I create my own. Also having builtin, easy to use memoization is great (I avoid looking how it's done so I can keep the illusion that it's done extremely well and optimized).
Aldipower · 4h ago
The web has grown over the last 30 years by maintaining backwards-compability. I think this is a huge success. Your a still able to display a website from 1995 in your modern browser (without https ;-)).
dgb23 · 4h ago
The separation of HTML and CSS is almost entirely arbitrary, which makes web development unnecessarily complex and requires way too much discipline to do right.
I disagree with SVG though. The format has a lot of problems when you look closely, but in principle it's great and there are a lot of benefits that you get from using it.
The main issue i have is that HTML itself stagnated. We still lack extremely basic UI components.
> Javascript is perfectly fine, actually.
The direction of JS went the wrong way quite a while ago. Keywords like class, let, const and import all break the dynamic nature of JS and the utility thereof.
When these things were decided, there was apparently nobody in the room who asked "Wait, what is the point of having a dynamic language again?"
rossant · 4h ago
Can't articulate how much sarcasm there is in this comment.
rossant · 4h ago
The article could have been much shorter, but I agree. It's not just the web; bloated, slow, buggy, bad UX software is pervasive nowadays.
amelius · 4h ago
Knee-jerk headlines are breaking the web.
fleebee · 4h ago
It's hard to take this article seriously between the unfounded claims and hyperboles.
It's not because of JS that semantic HTML and accessibility are neglected: it's because of inexperienced developers. If anything, modern libraries, frameworks and tooling empower developers to build modern UIs that are accessible. Of course, with power comes responsibility, but that's like blaming the car for speeding.
short-name · 4h ago
I agree with the sentiment but things were arguably worse when you had to download a whole plugin to visit some websites (flash) or Java Applets.
000ooo000 · 5h ago
>This isn’t evolution. It’s self-inflicted complexity. And we’ve normalised it – because somewhere along the way, we started building websites for developers, not for users.
We started building websites for the marketing department, not developers or users.
strogonoff · 5h ago
These days you can use JavaScript-centric stack (and, gasp, React) to render static HTML that does not require runtime JavaScript at all.
Why bother with it, though?
Imagine you wanted to add elements of runtime interactivity. When we think about new and cool things on the Web, that’s nearly all of them. Ask yourself, what would result in more complexity and moving parts: doing the whole thing in one stack (e.g., JavaScript and React), or using two disparate stacks (say, Wordpress and then a bunch of jQuery) and ad-hoc tying them together by duplicating data model and business logic?
The most under-appreciated point about good design is that it’s not just about a thing looking pretty and functioning well at one point in time. It’s about a thing that can be maintained, improved, and kept in good working condition. Good design is sustainable, it exists and satisfies expectations over time.
Good developer experience is not the only aspect of sustainability (there are also cultural/organizational aspects, business model, etc.), but it is an important one. Modern stack is great from this perspective, allowing to express potentially dynamic layout while largely preserving declarativity (JSX), forcing to think about exactly what data you work with at all times so that you catch more issues at compile time (TypeScript), etc.
Yes, it also offers plenty of opportunities for shooting yourself in the foot if you so choose: by carelessly adding random badly maintained dependencies with massive dependency trees, by not thinking through the architecture or piling on abstraction layers, by adopting a framework that does not exactly fit your use case or that you don’t understand how it works, etc. We’ve all done that at some point, but ultimately it’s skill issue. More powerful tools require more thoughtful application.
Yes, sometimes sustainability can compete with the thing’s being pretty or small at one point in time, even though all of those are worthy ideals. Sometimes tradeoffs need to be made.
Aldipower · 5h ago
Nah, tracking and ads broke the web (using JS).
dakiol · 5h ago
As much as I share the sentiment, at least the browser has one single programming language. What’s a waste of time is to have dozens of backend programming languages (each of them having a few frameworks and countless libraries). So much wasted effort. I agree that variety is important, but ffs, it’s time to make a good use of our time and stop implementing yet again the same things but in a different language.
nenadg · 5h ago
most frameworks after 2012-13 were never made to make any progress rather they kept devs in the eternal loop of new thing = better thing
if simplicity makes perfection, we are currently on the other side of that
andrewstuart · 3h ago
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.
This. But it's hard. But it's worth it. Best of both worlds.
windowshopping · 5h ago
Rose colored glasses at their finest. I think this person has forgotten what the web was like 15 years ago. I suggest they visit some Japanese websites to find out.
franciscop · 5h ago
I noticed this with the line "Around 2010, something shifted. The iPhone was ascendant. Native apps were sleek, fast, fluid."
When the iPhone was first released, the experience was much worse than today's web experience. Sure apps/native also got much better, so 15 year ago webs were worse than today's apps, but that's not a fair comparison.
dudeinjapan · 5h ago
Hey now… Japanese websites are the future (especially tablecheck.com!)
miguel_martin · 5h ago
I’m optimistic on the future. llms.txt will be adopted for all major sites (from AI hype), and ironically it will benefit humans to browse and interact with sites in a simpler manner.
I personally believe that a new era of “lite-browsers” will be made. Emacs got close into this direction, but not accessible to avg. consumers
Text oriented operating systems will be the future.
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.
"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.
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.
Each user can get their own stylesheet and every request will be a small surprise how it looks.
Fantastic idea, right? No? Always these haters...
But credit to lobster.rs, they also did an excellent job with the UI on web tech, while still being very reasonable on the css/JS side (though I can't check right now how much they serve)
125% it’s quite nice, actually. Large enough font to read.
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.
[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.
Even when they are not a telltale-sign, folks are afraid of using them now because of AI. I'm not saying em dashes are bad. Our books are littered with them, and that's why LLMs spit them out consistently.
https://medium.com/@brentcsutoras/the-em-dash-dilemma-how-a-...
I was scratching my head pretty much the whole time during the first read.
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).
> It reads to me like typical marketing writing.
hmm maybe that's why it rubbed me the wrong way.
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.
> al_borland
Borland had a nice and not complex solution. Which made for very fast, low latency interfaces. Everyone starts crying when you don't have the react, downward reactive (well, for some definition of this leaky abstraction thing they call reactive because javascript doesn't support anything to help), but with simple events, getters and setters it was much much clearer what was happening every tick and you could optimise, even as junior, accordingly because everyone gets it all after 10 minutes of tutorial of how it works. I have seniors asking me (every few days) why something doesn't or does update in react or why it's so slow to input something in a field in react (we fix or patch horrible software for a living, so we see 100s of different companies over the months / years; these are not the same seniors asking me this; there are very very few people actually understanding how it works and how not to crash and burn because it LOOKS like you can do something in 'this way' (even on the official react site), but when you do it, you machine gun yourself in your legs).
Not to mention that you would end up with a consistent UI with shortcuts that every user could use immediately instead of the shitshow of 'designer' choices.
Way too many very basic UI affordances cannot be made accessible without JS if they can be implemented at all.
- 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.
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.
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.
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.
> 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.
And if you broaden your idea of your user base a bit, even the fast computers aren’t ubiquitous. Try using a low end Android phone sometime, or a hand me down iOS device still on iOS 12.
a site where every interaction requires an http request and a reload of the page performs much worse over low latence than an SPA that is designed with a local first approach where all interaction is local and data requests happen in the background.
not all SPAs are designed like that. but none of the traditional sites are designed like that either because they can't.
take hackernews as an example. in order to write a reply i have to click a link, wait for the page to load, click submit, wait for the submission to complete and for the updated page to load.
i live with bad internet. submissions and pageloads on hackernews frequently time out.
with an SPA the first click would open a text field without any server request at all, and submit would happen in the background while i can keep reading. and it can be repeated if it fails without me noticing and having to worry about it.
likewise updating for new messages could happen in the background without me having to wait for a page load. on top of that new messages could show up in a different color without having to track that in the server.
> It doesn’t matter if you’re publishing a blog post or an ecommerce site – the stack is the same. Heavy, abstract, engineered to the edge of usefulness. And nobody understands it. Not fully.
That so many folks are using the same stack seems much much more likely to mean that people do understand it. Pax Reactus feels absurd but the reason it's so saturated is because it's what we know, because it's what's done elsewhere. It's done because lots of people do know it.
> And the worst part? Most of this complexity exists just to retrofit things we used to get by default: routing, metadata, caching, templating, layout.
We didn't get a lot of these by default though. We built those http services. We build template/layout engines for the server side. To a lesser extend we build routers, caches (those have been part of httpd services for a long time).
But it's still very near to me that our frameworks for SPAs (single page apps) often make us bring these concerns in each time. URL routing should be super super super common, to avoid degrading the user experience, but so often it's an afterthought. And it's not really the developers/company's fault entirely, if it's not foremost in the framework design. Its not an add-on its core to having good web architecture.
There was a defense for many years that react wasnt a framework, that it was a library. It only wanted to concern itself with rendering aspects. It left you to do a lot on your own, like state. That's both true, but it's wild how much negative space we haven't seen well integrated, how few good examples we have of a batteries included thoughtful well constructed front end.
To steer towards some kind of closing… it does feel tumultuous and chaotic. Technically we've been in transition and not making a ton of real visible progress since 2020 (react suspense is a good technique but feels obvious in retrospect, rsc is a huge slow shift), transition towards handling the SPA well.
But I'm so happy we are here. This is so different, so much more than what programming has been. HTML, CSS and JS are such an rich and capable platform, an interesting rich front end that displays anywhere on any device with secure and interesting interconnection to the world, that we can architect apps out of however we might dream. Very little seems to hold us back beyond our craft, beyond how we might imagine making these machines. So far in our lurching forward we have created such a richer connected world,… and fairly impressively direct toolkits that have shifted us from craftsmen who understood every little bit and every tool, to an industrialized workforce using advanced React Compilers. I don't love this hyper industrialization, but it's still amazing & powerful; I resist the part of me that wants to pastoralize the web, that has any sympathies for the very ardent very loud clambor against the web, that wants to see only simple pages again, that thinks it should all be torn down.
I really worry that the rage and disdain spreads so readily, on so many topics, & here where I still feel a glow of hope, even as things escalate & go unresolved, even as it feels mostly not to be honing in on really good answers (why are we still so broadly doing all work on the main thread?!). The anti-vocates pile into comments again and again, with endless energy to blast and destroy. I want to chime in to say, yes, it's complicated, but I love and cherish Dynamic HTML still, and I look forward to seeing ongoingly how we architect apps out of this base material.
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. :)
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.
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...
> 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?
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.
Look at Old Reddit for example; it used Javascript for inline comment reply textboxes and for expanding sections of the tree. With it turned off, everything else still worked. Of course, that's gone now.
Do you really need three megabytes of JS to replace the whole page with the video player when I click on a video, or is <a href="/video/foo"> enough?
if you read all the old press releases, they try to push the Java applet connection a lot.
The original plan was to run Java applets everywhere and JavaScript as a "glue". I think we are much better off now than with Java applets. It could have been much, much worse.
Anyway Java applets (and ActiveX) was expected to be the main thing; write once, run anywhere; and that world would be much much worse than what we got.
I have the slight feeling that JavaScript is not the problem, bad engineering is. Then I can agree to some of the statements in the article. But most of them suggest a simple solution without any context. Programming is one thing, software development another.
It seems to me that the better user experience that would be gained by a different approach has not been worth the (perceived or actual) hit to developer experience.
Or in a sentence: users do not seem to care enough to make it worthwhile.
https://blog.mecheye.net/2017/09/i-dont-know-who-the-web-aud...
...and don't get me started about 'trivial' things like copy-paste, fullscreen, input handling and filesystem access. These are all not programming language problems, but API design problems.
...e.g. the web could be so much more when there wouldn't be this schism between the 'document-view orthodoxy' and the 'app-platform protestants' ;)
Ad based monetization means that there are going to be all sorts of business requirements to optimize for the monetization case: detailed surveillance metrics, various design requirements related to branding and to fulfill the designers’ “vision“, paywalls allowing search engines to peek through, etc. oh, and a chat assistant, preferably AI powered, because OMG why would we possibly expend the resources to communicate with a customer.
Ad based monetization is just evil; 50 years from now people will look back on the last couple of decades as a lesson on what not to do. It’s not that ads are evil or that monetization is evil, it’s that optimizing the web for ad based monetization causes people to do so many things that are bad for humans.
I have a website for my students, with various content they need for assigned projects. HTML and CSS. The webserver itself is a small, simple Java application that sends files requested by the browsers.
KISS.
Sorry, the article itself was really painful for me to read.
It's not obvious to me that this blog post was synthesized whole cloth from an LLM. On the other hand, in that same interview, the author encourages the use of LLMs for idea exploration, and it's entirely possible that this is what he did.
In fact, using an LLM in this way may itself may be an SEO trick, in the sense that he simply wanted to boost his search rank (inasmuch as it's still the case that longer articles are more highly ranked) by beefing up what would have otherwise been a very short article.
You know what I'd do to be able to build a website using SwiftUI or GTK?
Given the terribleness of the web, naturally people will use bloated UI frameworks and build tools to even slightly avoid using them directly.
I personally use React because i like reducers reacting to state changes (I think finite state machines are the best thing since sliced bread), and my bosses don't like it when I create my own. Also having builtin, easy to use memoization is great (I avoid looking how it's done so I can keep the illusion that it's done extremely well and optimized).
I disagree with SVG though. The format has a lot of problems when you look closely, but in principle it's great and there are a lot of benefits that you get from using it.
The main issue i have is that HTML itself stagnated. We still lack extremely basic UI components.
> Javascript is perfectly fine, actually.
The direction of JS went the wrong way quite a while ago. Keywords like class, let, const and import all break the dynamic nature of JS and the utility thereof.
When these things were decided, there was apparently nobody in the room who asked "Wait, what is the point of having a dynamic language again?"
It's not because of JS that semantic HTML and accessibility are neglected: it's because of inexperienced developers. If anything, modern libraries, frameworks and tooling empower developers to build modern UIs that are accessible. Of course, with power comes responsibility, but that's like blaming the car for speeding.
We started building websites for the marketing department, not developers or users.
Why bother with it, though?
Imagine you wanted to add elements of runtime interactivity. When we think about new and cool things on the Web, that’s nearly all of them. Ask yourself, what would result in more complexity and moving parts: doing the whole thing in one stack (e.g., JavaScript and React), or using two disparate stacks (say, Wordpress and then a bunch of jQuery) and ad-hoc tying them together by duplicating data model and business logic?
The most under-appreciated point about good design is that it’s not just about a thing looking pretty and functioning well at one point in time. It’s about a thing that can be maintained, improved, and kept in good working condition. Good design is sustainable, it exists and satisfies expectations over time.
Good developer experience is not the only aspect of sustainability (there are also cultural/organizational aspects, business model, etc.), but it is an important one. Modern stack is great from this perspective, allowing to express potentially dynamic layout while largely preserving declarativity (JSX), forcing to think about exactly what data you work with at all times so that you catch more issues at compile time (TypeScript), etc.
Yes, it also offers plenty of opportunities for shooting yourself in the foot if you so choose: by carelessly adding random badly maintained dependencies with massive dependency trees, by not thinking through the architecture or piling on abstraction layers, by adopting a framework that does not exactly fit your use case or that you don’t understand how it works, etc. We’ve all done that at some point, but ultimately it’s skill issue. More powerful tools require more thoughtful application.
Yes, sometimes sustainability can compete with the thing’s being pretty or small at one point in time, even though all of those are worthy ideals. Sometimes tradeoffs need to be made.
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.
This. But it's hard. But it's worth it. Best of both worlds.
When the iPhone was first released, the experience was much worse than today's web experience. Sure apps/native also got much better, so 15 year ago webs were worse than today's apps, but that's not a fair comparison.
I personally believe that a new era of “lite-browsers” will be made. Emacs got close into this direction, but not accessible to avg. consumers
Text oriented operating systems will be the future.