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…
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...
JavaScript broke the web (and called it progress)
151–160 of 171 posts
Re: JavaScript broke the web (and called it progress)
#152In 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 reque…
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.
Re: JavaScript broke the web (and called it progress)
#153Re: JavaScript broke the web (and called it progress)
#154Saying JS broke the web when your website loads 754kB of JS across 13 separate requests makes me wonder if you're very serious about the problem.
Truthfully, _the website_ does not load anything. The so-called "modern" web browser used by many but not all HN commenters auto-loads resources, e.g., processing tags, and runs Javascript, e.g., XHR or fetch requests.
As such, by using a different client, not the one used by these HN commenters, this web page can be retrieved with only one HTTP request (initiated by the user) and and read, text-only, with zero Javascript files sourced.
There are of course other strategies to avoid auto-loading resources and running Javascript. IMO, anyone who is "very serious about the problem" would surely be using one of them, and probably unperturbed by yet another blog page that tries to source some standard WorddPress Javascripts.
Nor did Javascript "break the web". Web developers and web marketers did, using Javascript and browsers distributed by advertising companies, and organisations paid by advertising companies to send them data about browser users.
Re: JavaScript broke the web (and called it progress)
#155Saying 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.
> 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 "go…
However, I think that it's important to keep in mind that a "Hello World" app in NextJS is around 70kb as well, so I think that anything less than 100kb is pretty forgivable on the modern web. That's a rarer achievement than one would like to believe.
To fully clarify my belief, I use a ~$50 budget phone, and it's rarely the JS that makes the web unusable. It's usually when a website loads multiple advertisements that each contain video tags that I actually notice a degradation in experience.
Re: JavaScript broke the web (and called it progress)
#156Bitch 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…
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…
Re: JavaScript broke the web (and called it progress)
#157For a stark comparison, consider the site where these comments are entered.
HN Rulz! No js, no problem! Fast and functional...
And regarding the comment:
> it loads 754kB of JS across 13 requests
It didn't for me, since I browse by default with javascript and cookies disabled.
The site jonoalderson.com worked just fine without them.
I'm not sure why more technically literate people don't do this...
Re: JavaScript broke the web (and called it progress)
#158Earlier quoted context omitted.
Well, it's just wordpress and captcha can only be done in js (half the requests).
Absolutely, do as I say not as I do.
I do want HCL so we can sunset helm since it really is not the tool for the job (and slow).
Re: JavaScript broke the web (and called it progress)
#159Earlier quoted context omitted.
Well, it's just wordpress and captcha can only be done in js (half the requests).
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 w…
Re: JavaScript broke the web (and called it progress)
#160Earlier quoted context omitted.
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...
What's wrong with TypeScript for backends? Specifically backends where the load is moderate or happening in the database anyway?
For small and moderate projects I dont see issues, but I always build with scaling in mind and I'd like to keep the bill for that small.