Angular 2 Final Released
angular.io
angular.io
Breaking changes during alpha stage were expected, so I didn't have issues with it.
Most positive things I want to highlight:
1. Components are encapsulated and truly reusable (and without dependencies hell).
2. You don't need any "bridges" anymore to use 3-rd party JS libraries inside your Angular app. Nothing need to be "angularized" - twbs, D3, all just works out of the box. Maybe it's even most important part for me.
3. Idea of `(events)` and `[attributes]` is awesome, works really effective and makes code much more easy to read.
4. Performance is great.
5. Community is friendly and have a lot of fun and patience, even to newbies.
6. TypeScript gives a lot of bonuses with zero price - you don't need to learn anything (you can just rename js to ts and it will work) and additions to JS are simple and powerful.
7. Cool abilities like AOT-compilation, server-side rendering and tree-shaking.
Congrats to the all devs who are using Angular, congrats to the Angular team! :)
1. Typescript. If your team isn't familiar with it it's not trivial to get everyone on board. The up-front cost can absolutely be worth it in the long run, but there's some friction in the day-to-day work with managing type definition files and looking up esoteric lint-errors from the Typescript compiler.
2. RXJS. Canonical NG2 should use Observables, and rxjs is not a trivial library to learn the ins and outs of. Add to that that there's no clean way of doing testing with Observables at the moment (integrating with the rxjs testing schedulers is very finicky). This is doubly true if you're using ngrx (which you probably should).
3. Template language. I'm one of those who don't think it's a very good idea to bring a new DSL into html. I'd much rather do it the React-way of bringing HTML into JS instead of relying on a very complex compiler to do magic behind the scenes. This becomes a bit better with the template pre-compilation, but it's still new syntax that you need to learn and keep in mind. Some of which is not intuitive nor well documented (i.e. how pipes and parentheses work together).
4. It feels unfinished. This is to be expected since it's just on it's initial release, but the sharp edges do show up quite a lot. For example we very often have to do manual subscription and unsubscription of Observables in Components. This feeling also goes for quite a few of the community addons, such as the browser-extension. While I absolutely applaud their efforts, it's far from reaching the quality of e.g. the Ember-Inspector.
5. Sub-par debugging experience. When you get any errors there's a mile long stack trace filled with rxjs and zone.js garble, making it very hard to actually figure out what's going on. When there actually are custom error-messages they are not very informative, with you having to fundamentally grok how parts of NG2 works to even come close to understanding why it's not working (getting this a lot with the change detection).
6. Lack of documentation. I tried to stay very far away from Angular 1 since I found its documentation to be very low quality (probably a symptom of Angular 1 being poorly engineered as well). The NG2 docs are definitely better, but I feel like my mental model for reasoning about how things work was still very weak when I had finished going through the docs. There's some really huge gaps in there (testing) and a lot of the really complicated stuff that you will stumble over is only really documented in semi-old blog posts.
And they said your angular 1 experience wouldn't carry over.
I've worked with AngularJS and React. After spending enough time with each framework that I'm "productive" with them and don't get constantly confused by what's going on, this is now by far the most important reason to me when adopting a framework. React(and Redux) just spoil you with an awesome debugging experience, and it's just painful for me to go back to any set of tools that takes some of that away. The rest of the points I've already "suffered" through with AngularJS, and it is my opinion that they are a rough, but surmountable cost. Having a poor debugging experience, however, just kills my willingness to work.
(For the record, AngularJS has some debugging aides - you can inspect scopes pretty easily given a DOM element. However, the watches and digest cycles, which do all the heavy-lifting, are pretty much opaque - you need to have a good understanding of how your watch expressions are compiled into watch functions and place conditional breakpoints deep within the framework in order to inspect why a certain watch is not being called/being called too many times)
I haven't found either of these to be the case. Is your experience recent? If so, will you expand on it? I like Angular 1(.5) quite a bit, but I'd be interested to hear more about a different perspective.
Thought that's a lot better than hunting down bugs in production.
I love experimenting with ng-1: make a static HTML mockup; add a stub controller with a sample model and modify the HTML to insert the data and edit things as needed; add some event handlers with dummy actions. (add your REST calls later...)
All of the above can be done w/out any server or compile process - just keep reloading the page when you make changes (perhaps using something like python's SimpleHTTPServer module to serve files from your development directories). Once you get things about how you like them, start on the server side. This approach won't work for a page with a complicated workflow, but you can still prototype quite a bit for an initial learning experience.
Something funky going wrong when jQuery's involved? Good luck stepping through that.
2) amount of boilerplate code for unit-tests (not e2e - everything is fine there);
3) some things were removed by performance reasons - I think would be smarter just rename them with prefix "slow". Sometimes it's more important to have some functionality than don't have it, even if your app is blazing fast.
This is encouraging. I always thought that looked aweful so it's nice to hear that it actually makes sense.
- input:
```
<foo [x]="y"></foo>
```
```
<foo (x)="y = $event"></foo>
```
Is this accurate? What is a good use case for Angular?
Of course, now you have A LOT of event handling in a client app on top of your middleware / micro-services, but I feel it is a helpful separation of concerns.
I suppose in my case it helps that I would rather do more of the app in Javascript, and less in Java. YMMV, substantially - I'm pretty sure I have a minority view at work :-)
We are working on a rewrite of a largish app (for a small team, anyway) at work. We already have a second, alternate, client app for our back end for a pilot project that we can now easily tackle with the new architecture. There were very few changes required on the server, just an alternate login method to automate an initial connection to a third party app (which then runs our alternate U/I in a frame), rather than an interactive SSO form.
We have a "Few Pages App", rather than Single Page App. By design, we reload a small number of alternate pages after a longish task, just in case (e.g. - resource leaks, whether from our own mishandling, or some library) - not because of known issues, mind you, but just out of my own paranoia that I would rather plan to allow for minor errors rather than requiring perfection.
You need to think hard about whether you really need a SPA for something complex, or whether you can go back to the server completely in some instances.
In Angular 1 the only way to use them without resorting into angular-XYZ libraries is to put them in a directive and use the link function to write all the logic and DOM manipulation. What's different in Angular 2?
>In Angular 1 the only way to use them without resorting into angular-XYZ libraries is to put them in a directive and use the link function to write all the logic and DOM manipulation. What's different in Angular 2?
Well, there is no $scope in Angular 2, so there is no need for link function ( which was used for linking scope and DOM)
this._settingsService.settings$.mergeMap(settings => {
this.settings = settings;
return this._weatherService.getLatestWeather(this._location, settings);
})
.subscribe(
weather => this.weather = weather,
error => this.errorMessage = <any>error
);Not very promising...
React on the other hand, I stumbled upon looking at the source of the Wall Street Journal the other day. It is everywhere now.
Granted, not open source, but definitely drives home the point that it is trusted in production environments.
People who only take it up at the beta stage are obviously inferior, and hence denigrated as "beta men". And then there's the detestable wimps who go only for 'stable' versions, I suppose they must be "omega men", not even worthy of a mention in discussions.
Glad to know Real Programmers[1] still exist amongst us.
If nothing else, Angular just stranded all their developers, while React has a huge head start on mindshare/plugins/tutorials/etc.
I also really like Typescript and believe enforcing it is a good way to get general JS code quality up.
There's even a pull request to bring typescript into the mix. https://github.com/facebookincubator/create-react-app/pull/5...
create-react-app set up all the build tooling, for a router the clear recommendation is react router, and for a flux implementation the clear recommendation is Redux. It feels like there's a well defined path for beginners. Over time you'll have to figure out how everything works, as is always the case, but you can learn more as and when it's necessary.
The bumps were more whether to use ES5 or ES6 (but then I found an official position in favour of ES6), and whether or not you need to use flux (although that was really just learning how flux worked, which wasn't wasted time).
The only uncertainty I have now is whether TypeScript will be necessary/useful in future, and if so how to integrate it.
It was made for demos, proof of concepts, and beginners (at the beginning, maybe not anymore). I don't know how Angular CLI works, but if it works like Ember's, then there's no comparison. Ember CLI generates models, controllers, etc. any kind of thing and it enforces a file and directory structure that makes all Ember apps look the same.
I know a lot of work has been put in to angular-cli and it's been through a few iterations at this point, but I almost wish they would scrap the whole thing and fork create-react-app.
But how did you get rid of the implicit anys when using JSX?
I used this compiler flag that forbids them and suddnendly nothing worked anymore. It seemed that almost everything returned any per default.
I work daily on a large Angular app and a growing React app, and my React app, while being more pleasant to work with, is also much harder to keep standardised and clean. I'm also already experiencing perf issues because of not using immutableJS, which is quite annoying...
Both are similar in that they are component-oriented.
There are two important factors in my mind.
1. The ecosystem (as you mentioned). React has a clear head start here, but I expect Angular2 to make some gains over time.
2. Angular2 gives you a full framework, and as they say now, a whole platform. React is smaller and you rely on a bunch of other packages to get all the extra features you need. If you want a full solution, Angular2 gives you that.
This can be argued as a good thing or a bad thing. More flexibility with React, but also more things you need to figure out and make a decision about. With Angular2, once you buy in, you don't need to make all of those decisions.
In my particular circumstance, which is to migrate an Angular1 app to a newer framework over time (mainly for the server side rendering features), Angular2 provides a clearer path and offers some nifty features like component styles that allow a similar migration with CSS.
So did Angular 1, and then they threw it under a bus. Now developers have to either refactor for a whole new framework or get stuck with a legacy one.
Javascript ecosystem is becoming so hostile a project deprecates itself in favor of a clean rewrite and the migration path is an afterthought.
Will think twice before adopting google frameworks and tools.
Javascript ecosystem is in dire need of stability and trust.
They didn't just do this "because." There were sound technical reasons to do so. Angular made the correct decision, in my opinion, and decided to cut its losses immediately and right the wrongs within the framework.
But to contrast all three, I'll pick the area I'm most interested in - templating. The purpose of a framework is to render a dynamic view without the programmer having to wire up every state transition with a corresponding view transition. This is done by templating content with state, mediated by the framework. And how this is done affects the entire design of the framework and apps written on them.
Angular and Ember allows state and logic inside HTML. They figure out which state variables and corresponding templates go together and re-renders them automatically. The pro is that writing a modified version of HTML without too much code lets us have a dynamic app running in no time. The con is that there is a new language to study - with its own parser, control structures, scoping, and quirks.
React on the other hand lets us specify templates as Javascript functions which are run whenever the state changes. The pro is that there is no new language abstraction to learn; it re-uses Javascript. External DSLs especially are in an uncanny valley - they're not full-blown languages but have enough quirks to be bothersome. Language abstractions forces a virtual machine (the language parser/interpreter) to evaluate the code, and it is an opaquely magical layer that makes it hard to see the entire stack of abstractions during day-to-day programming. It also forces a separation between our view (written in the templating language) with the rest of our code.
The con of this approach is simply more code to write; the programmer has to anticipate and inform the framework of any state changes. With setState this isn't as bad a trade-off as we'd imagine. And MobX meanwhile brings an Angular like state abstraction to React - it watches over observables and automatically fires re-render.
The other big difference is that React is not opinionated. It is a very much a framework alright, but it for example doesn't ship with a router, nor does it prescribe a framework for organizing the code. Ember has so far done a great job here - I often wish I could combine the Ember ethos of backwards compatibility, great documentation, and a fanatic love for the existing users of the framework, with the way React approaches templating and composing components. I haven't had the chance to look at Angular 2, but for me, Angular 1 started the front-end revolution happen, and I'm curious what they have done this time.
Cx adds declarative data-binding, controllers and router on top of React and includes composable widgets and charts. It looks for a sweet spot between development speed and freedom to do whatever you want. Here's a quick example https://cx.codaxy.com/fiddle/?f=42vDn4I1.
Disclaimer: I'm the author of Cx.
What I need time to get around to is the concept of controllers and how it works when we want to compose things together. For example, how to write a multi-select widget that exposes a clear API to the rest of the world (onChange), and encapsulates all other details within. Cx does deserve a deeper look, and I'll definitely give it a whirl some time. Also kudos for the extensive documentation you've so far written!
> Angular and Ember allows state and logic inside HTML.
State updates do not occur in Ember templates. Templates specify the follow data from one component to another, as well as callbacks which are names of actions defined in a javascript portion of a component, or a parent component.
But it does not allow you to specify how state is updated within the template. In terms of Logic, there's just if statements & loops which is pretty conservative imo.
edit: rephrasing words
But by logic I meant all sorts of control structures, which though looks light-weight at first, needs a large number of language elements to function. To name a few: variables, expressions (which in turn need operator precedence rules), scoping, and even composition if we count partials/templates with it. Loops on the other hand requires not just simple array iteration syntax, but also over hashes, and it also needs other constructs like filtering (`todo in todos | filter:search`).
This is my biggest complaint with adding logic to text templates; behind the apparent simplicity there is always an entire language.
React expects you to do your development on some flavor of Unix, and really doesn't have a sane plan for Windows, so you lose VS.NET and its huge productivity gains. And it needs tools upon tools upon tools to set up, whateverify, transpile and pack the files you write into something that can display in a browser. Again, this all seems to want to run from a Unix command line.
I want to edit some HTML and Javascript, then reload the browser and see my changes. Angular isn't perfect, but at least it lets me do my thing without adding a bunch of extra hoops.
I think this was true six months ago but now there is create-react-app. You might want to try it out - you won't need to whateverify your code, you just need that one tool. Also it works on Windows.
https://github.com/facebookincubator/create-react-app
I want to edit some HTML and Javascript, then reload the browser and see my changes.
With create-react-app the browser will know you've made a change, and reload for you ;-)
The fun thing watching the new world of Javascript is that overtooling is so built in to everything that nobody even realizes how many tools they're using. You can't even install this thing until you have the standard pile of javascript tooling in place. And it never occurred to them to even mention how to get said pile set up.
Once set up, this still uses all the same stuff. It just removes a few steps to produce the Big Red Button you press to run it all.
Isn't that hot reloading of components which they say is unsupported?
Our projects compile from Typescript to ES6 and then ES6 to ES5 through babel. All of that takes place in webpack, and it was pretty easy to setup. We also all use Visual Studio Code and it's a joy to work with.
If you use something like hjs-webpack it gives you (hot-)reloading for code changes out of the box.
I despair these days at the ridiculous number of command line tools you need to run, but once you've completely wasted 2 or 3 days of your life on these pointless things, cut and pasting command lines from setup instructions that give no indication what any of the flags actually mean, you can forget about them.
There were days when you just had to run an installer and then you were good to go. Or just get the latest version of the tools (and by tools I mean actual tools with a GUI and everything, gasp!) That's obviously really untrendy now.
But yeah, you can set it all up in VS to deal with the insanity for you. Good thing too, as the ASP.Net team have been drinking heavily from the command line insanity kool-aid.
I've done both React projects with Python and C# apis. React is perfectly usable in VS.NET - are you aware of the Task Runner Explorer - https://blogs.msdn.microsoft.com/webdev/2016/01/06/task-runn... - hooks whatever you want into the build cycle, watches etc - once I discovered that, everything just clicked into place.
Yes, the majority of code is still written by Evan, due to speed required. but we know that vue is heading in right direction.
React would mean to rewrite your whole application as it has a totally different basic concept. Following the ng2 migration path you're able to migrate slowly.
With that, we could put a React component anywhere in our Angular app, and reuse Angular directives inside of React until we got around to rewriting them.
That ended up quite smooth.
I don't see what is a problem to just drop in React into `<script>` tag and use for single part of the page, gradually refactoring stuff.
1. as others mentioned its a fuller framework, mostly akin to using react with redux (or flux etc...) and a di framework. This also means that angular 2 third party components are probably easier to integrate.
2. Reactive Expressions, which angular2 uses in many places, is a joy to work with (though they might become maintenance hell later on I think). You can use RxJs with React of course, but it's easier when your framework is based on it
3. It uses string templates - which means that some things such as dynamic templates and per user customization of html would probably be much easier to do then in React.
4. It has Ionic - which is much much faster to develop for mobile with then react-native (though obviously there are important differences). It's unlikely that an Ionic like framework for react will gain traction with react-native to compete with.
The key with React is that you manipulate JS instead of HTML. In my experience, using JS to manipulate elements turns out to be easier and a much better experience than the conventional way of using templates.
Only downside is trying to hire Scala frontend devs.
The HTML template in Angular 2 is stored in a string. This has several disadvantages:
1. Editors can't do syntax coloring.
2. Editors can't do auto-indenting.
3. Editors can't offer "intellisense" suggestions.
4. Editors can't match tags.
You embed variables in this template string like this: '<div>{{hero.name}}</div>'.
This means:
1. Compilers can't find typos or find syntax errors at compile time.
2. If you make a typo in the variable name you don't get a compile-time or run-time error, instead the value is simply not displayed!
3. Tools can't refactor (i.e., rename) variables embedded inside the template.
4. No intellisense for the embedded expressions.
You have to learn weird syntax such as ngFor whereas in React you just use a JavaScript for loop.
In React you embed HTML inside the TypeScript and VisualStudio treats both the HTML and the TypeScript as first-class citizens. You get compile-time checks and intellisense for both the HTML and the TypeScript code! You can even put breakpoint inside the template and step through loops whereas in Angular you can't step through an ngFor.
Note that some of the above may have changed since I last looked at Angular 2.
This is patently false. Just use "templateUrl" instead of "template". This allows you to specify a file instead.
This is the way I always did it in angular 1 as well. I don't really understand why style guides & general practice recommend embedding html in the javascript though. It's horrible.
I'm sure 4 can be solved by editors, if it hasn't been already.
https://www.jetbrains.com/webstorm/whatsnew/#v2016-2-angular...
I do agree that I really really was a fan of the backticks for ES6 / react for templating. Avoiding the whole " vs ' escaping nightmare is something i've always looked forward to.
That seems like a very simple fix for them though, potentially.
edit: tone
Also with AOT compile, breakpoints inside templates are possible, so you absolutely can step through an NgFor :)
Edit: You can use external html files. Just look at their tutorial[0] using html-loader at the very end.
templateUrl: './app.component.html'
But when I look at how are built the sites I like and visit frequently, I'd say 95% of them are not SPA, they are classic sites where the server generate each page (sometimes with one or two Ajax requests)!
The Single Page pattern is great for desktop-like applications such as Gmail, it's obvious. But otherwise, I don't know... I think I still prefere the "feel" of classic websites.
Your hacker biases are showing.
The sites where 95% of people spend most of their time (Twitter, Facebook, Instagram, etc.) are all built as single page "applications." Users expect rich interactivity from websites these days and are usually not tolerant of UI refreshes.
The comparison is not to "desktop" applications but to mobile apps. Users expect a mobile app level of interaction. Plus, if you're building mobile apps then it's a lot easier to just reuse those same APIs for a web app.
That being said, if your site doesn't have any interactivity then it does make sense to just render it statically.
The app may have been slower to load the first time (hopefully not by much) but from then on, they get the perception of instant feedback even if they have to wait a round trip for the backing data sometimes.
SPA frameworks make this sort of interaction very easy to design and reason about as a developer.
If you are going to argue that this is about "hacker bias" you will have to show user studies, not poll JS developers.
They're fantastic for forcing people to buy new hardware just to look at information :|
I've done of a few of these types, and now have moved onto mixed environments. Where most is rendered server sided, then only updates requested client side. Of course you're doing things twice for same queries.
Serious question: are people so touchy these days that you have to assure them that you are not being hostile before even saying something?
Of course all that goes away when your boss says you need to support JS-disabled browsers.
Well seeing as this release of angular offers some form of server side rendering, as well as Ember with fastboot, & being implementable in React or something like that. It's more approachable these days, there's some tweaking that's required, but very much doable.
Unless of course you're dealing with an interaction heavy UI.
In any event, if you're making a real Web application (as opposed to just a Web site that's primarily static content) the experience is much better.
Classic websites have CMS, things like Wordpress, and a ton of MVC frameworks that have been tweaked over the last decade, like Rails, Django, ASP.NET MVC, etc. When it wasn't a solved problem, a new one like this was popping up in the news every other week.
Now, that that's done, people are trying to do other things, like complex web apps...and so that's where the brain time is being spent.
React is super good to take control of a small piece of the page and build a complexe widget on it (can't speak about angular, I only used it twice without getting very far).
However, in b2b use cases where SEO isn't an issue, SPA frameworks are ideal for coordinating a static-site<->dynamic-api system.
Most websites and web apps have use AJAX to dynamically update certain parts of the site. Even though few sites would need to use it for everything, once you introduce good tools for dynamically updating the DOM and hire some Javascript developers, it's easy to say "Let's just use this approach to everything".
It's fair to say it's a lazy approach. I've built many SPAs that probably would have been better as static sites, and would have benefited from better SEO. But hey, we got then shipped fast.
I don't think that's entirely true, they allow for building experiences that weren't really possible with the previous model of rendering entire pages server side on every action but they aren't easier in all respect to that. If you site is mostly static data, it's probably still easier to use the older model. SPA frameworks start to make more sense when you want to build interactive pages with components that you want to individually update etc...
But they do add complexity that can't be ignored. that's why tooling and frameworks are hugely important as they smooth out that complexity.
Websites are static documents.
Web Apps use the browser as a runtime for a UI application.
HTML5, CSS3, and Javascript have matured to the point where they are very powerful and flexible. I don't always see the point of over-complicating things with frameworks.
All-told, it took 20 hours, 7 of which was me getting used to the intricacies of developing a full-screen "App" (no scrolling) with flexbox and implementing the designs. I'm good with vanilla JS, but there's no way I could have done all of the coding (three 'game' pages, three 'admin' pages) in less than two days.
I guess the point is, a framework that you know and are familiar with can halve the time you spend on a project. I find that to be especially true with Ember because of the CLI tools and all of the various addons.
Simplify server logic
Use less bandwidth
Very detailed, proved by numbers, objective and professional argument. That's how things should work.
As someone coming up to speed with frameworks like React and Angular 2 it feels like that all over again.
It is funny that after the Rails driven success web devs had moving away from J2EE they are falling right back into the same traps - ultra complex bloated frameworks built on a terrible language.
Even if you consider JS a bad language, proper abstractions can change the face of it entirely. By your logic, assembly is also bad since it is absurd to write anything useful in it. IMO Elm is a step in the right direction.
Learning by rote is stressful since your mind has to retain effectively a bag of (to it incomprehensible) technical trivia. In contrast, first principles are compact and generative, and such a grasp also informs your intuition so you can actually make educated guesses and jump in the deep end when picking up a new stack. Same principles apply to learning programming languages.
The biggest headache in picking new stacks today is the current trend of technical neologisms, so a bit of initial squinting (for recognition) is required.
1. Typescript awesomeness: You can write plain JS or give type hints in Typescript. Typescript is awesome, because it is a superset of Javascript and compiles to Javascript. (Typescript > ES6 > ES5)
2. Modular code: It is is much easier to manage Angular code as it grows (compared to AngularJS). Components could be made independently and reused within other components using component interaction [1] (@Input, @Output)
3. Template Directives: .html template directives are available unlike ReactJS. A ReactJS vs Angular2 blog post online [1] argued that that putting HTML in Javascript is better than putting Javascript in HTML. I'd argue that template directives like ngFor, ngIf, etc are much simpler to understand. Also, it is easier to collaborate with a designer/half-developer who knows some html/scss and doesn't know Javascript than working in ReactJS where every collaborator has to know JS. This way, it is also easier for someone to gradually learn the framework. For me, template directives are a big win. If someone wants to construct templates with plain JS, that is still possible in Angular.
4. @angular/router is better than AngularJS routing and we don't have to use a 3rd party library (like ui-router was more popular in AngularJS than the angularjs router)
One thing that I have found annoying is that: UI libraries for Angular. Example: material2 (currently at alpha.8) [3] are not complete yet and lack several useful components. This can be a problem if you are looking to quickly build a complete, good looking UI. Hopefully, now with Angular 2.0.0 out; Angular team could focus on quicker development of material2, so we have all the AngularJS Material UI goodness with Angular.
[1] https://angular.io/docs/ts/latest/cookbook/component-communi... [2] https://medium.freecodecamp.com/angular-2-versus-react-there... [3] https://github.com/angular/material2
I agree with your annoyance with the UI libaries. It's been a PITA just to find a working datepicker. We eventually rolled our own starting with the source of an abandoned date picker project. Haha.
Source code here: https://github.com/ng-bootstrap/ng-bootstrap/tree/master/src...
Be aware, it is not perfect atm, especially around validation, but it is pretty much the only datepicker out there for ng2 in the open source world (not even Angular Material 2 has one).
I know it's supposed to be faster - I just am not finding people using this stuff in production seriously until now.
I don't want to clog up the angular group with these informal lines of questioning - obviously.
It basically uses the JQuery date picker and works quite well.
There is a lot of roughness around currently when it came to upgrades during the RCs - Angular 2 was far from full-fledged even during the earlier ones, and has come a long way in the course of their development. Testing has a massive gap in documentation/articles on how to do it right. There are also some pains such as some (IMO somewhat poor) opinionation in the Angular router, especially when combining with server-side routing - had some battles integrating the Angular 2 app with the full server-side app for work, in large part due to hapi's major deficiencies when it comes to delegating routing to a frontend only application. Setting up can be daunting, although I got a large boost from using https://github.com/preboot/angular2-webpack, a great starter pack largely maintained by a member of the Angular docs team. Not all of the benefits are easy to tap into currently, such as the fairly recent AoT compilation, which lacks any plugin support for any build system such as Webpack currently. I intended to write one & open source it, but I was assured by a member of the Angular team that it was on the docket to complete. Documentation also needs a lot of work to be more developer friendly, I have found senior developers making easy mistakes with Angular 2 because they are not familiar with how to structure everything while having to produce on difficult story work. Testing is also a sore point, especially with the need for the karma shim to be produced for each app.
That said, Angular 2 is a phenomenal upgrade over Angular 1 in the ease of structuring apps. It also avoids incorrectly munging everything into components, avoids imperative logic to construct DOM/components, and imposes opinionation & more modern tooling such as the availability of observables to more correctly manage app state & app flow. It is fast, and much easier to tap into optimizations than Angular 1, where one had to be able to work close to the source code in order to understand everything one can and cannot do. It also offers the flexibility to do everything one can do with React, including server-side rendering (with the ability to do so on platforms such as PHP, Java, Node, and .Net in the pipeline), web workers, service workers, and multiplatform apps via React Native or NativeScript.
Just curious if you are indeed saying that the built-in router allows you to do EVERYTHING you could do with ui-router (nested states / targeted views etc)? I was planning on sticking with ui-router-ng2 when we kick over to angular 2.
How about testing? Was that difficult moving test suites over?
Angular Router does allow nested states: - https://angular.io/docs/ts/latest/guide/router.html - https://angular.io/docs/ts/latest/api/router/index/Router-cl...
I don't quite recall what "targetted views" mean?
Specifically:
> Bug fixes and non-breaking features for APIs marked as stable
> More guides and live examples specific to your use cases
> More work on animations
> Angular Material 2
> Moving WebWorkers out of experimental
> More features and more languages for Angular Universal
> Even more speed and payload size improvements
> Semantic VersioningCompare the differences and consider the trade offs with complexity vs simplicity. It's worth a consideration.
I've been using Angular 2 in a major enterprise project since RC1. Even with some of the headaches between RC releases; all of the reasoning behind those changes is technically sound.
It's easy to write components and wire everything, and even small things like async validators are fluid and easy to implement.
I'm loving it, and while the entire build system is still a bit of a dumpster fire; we're doing great on things like testing, code coverage; etc.
There are a lot of problems with lazy developers hoping a blog will tell them how to do every little thing. The source code is on Github. If you can't get something working right; maybe go read the source code of the classes you are interacting with. I've found 99% of the time now that simply reading through the code gives me not only the transparency needed, but a clear path to a better solution. Kudos to them on the new forms; they're awesome.
Though next week's announcement...
Angular 2.0.1 RC 1
It's Change Log will read:
* Routing has been rebuilt.. all previous versions not compatible
* We decided to rename the NgModule decorator to NgYouMAD?
* All Internet tutorials no longer work... Good Luck relearning!http://smashingboxes.com/blog/choosing-a-front-end-framework...
https://www.developereconomics.com/feature-comparison-of-4-p...
https://www.developereconomics.com/comparison-4-popular-java...
Tried Ember.js more recently, didn't much care for it. I think I'm just not a fan of large frameworks.
Now mithril.js (http://mithril.js.org/) has finally lured me away from Backbone :)
Ionic 2 + Angular 2 seem to be the best choice, since I can basically write the app once and release for all three platforms.
React Native has the downside that React and React Native are two different things. Be aware that there is no such thing as React Native for the web. There's something in development right now, but nothing stable.
Truly native: I can't support three platforms as a single developer and I don't feel like outsourcing it.
I'll go with Ionic 2 + Angular 2, although Ionic 2 still has quite a few bugs. For example, the zoom attribute on <ion-scroll> doesn't work – which is critical for my app.
Sure, there are hacks and this reminds me on the discussion from the other day: https://news.ycombinator.com/item?id=12477190
Yes, it's all very hacky. But there's really no alternative I guess.
Getting Started with Angular 2
https://angular.io/docs/ts/latest/cookbook/a1-a2-quick-refer...
Did ng1 and react with JS before, react was more enjoyable but in the end it just doesn't compare.
Anyway, great to see the release :)
Devs must be in the thousands, but the users of their apps might figure in the millions :)
Seems few people know how to steward a free/open source software project that has lasted over 5 yrs.
Angular 2 in beta/rc was in many ways rapid iteration on top of experimentation to get the core APIs & developer experience right. They have finally reached a stability point where they feel completely comfortable with the framework they have ended up with as a result, thus the formal release of 2.0.
If you've actually paid attention to the development cycle of Angular 2, it was very fast - it turns out that Google moves much faster than most shops, which was seen in full display during alpha/beta/rc. However, that goes with the territory there, and the versioning did not lie. It is now following semver though, so we shouldn't be hearing of these problems anymore.
Cx documentation is written using Cx and it offers plenty of interactive examples and code snippets.
https://cx.codaxy.com/docs/widgets/grids
Disclaimer: I'm the author of Cx.
A very rocky road ahead, methinks.
Yet there is Polymer that just works, has a great ecosystem, awesome material design support and is a breeze to work with (+ its fast too).
Right now there was 2.0 announcement and new version really supports easy migration path unlike Angular 2.x.
To me, all these things put Polymer far behind the curve as something I'm interested in ever adopting.
Is bower less reliable than npm? (I do more python work than JS)
When it comes to performance it is great in Chrome. In other browsers not so. I hope v2 will be much better once they can get rid of the compatibility layer for other ever-green browsers.
It is much faster than Angular - somewhere around React performance. Polymer is picked up by big companies already whereas "no one"(big) is using angular 2.x for now.
People here seem to project a weird bubble around Angular/React.
> In other browsers not so. I hope v2 will be much better once they can get rid of the compatibility layer for other ever-green browsers.
Browsers get rid of it on their own - when they implement the standards, shims load when specific functionality is found or not.
funny i just spent an hour yesterday upgrading to 3.0.0-rc.7
I see their quick start has been updated to use the final. https://angular.io/docs/ts/latest/quickstart.html <= great way to get started.
agree with other comments that RxJS is a tough library to learn but I love that they used it instead of re-inventing that wheel. It is incredibly powerful and solves a lot of asynchronous programming problems. you can see all of the methods visualized with marbles here: http://rxmarbles.com/
:-p
This might appeal to java full stack/backend engineers that need to once in while show case a nice and shiny GUI. It my experience, the combo of Angular with Bootstrap/Font awesome works just fine for that.
Very positive to have static typing through TypeScript as well. But also here I am quite biased for I never liked the concept that 'everything is just a var' ;)
Is Leftpad included?
We also have a (community) react-native bridge, and of course all the awesome html5 stuff from Ionic.
NativeScript has a JavaScript<=>Java bridge on Android, and a JavaScript<=>Objective C bridge on iOS, like a cross platform version of Apple's ObjC bridge used in OS/X JavaScript for Automation [3] [4] [5] (but AFAIK Apple's ObjC bridge is apparently not available for developers to use as a framework, nor on iOS, nor of course on Android).
Unlike React Native's JavaScript engine, it runs in the UI thread, using V8 on Android and JavaScriptCore on iOS, and you can call all the platform specific APIs directly, subclass and implement Java classes and Objective C classes and protocols, call methods and functions, and pass objects back and forth, write your own plugins in TypeScript, JavaScript, Java, Objective C, etc.
[1] http://docs.nativescript.org/angular/tutorial/ng-chapter-0
[2] https://www.nativescript.org/
[3] https://developer.apple.com/library/content/releasenotes/Int...
[4] http://tylergaw.com/articles/building-osx-apps-with-js
[5] http://developer.telerik.com/featured/javascript-os-x-automa...
[1] - https://angular.io/docs/ts/latest/guide/template-syntax.html... [2] - https://angular.io/docs/ts/latest/guide/attribute-directives...
You cannot really compare these frameworks because Ember is far ahead of all. Super stable, matured, adopted the best practices, huge addon ecosystem, brilliant community, easy to learn, great documentation. Quite an obvious abd best choice. Life and development is just super easy and fast with Ember.
IDEs have to implement better support for NG2 but this will come over time.
There will be always limits for search engines on interpreting js.
It's important to IMMEDIATELY understand that the backend should not matter - so long as it returns JSON (or even XML i suppose) which AngularJS 1.x can consume with $http or $resource (or ng 2.x equivalent).
This is an advantageous pattern in my opinion because the front-end angular application is totally decoupled from the backend (we have separate code repos - and even separate developers) - you can keep the backend as Go, or PHP, or Python - or even a static JSON file with something like jsonserver. So long as the JSON is formatted appropriately and API does what angular expects - angular does not care!
I can't find a benchmark or size comparision somewhere.