6 ms·

What's the general consensus on Angular 2? I've built a few apps with it, and generally like it, although it's quite opinionated. Most of the time I've seen so

What's the general consensus on Angular 2? I've built a few apps with it, and generally like it, although it's quite opinionated. Most of the time I've seen something Angular-related appear on HN, there's generally a facet of the community lambasting it as too big/too enterprisey.

thelgevold 10y ago
It's unfortunate that the JS framework debate is so biased and subjective. I personally like to play around with several of the frameworks. My conclusion is that all the major players are of comparable quality (Angular, React, Aurelia etc). I think it really comes down to how you use the framework, rather than which one you end up with.
- lilbobbytables 10y ago
  I'm currently using both Angular 2 and React concurrently. I've previously used Angular. There are some points where I feel the opinionated aspects of Angular 2 makes things marginally quicker. However, the one thing I find most consistent is that issues with ng2 seem to frustrate me more than issues with React. It seems that the this might be a combination of quality and length of tracebacks in ng2. Quality seems to be spotty (sometimes very helpful, sometimes not), and the length of tracebacks in a ready-for-prod project are easily enormous (although sometimes only small). Leading to much more frustration while trying to find what the issue is - probably a matter of not declaring a service in a module or something. Similarly, the whole injection and declaration process feels tedious and unnatural to me, compared to React, where you just import components from wherever you'd like and use them. They both work fine, I'm just noticing that my frustration level is generally lower with React. I'm curious how it is for others that are using both concurrently, to compare.
  - thelgevold 10y ago
    I definitely agree that there is a bit of a learning curve to Angular. A big pivot for people who are used to version 1. The thing I like the most is how they are pushing the framework to reduce the footprint. In the upcoming version (4) they have made even more progress on this. There are also plans to introduce the Closure compiler in the build chain, which will lead to further optimizations.
zdragnar 10y ago
On the one hand, it's great for a large, distributed team of developers who are responsible for multiple programming disciplines... Mostly because the documentation is all in one spot, and angular material is very comprehensive. Personally, I prefer react, with small swarth of libraries such redux and tcomb to fill out the rest. However, it can be confusing for non-full time JS developers to discover that react isn't an all-encompassing, monolithic framework, and get lost trying to figure out which libraries are responsible for the different pieces of the puzzle. It can (and has been) done, but I do understand why people would rather use Angular in that scenario- the "don't think out of the box, it's got everything you need" mindset reminds me a lot of ember, which certainly has its fans and upsides as well. Pick something, get comfortable with it, then pick up something else. All of these choices solve similar problems from different perspectives, and understanding them will help you get a bit of a deeper understanding of the trade-offs when more new updates and tools come out.
keithnz 10y ago
always lots of different opinions on this, HN seems very React biased... which I use in a couple of products, but I find it a bit verbose. I'm finding Vue ( with Quasar ) quite nice
- jpkeisala 10y ago
  I also like a lot Vue. I have implemented one project with NG2. What I did not really realized on NG2 until "too late" that it is true SPA framework, it does not work well like NG1 where I could just have parts of site (or page) as an "app" and the rest would be normal website. But Vue does that perfectly and so easy to learn comparing to Angular and React.
  - iSnow 10y ago
    Could you clarify this a bit, what is the big difference here between AngularJS and Angular in terms of how much of the page you have to put under its control? I am just picking up Angular, coming from v1.
    - jordic 10y ago
      With angular there is no easy way of mixing it with html content from a CMS (something that was powerful with angularjs).
camus2 10y ago
Should your UI framework ship with an IoC container? you wouldn't expect your ORM to do that, this is a separate concern. If your UI framework is to complicated to be used without the IoC container then there is an issue with it. Even Hibernate or Doctrine don't make using an IoC container mandatory. So when you eliminate the IoC container, what is left? the router? it's OK but not fantastic. The databinding? again nothing special about it. The directives and components? these 2 things are really why we are all using JS frameworks today (bonus for test-ability). So the latter are good yes, but they are no better than React or Vue system. The framework that will succeed now is the one with the largest ecosystem of plugins and collection of components. In that sense Angular4 is no more entreprisey than the competition.
- rubber_duck 10y ago
  >Should your UI framework ship with an IoC container? Angular 2 is not a UI framework, it's a fronted application framework - it has IoC, HTTP stack, Router, internationalization, etc. If C#/Java like tooling and design patterns sound appealing to you (eg. enterprise roots) then Angular 2 is going to feel better than React and others, if you're more of FP guy and you prefer to cobble together for flexibility then React is a better choice - this is from my experience. And by far the best option I've tried for HTML front end was Angular 2 Dart - Dart default tooling beats NPM/WebPack/whatever ecosystem by a mile.
  - camus2 10y ago
    > Angular 2 is not a UI framework, it's a fronted application framework > it's a fronted application framework it is absolutely meaningless. Angular 2 is a UI framework, calling by any other name won't change that fact. The fact that is has 3rd party dependencies wont change that fact either. You use Angular because you want to use it to design user interfaces in the browser and that's it, that what a browser is for, to display content. internationalization, http calls or routing are separate concerns. > If C#/Java like tooling and design patterns sound appealing to you (eg. enterprise roots) then Angular 2 is going to feel better than React and others, if you're more of FP guy and you prefer to cobble together for flexibility then React is a better choice - this is from my experience. Which is bullshit of course. React is closer to what you can find with Java FX or XAML than Angular actually is with its string templates. And neither desktop solutions mandate IoC containers, nor forces you to use their own IoC container, so my point absolutely stands even more. Neither mandate a specific http client, or an internationalization solution either. So stop pretending that Angular 2 is more "enterpisey" than the rest. But I'll let the developer community speak. The lack of popularity of Angular 2 is a sign that it is not going to drive most enterprise front-end.
Bahamut 10y ago
As someone leading development of a non-trivial product in Angular 2 (team of 8-10 engineers, 2 QA, has varied some with resource shifting) with having to solve some tricky problems (drag and drop, web audio for playback, audio recording, etc., I have found using Angular 2 a mixed experience, if generally positive. Performance is pretty much phenomenal - for those who put in the work to optimize via build toolchain config and code, there are a lot of areas where Angular gives you room to implement improvements. Observables also allow very clean push-based reactive component systems, avoiding the need for unintentional changes most of the time - lifecycle hooks help you with the rest. Implementing AOT compilation to avoid shipping the whole Angular compiler to the runtime is super painful though - it is easily one of the most frustrating experiences for a developer to do currently. I find TypeScript to be a mixed bag - it doesn't let you go all out on FP, mostly due to its flaws in typing with function composition. Testing can be slow due to the compilation of everything via the TypeScript compiler & Webpack (the interlay between the two might be the culprit). Stack traces are sometimes mysterious - I spent a couple of minutes debugging a failure from a test I wrote that resulted in an ambiguous stack trace...all because I forgot to spy on my function. Personally, I think I would enjoy creating an app in React more, but I do notice significant productivity gains for my team with Angular 2 and TypeScript, and better code design. I am probably one of the biggest experts in Angular 1 outside Google out there, and pretty knowledgeable in Angular 2, although not as sharp since I have moved into management currently, if that helps give some context.
- jordache 10y ago
  Are you guys leveraging ngrx?
  - Bahamut 10y ago
    We are - we have had state issues as a result of ngrx/store & doing some dirty manual resetting at times to work around it, confirming my distrust of redux being essentially a global store...but that is a whole other discussion.
    - jordache 10y ago
throwawaysbdi 10y ago
Angular feels like Google's GWT (Google Web Toolkit) re imagined in JavaScript. It's not bad by any means but the layer of abstraction is too thick for my taste. Like GWT or Rails, Angular makes easy stuff trivial but you start chafing against the framework if you're doing things angular was not designed to do. TLDR: It's going to suck working on ng2 apps 15 years from now. I'm weary of building things in it because, IMO, the biggest downside of all encompassing frameworks that gives you lots of abstraction is that they age really badly. I've been burned over the years by a bunch of these. What you run into is applications that can't be gracefully updated. When you're entire app is tied to a jumbo framework and it gets outdated or abandoned you pretty much have to throw the app away and start over. In the big corporate environments that angular seems aimed at you can count on applications hanging around for 15-20 years. I would much rather maintain something modular that I can slowly swap out as needed than a monolith. Something built with a react clone and 5-10 standalone libraries is going to be a lot easier to update than a 20 year old version of angular some day
- brogrammernot 10y ago
  Can you give an example of something that won't "suck" to work on 15 years from now? Every legacy product I've stepped into sucks to work on, that's why people are often hating legacy code refactoring.
  - throwawaysbdi 10y ago
    Everything old sucks, but there's fixable and unfixable suckage. IMO stuff like old PHP sites are fixable suckage. Usually minimal layers of abstraction and no crazy hooks affecting the vanilla behavior of the browser and HTTP. If they used libraries, it's usually for small stuff and they can be replaced without rewriting swaths of code. I can generally add new widgets to existing pages without fucking with what's there. Webforms is a good example of unfixable suckage. The abstraction away from how the page and HTTP works is so thick that it's impossible to refactor slowly. Like angular, webforms takes over the page lifecycle. Client side code and MVC patterns just don't work nicely with it. I can't add anything to webforms pages outside of webforms because all these page reloads happen at unpredictable times and I can't stop them without breaking everything. Every time I work on a webforms site with user complaints the most reasonable solution is to scrap it and start over. At least with other old shit that doesn't try to reinvent the wheel I can cordon off the really bad stuff and refactor

thelgevold 10y ago

It's unfortunate that the JS framework debate is so biased and subjective. I personally like to play around with several of the frameworks. My conclusion is that all the major players are of comparable quality (Angular, React, Aurelia etc). I think it really comes down to how you use the framework, rather than which one you end up with.

lilbobbytables 10y ago
I'm currently using both Angular 2 and React concurrently. I've previously used Angular. There are some points where I feel the opinionated aspects of Angular 2 makes things marginally quicker. However, the one thing I find most consistent is that issues with ng2 seem to frustrate me more than issues with React. It seems that the this might be a combination of quality and length of tracebacks in ng2. Quality seems to be spotty (sometimes very helpful, sometimes not), and the length of tracebacks in a ready-for-prod project are easily enormous (although sometimes only small). Leading to much more frustration while trying to find what the issue is - probably a matter of not declaring a service in a module or something. Similarly, the whole injection and declaration process feels tedious and unnatural to me, compared to React, where you just import components from wherever you'd like and use them. They both work fine, I'm just noticing that my frustration level is generally lower with React. I'm curious how it is for others that are using both concurrently, to compare.
- thelgevold 10y ago
  I definitely agree that there is a bit of a learning curve to Angular. A big pivot for people who are used to version 1. The thing I like the most is how they are pushing the framework to reduce the footprint. In the upcoming version (4) they have made even more progress on this. There are also plans to introduce the Closure compiler in the build chain, which will lead to further optimizations.

zdragnar 10y ago

On the one hand, it's great for a large, distributed team of developers who are responsible for multiple programming disciplines... Mostly because the documentation is all in one spot, and angular material is very comprehensive. Personally, I prefer react, with small swarth of libraries such redux and tcomb to fill out the rest. However, it can be confusing for non-full time JS developers to discover that react isn't an all-encompassing, monolithic framework, and get lost trying to figure out which libraries are responsible for the different pieces of the puzzle. It can (and has been) done, but I do understand why people would rather use Angular in that scenario- the "don't think out of the box, it's got everything you need" mindset reminds me a lot of ember, which certainly has its fans and upsides as well. Pick something, get comfortable with it, then pick up something else. All of these choices solve similar problems from different perspectives, and understanding them will help you get a bit of a deeper understanding of the trade-offs when more new updates and tools come out.

keithnz 10y ago

always lots of different opinions on this, HN seems very React biased... which I use in a couple of products, but I find it a bit verbose. I'm finding Vue ( with Quasar ) quite nice

jpkeisala 10y ago
I also like a lot Vue. I have implemented one project with NG2. What I did not really realized on NG2 until "too late" that it is true SPA framework, it does not work well like NG1 where I could just have parts of site (or page) as an "app" and the rest would be normal website. But Vue does that perfectly and so easy to learn comparing to Angular and React.
- iSnow 10y ago
  Could you clarify this a bit, what is the big difference here between AngularJS and Angular in terms of how much of the page you have to put under its control? I am just picking up Angular, coming from v1.
  - jordic 10y ago
    With angular there is no easy way of mixing it with html content from a CMS (something that was powerful with angularjs).

camus2 10y ago

Should your UI framework ship with an IoC container? you wouldn't expect your ORM to do that, this is a separate concern. If your UI framework is to complicated to be used without the IoC container then there is an issue with it. Even Hibernate or Doctrine don't make using an IoC container mandatory. So when you eliminate the IoC container, what is left? the router? it's OK but not fantastic. The databinding? again nothing special about it. The directives and components? these 2 things are really why we are all using JS frameworks today (bonus for test-ability). So the latter are good yes, but they are no better than React or Vue system. The framework that will succeed now is the one with the largest ecosystem of plugins and collection of components. In that sense Angular4 is no more entreprisey than the competition.

rubber_duck 10y ago
>Should your UI framework ship with an IoC container? Angular 2 is not a UI framework, it's a fronted application framework - it has IoC, HTTP stack, Router, internationalization, etc. If C#/Java like tooling and design patterns sound appealing to you (eg. enterprise roots) then Angular 2 is going to feel better than React and others, if you're more of FP guy and you prefer to cobble together for flexibility then React is a better choice - this is from my experience. And by far the best option I've tried for HTML front end was Angular 2 Dart - Dart default tooling beats NPM/WebPack/whatever ecosystem by a mile.
- camus2 10y ago
  > Angular 2 is not a UI framework, it's a fronted application framework > it's a fronted application framework it is absolutely meaningless. Angular 2 is a UI framework, calling by any other name won't change that fact. The fact that is has 3rd party dependencies wont change that fact either. You use Angular because you want to use it to design user interfaces in the browser and that's it, that what a browser is for, to display content. internationalization, http calls or routing are separate concerns. > If C#/Java like tooling and design patterns sound appealing to you (eg. enterprise roots) then Angular 2 is going to feel better than React and others, if you're more of FP guy and you prefer to cobble together for flexibility then React is a better choice - this is from my experience. Which is bullshit of course. React is closer to what you can find with Java FX or XAML than Angular actually is with its string templates. And neither desktop solutions mandate IoC containers, nor forces you to use their own IoC container, so my point absolutely stands even more. Neither mandate a specific http client, or an internationalization solution either. So stop pretending that Angular 2 is more "enterpisey" than the rest. But I'll let the developer community speak. The lack of popularity of Angular 2 is a sign that it is not going to drive most enterprise front-end.

Bahamut 10y ago

As someone leading development of a non-trivial product in Angular 2 (team of 8-10 engineers, 2 QA, has varied some with resource shifting) with having to solve some tricky problems (drag and drop, web audio for playback, audio recording, etc., I have found using Angular 2 a mixed experience, if generally positive. Performance is pretty much phenomenal - for those who put in the work to optimize via build toolchain config and code, there are a lot of areas where Angular gives you room to implement improvements. Observables also allow very clean push-based reactive component systems, avoiding the need for unintentional changes most of the time - lifecycle hooks help you with the rest. Implementing AOT compilation to avoid shipping the whole Angular compiler to the runtime is super painful though - it is easily one of the most frustrating experiences for a developer to do currently. I find TypeScript to be a mixed bag - it doesn't let you go all out on FP, mostly due to its flaws in typing with function composition. Testing can be slow due to the compilation of everything via the TypeScript compiler & Webpack (the interlay between the two might be the culprit). Stack traces are sometimes mysterious - I spent a couple of minutes debugging a failure from a test I wrote that resulted in an ambiguous stack trace...all because I forgot to spy on my function. Personally, I think I would enjoy creating an app in React more, but I do notice significant productivity gains for my team with Angular 2 and TypeScript, and better code design. I am probably one of the biggest experts in Angular 1 outside Google out there, and pretty knowledgeable in Angular 2, although not as sharp since I have moved into management currently, if that helps give some context.

jordache 10y ago
Are you guys leveraging ngrx?
- Bahamut 10y ago
  We are - we have had state issues as a result of ngrx/store & doing some dirty manual resetting at times to work around it, confirming my distrust of redux being essentially a global store...but that is a whole other discussion.
  - jordache 10y ago

throwawaysbdi 10y ago

Angular feels like Google's GWT (Google Web Toolkit) re imagined in JavaScript. It's not bad by any means but the layer of abstraction is too thick for my taste. Like GWT or Rails, Angular makes easy stuff trivial but you start chafing against the framework if you're doing things angular was not designed to do. TLDR: It's going to suck working on ng2 apps 15 years from now. I'm weary of building things in it because, IMO, the biggest downside of all encompassing frameworks that gives you lots of abstraction is that they age really badly. I've been burned over the years by a bunch of these. What you run into is applications that can't be gracefully updated. When you're entire app is tied to a jumbo framework and it gets outdated or abandoned you pretty much have to throw the app away and start over. In the big corporate environments that angular seems aimed at you can count on applications hanging around for 15-20 years. I would much rather maintain something modular that I can slowly swap out as needed than a monolith. Something built with a react clone and 5-10 standalone libraries is going to be a lot easier to update than a 20 year old version of angular some day

brogrammernot 10y ago
Can you give an example of something that won't "suck" to work on 15 years from now? Every legacy product I've stepped into sucks to work on, that's why people are often hating legacy code refactoring.
- throwawaysbdi 10y ago
  Everything old sucks, but there's fixable and unfixable suckage. IMO stuff like old PHP sites are fixable suckage. Usually minimal layers of abstraction and no crazy hooks affecting the vanilla behavior of the browser and HTTP. If they used libraries, it's usually for small stuff and they can be replaced without rewriting swaths of code. I can generally add new widgets to existing pages without fucking with what's there. Webforms is a good example of unfixable suckage. The abstraction away from how the page and HTTP works is so thick that it's impossible to refactor slowly. Like angular, webforms takes over the page lifecycle. Client side code and MVC patterns just don't work nicely with it. I can't add anything to webforms pages outside of webforms because all these page reloads happen at unpredictable times and I can't stop them without breaking everything. Every time I work on a webforms site with user complaints the most reasonable solution is to scrap it and start over. At least with other old shit that doesn't try to reinvent the wheel I can cordon off the really bad stuff and refactor