Ask HN: Has anyone else found Angular to be destroying their productivity?
13 comments
Yes, angular is waaaay too complicated for what it brings to the table. Testing sucks. Debugging sucks. Implementing anything is more about jumping through angular hoops rather than the feature !!
I've used it for one project and will never use it for anything else. It might potentially solve problems that google has with their devs/team structure/enforcing "the way" but my problems are more mundane.
With all new trendy tech you gotta ask yourself if it actually makes your life easier or if the marketing is making you think it does.
These days it feels like the trendy tech gets in the way of actual dev. wtf.
It sounds like you aren't afraid to buck the trends. Good on you :)
I've used it for one project and will never use it for anything else. It might potentially solve problems that google has with their devs/team structure/enforcing "the way" but my problems are more mundane.
With all new trendy tech you gotta ask yourself if it actually makes your life easier or if the marketing is making you think it does.
These days it feels like the trendy tech gets in the way of actual dev. wtf.
It sounds like you aren't afraid to buck the trends. Good on you :)
I haven't noticed this, strangely most who have commented have, but I and my colleagues feel the opposite. At the company I'm at now, everything is angular. Mobile, main site, ancillary sites, and administration dashboard. In this case Angular is a HUGE productivity booster as we are sharing modules between multiple projects. This is great for a number of reasons, but I think whats always undervalued is it makes code reviews much easier, allows better use of CDNs and is more secure (less custom code = less attack vectors).
At a previous job in a major corporation we wouldn't use it in production, but given the chance others would always use angular for internal tools/portals/mockups etc. I think mostly because it was the fastest way to make something, with Visual Studios support of Angular syntax, and similar MVC style to what the team was used to. There is also something to be said about being able to reason about your code long after you wrote it. I think Angular is by far much easier to read than any other structure I've seen so far (yes even React). Also until Reacts testing libraries can catch up Angular is still the winner here - not the best but not the worst.
On reflection, I think Angular really shines in Enterprise software, with large teams. I agree it might be wasted time on one-off projects with 1 or 2 people. I've even been in a board meeting where the big emphasis was it's auto sanitization in application with lots of user input/display would save the company hours of baby sitting jr dev's. So you can see why verbose/defensive-programming can mean a lot on big teams.
At a previous job in a major corporation we wouldn't use it in production, but given the chance others would always use angular for internal tools/portals/mockups etc. I think mostly because it was the fastest way to make something, with Visual Studios support of Angular syntax, and similar MVC style to what the team was used to. There is also something to be said about being able to reason about your code long after you wrote it. I think Angular is by far much easier to read than any other structure I've seen so far (yes even React). Also until Reacts testing libraries can catch up Angular is still the winner here - not the best but not the worst.
On reflection, I think Angular really shines in Enterprise software, with large teams. I agree it might be wasted time on one-off projects with 1 or 2 people. I've even been in a board meeting where the big emphasis was it's auto sanitization in application with lots of user input/display would save the company hours of baby sitting jr dev's. So you can see why verbose/defensive-programming can mean a lot on big teams.
> I think Angular is by far much easier to read than any other structure I've seen so far (yes even React).
I agree re React (it takes getting used to), but what about EmberJS?
I agree re React (it takes getting used to), but what about EmberJS?
I worked at a startup that used angular. That was my impression also. It was taking them 3x-5x longer to implement features than what I thought was reasonable.
The CTO picked angular because he wanted to pad his resume with angular experience. The other programmers were to junior to notice they were running around in circles.
That's actually a common anti-pattern for startup failure. The CTO makes a technology choice based on padding his resume, instead of technical merit. He's looking out for his future career at the expense of his current startup.
There also were all sorts of weird performance issues with their website. If I left it running for an hour, it would crash. There were all sorts of weird "$digest in progress" errors in the console.
I'm pretty sure they weren't using angular correctly. However, if a team of average programmers aren't using angular correctly, do you blame them or blame angular?
Also, they were using angular 1.0, which means they're stuck now.
I don't mention angular on my resume, because I don't want to work with angular.
The CTO picked angular because he wanted to pad his resume with angular experience. The other programmers were to junior to notice they were running around in circles.
That's actually a common anti-pattern for startup failure. The CTO makes a technology choice based on padding his resume, instead of technical merit. He's looking out for his future career at the expense of his current startup.
There also were all sorts of weird performance issues with their website. If I left it running for an hour, it would crash. There were all sorts of weird "$digest in progress" errors in the console.
I'm pretty sure they weren't using angular correctly. However, if a team of average programmers aren't using angular correctly, do you blame them or blame angular?
Also, they were using angular 1.0, which means they're stuck now.
I don't mention angular on my resume, because I don't want to work with angular.
Yes and no. I'd say that Angular has one of the steepest learning curves of the single-page-application frameworks out there. And it's not necessarily intuitive in some areas. But once you get rolling (and the Angular way becomes muscle-memory) then you don't spend nearly as much time.
But yes I agree on your general point: In the beginning you don't feel like you're saving time using Angular. That is, unless you were used to rigging up two-way-binding (and other fanciness) manually before you used Angular. If you've ever tried to do such things in plain javascript, then Angular will prob feel like a timesaver.
But yes I agree on your general point: In the beginning you don't feel like you're saving time using Angular. That is, unless you were used to rigging up two-way-binding (and other fanciness) manually before you used Angular. If you've ever tried to do such things in plain javascript, then Angular will prob feel like a timesaver.
A lot of the bad rep about Angular results from the fact that it gives users too much rope to hang themselves with.
I worked at an Angular focused consultancy for a while, and have seen some absolutely horrifying (inherited) Angular codebases precisely due to overuse of controller spaghetti code and scope inheritance. On the other hand, our own greenfield projects have been a pleasure to work with because they focus on implementing most functionality in services rather than in controllers and using services for communication between directives over scope inheritance.
Angular 2 tries to cut back on some of the oft misused features like controllers and scope inheritance, but it's essentially an entirely new framework because of it. There's no clear upgrade path if you've been using these features gratuitously in your project, in which case you'd probably be better off doing some heavy refactoring, if not a rewrite, anyways.
And as far as new frameworks are concerned, React + Om is a much better way to build applications than Angular 2 in my opinion.
I worked at an Angular focused consultancy for a while, and have seen some absolutely horrifying (inherited) Angular codebases precisely due to overuse of controller spaghetti code and scope inheritance. On the other hand, our own greenfield projects have been a pleasure to work with because they focus on implementing most functionality in services rather than in controllers and using services for communication between directives over scope inheritance.
Angular 2 tries to cut back on some of the oft misused features like controllers and scope inheritance, but it's essentially an entirely new framework because of it. There's no clear upgrade path if you've been using these features gratuitously in your project, in which case you'd probably be better off doing some heavy refactoring, if not a rewrite, anyways.
And as far as new frameworks are concerned, React + Om is a much better way to build applications than Angular 2 in my opinion.
I think Angular is actually great for productivity, with the limiting factor being performance. Certainly, the initial learning curve can be painful, but after that I believe productivity is one of its strong points.
I’m trying to think about what part you think is 10x more lines of code than it should be and my best guess is directives. While directives can initially seem painful, if done right, they are perhaps the best part of Angular (along with 2 way data binding - ignoring the performance liability).
Certainly anything can be overdone or done poorly, so those may be factors. However, directives help turn HTML into your own enhanceable DSL with logic encapsulated in a new element.
Downsides of directives are one, the logic can flow from code to markup to code, which initially can be confusing and two, the setup required to create one. Perhaps I’m an Angular heretic, but I think avoiding excessive directives with a little jQuery in the controller isn’t always bad, especially when the code is still taking shape.
Other than directives, I’m not sure what part would be the 10x increase. Services don’t seem much different from utilities. Controllers or views? Our team must be somewhere around 1 million lines of Angular code and I think things are holding up well with productivity fairly strong. The primary issue I’d say we are seeing is regarding watchers and performance. It’s easy to let the number of watchers get out of control, but it's not that bad and only in areas where users can create 100s of custom widgets.
I’m trying to think about what part you think is 10x more lines of code than it should be and my best guess is directives. While directives can initially seem painful, if done right, they are perhaps the best part of Angular (along with 2 way data binding - ignoring the performance liability).
Certainly anything can be overdone or done poorly, so those may be factors. However, directives help turn HTML into your own enhanceable DSL with logic encapsulated in a new element.
Downsides of directives are one, the logic can flow from code to markup to code, which initially can be confusing and two, the setup required to create one. Perhaps I’m an Angular heretic, but I think avoiding excessive directives with a little jQuery in the controller isn’t always bad, especially when the code is still taking shape.
Other than directives, I’m not sure what part would be the 10x increase. Services don’t seem much different from utilities. Controllers or views? Our team must be somewhere around 1 million lines of Angular code and I think things are holding up well with productivity fairly strong. The primary issue I’d say we are seeing is regarding watchers and performance. It’s easy to let the number of watchers get out of control, but it's not that bad and only in areas where users can create 100s of custom widgets.
Around 1 million lines of Angular code is very interesting...
Does this product also support iOS and Android? How's rendering the performance there?
Does this product also support iOS and Android? How's rendering the performance there?
I'm not really a UI guy, but the UI folks at my current shop expressed a similar opinion when we were making technology choices for a new project (and they'd be qualified to know, because we have an Angular app in production).
The new product ended up going with React, and I've heard positive sentiments about it in comparison with Angular.
The new product ended up going with React, and I've heard positive sentiments about it in comparison with Angular.
I liked angular when I was using it, I felt I was able to get more done quicker than I could with Backbone, but both were slower than straight up, good ol' no framework JS.
The thing is, coding without a framework doesn't give you good coding habits, and the structure that lets other people quickly get up to speed with your code, so I figured a framework was a good idea to give me some structure.
When examining frameworks for my current employer, we were about to go with React and Flux, but as it felt much quicker to develop with, but I just wasn't a massive fan of the process flow of Flux.
In the end, we decided to go with Mercury.js https://github.com/Raynos/mercury, we created a few of our own rules around structure which has help us keep things modular and fairly simple. I highly recommend it.
The thing is, coding without a framework doesn't give you good coding habits, and the structure that lets other people quickly get up to speed with your code, so I figured a framework was a good idea to give me some structure.
When examining frameworks for my current employer, we were about to go with React and Flux, but as it felt much quicker to develop with, but I just wasn't a massive fan of the process flow of Flux.
In the end, we decided to go with Mercury.js https://github.com/Raynos/mercury, we created a few of our own rules around structure which has help us keep things modular and fairly simple. I highly recommend it.
I felt the same way after using it. I've switched to React since and I can say it's amazing. Far better than the other solutions IMO.
Debugging Angular was completely useless without tests too. It would be a waste of time to write anything in Angular without them.
Debugging Angular was completely useless without tests too. It would be a waste of time to write anything in Angular without them.
I've felt the same way when doing non-basic stuff with Angular (over a couple of projects). While a directive is usually more general than equivalent vanilla js/procedural code, this doesn't explain the 10x (In my experience it was probably closer to 5x code and time though).
I've been fortunate enough to use Durandal a fair amount since, and have found that it's probably 1.5x and 1.5x for a binding or custom element, which IMO is fair for the benefits that it brings.
I've been fortunate enough to use Durandal a fair amount since, and have found that it's probably 1.5x and 1.5x for a binding or custom element, which IMO is fair for the benefits that it brings.
While I haven't used Angular, I have watched a live demonstration of it and was not impressed. Yes it's very boilerplate heavy and reminds me of some of the clunkier Java frameworks.
I'll keep my suggestion short and simple. Look into ReactJs. If your coworkers are sharp they may be willing to look into it too. It's not just another crappy framework.
I'll keep my suggestion short and simple. Look into ReactJs. If your coworkers are sharp they may be willing to look into it too. It's not just another crappy framework.
If there an alterative for web stack and template engine, I choose Meteor+React, it's no brainer for small to medium scale project. In active development to scale large sized project well in the near future.
However, what I've found is that every single little thing is being blown up by 10x LOC in order to "fit the Angular philosophy"....things I could accomplish in 150-300 lines of plain JS become 1600 lines of Angular code, written before I got here, which I have to spend hours debugging.
I find 90% of my development time is spent figuring out the angular flow of code when the problem should be so simple.
Has anyone had similar experiences?