8 ms·

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

by lemper 3y ago

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.

translucyd 3y ago
[flagged]
andrewmcwatters 3y ago
I wonder how many of the top npm downloaded modules you could fit into an amalgam vendor minified build before you hit 168 MB.
- deleted 3y ago
  [deleted]
- baz00 3y ago
  All malware infested varieties of is-true for certain!
indy 3y ago
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?
- warp 3y ago
  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.
- afavour 3y ago
  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”…
- pault 3y ago
  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.
- deleted 3y ago
  [deleted]
baz00 3y ago
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.
- peteradio 3y ago
  > 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.
  - baz00 3y ago
    I've long given up on tact and politics. You say what it is. If someone doesn't like that, move the fuck on.
- mistrial9 3y ago
  be sure to mock people with +20 years software design and development experience, too...
  - baz00 3y ago
    Some of the people I am mocking do have that. Also I mock myself regularly :)
- weaksauce 3y ago
  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
Raed667 3y ago
I imagine it is not pure js code but a lot of embedded svgs and inlined assets and styles.
kragen 3y ago
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.
duxup 3y ago
I gotta think it was more than just JS? Some non JS assets and etc maybe?
Cthulhu_ 3y ago
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.
ransackdev 3y ago
Apparently you’ve never had to shed file size from a multiple megabyte react bundle shat out by webpacker
jacquesm 3y ago
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.
- babelfish 3y ago
  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?)
deleted 3y ago
[deleted]
Grimburger 3y ago
Please don't lump the linux kernel in with these heathens. Here's buildroot in the browser: https://copy.sh/v86/?profile=buildroot https://copy.sh/v86/?profile=buildroot It's 5MB
dfcowell 3y ago
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.

by lemper 3y ago

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.

translucyd 3y ago

[flagged]

andrewmcwatters 3y ago

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

deleted 3y ago
[deleted]
baz00 3y ago
All malware infested varieties of is-true for certain!

indy 3y ago

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?

warp 3y ago
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.
afavour 3y ago
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”…
pault 3y ago
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.
deleted 3y ago
[deleted]

baz00 3y ago

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.

peteradio 3y ago
> 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.
- baz00 3y ago
  I've long given up on tact and politics. You say what it is. If someone doesn't like that, move the fuck on.
mistrial9 3y ago
be sure to mock people with +20 years software design and development experience, too...
- baz00 3y ago
  Some of the people I am mocking do have that. Also I mock myself regularly :)
weaksauce 3y ago
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

Raed667 3y ago

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

kragen 3y ago

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.

duxup 3y ago

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

Cthulhu_ 3y ago

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.

ransackdev 3y ago

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

jacquesm 3y ago

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.

babelfish 3y ago
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?)

deleted 3y ago

[deleted]

Grimburger 3y ago

Please don't lump the linux kernel in with these heathens. Here's buildroot in the browser: https://copy.sh/v86/?profile=buildroot https://copy.sh/v86/?profile=buildroot It's 5MB

dfcowell 3y ago

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.