Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
“Screw You, Angular” (medium.com/jeffwhelpley)
26 points by bceagle on Nov 3, 2014 | hide | past | favorite | 5 comments


> You would think at this point that no one in their right mind would use Angular, but in reality it has been the most popular front end framework over the past year.

In other words, "If Angular is so bad then why do so many people use it, huh?!" See Visual Basic, PHP, the list goes on.


The author covers that in the section following "A cynic may make the following excuses for developers that love Angular."


Angular 2.0 strikes me as a Maven 2.x moment. Maven 1.x was a brilliant idea that pragmatically addressed real, practical problems with building Java codebases. Some pragmatic decisions turned to be real ugly (Jelly), but you really could get a fair amount of stuff done and have a consistent build process. Then Maven 2.x came out and made everything way more complicated, way more rigid in a way that clashed with real development needs. Weird decisions in Maven 2/3, such as throwing away its dependency on Ant and rewriting all that functionality in a new library (years later, still missing features, e.g. ability to include/exclude files while creating certain types of archives). Such as nearly erasing the differential between internal and external projects, as a result taking away the ability to version all your internal artifacts with one variable. There was also heavy migration pain and overhead, as little of the previous custom code was compatible. And pretty much for all of Maven 2.x/3.x, having used Maven 1.x in serious anger, I was left wondering "why oh why did you do this, and why did you change this?" And many of the public motivations for changes were "academically" right, yet practically disastrous in large projects.

So, here we are, starting with Angular 1.x, which seemed to be fairly pragmatically designed to solve certain pains and has received (IMO well-deserved) uptake in the ecosystem. Now, we are looking at Angular 2.x, where many of the decisions seem "academically" right, yet feel to me (and many of us) as practically disastrous.

This article is essentially saying: 'some kind of a migration path will definitely be worked on once we have a destination Angular 2.0, so stop freaking out.' Also this statement: ". If you are working on Angular 1.x today and you like it, you should want 2.0 to exist and you should be an active participant in making it happen."

Listen, we've been around the block and we've seen projects go through changes like these. And we've seen enough projects fail after changes like these, and we've seen enough 1.x branches wither in abandonment. And we've spent years now advocating for more incremental development approaches that validate decisions little by little. And so when Angular, as a project, decides to make huge changes, Angular tech leadership should understand this modern climate, and should make sure that the messaging touches on migration right away.

Look, I'd love to be pleasantly surprised, but I sure am skeptical that this will be a successful transition. It just doesn't sound like the Angular 2.0 project plans are grounded in reality of shipping production code and solving production problems. And I really think that's the root cause red flag that has everyone up in arms.


Hi, the author here.

I hear what you are saying, but I think the big difference between Angular 2.0 and (for example) something like Python 3 is that the goals and direction of Angular 2.0 are directly aligned with the future of the web whereas Python 3 changes were changes just for the sake of changes.

In other words, the world of the web is going to change drastically over the next two years regardless of what Angular does.

Now, I do think there are other approaches. Take Ember for example. They plan on building on top of all the new features coming out, but they are taking a more measured, iterative approach. The thing is that just because it seems like a good idea for Ember does not mean it is a good idea for Angular.

Look at it this way. If nothing else, it is really awesome to have two big front end frameworks taking two drastically different approaches to achieve a similar goal. There are merits to the Angular approach, but it all comes down to execution.

As much as I am rooting for Angular 2.0, it very well could be a train wreck. But, that is why I am planning on being an active participant during the entire process and I will do my best to make sure that doesn't happen.


While, yes, it is awesome to watch two big frontend frameworks take two different approaches, as a production user of Angular 1.x, I am nervous that "my" framework has taken the less iterative approach.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: