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
"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...
125% it’s quite nice, actually. Large enough font to read.
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.
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' ;)
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.
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.
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.
- 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.
All the SPA frameworks handle browser history and links correctly.
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.
Way too many very basic UI affordances cannot be made accessible without JS if they can be implemented at all.
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.
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.
* 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.
We started building websites for the marketing department, not developers or users.
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.
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.
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.
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 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?"
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).
> 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.
[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.]
There were so many contradictions in the article, I was going to point them out. Don't see a point now.
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.
… means absolutely nothing. I’ve been heavily using them for decades at this point.
The article itself may or may not be AI-generated, but we cannot penalise folks for simply using a stylish bit of punctuation.
I was focusing more on what you called "among other things". The way that the article uses English is extremely characteristic of, say, ChatGPT.
I don't believe this article is largely AI-generated. It reads to me like the work of every marketer who has learned a list of "best practices" and sticks to them rigorously. It's probably also been edited so it aligns with Grammarly's or Hemingway's view of good writing.
Plus, some people seem to think that any polished, professional writing is LLM-ish because that's the style LLMs often imitate (badly).
> It reads to me like typical marketing writing.
hmm maybe that's why it rubbed me the wrong way.
This. But it's hard. But it's worth it. Best of both worlds.
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.
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.
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?
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.
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.
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.
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.
> 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?
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.
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.
austin-cheney•2h ago
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.
sir_pepe•2h ago
falcor84•1h ago
zwnow•2h ago