Hacker News Reader

Comment by serial_dev | Hacker News Reader

> 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.

View on HN

Solid or Preact are less than 10kb, and captcha is pretty much useless at this point in my experience. There's no reason for this site to have over 70kb of JS. My blog has a similar comment section with less 15kb of JS. The funny thing is that almost half of the 70kb is jQuery which is basically baked into the browser at this point.

However, I think that it's important to keep in mind that a "Hello World" app in NextJS is around 70kb as well, so I think that anything less than 100kb is pretty forgivable on the modern web. That's a rarer achievement than one would like to believe.

To fully clarify my belief, I use a ~$50 budget phone, and it's rarely the JS that makes the web unusable. It's usually when a website loads multiple advertisements that each contain video tags that I actually notice a degradation in experience.

Someone should write a meta forum that just overlays related posts.

So how did JavaScript break the web then?

It didn't. Badly engineered sites suck. Nothing new.

No this is partially Javascript's problem. JS has virtually no standard library and was, for a long time, a bad, lobotomized language. ES6 helps a lot, but in the meantime we had to rely on absolutely huge frameworks.

JS also did not properly address the complexity of the web. We didn't have good APIs for manipulating the DOM. We didn't have good APIs for making server requests. We did things like spawn iframes to call XML endpoints that we then transform the result of into HTML via XSLT and then inject that into the DOM.

And, on top of all of this, JS is not performant. It's an extremely footgunny language, too. So we build on top more complexity. Minimizers, linters, static analyzers, compression, obfuscators, and more. These days JS is no longer a scripting language - it has more build steps than a C++ project.

So anyway, now here we are.

Reply on news.ycombinator.com