Default angular builds are large compared to other frameworks even when you consider all the extra stuff that gets bundled with angular.

5MB is large for a single bundle, I'd say if you are using lazy loaded modules 2MB for a single module is large.

Front-end performance varies in importance based on your context. In e-commerce performance is tied to conversion so it's very important. If you're a government contractor building CRUD apps, it's not as important.

> If you're a government contractor building CRUD apps, it's not as important.

I'm far from that, but "5MB is very large" to me is ludicrous. Press "play" on a Netflix movie and you're over that benchmark straight away.

I grew up in the era of sub-56k modems.

Just searching Google for "56k modems" returns 5.1 MB of data with an ad-blocker on.

Let's be realistic.

people seem to always talk about this as if it's about the time to download.

Open the profiler and see how long it takes for your computer to parse and execute those 5 megs of JS. especially if its not crafted in the right way for V8 or whatever to ignore the contents.

Also all the garbage your code might run on first run to get started. "Garbage" here being used as neutrally as possible (I like Python and it has a similar "pay init costs up the wazoo for anything" feelings)

> Open the profiler and see how long it takes for your computer to parse and execute those 5 megs of JS

I'm well aware of profiling as I am lead on this project.

No issues.

Oh, so this is why the web is shit.

Oh just parse that 5MB of JS to 20MB of used memory for the code (after spiking even higher), then actually run it and oh my it allocates another 20MB for god knows what, and we're gonna need like 5 representations or outright copies of every "component" on the page sitting around in memory somewhere, you know, in the name of being "performant" and having good "Developer Experience" so now it's nearing 150MB of memory total. Oh and we need instant updates from the server (narrator: no, they didn't) so let's have some web sockets eat a bit more memory and a few processor cycles (so, battery) here and there even when the user's not on the page. Oh and everything needs to be immutable because it's impossible to write good code otherwise, so of course we imported libraries for that (how do you think we got to 5MB, if not importing shitloads of libraries of dubious value? LOL it's not like our "app" actually does very much) and since Javascript's not designed for it we're gonna really give that garbage collector a workout for no good reason.

Great, now that that's sorted out: let's download a few MB of JSON, then parse that into Javascript data structure (more memory spikes), copy and slightly modify that about three times in different places, then use it to create a few representations of a "component" one of which will be a set of actual entries in the DOM. And we'll keep most of that around after we're done.

That's about right,...

Images and markup are not JavaScript.

A reasonable rule of thumb is that on a low-end Android phone 100KB of JS takes about 1 second to download and parse. A 5MB bundle would take 50s or so to run. You probably don’t notice this if you’re only testing on fast PCs/macs, or modern iOS devices.

> A 5MB bundle would take 50s or so to run

I deal with very large-scale Angular systems that handle this sort of stuff day in, day out ... can you give me an example of a 5 MB Angular payload that takes 50 seconds to execute?

Clearly this is on the developer.

That JS and image are different things entirely. It costs the browser more to parse JS than the image. These are not 1:1 comparisons, as you can see in this post

https://developers.google.com/web/fundamentals/performance/o...

> That JS and image are different things entirely.

I'm two decades into this. As the lead on my current project, on both sides (Angular and C#), I know all about this.

We have performance benchmarks and to this point, we've had no issues.