5 ms·

First standalone components to get rid of modules and now signals. There is quite some innovation happening in Angular while being a really mature framework. I

First standalone components to get rid of modules and now signals. There is quite some innovation happening in Angular while being a really mature framework. I enjoy Angular as much as I love React, Vue or Svelte. It's always about picking the right tool. And when thinking of Angular it's that batteries-included framework that is godsend for big enterprises where any decision given by the outside is something you don't have to battle for. Often I describe Angular as a hidden champion. It's loved and trusted by enterprises while they are not really talking about it. Plus they hide all the package downloads behind their own npm caching servers like Nexus or Artifcactory. On the other side there are tons of individual engineers working with React or Vue (for good reasons) and writing blog post after blog post. Maybe that's one reason why folks think Angular is dying? I don't see any signs of that though.

paulddraper 3y ago
In my experience people that hate Angular don't understand why they hate Angular. Like, if you like Svelte, that's great. You will probably like Angular too.
- ttfkam 3y ago
  A 3MB JavaScript runtime blob right out of the gate? ("Only" 275KB needed just to first render, like that's laudable on its own.) Other frameworks have already loaded dependent REST/GraphQL data before Angular has even initialized. Take someone on a mobile device and put them at the edge of cell signal range either because they're out an about or stuck in the bowels of a building with thick walls. Suddenly 275KB-3MB matters a lot more and the user is staring at a blank screen for 10+ secs. Then there's the boilerplate, all the metadata you need to add to each component that has nothing to do with your problem domain. And then there's runtime speed compared to alternatives. While I'm truly happy to see Angular incorporate signals, now devs need to learn when to use signals rather than rxjs. I know now that it's the difference between needing async or not, but if you go down one path, it's a PITA to tear it down and rewrite for the new path. THAT's why I don't like Angular, though I'd happily choose Angular over React and Vue, both of which are a prone to reducing codebases to big balls of mud due to their "flexibility".
- ttfkam 3y ago
  How about the extra 30 seconds to couple minutes for CI/CD to make a production build for static deployment? V16 added the ability to put esbuild/Vite into the mix, but it still builds WAAAAAAAAY too slow compared to modern alternatives, especially if you're on v15-. ng serve for development is a pig too. Save-reload cycle is far from instant.
- riku_iki 3y ago
  I like Angular, but approach of doing the same thing in 3 different ways (promises, rx and now signals) make codebase more complicated and adds additional brain load.
  - jamra 3y ago
    Compared to React with Contexts, hooks, redux, reducers, Relay, Recoil….
- warent 3y ago
  Their own website renders the Angular "template" as a string with no syntax highlighting. The framework is extremely overengineered requiring multiple files for "hello world" It introduces a lot of unnecessary complexity for projects of any size It uses invalid HTML, with attribute syntax including brackets and parentheses Sadly It's just not a good framework
  - stickfigure 3y ago
    I wrote this on Quora 8 years ago, and it's still true: https://qr.ae/pypHJw https://qr.ae/pypHJw It's my answer to what I can tell you agree is the most important question in software engineering - "What programming language has the shortest 'Hello World' program?"
    - operatingthetan 3y ago
      We're talking about a framework here, not a programming language. I don't think the above poster's assessment about the amount of files needed for hello world offers a charitable conclusion either, given frameworks are not languages. The same file usage would apply to many other popular 'heavy' opinionated frameworks.
      - stickfigure 3y ago
        My point is, nobody writes Hello World webapps for a living. The number of lines or files is irrelevant. There is precisely zero value in this metric.
        operatingthetan 3y ago
        Sorry, I misread your comment.
        baq 3y ago
        There’s a grain of truth in that thought. First impressions matter, frameworks aren’t exempt from that basic psychological fact. If you treat ’complexity of hello world’ as a proxy for learning curve steepness (again, people do things like that subconsciously), you may end with a very wrong assessment very early. It’ll probably tell more about the assessor than the framework but it’s a real risk.
- Zanfa 3y ago
  > In my experience people that hate Angular don't understand why they hate Angular. One of my major annoyances is the templating language. Completely unnecessary and over complicated, compared to JSX. Just another weird syntax to learn with its own arbitrary limitations and quirks. I think it’s a good indicator of the overengineering surrounding Angular overall.
  - paulddraper 3y ago
    And you say the same of Vue and Svelte, I assume?
    - Zanfa 3y ago
      I haven't had the chance to work with either much, but at the end of the day, a new new syntax just for doing fancy if/else/for seems unnecessary. I believe Angular's hand was forced since JS at the time didn't have as ergonomic syntax as it does now, with fat arrow functions, .map and other niceties.
  - politelemon 3y ago
    I see it as the opposite. JSX is a convoluted mess, and does not make for easy reading due to being mixed in with everything else, while Angular promotes clean separation and promotes a template language like many others. It's usually React codebases that I've seen overengineered due to lack of features, while Angular codebases are very same-y - that's a good thing from maintenance perspective.
    - Zanfa 3y ago
      Obviously there's some matter of taste, but JSX is simpler in my mind, because it's just JS with a tiny bit of syntactic sugar to have nicer function calls for components. That's it. Anything you can write in JS, you can write in JSX and it works. You can debug and use all the tools you'd use for regular JS. With Angular templates, there's an entire new language, with its own weird syntax ngIf/else, ngSwitchDefault, let-*, pipes and other components that get pulled in based on whether you forgot to set up correctly or not in modules far-far away somewhere in the codebase, brackets of different sorts having different functions and just a lot more stuff to remember. And if it doesn't work, you're gonna get a silent error most of the time with no easy way to set a breakpoint to investigate. I also don't believe there's any real separation between the HTML templates and the Component class, just because they're written in separate files. They're just as tightly coupled as any regular React component, just harder to follow. I don't think I've ever seen an Angular component, where you could swap out the template, without making simultaneous changes to the Component to accommodate it, which should be possible if they were truly separate.
- jbergens 3y ago
  I can just note that our Angular code seems to be much harder to maintain than our React code. The React ecosystem also improves faster (yes, sometimes a bit too fast).
  - NoNameProvided 3y ago
    > I can just note that our Angular code seems to be much harder to maintain than our React code. A big part of maintainability comes from the quality of code and/or existing experience with the two frameworks, not the frameworks itself. I work at an Angular only shop, if we would write some React it would be probably harder to maintain for us than the Angular ones.
- snemvalts 3y ago
  The entire library is so spread out, with so many half-assed features. When I wrote Angular I spent 2 weeks on getting something similar to `props.children` working. <ng-content> didn't work if the elements were dynamic. Outlet system was way too verbose. The 2 way databinding is anachronistic and belongs in 2010. The i18n system they shipped with is awful. No way to have translations in code, only in template. This breaks down very fast when building generic components. The DI relies on https://www.npmjs.com/package/reflect-metadata https://www.npmjs.com/package/reflect-metadata, which makes the builder an opaque black box unlike a webpack configuration. Because of the opaque CLI I've spent 2 weeks figuring out why every third dev build resulted in a 150 line long tsc stacktrace, and it turned out to be angular's 1.x types package. Would have been so much easier with a webpack configuration.
  - andix 3y ago
    The props.children/slots issue is one of my biggest problems with angular. It’s really hard to use composition like you always do in react. Another thing is, that angular components always wrap their template into a block element (like a div) in the DOM. So if you do some refactoring and split up one big component, the result in the DOM is different and your CSS may not work anymore. If you are using flexbox or grid, it may even be impossible to split the component.
  - paulddraper 3y ago
    > <ng-content> didn't work if the elements were dynamic Usually if you run into problems like that, you should use templates. Honestly, I'm not sure why `<ng-content>` exists vs templates. I'm sure there's a reason (verbosity?), but templates have way fewer caveats. > Would have been so much easier with a webpack configuration I agree. It's not hard at all to do a Webpack configuration of Angular. Just add the Angular plugin. (That's what the CLI does under the hood.) I wish they document it though.
    - snemvalts 3y ago
      The angular plugin for webpack is still an opaque black box.
- nikeee 3y ago
  Having mutability/2-way-databinding makes angular hardly benefit from using TypeScript. State is just so much pain and it is hard to make impossible states not representable in the types. Angular requires a lot of extra steps to get the templates properly type-checked (and you even need an editor plugin for that). I can't even name which non-standard entries in the tsconfig are necessary to have all templates checked entirely. Most people use the cli to generate new components. Where in other frameworks, you just create a new file, maybe use a snippet and call it a day, the cli yields a test, scss, html and the actual component code as separate files. Having worked with angular and react for 5 years in parallel, I'm pretty certain that I'd never touch angular again. The DX is so complicated in comparison. Despite forcing you to use TypeScript, angular is the framework that benefits the least of it.
phil294 3y ago
Angular is as little innovative for web frameworks as Firefox-ESR is for browsers. It merely keeps copying features from other frameworks - just many years later. It is a chronically outdated framework that always struggles to keep up with its competitors. It would be ok if those were deliberate design decisions, but if the features get copied some day anyway, what is the point? Why not do it the right way from the start? For example, this update brings us computed properties, an essential feature for any complex performant web application that was made popular by Vue.js 10 years ago [1]. And now in 2023 we get it in Angular, essentially a confirmation by its devs that its lack had always been a design error. I also cannot understand the "mature" argument. For example, it took five years for documentation on the integral `<ng-content>` to arrive [2]. This is something I'd expect from the side project of a lone programmer, not an enterprise-level framework. The only upsides of Angular are its "batteries included" approach and the (debatable) default of RXJS, while the downsides are plenty (see other comments). [1] https://github.com/vuejs/vue/tree/218557cdec830a629252f4a9e2643973dc1f1d2d https://github.com/vuejs/vue/tree/218557cdec830a629252f4a9e2... [2] https://github.com/angular/angular/issues/17983 https://github.com/angular/angular/issues/17983
- politelemon 3y ago
  Not quite, its webcomponent implementation is ahead of React's, which is still pretty poor. Its PWA integration has been among the simplest and most seamless I've seen. It's easy to cherry pick examples either way.
- neamar 3y ago
  Knockout.js, released in 2010, introduced computed properties to the web (slightly before Vue I think)
- spyke112 3y ago
  Computed properties has always been a possibility in Angular, you'd just create a getter[0] based on multiple different values, works like a charm. This new way is probably faster, but I've honestly never had any issues with the other approach. [0] https://www.typescripttutorial.net/typescript-tutorial/typescript-getters-setters/ https://www.typescripttutorial.net/typescript-tutorial/types...
epolanski 3y ago
I just don't like Angular at all. Every version essentially breaks the previous one. 90% of the information online is outdated or incorrect. By the time you start a project on Angular X, Angular X+2 is out which makes many things complicated, some deprecated. It's true that it provides a robust set of defaults and libraries but those are generally an overkill for most projects. On top of that there's a higher compilation complexity in Angular which I have seen every single Angular project struggle at some point.
- spyke112 3y ago
  The Angular team has this nifty little update tool[0] that helps us through running migrations and preparing the code base for upgrades. [0] https://update.angular.io/ https://update.angular.io/
- 1thrasher 3y ago
  > Every version essentially breaks the previous one. This is simply not true. It might have been true in the early Angular v2 days, but since v6 or so, updates are relatively trivial. https://update.angular.io https://update.angular.io has your back extremely well. The trick is to ensure whatever third party libs you're using have also been updated, otherwise you're application may break.
  - epolanski 3y ago
    Exactly, not only updating the application is an issue, but third party libraries quickly lose support for previous versions.
ggorlen 3y ago
> I don't see any signs of that though. Even if we take it for granted that package downloads are hidden, how should we account for the ~40% drop in new questions in the Angular tag on Stack Overflow since its peak in 2018? https://insights.stackoverflow.com/trends?tags=angular%2Creactjs%2Cnext.js%2Cvue.js https://insights.stackoverflow.com/trends?tags=angular%2Crea... In the Stack Overflow developer survey last year, Angular was 52% loved versus 68% for React and 63% for Vue. Can we find a way to dismiss this as well? https://survey.stackoverflow.co/2022/#section-most-loved-dreaded-and-wanted-web-frameworks-and-technologies https://survey.stackoverflow.co/2022/#section-most-loved-dre... On the freelancing platform Codementor, based on rough sampling, there have been about 338 Angular requests in the past year versus 2098 for React (6x). Sure, Angular won't die outright because the enterprises that have adopted it will need ongoing support, but this seems like a weak metric for growth. For enterprises selecting a tech stack now, choosing Angular chops the hiring pool by a significant factor. I don't see evidence of advantages Angular offers overcoming that. On the other hand, React has gained new life through frameworks like Next.js and maintained relevance. React's popularity is not just individual engineers making a disproportionate amount of noise on blogs. React hooks are the most established unit of construction for making components at this point across web, mobile, desktop and command line. That won't last forever, but there are too many signs of Angular trending out and React trending upward to dismiss.

paulddraper 3y ago

In my experience people that hate Angular don't understand why they hate Angular. Like, if you like Svelte, that's great. You will probably like Angular too.

ttfkam 3y ago
A 3MB JavaScript runtime blob right out of the gate? ("Only" 275KB needed just to first render, like that's laudable on its own.) Other frameworks have already loaded dependent REST/GraphQL data before Angular has even initialized. Take someone on a mobile device and put them at the edge of cell signal range either because they're out an about or stuck in the bowels of a building with thick walls. Suddenly 275KB-3MB matters a lot more and the user is staring at a blank screen for 10+ secs. Then there's the boilerplate, all the metadata you need to add to each component that has nothing to do with your problem domain. And then there's runtime speed compared to alternatives. While I'm truly happy to see Angular incorporate signals, now devs need to learn when to use signals rather than rxjs. I know now that it's the difference between needing async or not, but if you go down one path, it's a PITA to tear it down and rewrite for the new path. THAT's why I don't like Angular, though I'd happily choose Angular over React and Vue, both of which are a prone to reducing codebases to big balls of mud due to their "flexibility".
ttfkam 3y ago
How about the extra 30 seconds to couple minutes for CI/CD to make a production build for static deployment? V16 added the ability to put esbuild/Vite into the mix, but it still builds WAAAAAAAAY too slow compared to modern alternatives, especially if you're on v15-. ng serve for development is a pig too. Save-reload cycle is far from instant.
riku_iki 3y ago
I like Angular, but approach of doing the same thing in 3 different ways (promises, rx and now signals) make codebase more complicated and adds additional brain load.
- jamra 3y ago
  Compared to React with Contexts, hooks, redux, reducers, Relay, Recoil….
warent 3y ago
Their own website renders the Angular "template" as a string with no syntax highlighting. The framework is extremely overengineered requiring multiple files for "hello world" It introduces a lot of unnecessary complexity for projects of any size It uses invalid HTML, with attribute syntax including brackets and parentheses Sadly It's just not a good framework
- stickfigure 3y ago
  I wrote this on Quora 8 years ago, and it's still true: https://qr.ae/pypHJw https://qr.ae/pypHJw It's my answer to what I can tell you agree is the most important question in software engineering - "What programming language has the shortest 'Hello World' program?"
  - operatingthetan 3y ago
    We're talking about a framework here, not a programming language. I don't think the above poster's assessment about the amount of files needed for hello world offers a charitable conclusion either, given frameworks are not languages. The same file usage would apply to many other popular 'heavy' opinionated frameworks.
    - stickfigure 3y ago
      My point is, nobody writes Hello World webapps for a living. The number of lines or files is irrelevant. There is precisely zero value in this metric.
      - operatingthetan 3y ago
        Sorry, I misread your comment.
      - baq 3y ago
        There’s a grain of truth in that thought. First impressions matter, frameworks aren’t exempt from that basic psychological fact. If you treat ’complexity of hello world’ as a proxy for learning curve steepness (again, people do things like that subconsciously), you may end with a very wrong assessment very early. It’ll probably tell more about the assessor than the framework but it’s a real risk.
Zanfa 3y ago
> In my experience people that hate Angular don't understand why they hate Angular. One of my major annoyances is the templating language. Completely unnecessary and over complicated, compared to JSX. Just another weird syntax to learn with its own arbitrary limitations and quirks. I think it’s a good indicator of the overengineering surrounding Angular overall.
- paulddraper 3y ago
  And you say the same of Vue and Svelte, I assume?
  - Zanfa 3y ago
    I haven't had the chance to work with either much, but at the end of the day, a new new syntax just for doing fancy if/else/for seems unnecessary. I believe Angular's hand was forced since JS at the time didn't have as ergonomic syntax as it does now, with fat arrow functions, .map and other niceties.
- politelemon 3y ago
  I see it as the opposite. JSX is a convoluted mess, and does not make for easy reading due to being mixed in with everything else, while Angular promotes clean separation and promotes a template language like many others. It's usually React codebases that I've seen overengineered due to lack of features, while Angular codebases are very same-y - that's a good thing from maintenance perspective.
  - Zanfa 3y ago
    Obviously there's some matter of taste, but JSX is simpler in my mind, because it's just JS with a tiny bit of syntactic sugar to have nicer function calls for components. That's it. Anything you can write in JS, you can write in JSX and it works. You can debug and use all the tools you'd use for regular JS. With Angular templates, there's an entire new language, with its own weird syntax ngIf/else, ngSwitchDefault, let-*, pipes and other components that get pulled in based on whether you forgot to set up correctly or not in modules far-far away somewhere in the codebase, brackets of different sorts having different functions and just a lot more stuff to remember. And if it doesn't work, you're gonna get a silent error most of the time with no easy way to set a breakpoint to investigate. I also don't believe there's any real separation between the HTML templates and the Component class, just because they're written in separate files. They're just as tightly coupled as any regular React component, just harder to follow. I don't think I've ever seen an Angular component, where you could swap out the template, without making simultaneous changes to the Component to accommodate it, which should be possible if they were truly separate.
jbergens 3y ago
I can just note that our Angular code seems to be much harder to maintain than our React code. The React ecosystem also improves faster (yes, sometimes a bit too fast).
- NoNameProvided 3y ago
  > I can just note that our Angular code seems to be much harder to maintain than our React code. A big part of maintainability comes from the quality of code and/or existing experience with the two frameworks, not the frameworks itself. I work at an Angular only shop, if we would write some React it would be probably harder to maintain for us than the Angular ones.
snemvalts 3y ago
The entire library is so spread out, with so many half-assed features. When I wrote Angular I spent 2 weeks on getting something similar to `props.children` working. <ng-content> didn't work if the elements were dynamic. Outlet system was way too verbose. The 2 way databinding is anachronistic and belongs in 2010. The i18n system they shipped with is awful. No way to have translations in code, only in template. This breaks down very fast when building generic components. The DI relies on https://www.npmjs.com/package/reflect-metadata https://www.npmjs.com/package/reflect-metadata, which makes the builder an opaque black box unlike a webpack configuration. Because of the opaque CLI I've spent 2 weeks figuring out why every third dev build resulted in a 150 line long tsc stacktrace, and it turned out to be angular's 1.x types package. Would have been so much easier with a webpack configuration.
- andix 3y ago
  The props.children/slots issue is one of my biggest problems with angular. It’s really hard to use composition like you always do in react. Another thing is, that angular components always wrap their template into a block element (like a div) in the DOM. So if you do some refactoring and split up one big component, the result in the DOM is different and your CSS may not work anymore. If you are using flexbox or grid, it may even be impossible to split the component.
- paulddraper 3y ago
  > <ng-content> didn't work if the elements were dynamic Usually if you run into problems like that, you should use templates. Honestly, I'm not sure why `<ng-content>` exists vs templates. I'm sure there's a reason (verbosity?), but templates have way fewer caveats. > Would have been so much easier with a webpack configuration I agree. It's not hard at all to do a Webpack configuration of Angular. Just add the Angular plugin. (That's what the CLI does under the hood.) I wish they document it though.
  - snemvalts 3y ago
    The angular plugin for webpack is still an opaque black box.
nikeee 3y ago
Having mutability/2-way-databinding makes angular hardly benefit from using TypeScript. State is just so much pain and it is hard to make impossible states not representable in the types. Angular requires a lot of extra steps to get the templates properly type-checked (and you even need an editor plugin for that). I can't even name which non-standard entries in the tsconfig are necessary to have all templates checked entirely. Most people use the cli to generate new components. Where in other frameworks, you just create a new file, maybe use a snippet and call it a day, the cli yields a test, scss, html and the actual component code as separate files. Having worked with angular and react for 5 years in parallel, I'm pretty certain that I'd never touch angular again. The DX is so complicated in comparison. Despite forcing you to use TypeScript, angular is the framework that benefits the least of it.

phil294 3y ago

Angular is as little innovative for web frameworks as Firefox-ESR is for browsers. It merely keeps copying features from other frameworks - just many years later. It is a chronically outdated framework that always struggles to keep up with its competitors. It would be ok if those were deliberate design decisions, but if the features get copied some day anyway, what is the point? Why not do it the right way from the start? For example, this update brings us computed properties, an essential feature for any complex performant web application that was made popular by Vue.js 10 years ago [1]. And now in 2023 we get it in Angular, essentially a confirmation by its devs that its lack had always been a design error. I also cannot understand the "mature" argument. For example, it took five years for documentation on the integral `<ng-content>` to arrive [2]. This is something I'd expect from the side project of a lone programmer, not an enterprise-level framework. The only upsides of Angular are its "batteries included" approach and the (debatable) default of RXJS, while the downsides are plenty (see other comments). [1] https://github.com/vuejs/vue/tree/218557cdec830a629252f4a9e2643973dc1f1d2d https://github.com/vuejs/vue/tree/218557cdec830a629252f4a9e2... [2] https://github.com/angular/angular/issues/17983 https://github.com/angular/angular/issues/17983

politelemon 3y ago
Not quite, its webcomponent implementation is ahead of React's, which is still pretty poor. Its PWA integration has been among the simplest and most seamless I've seen. It's easy to cherry pick examples either way.
neamar 3y ago
Knockout.js, released in 2010, introduced computed properties to the web (slightly before Vue I think)
spyke112 3y ago
Computed properties has always been a possibility in Angular, you'd just create a getter[0] based on multiple different values, works like a charm. This new way is probably faster, but I've honestly never had any issues with the other approach. [0] https://www.typescripttutorial.net/typescript-tutorial/typescript-getters-setters/ https://www.typescripttutorial.net/typescript-tutorial/types...

epolanski 3y ago

I just don't like Angular at all. Every version essentially breaks the previous one. 90% of the information online is outdated or incorrect. By the time you start a project on Angular X, Angular X+2 is out which makes many things complicated, some deprecated. It's true that it provides a robust set of defaults and libraries but those are generally an overkill for most projects. On top of that there's a higher compilation complexity in Angular which I have seen every single Angular project struggle at some point.

spyke112 3y ago
The Angular team has this nifty little update tool[0] that helps us through running migrations and preparing the code base for upgrades. [0] https://update.angular.io/ https://update.angular.io/
1thrasher 3y ago
> Every version essentially breaks the previous one. This is simply not true. It might have been true in the early Angular v2 days, but since v6 or so, updates are relatively trivial. https://update.angular.io https://update.angular.io has your back extremely well. The trick is to ensure whatever third party libs you're using have also been updated, otherwise you're application may break.
- epolanski 3y ago
  Exactly, not only updating the application is an issue, but third party libraries quickly lose support for previous versions.

ggorlen 3y ago

> I don't see any signs of that though. Even if we take it for granted that package downloads are hidden, how should we account for the ~40% drop in new questions in the Angular tag on Stack Overflow since its peak in 2018? https://insights.stackoverflow.com/trends?tags=angular%2Creactjs%2Cnext.js%2Cvue.js https://insights.stackoverflow.com/trends?tags=angular%2Crea... In the Stack Overflow developer survey last year, Angular was 52% loved versus 68% for React and 63% for Vue. Can we find a way to dismiss this as well? https://survey.stackoverflow.co/2022/#section-most-loved-dreaded-and-wanted-web-frameworks-and-technologies https://survey.stackoverflow.co/2022/#section-most-loved-dre... On the freelancing platform Codementor, based on rough sampling, there have been about 338 Angular requests in the past year versus 2098 for React (6x). Sure, Angular won't die outright because the enterprises that have adopted it will need ongoing support, but this seems like a weak metric for growth. For enterprises selecting a tech stack now, choosing Angular chops the hiring pool by a significant factor. I don't see evidence of advantages Angular offers overcoming that. On the other hand, React has gained new life through frameworks like Next.js and maintained relevance. React's popularity is not just individual engineers making a disproportionate amount of noise on blogs. React hooks are the most established unit of construction for making components at this point across web, mobile, desktop and command line. That won't last forever, but there are too many signs of Angular trending out and React trending upward to dismiss.