Is Angular Dead in 2022?

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

Comments

[Berrou]

What a waste of time reading this post

[Jonathan Gamble]

You're probably right 😆

[Antonio Sarcevic]

SvelteKit FTW :)

[Ivan Jeremic]

React > Svelte

[mellunar]

Yeah, because it's better to keep on:

import React, { useState } from 'react';
function Component() {
  const [count, setCount] = useState(0);
}

instead of:

let count = 0;

🤷

[Ivan Jeremic]

You got hooked by the popular talk but lets be real there will always be people who like the react way more its just a function which returns UI no matter ho clean svelte or any new framework that comes out is there will always be people who like the react way more.

[Antonio Sarcevic]

we got hooked by the underlying philosophy that creating interactive UI doesn't need to be a chore :D

[Ivan Jeremic]

But it isn't for everyone, as I already said there are people who will always like the react model no matter what comes out because they come maybe more from a programming background first, in programming you build an application by composing functions together that do a certain job. In react you use functions and each one returns a piece of UI and its logic which makes sense and people build UIs that ways easier.

[Eduard Jacko]

@mellunar The React example is not a valid component ;) Maybe you should write an actual simple component as you are pointing to difference between state management only. This is more fair to compare

<script>
    let name = 'world';
</script>
<h1>Hello {name}!</h1>
<button on:click={() => name = "Hi"}>click me</button>

vs

function Greeting() {
  const [state, setState] = useState("world")
  return (
      <>
          <h1>Hello  {state}!</h1>
          <button onClick={() => setState("Hi")}>click me</button>
      </>
  )
}

[Ivan Jeremic]

A javascript function body is your script tag in Svelte the javascript return is your svelte file for markup, some people like programming some like XML style.

[Antonio Sarcevic]

Implying writing HTML isn't programming

[Ivan Jeremic]

Writing jsx is.

[Antonio Sarcevic]

Im glad you feel superior for making your life harder 🤣

[Ivan Jeremic]

I'm sorry for you that your brain can't grasp it.

[Antonio Sarcevic]

less features, more code, bigger bundle, worse performance ... 🤷‍♂️

[Ivan Jeremic]

Bigger bundle on hello world apps yes, but once you have an bigger app react is smaller. Also less built in features(maybe) but overall more feature because of ecosystem, worst performance, nahh do you feel it?

[Adan Ulloa]

Svelte is faster because of the way it was designed without the virtual dom. That doesnt mean you will feel the diference on a modern pc. But been faster means that your application will be compatible with older devices or IoT devices which doesnt have that big of a hardware.

[SergDev]

There's no silver bullet. The framework we choose is really depends on the task (and the team we working with). Maybe I would not go with Angular for some lightweight site, but for complex enterprise application I believe Angular may be a good choice.

[Kristher Vidal]

@jdgamble555

"You learned Angular through fireship.io, although he now prefers React (SMH)"

I think he still prefers angular, but React is where the views are.

so yeah so sad...

[Lars Rye Jeppesen]

Our enterprice app, with 4 language versions compiled at build time, takes 1 min to compile.

Wth are you doing with your code?

[Jonathan Gamble]

Sorry, I was referring to installing Angular Universal with all its dependencies on Cloud Run, not a local compile.

[Lars Rye Jeppesen]

ah makes sense. thanks

[Templar++]

Angular seems pretty much dead actually according to insights.stackoverflow.com/trends?...

[Joel Nieto]

You know that the line you're highlighting isn't Angular, right?

[Eduard Jacko]

true. but still, the green is dying slowly

[Sean Perkins]

Ionic Framework developer here; Ionic's components are built with web components. We ship framework specific packages to help with framework integrations (React, Angular and Vue).

No Angular isn't dead.

The packages you mention as dead are just the predecessors to the current packages.

Thank you for acknowledging that Ionic isn't from Google. That is factual.

[Eduard Jacko]

You know, Microsoft is moving to use react-native in UWP so you are not right saying "Google and Microsoft build most of their apps with it." Microsoft did some experiments with Angular but they run away from it as fast as they could.

docs.microsoft.com/en-us/windows/d...

[Andrew Baisden]

Angular and JQuery don't get a lot of love anymore 😂

[mellunar]

React is the one that should be dead