> Have these kinds of issues been improved since?

Currently in an Angular project and I would say "somewhat". Our production bundle is still >1MB if you include all the polyfills etc.

As an alternative I recommend Svelte Kit:

https://kit.svelte.dev/

But it's best to wait until it's out of beta. The value proposition here is that it's performant, bundles are exceptionally small since it's more a compiler than a framework and you need less code than in say, React, to achieve the same result.

Now that it has TypeScript support the developer experience is decent as well.

I just love vue3 with vite ecosystem. For example: https://github.com/antfu/vitesse/ is a good template to start "modern" webdev. DX is very good.

you can integrate it to a server with ssr: https://github.com/frandiox/vite-ssr

Same.. although I only left Angular around v 8/9 if I recall.

These days, I can't imagine using anything but Svelte/SvelteKit for anything JS.

> I abandoned angular (around version 5) because even a simple application was unusually large in size, and I did not want to have to deal with the disproportionate time investment of trying to squeeze out performance / optimization / reduce bundle sizes.

What do you consider "unusually large in size?".

I am lead on a "large" Angular code-base, which compiles to less than 5 MB in production mode using lazy-loaded modules.

5 MB is often smaller than a picture of a cat people post online, and can be cached.

I think front-end developers often overthink "performance" and "bandwidth". Sure, it's great to keep things as small and concise as possible, but at the end of the day it gets a lot more nuanced.

I'm much more concerned about the C# code and the SQL than I am about anything Angular is doing in JS land.

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.

Angular 5 is like prehistory now. You should check how Google has improved the compilation, for instance. This is like day and night.

> A seamless way to drop-in to an existing server-side web framework without wanting to take over routing and other such things

These days, I would first check whether I can get away with just using web components, typically with lit for convenience. The reason being that web components are a browser standard, which means that if you do it right, you get an opportunity to escape the hamster wheel of keeping up with new frameworks.

That web components are often adequate to do the job is evidenced by Adobe releasing their web version of Photoshop based on web components and lit.

For internal tools and small apps, I stopped using React and went with Svelte. Not as mature, but what a breath of fresh air.

Otherwise, React for larger projects though I'm trying SvelteKit for a larger project right now, and it's pretty amazing. It's a lot less boilerplate than React, and god that feels good.

I went with Elm instead. It helps I really like types and prefer a fight with the type-checker/ compiler then with runtime errors any day.

> it's pretty amazing. It's a lot less boilerplate than React, and god that feels good.

I could have said this for Elm! :)

What do you use for the backend with Elm? I find it hard to go back to TS after it.

If your target userbase has a stable, reasonably good internet connection, bundle size doesn't matter. Perhaps it's a dirty secret of front end development these days, but in many use cases, it's a micro-optimization. Now if you're selling goods on Amazon, and billions of page hits and 50ms slower page load time means X% fewer goods sold, you've made a case: one developer spending time on performance optimization is saving your business millions. Most engineers aren't working at that scale.

Isn't it true that these metrics impact lighthouse scores, which are a significant factor in determining your page rank?

i.e. if your product is relying on some organic search traffic to grow, would bundle size be a concern?

Depends if I need to be able to hire for it.

Svelte if I don’t.

React via CRA if I do.

I’m hopeful that Svelte will continue to pick up steam, but React serves my needs well as-is.

Svelte/Sveltekit. It's really difficult to go back to React/Vue/Angular once you get a hang of Svelte.

What’s better?

The complaint about the high initial complexity of Angular certainly resonated with me.

This is absolutely true. Svelte just works really well with my brain.

React via NextJS is becoming a popular option. It ticks all of your boxes. NextJS has an opinioned way of approaching the backend but also supports just rolling your own and exporting the frontend as a fully static site if wanted.

Vue. Still find React incredibly annoying.

For all these points the correct answer would be Angular.