DEV Community

Cover image for Is Angular Dead in 2022?
Jonathan Gamble
Jonathan Gamble

Posted on

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

Discussion (35)

Collapse
gaul profile image
Info Comment hidden by post author - thread only accessible via permalink
Berrou

What a waste of time reading this post

Collapse
jdgamble555 profile image
Jonathan Gamble Author

You're probably right 😆

Collapse
sarcevicantonio profile image
Antonio Sarcevic

SvelteKit FTW :)

Collapse
ivanjeremic profile image
Ivan Jeremic

React > Svelte

Collapse
mellunar profile image
mellunar • Edited on

Yeah, because it's better to keep on:

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

Enter fullscreen mode Exit fullscreen mode

instead of:

let count = 0;
Enter fullscreen mode Exit fullscreen mode

🤷

Thread Thread
ivanjeremic profile image
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.

Thread Thread
sarcevicantonio profile image
Antonio Sarcevic

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

Thread Thread
ivanjeremic profile image
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.

Thread Thread
kresli profile image
Eduard Jacko • Edited on

@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>
Enter fullscreen mode Exit fullscreen mode

vs



function Greeting() {
  const [state, setState] = useState("world")
  return (
      <>
          <h1>Hello  {state}!</h1>
          <button onClick={() => setState("Hi")}>click me</button>
      </>
  )
}
Enter fullscreen mode Exit fullscreen mode
Thread Thread
ivanjeremic profile image
Ivan Jeremic • Edited on

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.

Thread Thread
sarcevicantonio profile image
Antonio Sarcevic • Edited on

Implying writing HTML isn't programming

Thread Thread
ivanjeremic profile image
Ivan Jeremic

Writing jsx is.

Thread Thread
sarcevicantonio profile image
Antonio Sarcevic

Im glad you feel superior for making your life harder 🤣

Thread Thread
ivanjeremic profile image
Ivan Jeremic

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

Collapse
sarcevicantonio profile image
Antonio Sarcevic

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

Thread Thread
ivanjeremic profile image
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?

Thread Thread
heydan83 profile image
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.

Collapse
ssergdev profile image
Sergei Sergeevich • Edited on

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.

Collapse
spock123 profile image
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?

Collapse
jdgamble555 profile image
Jonathan Gamble Author

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

Collapse
spock123 profile image
Lars Rye Jeppesen

ah makes sense. thanks

Collapse
nssimeonov profile image
Templar++ • Edited on

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

Franewirj Popularity

Collapse
joelnietoll profile image
Joel Nieto

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

Collapse
kresli profile image
Eduard Jacko • Edited on

true. but still, the green is dying slowly

Collapse
seanperkins profile image
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.

Collapse
kresli profile image
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...

Collapse
liviufromendtest profile image
Liviu Lupei

The death of Angular was really visible on our side.

Lots of folks who were using Protractor for testing switched to Endtest.

Collapse
themikesanto profile image
Mike Santo

That could be due to the team's plan to deprecate Protractor by the end of the year.

Collapse
liviufromendtest profile image
Liviu Lupei

Oh, yes. That's a known fact.

Collapse
datumgeek profile image
Mike Graham

thank you sir - great perspective... building enterprise apps myself. love angular :)

Collapse
andrewbaisden profile image
Andrew Baisden

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

Collapse
davishek7 profile image
Info Comment hidden by post author - thread only accessible via permalink
Avishek Das

This dude knows only one way to write clickbait titles, 'This technology is dead'.

Collapse
basspod profile image
Paul ODell

Sorry guys. Flutter is the way to go.

Collapse
mellunar profile image
mellunar

React is the one that should be dead

Collapse
jankapunkt profile image
Jan Küster • Edited on

You know that a framework became mature and stable when people say it's dead while at the same time it has an ongoing roadmap and zillions of apps running at production.

Some comments have been hidden by the post's author - find out more