Angular 1 and Angular 2 integration: the path to seamless upgrade | Hacker News Reader

Angular 1 and Angular 2 integration: the path to seamless upgrade

angularjs.blogspot.com

202 pointshswolff100 comments

I have been evaluating writing some new applications in Angular at work and was quickly turned away from it because before today the actual migration path seemed very unclear. Without a migration path, picking v1 for a new application at this point would be silly, and 2 is completely unready for production.

Hearing that they are really planning on making it more or less "backwards compatible" is definitely a smart move from the Angular team, and makes me more comfortable potentially suggesting Angular as a framework.

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.

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?

https://news.ycombinator.com/item?id=10054717

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.

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.

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.

Seeing a lot of comments about how Angular had no migration plan. Migration was discussed at length at ng-conf back in March, including a large portion of the keynote(s). They made it very clear a smooth and simple migration was top priority.

Part of migration talk in keynote: https://youtu.be/QHulaj5ZxbI?t=12m43s

Full playlist: https://youtu.be/QHulaj5ZxbI?list=PLOETEcp3DkCoNnlhE-7fovYvq...

Yes, it is a considerable frustration. At the beginning, the Angular team said something along the lines of "we are working on a Angular 2, after we figure out how it should work then we will consider migration and come up with a plan". For some reason this was widely interpreted as "there will be no migration plan".

I agree that there were a lot of misunderstanding going around but it has caused some problems. For new projects you have to choose a platform/framework. If you choose Angular 1 you might have to learn it and release a version of your app with it before Angular 2 is released or just before the migration path is clear. And it is till hard to estimate the migration cost/time. Or you could start with Angular 2 which you knew was not ready. It was and is also unclear exactly when Angular 2 will be "ready" making it a less interesting choice if you have/had a hard date when your app should be released.

Fair point, but worth noting that compared to the migration plan discussed at ng-conf in March, this is now an improved plan. For example, from the post just published:

Wasn't the original upgrade plan to use the new Component Router?

The upgrade plan that we announced at ng-conf 2015 was based on upgrading a whole view at a time and having the Component Router handle communication between the two versions of Angular.

The feedback we received was that while yes, this was incremental, it wasn't incremental enough. We went back and redesigned for the plan as described above.

I know that hating angular is popular these days, but i'm still using it, and it serves me well. Looking forward to Angular 2!

Yeah, it seemed that way because there was no migration path... That is fixed though ;)

Almost everyone i know is using something in the likes of AngularJS

> Almost everyone i know is using something in the likes of AngularJS I do wonder what you mean with that. I think that both React and Ember are different but if you mean a javascript framework for building single page applications you're probably right.

Everyone who is following a bit of technology and/or searching for extra developers ( Brussels/Belgium) are all using AngularJS. Haven't found any mention of EmberJS or React or anything ( doesn't mean they don't know it)

There was only one difference, someone used AngularJS with Typescript :) ==> c#

Agreed. Once you are fully up to speed with it (and not at one of the local optima as brilliantly shown on the famous Angular learning curve diagram), it's a pleasure to work with.

This looks nice. I like the idea of more-or-less seamless integration between a1 and a2 on the same page, to allow for incrementally experimenting with a2 features without having to port the entire application over.

With angular 2 moving to a virtualdom implementation we can get serverside rendering and some real speed improvements (if you move your virtualdom stuff to a web worker for example). This is rad.

Every time I use Angular it feels like it's doing things the right way and it's becoming the Rails or Django of the JavaScript world. Wish I had fought to use AngularJs directives and $resource instead of messing about with ReactJS and jQuery ajax calls.

With this migration plan it seems silly not to keep hacking with AngularJS 1.x

Yep, even though directive implementation is verbose in 1.x, once you get really comfortable building them it's a pleasure to use them.

I also share this sentiment. I also added a directive class that helps dramatically with code organization/comprehension. For example, listeners should be implemented here, view-model things should be setup here, etc...

If you're using React you could look into different flux frameworks or even Relay+GraphQL to avoid jQuery ajax (or at least hide it). That last thing is the bleeding edge right now but looks promising. Flux is probably here to stay and you have a ton of libraries to choose from. I started with Reflux but is now using Alt.

GraphQL requires backend infrastructure to use, which takes time usually to plug into the planning pipeline.

I see 2-way data-binding is mentioned here and will still be supported (good). Curious why has 2-way now become 'uncool' recently, e.g. React? 2-way is what got me excited about client side JS due to the code reduction in an average app. Is just that Angular 1's implementation was non-performant? (lots of other frameworks use it as well, e.g. Knockout, RactiveJS, etc).

Two way data binding is awesome and neat and shiny and chrome. It's also pretty slow; a lot of pragmatic angular work involves keeping the number of watchers firing during digest cycles minimized. If you have a lot of data that's all two-way-bound by default, but aren't making any use of the bindings, that's a lot of wasted cycles. I mean, my app has a lot of data in it, stuff like {{username}} which rarely ever changes in the model, so I don't really need two-way binding for it.

What I like here is that one-way binding is the default, and you can do two-way stuff if needs be, because sometimes it really is the best call.

Thanks. Yeah 1-way as default is reasonable. I suppose in my case I haven't seen performance issues due to data size, and also have taken to using RactiveJS which allows both 1-way and 2-way via [[someProp]] and {{someProp}}, respectively.

I think two-way binding going by the way side because developers are tired of having to deal with unintended loop backs. You start having to add weird flags to your data to indicate that data changes were the result of user actions and not changes from the backend to avoid endless event loops. Two-way binding results in more code that's buggier whereas one-way binding with actions results in much more organized and understandable code with none of the unintended consequences.

I'm thinking that's a framework-specific or coding-style issue? From using a number of frameworks, I've virtually never had issues with endless loops. Perhaps it helps that frameworks like Knockout, etc don't trigger change events when the value is the same.

> Two way data binding is awesome and neat and shiny and chrome. It's also pretty slow;

No it's not, Angular's implementation of two way data binding is slow; dirty checking is what's slow.

{{username}} is a one-way-binding. Two-way-binding happens only with ng-model and = on isolate scopes.

This seems to be the new standard in JS framework development. Ember, Angular and React have all switched to making "data down, actions up" be their M.O., while still supporting 2-way data binding if you want or need it.

Two way bindings are awesome for demos.

They tend to introduce a fair amount of unnecessary complexity in real world applications. Especially if you have to deal with changes that don't happen in real time or intermediate states or two different formats of presentation for the same data.

The workaround for two way bindings in React is relatively easy compared to the kind of hoops you have to jump through when you start with two way bindings and have to backtrack because of pesky real world requirements.

Why isn't there a single domain for the angular project?

From what I can see there seems to be 2 main ones: angular.io (for angular 2) and angularjs.org (for angular 1.x) as well as angulardart.org and other sites for angular material design (material.angularjs.org) and angular firebase (firebase.com/docs/web/libraries/angular/). Why not have a single site (or at least a main domain with corresponding subdomains) with similar documentation and navigation?

In addition, searching for "angular" in Google provides no obvious distinction between the different sites. For a Google sponsored project, I would have expected better attention to the search meta-data to make the distinction clear.

Part of the reason is so that they can track usage trends to see how long they should continue supporting Angular 1 after Angular 2 is released.

That could be solved by analytics on one domain.

For example, http://getbootstrap.com/2.3.2/.

> In addition, searching for "angular" in Google provides no obvious distinction between the different sites.

You can try to search using DuckDuckGo as it highlights _official sites_. Really useful feature, even for quick one-time searches.

https://duckduckgo.com

Aren't they both official sites though, just of their respective versions? (although admittedly, Angular 2 is still in the Developer Preview stage)

See , that's how you manage an open source project , you listen to your community , and yes people can have relevant suggestions. Angular JS became successful because of its pragmatism but also because it allowed more than 1000 people to contribute to its core, not because it was a "Google project" .

Everybody knows what other project i'm talking about.

What other project are you talking about?

If they mean closed source, that list could include Google +, Google Reader, Google Wave, etc

GWT ?

Dart?

I think Polymer is in Google's strategic plan and will be in much more limelight even going forward.

Polymer is a pain to use by comparison to practically everything. My understanding is it's meant as basically just a comparability layer.

Yes.

I thought everybody remembered that Polymer was originally intended to be an experiment. It was never meant to amount to much more than a bunch of glorified polyfills (and "prollyfills").

Remember when we were worried about the semantic purity of our HTML.

Remember separation of concerns ? Fuck that, let's just mash code and markup together.

What concerns do you think you're separating exactly, when you're dealing with presentation-tier markup and code that combine intimately to a single component?

I think a lot of the people worrying about this separation of concerns, and feel it's such an obvious problem that they don't even need to expand on it at all, are probably people who had to deal with hideous PHP (in the unenlightened days before Laravel, let's say) where views, business logic, and everything else get snarled up together in a horrible mess between some opening and closing PHP tags.

I had similar worries when I first saw JSX. Having used it quite extensively, though, it does feel like it's a sensible idea now, from a development perspective at least. That said, it does increasingly feel like the days where certain people could just write HTML and CSS, and other people could handle the trickier JavaScript, are long gone (especially with things like Radium for React).

Business logic should still remain separate. This would be display logic.

The fun part is that Angular (1, anyway) has pretend-separation. Sure, there's truth in DOM, but not really. Littering your custom directives all over the place may feel like progressive enhancement but if you're using an app framework like Angular your JS is likely already complex enough that you can't meaningfully consider it a mere "enhancement" -- we're talking core functionality, not fairy dust.

People react (heh) strongly to React's JSX when they first come across it but at the end of the day I find React far more honest in its approach. Your Angular templates don't really gain anything from looking like they're just HTML templates -- instead you end up either serializing your data into some kind of string format or faffing about with magical nested "scope" objects (as if JS scoping wasn't enough to keep in your head).

But in order to maintain that illusion you also have to buy into these huge layers of added complexity when writing your own directives. I'd rather go all the way back to steamrolling the DOM with Backbone templates than these pretend-semantical lumps of custom elements and attributes.

Sorry for ranting. I'm still sore about being burned by Angular.

How exactly were you "burned by Angular"? Many of us here are using it very successfully. And no, you don't need to "serialize your data into some kind of string format" (at least in the sense that you would never flatten JS objects into serialized strings in order to work with them). Scopes definitely take some getting used to, but they are not magical.

I don't know that "semantic" is what you mean here.

Semantics in HTML is about exposing the meaning of content through the DOM. Adding data-binding via attributes doesn't change that at all.

    <label>Name <input type="text" [(ng-model)]="model.name"></label>

still encodes just as much semantics as

    <label>Name <input type="text"></label>

I think what you might have meant, as mariusmg mentioned in a sibling comment, is "separation of concerns"? Personally I think that has diminishing returns as your application gets more complex. It's very difficult not to still have tight coupling, just hidden under a layer of indirection.

I think it's more like "syntactic" then semantic.

      <input type="text" ng-model="model.name">

Is syntatically valid HTML, although ng-model may not be a legal attribute name in standard HTML. On the other hand:

      <input type="text" [(ng-model)]="model.name">

Isn't even syntactically valid HTML. It kind of rubs me the wrong way too, although I don't know if it matters in practice, although I'm not sure it doesn't either. It does seem ugly.

I'm not sure you are correct. According to the w3 spec for HTML attributes [0], html element attribute names must consist of one or more characters other than the space characters, U+0000 NULL, """, "'", ">", "/", "=", the control characters, and any characters that are not defined by Unicode.

Granted, it isn't necessarily what I'd expect to be legal, but it doesn't look illegal either. We may just need to add some logic to HTML colorizing syntax checkers in our IDEs is all.

[0]: http://www.w3.org/TR/html-markup/syntax.html#syntax-attribut...

interesting!

To emphasize what you are saying, on multiple occasions the Angular team has said that they chose this new syntax because it is valid.

It's illegal. Go to your console and type el.setAttribute("(foo)", "bar") and see what happens.

No it is not. See the discussion here: https://github.com/angular/angular/issues/133

What there contradicts what I said? I'm aware of innerHTML hacks that make it possible to work around but those are not valid attribute names. I'm not even against the syntax; i like it, but that doesn't change the fact that it is invalid html.

Parent quotes the W3 Spec to prove that it's legal, and your response is "it's illegal because $BROWSER say's so"?

I trust the spec more than an implementation.

The parent didn't quote the spec, they quoted a GitHub issue with 71 participants. If you want to post a link to the spec text please do.

If true I'm not sure it matters if every browser throws an exception.

User pfooti's comment referenced the specification[1]. You said that a browsers' implementation of the DOM API proves that it is illegal. I then linked to an issue with a detailed discussion of how the DOM API isn't consistent with itself, much less the HTML specification.

[1]:http://www.w3.org/TR/html-markup/syntax.html#syntax-attribut...

Others have pointed out that it is in fact syntactically valid HTML. It's also worth mentioning that this is syntactic sugar, and you can get the same behavior with:

  <input type="text" bindon-ng-model="model.name">

Similarly, property bindings surrounded by brackets "[myprop]" and event bindings surrounded by parens "(myevent)" are equivalent to the following:

  <input type="text" bind-myprop="model.foo" on-myevent="bar()">

All of angular2's template syntax can be replaced by more normal-looking tag properties with "reserved" prefixes that tell Angular what to do with them.[0] The less verbose symbols are probably easier for the eye to parse than the long forms once you're used to them, and either form can be easily analyzed and highlighted by an IDE.

[0]http://victorsavkin.com/post/119943127151/angular-2-template...

> We've decoupled Angular 2's rendering from the DOM.

Does this mean they are using some sort of virtual dom a la React?

if I'm reading this correctly, they also planning to release a react native competitor?

"Native mobile UI. We're enthusiastic about supporting the Web Platform in mobile apps. At the same time, some teams want to deliver fully native UIs on their iOS and Android mobile apps."

That is very possible. I found that statement a bit odd since they appear to work fairly closely with http://ionicframework.com/

Actually they will integrate with react native and native script. They talked about it (and demo it) in the angularu conference: https://www.youtube.com/watch?v=aHGmj_fqPLE&feature=youtu.be...

One of the biggest benefit of Angular is the vast amount of libraries built on it, like bootstrap-ui and ui-grid to name a few, how can we switch to Angular 2 until the most adopted ones don't switch too? (real question)

Notionally, the Angular1<->2 compatibility layer could handle mixing and matching, but I'm not sure how well it'd work in practice

Depends on how brave you are, really.

While a lot of the development community will likely be tracking 2.0's development and working to release libraries not long after 2.0 releases...2.0 is effectively a 1.0 release all over again, so it's a matter of production-readiness not only where community support is concerned, but with itself.

I'm waiting to see where things shake out on all sides after a few releases before really judging anything. We'll still kick the tires on our team here in the meantime.

Or the biggest failure. I guess that's how we get 5MB pages which could be done without any JS at all.

Commets here made me think about whether it's forward-looking using angular 1.0 for next projects: i guess i'll go with React with my short-coming project then... I don't know what to do

In my limited experience React is way easier to comprehend than Angular.

I've had the opposite experience, with a code base responsible for millions in revenue each month.

Took less than a day to understand angular from nothing -- taking more than a day just to evaluate flux implementations with react.

Anyone knows how Angular 2 plays with "outside" code? It is very frustrating, having to convert everything to a directive when using with Angular 1.

For the curious, this is the official repository for the ng2-to-ng1 engine: https://github.com/ngUpgraders/ng-forward

ng-forward contributor here: that is not the ng2-to-ng1 engine. ng-forward is an Angular team sanctioned library for eventually enabling Angular 2 syntax in Angular 1. It shares a lot of goals with what is outlined in today's announcement but is more catered for teams that want to start an app today with the quickest possible migration strategy.

The code for the ng2-to-ng1 engine (called ng-upgrade) is either not public yet or will be at https://github.com/angular/angular

Ahh, I was mistaken with what I saw in the gitter then - thanks for correcting me!

This is really great news for my company, as we have several Angular 1 applications still in development that can benefit from this incremental upgrade pattern.

Finally! There has been talk for what seems months for an upgrade path. I'm so happy that there is finally some clarification.

The dramatic shift from version 1 to 2 is generally a sign of design mistakes. Angular 1 should have been angular beta.

Browsers and JavaScript have changed quite a bit since 2009. You couldn't have created something like Angular 2 6 years ago or even 2 years ago for that matter. Angular 2 is possible today thanks to technological advancements.

For example?

for example like quantum chips, neural nets and big data are all now buzz words that changed the technology of javascript forever.

Seriously though, if anything has changed it's ES6, and that doesn't count as it's all sugar that compiles back to ES5.

For one, it's written in TypeScript. There is one codebase for ES5/6, TypeScript, and Dart. A big benefit of Angular 2 is the better tooling you get with TypeScript and Dart.

It uses things like classes, decorators, and the <template> tag. It uses a virtual DOM, which is still a fairly new concept. It can run in Web Workers and you can even use it for native applications which do not have a regular DOM.

It really is quite different from anything one could have started back in 2009. Even those odd-looking attribute might have not worked because HTML5, which specified a lot of those things more precisely, was far from being done.

Angular 1.x made pretty good use of the things which were available at the time.

Slightly off topic, sorry, but I do HATE how blogger.com sites are totally unusable with JS turned off / noscript / etc ...

Welcome to the 0.01%

Aurelia is looking nice right now.

Care to elaborate?

Reply on news.ycombinator.com