To be fair, it looks like the website itself for angular.io [0] is built on Angular, or at least a HTML framework that is not Jekyll (which is what they've used for other site documentation, including AMP [1])...so at least they're dogfooding Angular on Angular's own homepage, even when it doesn't seem needed (I didn't see many features that didn't seem to be mostly static HTML)
As a Brit living within a region under the influence of the EU, I concur. A massively annoying imposition from power-tripping bureaucrats who have no idea what a stateless protocol is.
Anyone has the experience working with NativeScript and Angular 2? How's it compared with React Native? And is there any chance this will evolve to a viable alternative to developing native apps using web technology?
Jen from Telerik DevRel here...we are working with Google to ensure that Angular 2 works great for your NativeScript apps. Please check our blogs at nativescript.org for forthcoming info on performance comparisons and how-tos. I'd encourage you to visit our getting started guide on the above web site to see how you like NativeScript!
Angular2's architecture is split in such a way that the rendering layer is separated from the application code. This allows swapping out the render layer - enables stuff like NativeScript and React Native renderers, server-side universal and running your app in a web-worker, dispatching to the main thread to render.
No, NativeScript is a Telerik product. Angular is a Google/ Open Source project. I'm not sure how they are related, I haven't seen anyone use the two in conjunction.
I'm a C# developer. I have been patiently waiting for angular 2.0 with the hopes of switching my stack to TS.Node + Angular and I'm really excited about trying this!
I'm very impressed with the power Visual Studio Code offers for developing JS/TS projects. Do you do all of your development in the .NET flavour of Visual Studio?
I really wanted to start using ts in my next React app but did not find any good resources and couldn't get it off the floor. Happen to have any insight on that?
This happened to me. When TS came out with JSX support I immediately forked our NG 1.4 project and tried to start a port. I barely got Visual Studio working with the React TS code and quickly ran out of steam. Looks like I'll need an external build step because I could never get Visual Studio to build the React app into a single app.js file.
Yeah, sad really. It almost seems like Visual Studio Code is getting better support for it, which from the point of a paying VS user feels a bit off, I now switch between two editors to develop one app (VS and Atom), but would love to do everything in VS. Ah well, we'll probably need to wait.
I've been working on a TS/React/Redux app for the last couple of months, trying to make use of the "latest and greatest" tools and best practices, and hope to write up a blog post over Christmas describing my experience (overall very positive) and how to set it all up, so I will be sure to post it to HN when it is done.
I don't have one yet, this will be the inaugural post! But I am on twitter @tomduncalf, so if you want you can follow me and I will tweet you when it's out. This is good, it puts pressure on me to actually write it ;)
How many Angular folks are sticking with native ES6 and babel vs TypeScript? Angular is clearly directing folks to TypeScript. I don't want to have to use TypeScript on front-end and ES6 + Babel in Node. Trying to pick one.
As I understand it they have most of their docs written for TypeScript but they plan to fully support ES6 and have the docs to show how to use ES6 too. I would prefer ES6, however it appears that TypeScript is a bit less verbose to write.
The big difference between TS and ES6 is dependency injection. Types can be resolved through TS types while you need to use decorators with ES6.
The problem I have with decorators is that they are not officially part of ES7 spec yet, even if there is a big chance they end up in the final spec, features like ES6 modules are a proof that things can be reworked to death before being standardized.
I'm finding it very difficult due to the sheer number of choices. Angular 2 supports ES5, ES6, TypeScript, and Dart. It's hard enough evaluating what our upgrade path will be from Angular 1.x, let alone which language we should end up using.
I kind of have a feeling that by the time we actually need (and have the resources) to upgrade or even start mixing in Angular 2 on our project, native browser support for ES6 will be close enough to complete that we won't need a transpilation step. That might be a nice time to do the migration.
Looking forward to hearing what other devs end up using.
A lot of Angular 2 is optimized around using Typescript. A lot of the heavily-used Typescript features (eg. annotations) are on track for ES7, but not part of ES6.
TypeScript is fully compatible with ES6 as far as I know, so if you want to start using it either on the client side or on the server side, you can start doing that whenever you like (provided you don't mind changing file extensions, etc.)
That's a negative, it is the reverse -- MS has always maintained that TS will be a superset of ES and that they are completely open to porting TS features over to ES.
We've been using TypeScript with Angular 1 projects for almost a year now and have really been enjoying it. Having it integrated directly into the framework is a great improvement for my team, at least.
Yes. You just include a "type definition file" for Angular in your project. There is a very large existing repository of type definitions for popular JS libraries in the DefinitelyTyped project.
TypeScript, all the way. I work with it professionally and I couldn't be happier, especially in comparison to CoffeeScript.
I used to love CoffeeScript but, after giving ES6 (with eslint) a shot, it no longer has a special place in my heart.
I do enjoy the terseness of it (writing it is fun) but some things are just painful (reading it after the fact).
As for TS vs ES6+ -- I would go with TS but only because Angular projects have a tendency to become very large, and having a compile-time type system hold your team's hand is very comforting.
With Ionic 2, we're giving people Babel + ES6+ for our starter projects, with the option to enable typescript. I agree with you that typescript should "enhance" an app, but not dictate it from the start. We're giving people the option and will see how that goes.
I've been using TypeScript for a few months now and have been so impressed with it that I am beginning to favor Angular 2 over React just because of Angular 2's TS integration.
TypeScript basically made JavaScript more powerful and a whole lot more fun for me. I feel so much better about slinging around parameters now that I know my IDE will catch type/parameter mismatches before I run the code, before I build it, even before I save the file! It simply alerts me in the IDE (I use VSCode which I also love). This is a huge time saver.
Another great thing is the intellisense, which allows me to keep on coding without looking at some API documentation or other files in the project. The intellisense even has the documentation in it - so this is a really fun and efficient way to learn new libraries and frameworks.
I didn't even know how much I missed enums in JavaScript until I started using them in TS. Also love the fact that you can revert to using the Any type if you have to and there is even support for generics as well.
All of this stuff can be had in various transpilers or IDEs, but TypeScript and VSCode just bring everything together in a very simple yet powerful way.
I never jumped on the CoffeeScript bandwagon .. I know people love it, just not me. Hence unlikely I will try TypeScript.
Despite all its glaring flaws, javascript is an insanely productive language due to excellent mix of features. To improve upon that Id need to go to lisp / clojure [ but it lacks wide commercial acceptance .. not a criticism at all ]
I'm actually wary of using the newer additions to javascript language - ES6, Promises and arrow notation don't seem that much of a win to me, I'm very sceptical of new being good in language design...
whereas I really love Ramda.js as a general underscore / lodash replacement.
Productivity seems more a function of how we structure our code [ eg. keep state so we can jump back into where we were in the web app, thus iterate easily - as per the Om approach ] and thinking functionally.. rather than language syntax additions.
I don't see the need for an IDE .. they tend to come into their own when Your.ColourfulAndCompleteMethodNames are so long they need auto-completion. Thats the beauty of javascript [ and lisp etc ] we should fight to keep things small and terse.
I don't want to argue on your other points but imo the part of auto-complete that saves typing time is the least important thing in a IDE. The really useful part of auto-completion is actually exploring unfamiliar APIs.
> I've been using TypeScript for a few months now and have been so impressed with it that I am beginning to favor Angular 2 over React just because of Angular 2's TS integration.
As a big fan of types myself, I hear you. Have you tried using flow with react? I wonder how they compare.
I can't tell you anything about flow (no experience and no interest), but I have no played a little bit with React & Typescript as well as Angular 2 & Typscript. Imho both configurations work quite good:
What I liked about React is that I also got type checks in JSX (compiler tells me if the types that I assign to props are correct). I don't get that kind of type checks for angular2 templates. If I assign something wrong there then it blows up at runtime.
What I disliked about React is that the ecosystem doesn't embrace typescript. For most 3rd party components that I tried there were either no type definitions available or they were broken (which is often worse - because then you can't assign props that are actually valid).
For Angular2 at least the framework is already typescript-first (so we have automatically up-to-date type definitions through the compiler), and I would hope many 3rd libraries follow that design.
It is a shame that so few React-based libraries are on DefinitelyTyped. As the project I've been building had quite a short timeline, I've just been creating "any" type definitions for libraries which don't have definitions (in an ideal world, I'd like to create and share a proper definition), which works but you lose type safety and auto-complete for these libraries. Not the end of the world but it allows more runtime errors to creep in.
On the Flow vs Typescript thing, I evaluated both for this project, and almost went with Flow primarily because at the time, I liked that Flow felt lighter weight (it is truly "opt in" unlike TS, and getting the TS setup right was quite hard work), and I was also put off by the overhead of having to write .d.ts files (now I can create an "any" definition for a library in a few seconds, but at the time found it all quite time consuming).
However, I persevered with Typescript in the end, as I felt that some of the features it offered over Flow were worth the extra effort - specifically, the editor/IDE support (Atom with Nuclide for Flow was really unstable for me and the autocomplete still didn't compare to TS) and the fact that Typescript does a full compile of your code, so will pick up on things like mis-spelled imports, which Flow didn't seem to.
Also, I found documentation for Flow (beyond the basics) to be quite lacking, and there didn't seem to be as much community around it - for example, I just couldn't work out how to get it to check React propTypes, which was a pretty important feature for me. Bit of a shame, as its type system actually seems more fully featured than Typescript's (e.g. types are non-nullable by default), but TS's type system is certainly good enough.
I'd say go Typescript at the minute if it's a reasonably large greenfield project, but Flow might suit your needs if it's something smaller (whether that's in amount of code or in team size), or if you prefer the lighter touch/opt-in approach - for example, if you want to introduce it to an existing JS code base. I would definitely say it is worth the effort to go with one or the other, I'm not looking forward to going back to writing plain JS - having the compile stage makes refactoring in particular trivial, without the overhead of having to write loads of unit tests. In TS I'll refactor constantly as I go whereas in a large JS app, it's tempting to put off refactoring as you might miss somewhere and not know until it is QA tested (or the customer spots it is broken...).
Looks promising... But personally I dislike TS., and I know that it not required for Angular 2..., Now I prefer ES6 + babel, maybe in future I'll change my attitude to TS.
Trying to find info on their packaging story. Last I heard the official tooling seemed to be moving off systemjs+jspm in favour of WebPack, but I don't see any clear info on this; does anyone know?
We've started experimenting with systemjs and really like it (though support is a bit limited right now, plus it not really liking PhantomJS/karma), and we want to modernize our Angular 1.x app packaging/loading/bundling, but don't really want to do needless work if we have to move to another solution for Angular 2.x.
We're playing with all manner of tooling here. Our CLI (broccoli based), Webpack, SystemJS / JSPM, Rollup, etc - we'll also be focusing on HTTP/2 as we move forward.
[Shameless plug]: I've been writing a book on Angular 2 over the past few months: ng-book 2 [1]. If you want to write your first app, you can get the first chapter of our book for free.
You can of course learn Angular 2 from lots of disparate blogs on the internet. There's lots of good resources. But the goal of our book is that you'll be able to learn everything, in-order, in one place.
We've been keeping the book updated alongside Angular's development (though it will take us a few days to get up to the most recent beta). We've already updated the book over a dozen times, so I think you'll really like it.
ng-book is one of the most in-depth resources that I recommend to those who want to get into angular development.
I can't quite say the same for ng-book 2, as I have not yet read it, but it's definitely worth spending money on, especially when you get the updated versions on digital copy.
I had a really painful time trying to contribute to the angular 2 project. I get the impression that the developers actively working on this are working with discussion mostly internal to Google.
It's a shame, because it does seem like both a very powerful and nice approach to building SPAs that I would love to contribute to.
@estsauver while I agree that it takes some time to get into contributing into a big project like Angular 2, it is simply not true that it is "Google only" project. I'm a regular contributor (#6 in terms of no of commits: https://github.com/angular/angular/graphs/contributors) and I don't work for Google.
Angular team is bunch of great people, real pleasure to work with. I can tell you - the initial effort to start contributing pays off _very_ fast.
As pointed out in the blog post shaving off bytes is one of the priorities before 1.0 release. We've got many tricks to play here, so expect those numbers to be much lower in the final release.
Flow was written by Facebook, yet TypeScript seems markedly more popular and well-liked. There are some who hate TypeScript because MS, and there are some who hate Flow (and React) because FB. But most of the criticism against TS has, anecdotally, been technical in nature.
Edit: by popular I didn't mean that it's merely used by more people. I've clarified that.
I'm not talking about popularity. I'm talking about indiscriminate hate because it's connected with microsoft. C# has suffered the same stigma since the beginning.
People hate Dart, written by Google, for same reason: it is better to stick to single language, for better ecosystem, than to fragment it.
I, personally, just ignoring Dart, CoffeeScript, TypeScript, etc. Life is short.
We're stuck with javascript due to historical reasons, not because it's any good. I think that treating it as a bytecode, binaries, etc.. is the way to go. I.e. javascript (preferably fast subset of it) will be produced by proper tools and you'd never have to look at it again. Fragmentation is only natural.
So these languages exist precisely because life is short. Are they the perfect/stable solution? Probably not. But it's the right way to go.
We're stuck with javascript because it is good enough, so switching to an another language, e.g. Dart or VBScript, are not worth effort and consequences. JS even used at backend side. IMHO, it is better to invest into JS than to fight with it.
I really love the new component creation syntax(API) and Typescript gradual typing is super useful.
I can see Angular 2 being use even more than Angular 1 in the near future...
From what I've seen, there are a lot of vocal proponents of Typescript, but not many vocal detractors. Which of those is the actual majority is hard to day.
I have a theory that many of the people who like Typescript came from a statically-typed background (Java, C#, etc) and don't like the loosely-typed world of Javascript.
More speculation: People who came to front-end development by choice are happier with Javascript than those who were transplanted from the server side and forced to convert to the One Language Of Browsers (ignoring transpilers, of course).
Don't forget people who came from desktop ui or game development and have had code completion and navigation for years and can't handle the slowness and unreliability of navigating and developing a js codebase.
You can write your Angular 2 application code in ES5, ES6, TypeScript, Dart, or to-JS languages like CoffeeScript.
TypeScript is pretty popular and it does work really well. Writing larger applications in a team is much easier if there is tooling to assist you. With most projects, about 80% of the work is maintenance and tooling does immensely help with that.
Wow, from +8 to -2, a lot of downvoting on this comment.
All I know is when the first angular 2.0 beta came out, it was not well received by anyone including myself because of the vast difference in syntax (simple -> complex) which is the only reason I and a lot of others picked Angular in the first place. It seems it has been tweeked a lot since then, but those problems have not been fixed. I don't think next version of angular is usable for me.
Typescript's audience is far less than Angular's audience, there should be no reason to use typescript as the official example. This kind of bundling is similar to Microsoft explorer coming with Windows.
there's a very nice strategy for this - the upgrade module allows you to run ng2 components inside of ng1 apps (or vice-versa) so you can incrementally upgrade.
I've just started working on an app using Angular 2 and Ionic 2.:
1. TypeScript - It's really nice to be able to use a typed version of JS, although it does feel like I'm writing C# sometimes! It supports lambda syntax / ES6 which is great.
2. Annotations seem a bit clunky, not really sure what the point of them is.
3. Absolutely love the functional reactive / RxJS stuff they've incorporated - it's going to make it VERY easy to write really powerful apps.
4. It's a million times easier to develop with than angular 1. $scope.apply anyone?
Started to work on a frontend for realtime automotive networking systems in angular2. I used angular2 services which provide all (non-constant) state via Observables to the components - and I'm really pleased with the result. Totally reactive, and the implementation effort and complexity is relativly low.
...re typescript, i feel like if i'm gonna use a not-script of some sort, it might as well be clojurescript or something else that's like a really-srsly-not-js rather than js-but-prettier (coffee) or js-plus-a-paradigm-grab-bag (my totally uninformed take on type)
I'm curious what Angular 2 is like for developers who normally write React? I hear 2 is a lot better than 1, but I'm still turned off by the amount of Angular-specific terminology, whereas most of React terminology is not necessarily React-specific.
We use Angular 1.4 at work, but your reasons are exactly why I'd prefer React. It is mostly just Javascript without a lot of Angular specific conventions. At least Angular 2 looks nearly as good as React and work is planning on upgrading.
Me too. Impression, admittedly only from reading about it and looking at a few code samples, is that Angular 2 is over engineered and complected, as is 1.x, which I have worked in daily for over a year. ReactJs is much more appealing these days.
I've used and followed Angular 2 somewhat over the past year. My take is that React is better for engineers familiar with JavaScript, while Angular may be more comfortable for engineers with a preference for Java/C#. I don't mean that in a bad way; it's simply been my experience that people coming from those languages love what they see of Angular 2, and are repelled by React.
It's not hard to see why. This code[0] from Angular 2 would just be a function in React:
@Pipe({
name: 'tempConvert'
})
// The work of the pipe is handled in the tranform method with our pipe's class
class TempConvertPipe implements PipeTransform {
transform(value: number, args: any[]) {
if(value && !isNaN(value) && args[0] === 'celsius') {
var temp = (value - 32) * 5/9;
var places = args[1];
return temp.toFixed(places) + ' C';
}
return;
}
}
There's also the fact that Angular is a framework, whereas React is a library. Those of us in JS land typically (but not always) prefer smaller libraries.
let's be fair, Pipes can do a little bit more then pure functions. E.g. the async pipe which lets someone directly use Observables in the view is really helpful. And a simple function in combination with Observable.map() or Promise.then() won't bringt that functionality to React (you need to write lifecycle hooks or mixins, and in the end it would look similar to your construct.
Lets see what happens to react. I hear React is building in support for Relay, React Native, other facebook stuff. I <3 <3 <3 react, they have done an amazing job so far, as a React.js consultant and early adopter I owe my financial well-being to React, but big projects from big companies have weird incentives, Conway law, everything made by big companies inevitably goes to shit, yada yada. Maybe Relay ends up being not the best solution to the client/server query composition problem (IMO its not). Maybe people will get burned by 50-shades-of-flux (IMO the Great Flux Wars have barely started) and for the type of company that writes a ton of javascript, the framework pattern will come in vogue again (IMO). Maybe there will be an explosive patent lawsuit where Facebook decides to weaponize its "defensive" patents for whatever reason. I personally believe all of the things in this paragraph will happen in the near term.
In my mind at least, the so called Great Flux Wars have already been won by Redux.
I just finished my first non-trivial app built with Redux + ImmutableJS a few days ago, and it was pure bliss. Finally, we're able to build entire applications as a mapping of pure state transitions on top of immutable data in JS. Redux is by far the biggest reason why I haven't yet completely abandoned JS for ClojureScript.
React providing a mustache-like format (like ractive.js uses) would be great - more familiar than JSX and less clumsy than createElement().
Edit response to person below (rate limit): there's no 'problem', just that mustache is still more familiar. Moving JSX into a different file doesn't change that.
JSX/createElement is not just syntax sugar though. It avoids the whole step of parsing the template. Because JSX is JS code, you can pass native JS values to it including callbacks. Whereas anything you could pass to mustache-style templates will be stringified.
So for example in case of parsed templates, to pass a callback to onClick you'd need to define a convention on how you're going to locate the callback by a given string (since you can't pass the function itself, you need to pass some "name" of that function). Whatever logic that will be, the result will not feel like React anymore because you're back to typical framework-specific template magic instead of using plain JS.
This is not what I'm doing. JSX is JS. I'm not putting any logic "in HTML". If I were able to express what I'm doing in mustache-style syntax, it would be:
So, once again, JSX is JS. You're free to write the exact same thing without XML syntax. If you don't like that either, then what you're really saying is "Don't generate HTML using JS". Why not? The benefits are obvious:
* With React & ESLint you get basic checks to make sure you're not passing non-existent variables
* Your IDE understands what you're doing and lets you jump to callback definitions
* You understand what you're doing because you have one obvious place where you do templating and data binding.
* Your actual behaviour logic is still separated from your template, living in some other JS file.
On the other hand, if you add event listeners to HTML from JS the classic way, you get other problems:
* You're querying the DOM tree by CSS classes or some custom attributes. It's surely a familiar way of doing things, but also fragile and unintuitive.
* It requires your JS to know the structure of your DOM to some extent, and that structure is defined elsewhere. So it's basically the same problem as with mustache templates – passing around magic strings – but the other way around.
Thats the paradox you either go one way or the other. The problem with Javascript or something that turns into Javascript in HTML is it can inevitably lead to magic variables. I don't know how many times I have went in to support another developers angular code and found a variable who's origin can be traced to a scope variable which has been declared and initialized in an HTML file and all the sudden is magically being used halfway thru a routine. It's just shy of globals.
At the end of the day you go one way or the other, my preference is the template not having the ability to affect logic as it is not natural to look thru templates to find what is mutating the state of your application. I liked Dojo and I think react is a step back in that direction which in my personal opinion is the right direction for large web application.
I'm someone that initially hated the look of JSX (the html markup inside of Javascript thing).
But I've learned to like it. React encourages you to keep components very granular and small and so the amount of markup in each component doesn't really get in the way I find. I've also learned to appreciate how easy it is to reason about what React is going to spit out onto the page because the view is right next to the logic that dictates the various states of the view. Feels very concise.
I still don't like the idea of it, but in practice it works quite well.
..I feel the same way. I prefer creating dom with code syntax.
You can replace JSX by hand-coding with React classes - take a look at the compiled jsx and mimic that. I find it as easy to work with, and less cognitive dissonance [ a personal preference ]
I actually am looking seriously at Mithril in preference to React for my next chunk of work.
I might swing the other way if React native became stellar [ and viably crossplatform ]
> Never understood why people liked React so much. I don't know why, but mixing javascript and HTML just looks... gross.
But you never write HTML with JSX, that's the point. XML like syntax is just sugar that gets transformed into functions. This is not HTML. With angular you need to use string templates which cannot be easily validated by IDEs for instance. JSX syntax validation is straight forward because it's directly integrated in the language.
Your end product has both HTML and JS so there's no way around mixing them somehow at some point. You could do it by keeping them separate and linking between them by means of CSS classes and magic strings in HTML templates. Or you can generate the HTML using JS functions. JSX just gives that latter option a pretty syntax.
If you don't like mixing logic into HTML you're free to create dumb components that only contain as much logic as you would want to put in a template. Such a component would accept properties and output a representation of the resulting HTML. A smarter component that does not generate HTML will provide the logic required for the template to function. That approach actually encouraged and is the right way to do React.
The bonus of this whole generate-HTML-representation-with-functions thing is that you pass around native JS values instead of stringified values and magic strings. Want to provide an onClick callback? Pass a callback. Not some magic string that represents a key which holds the callback in some object defined by framework-specific convention. No, you just pass a raw javascript function that will be run on click.
This might seem like a trivial distinction, but it's the difference between writing native JS vs writing magic framework code. I vastly prefer the former.
Mixing of logic and presentation is bad for application, but so don't use <font> tag in your code, because it will be hard for _designer_ to change appearance of hardcoded page.
React mixes logic and structure, which causes no harm, because both are written and maintained by same developer.
I've spent a lot of time with Angular 2 (alpha)[0] and React (redux flavored).
All in all it is fairly similar, and feels pretty good. You have to remember more syntax, because of the configuration, but it isn't as conceptually difficult as Angular 1.x
The templating syntax is "weird", and it definitely adds to the list of things you have to know specific to Angular 2.
React and JSX is nice because logic is just JS, and not special template syntax (directives).
I'd be happy to build an app with Angular 2 or React for different reasons. What's hard is looking at Angular 1 now.
[0] I've given multiple Angular 2 workshops, built large scale Angular 1 apps, and build React components daily for my business (a popular web developer video tutorial site).
Step 1: Include the Angular 2 and ng-upgrade libraries with your existing application
Is anyone with a serious application actually considering this? It would have been nice to include only the pieces of Angular 2 that you actually use. Instead, we have to ship both libraries, our application code and an additional plugin down the wire? I don't see this upgrade path as a legitimate option for anyone who cares about page load times.
Angular 2 addresses a lot of the serious shortcomings in Angular 1.x. The Angular 2 approach to components and encapsulation feels cleaner and less complicated than the previous mess of services, factories, and directives.
Though initially skeptical of Typescript, I've found that Angular 2 really benefits from the advantages of having a coherent object model and optional type safety. Typescript never gets in the way, you can selectively use type declarations only where you want to use them. It's often helpful to leave them out while prototyping and then add them later when you want more robustness and easier debugging while you are working on writing the glue code and application logic that connects your various components.
As other posters have noted, you're still saddled with a lot of the artificial complexity and odd terminology that is pervasive in Angular 1.x. There are also bits and pieces of the library ecosystem, particularly the routing engine, that are over-engineered and painful to work with in practice. But, in general, I find version 2 much more intuitive and easier to reason about than version 1.x. Key features like data binding are much saner and behave more predictably.
I've never particularly liked Angular or React (my personal preference right now is for Vue or Polymer), but I think Angular 2 is a solid improvement over its predecessor. More significantly, I think the improvement is substantial enough to justify the team's decision to do a clean break.
The only thing I haven't really seen on their 'Quick Start' and 'Guides' site is any examples that show retrieving data from an API. Are those out there and I didn't see them?
There's an optional Http client that uses RxJS Observables - see http://plnkr.co/edit/UQJpd5dA6x45T4PPZRWW for a basic demo that also uses the `async` pipe to subscribe from the view. Of course, the native fetch API works fine too.
I am in Germany and this link forces a redirect to angularjs.blogspot.de because of my location (which is a version of the blog in German, which I don't read).
No simple way around this, and no link I can see to go to .com instead. That's quite frustrating.
(Edit) No actually I spoke to soon. Even when the url doesn't redirect, the blog post is still in German for me!
(Edit again) Must have been cached, it's in English now.
React does indeed have about 4x as many daily downloads, but (Angular 1 + 2)'s download counts are ~5x what they were a year ago. (iirc the ng-europe RIP Angular fiasco happened in October 2014)
I feel people using Angular 2 are people migrating from 1.x so not quite sure if is a correct estimation adding the two values.
At the same times, my comment, is based on my gut feelings, nowhere close to a reliable source :)
Worth noting that the onboarding process for each framework is different. Getting started with react pushes you to npm. Angular 1 pushes you to CDN, so I'm not sure how useful this graph is. Interesting, nonetheless.
I'm pretty sure Google has invested millions more into Angular & the ecosystem than Facebook has into React - they even have a CSM on the Angular team. Even internally the investment seems to be proving vast, as Google even has a production Angular 2 app already (during the painful alpha) & multiple teams publicly pledging to use it, which will probably grow as it becomes appropriate for Google to migrate products to Angular 2. Google has a rarified number of software products compared to Facebook - it's irrational to assume all of them will jump to their framework immediately, especially considering it was in heavy R&D the past two years & only now entering beta.
I assume he means investment as in how much they use the product. Their two top products, Facebook and Instagram heavily use React. A bunch of Google products do use Angular, but in no way are they the primary products and that probably lends to the less fluid progression.
If Google was as invested in Angular as Facebook was in React, they would probably have gone with a more gradual, methodical approach to improving the framework (like the Ember team did). And until that changes, there is very little stopping them from doing another mostly incompatible rewrite in a few years.
As it stands, Angular 2 is closer to a completely new framework roughly inspired by Angular 1.x than a new version of Angular.
This is a nice worldview but doesn't hold up to the evidence.
Google has said they have something like 10k Angular 1.x apps, so they will keep on working on Angular 1. Angular 2 happening along this support is showing that they're willing to invest in the conservative route and the "burn down the libraries" route at the same time.
By level of investment, both me and the OP meant in terms of products that are key to the company's operations, and need to be continuously supported and improved. Facebook is one such app for Facebook that uses React. Instagram is one such app for Facebook that also uses React. I honestly don't know any such app for Google that uses Angular. Until that changes, there is very little incentive for the Angular team to keep improving upon the existing solution instead of building something completely new with no regard for the people that depend on it.
The so called upgrade path they offer for Angular 1.x is a complete joke. That you can "mix Angular 2 into your existing Angular 1 application" would be a true statement with any component-oriented framework in place of Angular 2, like React, and Ember. And this was not true for Ember just a few months ago, which is living proof that gradual improvement can in fact be accomplished with any framework, but of course, throwing everything away is much easier, so the framework developers need to have strong incentives to not do so.
Google uses Angular in over 1000 internally and externally facing apps, including some on Angular2 already. They are also on the main trunk, and update on commit. The test suite for Angular at Google actually checks not only the Angular tests, but also all of the tests for all 1000+ apps at Google that use Angular, before allowing it to be deployed.
To be fair, ng1 wasn't good enough for such huge apps. NG2 is good enough - incredibly performant, with server-side rendering, with support of TypeScript (refactoring of huge amounts in code in IDE), with real components encapsulation and DI. And some ideas were inspired by React - such as reactive data flow ("one-way", as it called in docs).
So I think Google will do it. Google Fiber is ng2 already :)
Google is behind Angular, as are other large companies, but the product was made for 'Angular', an online JSON storage product by Brat Tech LLC, hosted at getangular.com. The company failed, but one of the people there got a job at Google.
The point is that - despite the common misconception - Angular isn't Google's Anointed JS Framework. There's a whole bunch of Polymer and a whole bunch of GWT inside Google.
I don't understand the point of this comment. Almost every new Google service I see is written in Angular. Why are we jumping on comparing it to React already?
Maybe let's withhold judgement until we actually use it. Just a thought.
Apples to Fruit Basket comparison. React is a strict view layer, though i've seen too many instances of people trying to make it a ubiquitous framework. Angular is far wider reaching library.
No, its not an apples to fruit basket comparison. When people talk about React they're not talking about only React, but more likely a front end app that implements React.
No one is saying "oh I love writing view layers. It's way better than actually building things".
I disagree. The distinction is worth pointing out, and he's right. Angular is more than just the view layer (directives). It provides the structure for the rest of your app. Other tech like Knockout.js is more comparable to React, as it's only solving the view layer problem.
If you're in New York, and you want to travel to London, you can either fly on a plane, or take a boat ride.
If I am trying to compare the pros and cons of flying vs sea travel, a distinction between the fact that a ship is not an airplane isn't really important.
Two vastly different approaches can attempt to solve the same problem, and they're worth considering on equal ground.
On a side note, when people mention working with React, it's safe to assume (if they're building real software) that they are using React with a framework, whether that be some implementation of Flux or Relay or something else entirely. When comparing Angular to React / Flux you've got yourself an apples to apples comparison.
Not really; a better analogy is if I'm in Kansas and I want to get to Beijing. I can fly all the way there, or I can take a car/plane/train to a boat to a car/plane/train.
Angular is the airline flight(s), React is the boat. It won't get you all the way there on its own.
Google's Polymer [0] is probably closer to React than Angular. Angular's more of an application framework. Polymer's more of a Web Components[1] framework, which I think is closer to what React is doing.
Long term I can see web components/polymer shims being preferred over React, but not till the major browsers catch up. Like the parent says, Facebook is deeply invested in making React work and it really shows. Angular/Polymer always seems more r&d/experimental to me, which is great but not for people who want to do production work.
We had a look at Angular 2 at Pusher since a lot of our customers are using Angular to build app. If you want to check out a quick tutorial and see some actual working angular 2 code in action , you can go to https://blog.pusher.com/real-time-apps-angular-2/
272 comments
[ 2.9 ms ] story [ 235 ms ] threadRight now, there is a massive cookie consent form blocking my view of the actual article.
[0] https://github.com/angular/angular.io
[1] https://github.com/ampproject/docs
https://en.wikipedia.org/wiki/HTTP_cookie#EU_cookie_directiv...
There are even some adblock/ublock/what-have-you filters now that block those forms.
How is it going to work exactly ?
The problem I have with decorators is that they are not officially part of ES7 spec yet, even if there is a big chance they end up in the final spec, features like ES6 modules are a proof that things can be reworked to death before being standardized.
I kind of have a feeling that by the time we actually need (and have the resources) to upgrade or even start mixing in Angular 2 on our project, native browser support for ES6 will be close enough to complete that we won't need a transpilation step. That might be a nice time to do the migration.
Looking forward to hearing what other devs end up using.
Want to give this a try :-)
Thanks
https://github.com/DefinitelyTyped/DefinitelyTyped
I used to love CoffeeScript but, after giving ES6 (with eslint) a shot, it no longer has a special place in my heart.
I do enjoy the terseness of it (writing it is fun) but some things are just painful (reading it after the fact).
As for TS vs ES6+ -- I would go with TS but only because Angular projects have a tendency to become very large, and having a compile-time type system hold your team's hand is very comforting.
TypeScript is doing really good.
TypeScript basically made JavaScript more powerful and a whole lot more fun for me. I feel so much better about slinging around parameters now that I know my IDE will catch type/parameter mismatches before I run the code, before I build it, even before I save the file! It simply alerts me in the IDE (I use VSCode which I also love). This is a huge time saver.
Another great thing is the intellisense, which allows me to keep on coding without looking at some API documentation or other files in the project. The intellisense even has the documentation in it - so this is a really fun and efficient way to learn new libraries and frameworks.
I didn't even know how much I missed enums in JavaScript until I started using them in TS. Also love the fact that you can revert to using the Any type if you have to and there is even support for generics as well.
All of this stuff can be had in various transpilers or IDEs, but TypeScript and VSCode just bring everything together in a very simple yet powerful way.
Despite all its glaring flaws, javascript is an insanely productive language due to excellent mix of features. To improve upon that Id need to go to lisp / clojure [ but it lacks wide commercial acceptance .. not a criticism at all ]
I'm actually wary of using the newer additions to javascript language - ES6, Promises and arrow notation don't seem that much of a win to me, I'm very sceptical of new being good in language design...
whereas I really love Ramda.js as a general underscore / lodash replacement.
Productivity seems more a function of how we structure our code [ eg. keep state so we can jump back into where we were in the web app, thus iterate easily - as per the Om approach ] and thinking functionally.. rather than language syntax additions.
I don't see the need for an IDE .. they tend to come into their own when Your.ColourfulAndCompleteMethodNames are so long they need auto-completion. Thats the beauty of javascript [ and lisp etc ] we should fight to keep things small and terse.
I also like cljs, mostly in a text editor.
Code quality it is the ultimate time saver. I prefer reading concise, literate source to exploring/churning APIs.
As a big fan of types myself, I hear you. Have you tried using flow with react? I wonder how they compare.
What I liked about React is that I also got type checks in JSX (compiler tells me if the types that I assign to props are correct). I don't get that kind of type checks for angular2 templates. If I assign something wrong there then it blows up at runtime.
What I disliked about React is that the ecosystem doesn't embrace typescript. For most 3rd party components that I tried there were either no type definitions available or they were broken (which is often worse - because then you can't assign props that are actually valid).
For Angular2 at least the framework is already typescript-first (so we have automatically up-to-date type definitions through the compiler), and I would hope many 3rd libraries follow that design.
On the Flow vs Typescript thing, I evaluated both for this project, and almost went with Flow primarily because at the time, I liked that Flow felt lighter weight (it is truly "opt in" unlike TS, and getting the TS setup right was quite hard work), and I was also put off by the overhead of having to write .d.ts files (now I can create an "any" definition for a library in a few seconds, but at the time found it all quite time consuming).
However, I persevered with Typescript in the end, as I felt that some of the features it offered over Flow were worth the extra effort - specifically, the editor/IDE support (Atom with Nuclide for Flow was really unstable for me and the autocomplete still didn't compare to TS) and the fact that Typescript does a full compile of your code, so will pick up on things like mis-spelled imports, which Flow didn't seem to.
Also, I found documentation for Flow (beyond the basics) to be quite lacking, and there didn't seem to be as much community around it - for example, I just couldn't work out how to get it to check React propTypes, which was a pretty important feature for me. Bit of a shame, as its type system actually seems more fully featured than Typescript's (e.g. types are non-nullable by default), but TS's type system is certainly good enough.
I'd say go Typescript at the minute if it's a reasonably large greenfield project, but Flow might suit your needs if it's something smaller (whether that's in amount of code or in team size), or if you prefer the lighter touch/opt-in approach - for example, if you want to introduce it to an existing JS code base. I would definitely say it is worth the effort to go with one or the other, I'm not looking forward to going back to writing plain JS - having the compile stage makes refactoring in particular trivial, without the overhead of having to write loads of unit tests. In TS I'll refactor constantly as I go whereas in a large JS app, it's tempting to put off refactoring as you might miss somewhere and not know until it is QA tested (or the customer spots it is broken...).
We've started experimenting with systemjs and really like it (though support is a bit limited right now, plus it not really liking PhantomJS/karma), and we want to modernize our Angular 1.x app packaging/loading/bundling, but don't really want to do needless work if we have to move to another solution for Angular 2.x.
You can of course learn Angular 2 from lots of disparate blogs on the internet. There's lots of good resources. But the goal of our book is that you'll be able to learn everything, in-order, in one place.
We've been keeping the book updated alongside Angular's development (though it will take us a few days to get up to the most recent beta). We've already updated the book over a dozen times, so I think you'll really like it.
[1]: https://www.ng-book.com/2/
I haven't started using ng2 yet, but if I do decide to learn it i'll be purchasing ng-book 2.
They seem well prepared for the demand in Angular2 training :
https://egghead.io/technologies/angular2
It's a shame, because it does seem like both a very powerful and nice approach to building SPAs that I would love to contribute to.
Angular team is bunch of great people, real pleasure to work with. I can tell you - the initial effort to start contributing pays off _very_ fast.
Maybe I just had an experience of trying to get help at a series of slow times, but it was really hard to get help with the build setup.
angular2.min.js - 568K
Version 1.4.*
angular.min.js - 148K
File size really increased (Angular1 * 4 == Angular2), if compared with first version. Something went wrong.
Angular 1 is a fully fledged framework, you can use it on it's own, but 2 seems to depend on rxjs, and it's also bigger.
To me that seems like a step backwards.
It is based on ember CLI and helps a lot scaffolding new projects.
This is how you turn the most popular javascript MVC framework to nothing.
Edit: by popular I didn't mean that it's merely used by more people. I've clarified that.
So these languages exist precisely because life is short. Are they the perfect/stable solution? Probably not. But it's the right way to go.
You also don't need to use typescript with angular 2.
Angular 2, on the other hand, has so far been received very coolly.
I have a theory that many of the people who like Typescript came from a statically-typed background (Java, C#, etc) and don't like the loosely-typed world of Javascript.
More speculation: People who came to front-end development by choice are happier with Javascript than those who were transplanted from the server side and forced to convert to the One Language Of Browsers (ignoring transpilers, of course).
TypeScript is pretty popular and it does work really well. Writing larger applications in a team is much easier if there is tooling to assist you. With most projects, about 80% of the work is maintenance and tooling does immensely help with that.
All I know is when the first angular 2.0 beta came out, it was not well received by anyone including myself because of the vast difference in syntax (simple -> complex) which is the only reason I and a lot of others picked Angular in the first place. It seems it has been tweeked a lot since then, but those problems have not been fixed. I don't think next version of angular is usable for me.
Typescript's audience is far less than Angular's audience, there should be no reason to use typescript as the official example. This kind of bundling is similar to Microsoft explorer coming with Windows.
I work on a rather large Angular 1.4 codebase daily and while this is good news, I'm not sure how we'd ever upgrade to be honest.
There's a great blog post by the Thoughtram team here : http://blog.thoughtram.io/angular/2015/10/24/upgrading-apps-...
1. TypeScript - It's really nice to be able to use a typed version of JS, although it does feel like I'm writing C# sometimes! It supports lambda syntax / ES6 which is great.
2. Annotations seem a bit clunky, not really sure what the point of them is.
3. Absolutely love the functional reactive / RxJS stuff they've incorporated - it's going to make it VERY easy to write really powerful apps.
4. It's a million times easier to develop with than angular 1. $scope.apply anyone?
It's not hard to see why. This code[0] from Angular 2 would just be a function in React:
There's also the fact that Angular is a framework, whereas React is a library. Those of us in JS land typically (but not always) prefer smaller libraries.[0] https://auth0.com/blog/2015/09/03/angular2-series-working-wi...
http://qbix.com/platform
It was built with concepts from Angular 1 and React in mind. But it doesn't use either.
Especially this: http://qbix.com/platform/guide/tools#dom
Here is an example app built on it: https://github.com/EGreg/Overlay/blob/master/web/js/Overlay....
Edit; Sorry i meant Conway's Law https://en.wikipedia.org/wiki/Conway%27s_law
[1] https://meta.wikimedia.org/wiki/Cunningham%27s_Law
I just finished my first non-trivial app built with Redux + ImmutableJS a few days ago, and it was pure bliss. Finally, we're able to build entire applications as a mapping of pure state transitions on top of immutable data in JS. Redux is by far the biggest reason why I haven't yet completely abandoned JS for ClojureScript.
Edit response to person below (rate limit): there's no 'problem', just that mustache is still more familiar. Moving JSX into a different file doesn't change that.
So for example in case of parsed templates, to pass a callback to onClick you'd need to define a convention on how you're going to locate the callback by a given string (since you can't pass the function itself, you need to pass some "name" of that function). Whatever logic that will be, the result will not feel like React anymore because you're back to typical framework-specific template magic instead of using plain JS.
Putting behaviour in HTML is a bad idea. Leave it in JS, and have one place to go when the behaviour changes.
This is not what I'm doing. JSX is JS. I'm not putting any logic "in HTML". If I were able to express what I'm doing in mustache-style syntax, it would be:
Where `callback` is a reference to a JS function (rather than a string holding it's name).What's your ideal way of registering an onclick callback?
* With React & ESLint you get basic checks to make sure you're not passing non-existent variables
* Your IDE understands what you're doing and lets you jump to callback definitions
* You understand what you're doing because you have one obvious place where you do templating and data binding.
* Your actual behaviour logic is still separated from your template, living in some other JS file.
On the other hand, if you add event listeners to HTML from JS the classic way, you get other problems:
* You're querying the DOM tree by CSS classes or some custom attributes. It's surely a familiar way of doing things, but also fragile and unintuitive.
* It requires your JS to know the structure of your DOM to some extent, and that structure is defined elsewhere. So it's basically the same problem as with mustache templates – passing around magic strings – but the other way around.
* Neither ESLint nor IDE will help you do it.
(at least 1.x did)
At the end of the day you go one way or the other, my preference is the template not having the ability to affect logic as it is not natural to look thru templates to find what is mutating the state of your application. I liked Dojo and I think react is a step back in that direction which in my personal opinion is the right direction for large web application.
But I've learned to like it. React encourages you to keep components very granular and small and so the amount of markup in each component doesn't really get in the way I find. I've also learned to appreciate how easy it is to reason about what React is going to spit out onto the page because the view is right next to the logic that dictates the various states of the view. Feels very concise.
I still don't like the idea of it, but in practice it works quite well.
You can replace JSX by hand-coding with React classes - take a look at the compiled jsx and mimic that. I find it as easy to work with, and less cognitive dissonance [ a personal preference ]
I actually am looking seriously at Mithril in preference to React for my next chunk of work.
I might swing the other way if React native became stellar [ and viably crossplatform ]
Q: which do you prefer - this:
or this? A: handlebars.A: mithril.js
But you never write HTML with JSX, that's the point. XML like syntax is just sugar that gets transformed into functions. This is not HTML. With angular you need to use string templates which cannot be easily validated by IDEs for instance. JSX syntax validation is straight forward because it's directly integrated in the language.
If you don't like mixing logic into HTML you're free to create dumb components that only contain as much logic as you would want to put in a template. Such a component would accept properties and output a representation of the resulting HTML. A smarter component that does not generate HTML will provide the logic required for the template to function. That approach actually encouraged and is the right way to do React.
The bonus of this whole generate-HTML-representation-with-functions thing is that you pass around native JS values instead of stringified values and magic strings. Want to provide an onClick callback? Pass a callback. Not some magic string that represents a key which holds the callback in some object defined by framework-specific convention. No, you just pass a raw javascript function that will be run on click.
This might seem like a trivial distinction, but it's the difference between writing native JS vs writing magic framework code. I vastly prefer the former.
React mixes logic and structure, which causes no harm, because both are written and maintained by same developer.
All in all it is fairly similar, and feels pretty good. You have to remember more syntax, because of the configuration, but it isn't as conceptually difficult as Angular 1.x
The templating syntax is "weird", and it definitely adds to the list of things you have to know specific to Angular 2.
React and JSX is nice because logic is just JS, and not special template syntax (directives).
I'd be happy to build an app with Angular 2 or React for different reasons. What's hard is looking at Angular 1 now.
[0] I've given multiple Angular 2 workshops, built large scale Angular 1 apps, and build React components daily for my business (a popular web developer video tutorial site).
That is some very unsound advice. I find it worthy of ridicule that it's being suggested as a possibility.
The upgrade path was very necessary to address the huge amount of breaking changes.
Step 1: Include the Angular 2 and ng-upgrade libraries with your existing application
Is anyone with a serious application actually considering this? It would have been nice to include only the pieces of Angular 2 that you actually use. Instead, we have to ship both libraries, our application code and an additional plugin down the wire? I don't see this upgrade path as a legitimate option for anyone who cares about page load times.
Though initially skeptical of Typescript, I've found that Angular 2 really benefits from the advantages of having a coherent object model and optional type safety. Typescript never gets in the way, you can selectively use type declarations only where you want to use them. It's often helpful to leave them out while prototyping and then add them later when you want more robustness and easier debugging while you are working on writing the glue code and application logic that connects your various components.
As other posters have noted, you're still saddled with a lot of the artificial complexity and odd terminology that is pervasive in Angular 1.x. There are also bits and pieces of the library ecosystem, particularly the routing engine, that are over-engineered and painful to work with in practice. But, in general, I find version 2 much more intuitive and easier to reason about than version 1.x. Key features like data binding are much saner and behave more predictably.
I've never particularly liked Angular or React (my personal preference right now is for Vue or Polymer), but I think Angular 2 is a solid improvement over its predecessor. More significantly, I think the improvement is substantial enough to justify the team's decision to do a clean break.
No simple way around this, and no link I can see to go to .com instead. That's quite frustrating.
http://angularjs.blogspot.co.uk/
(Edit) No actually I spoke to soon. Even when the url doesn't redirect, the blog post is still in German for me! (Edit again) Must have been cached, it's in English now.
Previously used by google.com too, seems to be ignored now.
https://support.google.com/websearch/answer/873
If that doesn't work, try a private tab so that it doesn't use any previously-set cookies:
Firefox: ctrl-shift-p
Chrome: ctrl-shift-n
I wish the success of a web framework was a bit more about the technology nature of it rather than the market adoption and hype.
Here's a chart where you can see daily download counts for react, angular, and angular2.
http://npmcharts.com/compare/angular,react,angular2
React does indeed have about 4x as many daily downloads, but (Angular 1 + 2)'s download counts are ~5x what they were a year ago. (iirc the ng-europe RIP Angular fiasco happened in October 2014)
I've been loving using React. Building in components is fantastic, and it just feels like writing Javascript. That's a win in my books.
If Google was as invested in Angular as Facebook was in React, they would probably have gone with a more gradual, methodical approach to improving the framework (like the Ember team did). And until that changes, there is very little stopping them from doing another mostly incompatible rewrite in a few years.
As it stands, Angular 2 is closer to a completely new framework roughly inspired by Angular 1.x than a new version of Angular.
Google has said they have something like 10k Angular 1.x apps, so they will keep on working on Angular 1. Angular 2 happening along this support is showing that they're willing to invest in the conservative route and the "burn down the libraries" route at the same time.
The so called upgrade path they offer for Angular 1.x is a complete joke. That you can "mix Angular 2 into your existing Angular 1 application" would be a true statement with any component-oriented framework in place of Angular 2, like React, and Ember. And this was not true for Ember just a few months ago, which is living proof that gradual improvement can in fact be accomplished with any framework, but of course, throwing everything away is much easier, so the framework developers need to have strong incentives to not do so.
So I think Google will do it. Google Fiber is ng2 already :)
I'd argue Adwords is one of the most important Google products.
The point is that - despite the common misconception - Angular isn't Google's Anointed JS Framework. There's a whole bunch of Polymer and a whole bunch of GWT inside Google.
Maybe let's withhold judgement until we actually use it. Just a thought.
What exactly is your point here?
No one is saying "oh I love writing view layers. It's way better than actually building things".
If I am trying to compare the pros and cons of flying vs sea travel, a distinction between the fact that a ship is not an airplane isn't really important.
Two vastly different approaches can attempt to solve the same problem, and they're worth considering on equal ground.
On a side note, when people mention working with React, it's safe to assume (if they're building real software) that they are using React with a framework, whether that be some implementation of Flux or Relay or something else entirely. When comparing Angular to React / Flux you've got yourself an apples to apples comparison.
Angular is the airline flight(s), React is the boat. It won't get you all the way there on its own.
[0]: https://www.polymer-project.org/1.0/ [1]: https://developer.mozilla.org/en-US/docs/Web/Web_Components
react.c : Activity/Fragment :: web component : View :: web : Android
(???<_<)