Hacker News Reader

Comment by lemper | Hacker News Reader

168 mb of bundled js? they must've written a fully functioning unix-like kernel too, yeah? or embedded Taylor Swift's 7th album. otherwise, I don't know how the number is as high as that.

View on HN

This stinks of no-one-knows-what-the-fuck-they-are-doing-itis, a common problem in the software engineering community. When mixed with a deadly dose of sunk-cost-fallacy-itis and project-death-march-itis, the only way out is adding more JavaScript until it creates a singularity from the accumulated mas and sucks the project into oblivion.

Trying to fight one of these off now. We don't need a fancy shit ass UI. We just need stuff that works and is simple. But plenty of one-trick pony developers and architects who build complicated mechanisms out of piles of nodejs and microservices which merely consume time, energy and attention and delivery sweet fuck all ROI.

I think it smells of the common trend in javascript to grab any old package and use it if it scratches an itch. look at lpad(and that debacle). back when i was doing compiled stuff (well even now in scripted land) you'd look hard at whether or not you needed that dependency since every dependency is a liability. and of course you'd manage the dependencies by hand.

kidsthesedaysgetoffmylawn

That's most modern software development though. Drag any old shit off the internet, dependencies, malware and incompetence included, then execute it as some arbitrary user with full access to your mission critical data and an outbound network connection. Maybe if you're big enough to have a security or compliance guy they will at most want you to buy in something that does a half assed attempt at tracking dependencies after it's too late or intercepts traffic pointlessly on the way out crippling your business inconveniently sometimes.

I tend to just use whatever Debian ships with package-wise when I'm doing something for my own purposes. People laugh at me. Their funeral.

Heh, it's fun doing SCA and SBOM these days and having the report generation break because the servers run out of ram building the list of everything the devs included. Then the dev team comes back and says it's impossible to run the application out of ram, they'd have to include thousands of modules and there is no way in hell you could keep that application working over time and manage to audit it. Then you show the devs the trace logs for the error and they shudder in terror.

What are you using to generate SBOM these days?

This is due to a long time of the standard library being seriously lacking. Even today, group / groupToMap still aren't standardized, nor are iterator methods. It used to be even worse though.

Very true. This is one thing I like about Go. The standard library is very complete. I can do most things I need to do without having to pull in any external dependencies.

> no-one-knows-what-the-fuck-they-are-doing-itis

This is so funny. I feel like in the old days it would be called out without remorse, like an old hand putting down a maimed horse. Nowadays you have to tapdance around the issue to such a degree that you look insane to try, people will just spout jargon longer than a ducks dick and your manager will sucker down.

I've long given up on tact and politics. You say what it is. If someone doesn't like that, move the fuck on.

Good luck with that. I'm one of a handful of people on a team that maintains a native iOS app and the powers that be want to transition it to be a minimalistic container for a React web app so they can "just design it once and push changes without needing a separate App Store submission". I can fight that only so long, and then we need to let them do it and prove to themselves and every user that the UX will suck. The best they can hope for is mediocrity.

be sure to mock people with +20 years software design and development experience, too...

Some of the people I am mocking do have that.

Also I mock myself regularly :)

Please don't lump the linux kernel in with these heathens.

Here's buildroot in the browser: https://copy.sh/v86/?profile=buildroot

It's 5MB

I wonder how many of the top npm downloaded modules you could fit into an amalgam vendor minified build before you hit 168 MB.

All malware infested varieties of is-true for certain!

Surprising that at the point when it crossed 100mb there was no-one on the team who raised any concerns. Perhaps this was a case of boiling the frog?

Probably bundling the server side dependencies into the client. I’ve also seen this happen when people add uncompressed 4k png images and the build tool is configured to inline all static assets. Obviously there was a lack of domain knowledge in the company or this wouldn’t have happened.

What I understood from the post was that it was only 168mb because tree-shaking didn't work on whatever version had support for server-side rendering. With working tree-shaking the bundle these developers were working with during development would be considerably smaller.

Wouldn’t be at all surprised if no one was paying attention. Chrome on a top spec MacBook can chew through 100MB of JS without thinking about it. Someone on an old machine is screwed but hey, “works on my machine”…

I imagine it is not pure js code but a lot of embedded svgs and inlined assets and styles.

Author here. At the time, Angular relied a lot on the AOT compiler and tree shaking to keep bundle sizes down. No idea if this is still the case.

If we built the app with the stable branch the bundle size was orders of magnitude smaller: less than 200kb. Still a bit of a chonker, but more reasonable than the ridiculousness the experimental SSR branch spat out.

Apparently you’ve never had to shed file size from a multiple megabyte react bundle shat out by webpacker

If it's not like... large language bundles or images or whatnot, I suspect it might be a lack of technical oversight and everyone just adding their favorite library.

a fully functioning unix-like kernel is more like 0.03 megabytes

remember the pdp-11 was a 16-bit machine, and there's also c64 lunix, etc.

I gotta think it was more than just JS? Some non JS assets and etc maybe?

Shall we make a bet that it was node.js based?

That has the ability to spiral out of control completely if you don't keep a really sharp eye on what includes what.

It was Angular. It may have been served by Node, but Node wouldn't have been included in the bundle (unless something had gone terribly wrong, which...I guess is possible, given the article?)

Reply on news.ycombinator.com