Hacker News new | past | comments | ask | show | jobs | submit login

Since Angular 2 was announced, I had the feeling that I picked the wrong framework for our product with Angular 1, and was feeling regrets about that choice towards my team, to have blocked them with a framework without future.

Knowing that we'll be able to slowly move our app to Angular 2, one feature at a time, is certainly the best news I've had in a while.




BTW, why do I always feel like betting in a horse race when choosing a web framework/library? Hoping it'll be maintained long enough, hoping it'll not be deprecated after 6 months for the new cool kid...


I had always a bad feeling about angular.

The first guy I heard talking about it was like "It was made by an underdog at google" and "We often had the feeling about hitting a dead end when developing with it, but it was always because we were using it wrong" which both sounded strange to me.

I used ExtJS, Ember and React. And never switched away from them because it wasn't maintained anymore. It just happened that people preferred to use new frameworks on new projects.


I know what they mean when they say 'it was always because we were using it wrong'. Last place I worked used Angular 1 for their product reboot, and any time I hit a dead end I'd lookup the problem on stackoverflow only to find I wasn't doing things 'the angular way'. Generally this would be because I'd decided to mix in JQuery and alter some of the visual tree myself (something angular is meant to exclusively take care of).

At the end of the day, when you're writing commercial software in a big team you are inevitably going to have to join up technologies whether you or angular likes it or not. Angular 1 decided to make this a PITA, so I can't ultimately recommend it for use. I haven't looked into Angular 2 though.


I have been able to combine basically any framework or library with angular for DOM manipulation and other related tasks. You just need to wrap the libraries with angular, which is fairly trivial to do for your selected subset of functionality.


ExtJS went through some rough upgrade cycles as well. From what I remember, the 2->3 upgrade path covered a small subset of codebases.


Ember OTH has the smoothest upgrade path known to man.


Not that smooth if you saw the comments on HN last week - teams lost months of productivity keeping up with the rewrites in Ember, even with no immediate breaking changes.


Can I have a link to that please?



Angular is my 'plan b' while I continue working with ExtJS.

Last December I coded up just enough of an app in Angular to ensure that my Sencha-focused Flask app would work with another JS framework should the need ever arise. I'd hate to have to go that route of course (even if Sencha changes hands), but it's nice to have options.


This is true of any kind of component, in any language, that you don't maintain yourself. It's the nature of the thing: you don't have to build it yourself, and in exchange, you have less control over it.


We used to live in a world where Moore was the name of a law and our libraries changed every second year. Maybe we're reaching a plateau and we've found the right way to do things. Maybe the set of js libraries we know today is close to the final set, the ideal toolbox of a front-end developer. Maybe the next huge development of IT is the cloud, deep learning and Cortana, and maybe since the desktop/mobile power isn't expected to expand anymore, the will to write yet-another-heavier js framework will vanish. Maybe Angular 2 will be the way to do things in 2015.


It's got nothing to do with Moore and everything to do with the collective fingers being pulled out of bums by the standards committees and finally adding new features to js after 10 odd years of stagnation.

And given javascript is still way behind the other languages at the moment, javascript libraries still have a lot of settling down to do.

For example, one of the big problem with javascript was specifically that there was no way to watch for property changes, so all sorts of crazy strategies were adopted, like getters and setters as methods, or scanning all registered objects for changes. But they all suck and force you to write crappy code. As new ES features are adopted, less of these dirty hacks are needed but they cause major changes in libraries.


+1 for Proxy() :)


Stuff written against angular 1.x should be good for years to come. I'm still using 1.2.x for compatibility with ie8.




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

Search: