Even if Angular 2.0 is not backwards compatible, it doesn't mean that once Angular 2.0 comes out that all of Angular 1.x is no longer useable. I'd imagine 1.x will be used for a long time to come. Also, having a good idea of Angular 1.x especially 1.4 will prepare people a lot for 2.0.
Because Angular 1.x has a long term support plan in place that should see maintenance provided to the framework for at least a couple of years after Angular 2 drops. Another major component of that plan is building out a compatibility layer between Angular 1 and Angular 2.
Why are you looking for jobs that specifically require Angular?
You'd be better off in the long run looking for jobs that require Javascript knowledge and are familiar with at least one current framework. Those are the types of companies who will be more likely to upgrade their stack as technology progresses.
I doubt he's specifically looking for Angular jobs or likely any job at all. It's likely he's getting contacted by recruiters or just seeing job ads. The current trend is react but I run across node+angular postings regularly.
Because it was hyped, and was chosen for some project on the hype alone, without anybody bothering to check what is all about and how the future with it will look like.
Angular 2 looks way easier to understand. That is from the perspective of someone just starting out. Although note alot of things changes in Angular 2. So some tutorials may be out of date.
There are more resources about Angular 1.x obviously.
What might be confusing is the whole AtScript/Typescript/Javascript thing.
I never found Angular 1.x difficult, but it's a bit like Rails, people might have the impression that they can learn the framework without learning the language at first place. Ultimately 1.x was limited by ES5 itself. That's what it was a bit confusing sometimes, especially with all the scopes and contexts stuff.
In theory it will be. In practice, not yet because the documentation has a lot of gaps and error messages aren't that good yet. Still, I'm liking it. (I'm trying out the Dart version.)
The website wasn't made by anyone on the React Native team, but it is based on an "official" statement, though the time estimate was simply a best-guess. It'll be out when it's ready.
After working with react, IMO angular 2 is probably going to come to the game too late. If it's anywhere as complex as 1, then I see no point in using it. React takes the cake in simplicity and expressiveness. It's also a truly component oriented system.
Not true, I still get recruiting emails every week asking for angular experience, which means there is probably a huge group of people locked into the angular framework, and since 2.0 will be backwards compatible, I'm sure a decent amount of people will be switching their angular 1.0 apps to 2.0. It will be easier then converting a whole angular stack to React and figuring out all of the other React libraries and frameworks you need to use.
Learning all of the libraries and frameworks for React is quite complex and not less complex then learning Angular 2.0. with its backwards compatible support.
Angular 2.0 is backwards compatible the same way that React is compatible with Angular 1.0... basically it's mainly just the new Router that makes it possible to use other libraries easier with 1.0.
From looking at the Angular 2 alpha, design documents, etc., it looks to end up with considerably less accidental complexity (from an application developer point of view) than version 1, and it has a lot of ideas under the hood which are reminiscent of React.
I think the most visible difference will remain that React is code centric, with templates as a sort of special case of code. Angular (1, 2) is more explicitly divided between code and template.
I believe the main driver in choosing between them will not be technical, but cultural. There are many organizations where considerable value is ascribed to the notion of code versus template, such organizations might lean toward Angular (especially in version 2) over React and friends.
Also if you've got an Angular 1.x app already, moving to 2, while probably just as hard as moving to React or something else, let's you remain soley in the "Angular community" where people in similar positions of straddling both versions can share knowledge.
Honestly, there are plenty of other options out there besides Angular and even React, despite the tremendous hype around it at the moment.
Aurelia seems to be the best ideas from Angular + the best ideas from the creator's previous framework, Durandal, in one framework with much cleaner syntax and much less complexity than both Angular & Angular 2.0.
Ember has made some big updates recently, rewriting their rendering engine to use a virtual DOM.
A lot of people still seem to really like Meteor.
Mercury, Mithril, Ractive, JSBlocks, etc. are all smaller, lesser known projects with a lot of potential.
True, but by default it doesn't use React or Angular and provides Blaze for creating UIs.
It supports React and Angular as of recently, I suspect, simply to maintain itself as a competitor to other stacks, due to the extreme popularity of React and Angular.
Yes, the future will be web components, which would mean Polymer / x-tag until the spec is in all modern browsers. React will die when web components don't need polyfills.
All major web frameworks have settled on a pattern of using components to manage not only private DOM, but also to manage data scoping. The web components standard is a long, long way from doing anything related to data-passing.
For anything larger than a simple widget, I highly doubt you will see a move to use native web components for a long time. There are application architecture issues they have not even begun to tackle.
...and Flux is a philosophy or recommendation, not an implementaton. There are various independent Flux implementations out there, but none that have been battle-tested at the enterprise level AFAIK. Plus, from recent rumblings, Facebook seems to be moving "beyond Flux".
With Reflux or similar, you have everything you need. Simple to build UI, simple to hookup to backend, simple to dynamically update backend and front end based on change or events on data.
When you say it's not a "framework" I don't even understand what you mean by "framework". If you mean a system that locks you into one way of doing things and is hard to integrate with other tools, then by all means, it's not a framework, and then I don't want it anyway.
Angular 1.x to 2 reminds me of the transition that Flash made from ActionScript2 to ActionScript3. AS2 had a bunch of newfangled conventions just like Angular and then AS3 came along and made everything more sensible. Speaking of front end frameworks though. I wonder what happened with Enyo and why that didn't take off.
Enyo was/is an amazing web component framework, but I think the whole HP webOS debacle pretty much scared people away from adopting it, due to uncertainties about it's future ownership and development. I believe it's still in use in the LG webOS TV SDK, at least.
Is anyone ignoring the Angular team's advice and going to prod with Angular 2 already? I've got an Angular 1.3ish app rotting on the vine that needs serious love but I don't want to touch it until I can at the very least make use of the new router (I never used UI router and now regret it) but I can't wait on that forever.
They may warn us that the alpha bits change frequently but if it works on one alpha build there would be nothing forcing the move to the next alpha.
47 comments
[ 3.9 ms ] story [ 101 ms ] threadFor more information on that plan, see here: https://docs.google.com/document/d/1xvBZoFuNq9hsgRhPPZOJC-Z4...
You'd be better off in the long run looking for jobs that require Javascript knowledge and are familiar with at least one current framework. Those are the types of companies who will be more likely to upgrade their stack as technology progresses.
Compare that to the number of job ads looking for "experience with Angular".
I agree that it shouldn't be that way, but the hiring process is badly broken in most places.
http://www.effectiveui.com/blog/2015/04/20/learned-ng-conf-w...
What might be confusing is the whole AtScript/Typescript/Javascript thing.
I never found Angular 1.x difficult, but it's a bit like Rails, people might have the impression that they can learn the framework without learning the language at first place. Ultimately 1.x was limited by ES5 itself. That's what it was a bit confusing sometimes, especially with all the scopes and contexts stuff.
https://www.youtube.com/watch?v=rLuuAlDXHU0
It's fairly recent too: August 3 2015.
Learning all of the libraries and frameworks for React is quite complex and not less complex then learning Angular 2.0. with its backwards compatible support.
I think the most visible difference will remain that React is code centric, with templates as a sort of special case of code. Angular (1, 2) is more explicitly divided between code and template.
I believe the main driver in choosing between them will not be technical, but cultural. There are many organizations where considerable value is ascribed to the notion of code versus template, such organizations might lean toward Angular (especially in version 2) over React and friends.
Aurelia seems to be the best ideas from Angular + the best ideas from the creator's previous framework, Durandal, in one framework with much cleaner syntax and much less complexity than both Angular & Angular 2.0.
Ember has made some big updates recently, rewriting their rendering engine to use a virtual DOM.
A lot of people still seem to really like Meteor.
Mercury, Mithril, Ractive, JSBlocks, etc. are all smaller, lesser known projects with a lot of potential.
Meteor officially supports React and Angular. Meteor is a web and mobile development platform, not a front-end framework.
It supports React and Angular as of recently, I suspect, simply to maintain itself as a competitor to other stacks, due to the extreme popularity of React and Angular.
Yes, the future will be web components, which would mean Polymer / x-tag until the spec is in all modern browsers. React will die when web components don't need polyfills.
For anything larger than a simple widget, I highly doubt you will see a move to use native web components for a long time. There are application architecture issues they have not even begun to tackle.
When you say it's not a "framework" I don't even understand what you mean by "framework". If you mean a system that locks you into one way of doing things and is hard to integrate with other tools, then by all means, it's not a framework, and then I don't want it anyway.
I never said that , don't put words in my mouth. The rest of your comment is irrelevant since you're making stuff up.
They may warn us that the alpha bits change frequently but if it works on one alpha build there would be nothing forcing the move to the next alpha.