In case you're unaware, Google has had an interesting track record in the Framework category. Not all of these are technically frameworks, but can be used as such.

Frameworks

• AngularJS - DEAD Recently
• Angular 2 - Every version up until 13, not confusing at all
• Polymer - DEAD Recently
• Lit - Replaced Polymer for web components
• Angular Universal - A package for Angular 2 to add SSR functionality
• Angular Dart - DEAD Recently, although still used at Google internally for certain Google Apps
• Ionic - Not Google, worth mentioning because mainly used with Angular to build multi-platform apps
• Flutter - IMHO best multi-platform app builder, arguably except for the web (DART instead of JS)

If you have been paying attention to the latest Framework features, particularly NextJS and Sveltekit (NUXT too), you see these new ideas and features.

Features

• Incredibly small bundle sizes
• Small build times
• Easy SSR Deployment to different hosting environments
• Incremental Static Regeneration (ISR)
• Automatic Static Optimization
• SSR Streaming
• File System API with Dynamic Routing
• ESLint Built-in
• Edge Functions (Middleware)
• Edge Network

So, what's going on with Angular? Well, let's take the cases one-by-one, including what you didn't know Angular CAN do, or partly do:

• The bundle sizes and built times are terrible in Angular, even with the newer IVY compiler. This desperately needs work. It took me 15 min to compile my fireblog.io site, although I admit there are probably many ways I could tweak it. Lazy-loading is pretty much your only option here.

• Deployment - This is actually not an issue. There are plugins for Angular Universal for all hosting environments except Vercel. However, you can deploy to Vercel, as long as you don't have a package bigger than 50MB, which could be a problem.

• ISR and Static Optimization - I am not a fan of this in NextJS. You're basically creating a static page with JavaScript on it. You could manually write this code, but why would you. Your meta data would not dynamically update. I also don't want to automatically generate a static page, as I would prefer to chose it myself. However, I could definitely see the use of this depending on your site.

• SSR Streaming. I have seen on REDIT arguments why this is overkill. This is basically using HTTP Streaming to send asynchronous data (promises) to the server. This is potentially against the HTTP protocol from my understanding, and you're creating a promise with the browser to only get resolved when finished. It is in Alpha mode in NextJS, but very interesting. A stream is different from an observable in that it can be run only once, but here the promise IS the browser since it is technically a promise which uses the http protocol. This is also on Rich Harris's list for SvelteKit.

• File System API - This uses the dynamic routing feature from React, and serverless functions in SSR mode. This was emulated for Svelte and Vue. NextJS and Nuxt (soon SvelteKit) compile each route to its own serverless function. This explains why Vercel only allows 50MB lambdas. While this sounds good, I am not a fan of this at all. React just does routing differently than Angular. The extra-function will create another cold start on each route. I suggest loading just the original route via server, and then client lazy-load the other routes (if you use Angular or any of them). Cold starts are the problem. That being said, this seems to be a norm Angular is ignoring, although Google creates its own norms.

• Angular will eventually have es-lint built-in like it used to have TS Lint, right? Well, until then, the semi-official solution seems to be this package.

• The Edge - So, if you host on Google, it recently has an edge network with all the great features a CDN should have. However, even though it is not too difficult to configure, you still have to configure and pay for it; it does not work out-of-the box. There is also edge computing for those micro calculations. This is pretty much exactly what Vercel's Middleware is. Unfortunately it is not built into Angular, and I don't even know if you could configure it for SSR purposes. This could be a way to do my puppeteer idea.

Roadmap

You can view the Angular Roadmap. A few things of note:

• Micro frontend architecture. Well, more automatic lazy-loading separated components. This is absolutely the most important thing that I see. Sounds interesting.
• Zone.js opt-out... the reason async await doesn't work like you think for components, I am pro this
• Code-splitting - nuff said
• New Angular Material 3 built-in... freaking cool here
• Optional NgModules with Standalone pipes and directives - See this video. This will help the speed with less coding, although some might not like this.
• Lots of more diagnostics and tools you would expect from Google

Conclusion

Obviously the answer here is NO. A big fat no. It is not dead, and it will continue to strive for a long long time. However, I don't think it is trying to be something it is not. It does not have experimental features like HTTP Streaming, and it is not in-style using ISR and the File System API. I suspect if HTTP Streaming catches on, it will eventually incorporate it. ISR is cool, but probably not at the top of the list. I believe that is a fad just for React. The File System API, I am not so sure about. I think it depends on what the Angular team "discovers" while doing code-splitting and micro frontend architecture research.

That being said the build time and build size are disastrous... for a reason: Angular is a beast. Angular has all of these items all enterprise apps have to add, built-in. Angular may have a much smaller package size for larger apps, since it has incorporated these packages within Angular.

Reasons to Choose Angular

• It is Polished
• Testing, Typescript, Build Options, Logic
• You are building a serious app, enterprise grade
• You learned Angular through fireship.io, although he now prefers React (SMH)
• Reliability
• Google and Microsoft build most of their apps with it. Yes, those two small companies you may have heard of.
• You want to deploy your app somewhere besides Vercel (unless your app is small)
• You hate bootstrap and want to use the latest, best Material UI package

The key word is here, enterprise.

But I'm currently building my app in SvelteKit, despite the framework being ready for production builds... I guess I am my own leader...

J