Angular 1 and Angular 2 integration: the path to seamless upgrade(angularjs.blogspot.com) |
Angular 1 and Angular 2 integration: the path to seamless upgrade(angularjs.blogspot.com) |
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.
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.
Part of migration talk in keynote: https://youtu.be/QHulaj5ZxbI?t=12m43s
Full playlist: https://youtu.be/QHulaj5ZxbI?list=PLOETEcp3DkCoNnlhE-7fovYvq...
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.
Almost everyone i know is using something in the likes of AngularJS
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.
With this migration plan it seems silly not to keep hacking with AngularJS 1.x
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.
You can try to search using DuckDuckGo as it highlights _official sites_. Really useful feature, even for quick one-time searches.
For example, http://getbootstrap.com/2.3.2/.
Everybody knows what other project i'm talking about.
Remember when we were worried about the semantic purity of our HTML.
Does this mean they are using some sort of virtual dom a la React?
"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."
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.
Took less than a day to understand angular from nothing -- taking more than a day just to evaluate flux implementations with react.
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
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.
No it's not, Angular's implementation of two way data binding is slow; dirty checking is what's slow.
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.
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>
<label>Name <input type="text"></label>
<input type="text" ng-model="model.name">
<input type="text" [(ng-model)]="model.name">
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.
There was only one difference, someone used AngularJS with Typescript :) ==> c#
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").
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.
Seriously though, if anything has changed it's ES6, and that doesn't count as it's all sugar that compiles back to ES5.
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).
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...
<input type="text" bindon-ng-model="model.name">
<input type="text" bind-myprop="model.foo" on-myevent="bar()">
[0]http://victorsavkin.com/post/119943127151/angular-2-template...
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.
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.
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.
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.
I trust the spec more than an implementation.
If true I'm not sure it matters if every browser throws an exception.
[1]:http://www.w3.org/TR/html-markup/syntax.html#syntax-attribut...