I'm coming at this from the perspective of someone who has never used Angular 1.x or 2.x.
I guess the first thing on my mind is: can I make Angular 2 work just like React does? Is there any way to use it without making/(being allowed to make) separate HTML templates and CSS files? If not, this is a serious disadvantage. Having the view layer scattered across 3X the files (vs React) would make it very hard to follow the code in a large project.
Also, are there any real advantages over React that would be big enough for someone to consider pushing for a switch? If so, what are they?
One can use the @Component decorator with the template & style options - currently it seems to be the norm to do so, at least until the template compiler is understood more widely (it is pretty fresh), although long term having the template and styles in the same file probably will not be sustainable for more complex components.
Angular 2 has some serious perf advantages over anything else out there, reportedly up to 2x React in some scenarios (i.e. repaint perf). It also is set up for incremental rendering, as opposed to React's blocking rendering loop, which can allow for more flexible UX. With the new bundling system for Angular 2, I believe it is currently a fraction of the size of React (I think the Angular team achieved < 10 KB app framework size, although I haven't checked out the new npm packages to be sure).
React wins out on simplicity though, including how simple it is to communicate between components. React is also currently a lot more mature, with a much more mature third party ecosystem.
Edit: I stand corrected on the size, but the 10 KB minified & gzipped is the Angular team's goal I remember reading.
I read something a while ago that I think really sums the key difference, is that angular and other frameworks inject javascript into html and its awkward. React injects HTML into javascript, and it seems, that way around is a lot more powerful as you have all of javascript to manipulate html rather than having HTML/Templating/Extensions to manipulate Javascript.
The two advantages are speed (it's supposed to be faster) and its closer to the web component standard than react, so if/when web components become mainstream it could be a lot easier migrating from angular2. However, both of those wouldn't be my prime reasons for choosing a framework though.
I think a lot is preference. I think HTML in JS is dirty just like HTML in server side strings. Other people feel the opposite, that putting new tags which are similar to inline onclicks and other events that we moved away from w jQuery is dirty. There is truth to both.
Angular gives a lot of flexibility in code style and structure. You can componetize everything and have all your component files in one folder. You can inline it. Or you can go more MVC style folder structure like I do.
I personally like my html being approachable to junior devs and not being so chopped up and abstracted away from static HTML markup like it might be with React. Not sold on the new tag styles of A2 but I suppose it will just take some adjustment.
> Other people feel the opposite, that putting new tags which are similar to inline onclicks and other events that we moved away from w jQuery is dirty.
Not even remotely the same thing. HTML has a hierarchical structure which isn't a particularly good structure for a web application. Javascript syntax allows far more control over the hierarchy.
Your example is akin to saying putting a tank in an airplane is the same thing as putting an airplane in a tank.
> You can inline it.
Pretty thin separation between inline templates and JSX. But then, I've never understood why people think putting their template in a different file is somehow separation of concerns.
> I personally like my html being approachable to junior devs and not being so chopped up and abstracted away from static HTML markup like it might be with React.
Oh it's abstracted, with completely invalid HTML syntax and template variables. That's not to say that it's bad, I quite like the simplicity of the event/binding syntax of Angular 2. But JSX and Angular Templates are just two sides of the same coin.
Yes, isolated components with as few components being aware of the application state as possible. This is the fundamental structure if a redux app, which is effectively the point if Web Components.
Throwing on click tags or jquery selectors on a huge HTML document is not a good structure.
> Not even remotely the same thing. HTML has a hierarchical structure which isn't a particularly good structure for a web application. Javascript syntax allows far more control over the hierarchy.
I agree with you on the control but my point was that a lot of people that dislike Angular don't like the idea of putting tags on HTML elements which is very reminiscent to inline onclicks and the hackish approach to apps from yesteryear.
onclick="doSomething()" versus ng-click="controller.doSomething()"
Sure, there's a lot more under the hood with Angular but it looks and feels similarly and it scares some people away toward other approaches.
JS used to have a lot of inline code back in the day. Then jQuery came along and devs moved their JS into separate files but everything was still tied to elements and very frail. It was terrible for apps of any complexity. Now we have a ton of options and there is no consensus. However, maintainability is easier and building robust front-ends that don't break when someone moves a div or renames a class is not difficult anymore.
Angular is my favorite but I'm also liking what I'm seeing from Vue for a lot of applications.
I like that summary but I think it is dishonest. Angular doesn't use HTML, it uses strings with templates that use a superset of HTML with barely well-formed special attribute names.
And React doesn't use HTML either. It uses function calls that can be made to look kinda like XML by using a transpiler.
Neither puts HTML in JS or JS in HTML because neither actually uses HTML. Both build a virtual DOM: React does it explicitly with nested function calls, Angular does it implicitly using flat pseudo-HTML templates as strings.
React is really just a DSL for components that looks kinda like XML but if you consider React Native it is apparent that being able to render those components to HTML (on the server) or to the DOM is just an implementation detail of the renderer (i.e. ReactDOM, React Native, React Windows, WebGL, etc).
"Is there any way to use it without making/(being allowed to make) separate HTML templates and CSS files? If not, this is a serious disadvantage"
Translation:
"Can I sh*t where I eat? If not, this is a serious disadvantage"
Saw references to rc0 in the angular2-seed earlier - wasn't too sure what to make of that, as I still saw the beta in the main repo.
"This is the first release candidate that contains repackaging of Angular into individual packages one per each feature area. ... This changes how Angular is installed via npm and how you import the code"
This seems like a pretty big change to include as part of the first RC??
I realize a lot of companies flocked to Angular and it's used in a lot of places, but from the outside it seems to be fighting on two fronts.
1. Companies currently implementing it not wanting it to change or for there to be a quick and painless migration from 1.x to 2.x. So, less change, more hand-holding. The web changed a lot though, so its change is understandable.
2. Trendsetters and upcoming companies looking for something new fresh and solid: Framework competition from React and the like. Maybe that second group is a lot louder in certain circles, startup-y hackernews being one, but it sounds like Angular will eventually reside in the shadow of React if it stays that way for long. Google pulling the plug on things fairly commonly doesn't help with the uncertainty.
Just seems like anytime Angular comes up in conversation, React isn't far behind. This post is no exception I guess, I just can't see Google maintaining Angular if it becomes Dojo in the eyes of developers.
React lets you summarize your framework in a single sentence: make your UI a pure function of your model, but keep performance. OTOH, I still don't understand what the deal with Angular is.
I disagree. CSS animations work very well and offer better performance. You can maintain the animation lifecycle by the React lifecycle callbacks and use of setTimeout
CSS animations do not work when you need to morph
distinct components in complex coordinated manner. They are significantly slower then velocity js. Doing things available with quality solutions such as Ember liquid-fire are simply not possible.
On route transition you want to animate morphing
unrelated components between before transition components and after transition components. You will not be able to do this in functional manner.
You will not be able to do this with CSS animations. Example of how this is done with Ember liquid fire. https://www.youtube.com/watch?v=vq_BcIFM8Rc
Angular is an ORM for the DOM. With an ORM it's: "here's my model, figure out what to do to the database". With Angular it's "here's my model, figure out what to do to the DOM". Some people hate ORMs because there's too much magic, other's like them because they let one think about other parts of the app more.
How is Angular any different than React in the way that it allows you to bind models to the DOM? They're both component based, you have to specify the template and backing logic in both.
You can use Redux with almost anything including Angular 2. The purely functional manner is only an option if you Ok with providing subpar user experience (need to provide quality cross component animated transition that no side effects functional thing goes out of the window really fast). Given modern tooling the testing point is also a bit overstated.
I've used flux and redux in angular for years. You can write purely functional directives. Angular is much more than just a view library. I've built quite a bit in both react and angular.
React is not "eating Angular's lunch". The only reason it seems that way is that it is impossible to have a conversation about Angular on the internet without a horde of React zealots turning up and banging on about it.
Recommending React to somebody who's considering Angular is like recommending tyres to somebody who's shopping for a car.
React is eating Angulars lunch when you look at the amount of large enterprises that choose react over Angular.
Part of the problem with Angular that no one seems to care about is that Angular 2 was such a big change from Angular 1 it forced companies that depended on Angular 1 to do a complete re-write.
I was an Angular 1 dev and Angular 2 caused me to abandon Angular altogether.
Angular also adds more abstractions on top of JS which is unnecessary and can cause unexpected behavior when transpiled.
Angular is still a lot more prevalent than React in most of the world. A lot of the big companies using React also use Angular - it's not so simple.
Most companies are doing the responsible thing and holding off on worrying about migration until Angular 2 stabilizes more. Even if one wanted to do a complete rewrite due to poor Angular 1 app code, one can then evaluate all options from scratch and choose the best option for their app.
Every library adds abstractions on top of JS - React is no different with your complaint of unexpected behavior.
This reads as an overly emotional post without applying engineering - "this sounds too hard so I'll just run away to another solution" is the vibe I get.
Angular embraces two way data binding while React does everything humanly possible to avoid it.
I will also point out that Angular essentially re-implements JavaScript in the form of extensions to html. EG, if you want to iterate over something in React, you use map while Angular makes use of ng-repeat.
I've found that using :: to disable two-way binding where needed and using 'track by $index' in ng-repeat removes both of those performance concerns (in my usage).
I was surprised to find that Angular has a limited duration time window during which changes will update the view. In my case, symptoms were observed only after deployment, for user who had a high latency connection between their browser and the server.
One could mitigate this by calling $scope.$apply() after every change. But if you have to apply() all changes, then what's the point of having angular handle synchronization?
In our platform, we just let the developer call a function manually after updating the state of a tool. So it is event-driven reactive changes.
Yes, shockingly, we don't save those keystrokes, but we also don't have the elaborate dirty checking. The developer of a component is extremely likely to make sure during development that the update to a state has updated the view. Of course, you could just hook up React or VDOM or mirthril and it's totally complementary to what we do.
Ugh, this lacks any contextual reason on why one is better than the other. Dirty checking a model requires a direct comparison on every digest loop, regardless of whether or not the state has changed (because we don't know if the state has changed).
React runs its dirty check only after a state change obligates it to. As your model gets larger and larger, dirty-checking the model on every digest loop starts to have performance problems.
This was the case in Angular 1 - in Angular2, not so much. The component-tree structure (much like React) allows far smarter optimization on change detection - both with immutable data structures and observables - entire subtrees of components can be removed from the change detection step until the state notifies it of a change.
It is the million dollar question. If you are building a large product with an expected life of 10+ years, can you trust Angular to still be maintained?
I cant recall a single UI library / framework (with the solely exception of Jquery) to be mantained that much. In less than 5 years VR, AR will probably be mainstream, and UI technologies will probably to be revisited from ground up again.
Explanation:
In js land, Long term Support means "6 months". so your best bet is to have a framework which makes migrations easy and does not introduce changes.
With angular being backed by google, there is no guarantee if angular will be maintained 4 years down the line.
Angular 1.x has been around since 2009 - 7 years - that predates pretty much every framework in use today, before modules (commonJS, let alone ES6) were widely in use, etc. At some point, we had to make a decision to be forward looking towards the future of the language. Support for 1.x won't disappear for some time. Angular 1.5 had a number of big upgrades - a focus will be easing the transition to 2.x over time ( .component(), lifecycle hooks, etc...)
I think there is another problem. With framework the size of of angular is hard to maintain. It will be hard for others to take over if needed. With react's smaller parts every part (redux, react-router, etc) can be maintained by a small group of people. If some part isn't maintained anymore you can switch out that part. With angular you might have to rewrite the whole application. That is a risk I would like to avoid.
It is easy to expect that during 10 years, at some point this application might get completely rewritten...so not that important either, if we are talking about the framework longevity...
We've been slowly migrating https://splice.com from Angular 1 to Angular 2, so far it's been great. We switched to TypeScript, we cleaned up our code organization. We are writing new components in ng2 and migrating old code we we go. The betas have been somewhat painful with bugs and breaking changes, but that's the price to pay. When it comes to performance and consistency, ng2 is a big winner. Why not React you might ask? React is great, but having to figure out/argue for each piece of the frontend stack isn't something we were willing to do. ng2 has its quarks bug at least it comes as a whole and that's super useful for us at this moment.
Re: switching to TypeScript, manual rewrite or transpilation? My codebase is CoffeeScript, so I'm also interested to hear if you have any experience with that (with Angular 2).
My advice would be to compile your CoffeeScript to JS, then start from there. That's assuming that CoffeeScript still produces readable, idiomatic JavaScript...?
As of TypeScript 1.8(?) you can set an "allowJs: true" flag in tsconfig.json, which tells TypeScript to include JS files in your build.
Then you can just manually add type annotations and ES2015/2016 goodness to your code and change the suffix to '.ts' on a file-by-file approach.
I'm doing this at the moment with a fairly large AngularJS 1.5 project, using Webpack with awesome-typescript-loader as the build system, and it's working perfectly so far.
Progressive switch, we use TypeScript for new code and everything we touch old code, we try to convert from JS to TS. The tooling is amazing, even the skeptics in the team wouldn't go back to js now. Defining interfaces, using types really reduced the feedback loop and sped up our dev time.
The one thing that is wish is that templates could verified by the compiler instead of waiting for runtime (react uses views written in code and therefore you get that for free when using react + TS)
React and Angular are two very different experiences.
Using Angular 2 with TypeScript is almost like using WPF and C# on the desktop - it has that enterprise framework feeling - hierarchical DI everywhere, everything out of the box (DI, routing, events, forms, etc.), classes and OO are the foundation, decorators, even "functional" parts adopts RX from .NET. Using Dart gets you even more stuff working "out of the box" with a functional package manager and build system but it seems like that language might be a dead end so TS is a safer bet. Tooling provided powered by TS is top notch.
React is much more of a JS approach - sure the core library is smaller but in the end you throw in a bunch of libraries to compose your own framework and you're stuck with good old JS decision hell (should I use redux, which routing lib, etc.) - this may be an advantage if you you have a bunch of front end devs that like to sink time in to exploring the ecosystem and chasing the latest fads to keep up to date with what's being supported - but if you need a library to give to your corporate C#/Java devs angular would be my go-to. Coding styles are classic JS mix-and-match pseudo functional + pseudo OO.
Angular 2 feels slightly over-engineered but at the same time I'm more comfortable with this approach - even after using clojure full-time for 2 years - react feels too messy both from a functional/OO and ecosystem standpoint.
React is much more of a JS approach - sure the core library is smaller but in the end you throw in a bunch of libraries to compose your own framework
Thats the reason i decided against React. After so many years of programming i really like opinionated its so time consuming to figure out which major library component (*flux) will be maintained down the road and have enough momentum behind it.
And the combination of Angular2 with Typescript it really nice
I have done some small personal projects with React, Angular 1 and 2 just for learning, and I agree with your assessment. If I were building a production system with a small team of intermediate non-specialists, I would use Angular every time. For a front end dev, it's like comparing SASS (React) to Bootstrap (Angular).
They're both good at what they do, but they have different sweetspots in terms of the problems they're good at solving.
I agree, i also prefer an optionated Framework like NG2 in this case and i love Typescript. After 10 years as a webdev react and it's ecosystem feels like a step back to me in terms of maintainability of the whole thing if you have a really complex project. For smaller stuff, React is usually fine though.
That's true but it's not what I was getting at - Angular 2 is developed in TS - it's designed with TS in mind - everything is built on classes, decorators.
React is a mishmash of various approaches and tools - functional, OO, embeded markup, etc. You can get type definitions for it but it's not really "natural", for eg. support libraries just have terrible type definitions because they don't map to typescript type system nicely at all - which is what I was getting at.
Well, yes... and no. When I tried to use Typescript with React I couldn't help but feel like I was squeezing a square peg through a round hole. Eventually you can do it, but it's an effort. Ultimately you end up with something marginally better than plain JS.
Since virtually ALL available React tutorials, courses, quick starts, etc are written in JS, there is very little support out there for TS.
With Angular2, it's all TS all of the time. And, to me, that's incredibly important.
I knew it before opening the threat. What would the highest ranking post be, someone discussing the merits of Angular 2 or someone doing the usual "yeah nice, BUT REACT!"?
There are lots and lots of shops that - for one reason or another - don't care about React. And frankly for someone who works with Angular 1.x, React might just not be that interesting.
I was really trying to make a post before the post about React because I too saw it coming. More about the fact that I saw it coming though. I didn't intend on it to come off as "React is better, lets look this way instead", but a "I feel like this is unfortunately looming over Angular's head, here's what I think Angular's predicament is". Tomatoes potatoes, but I think it's an important distinction.
I think angular2 is a lot more interesting than angular 1.x and has a lot of merit, especially for a company wanting a "batteries included" framework, opinionated syntax or Typescript throughout. A lot of developers seem to hear angular and still think inefficient 2-way binding or 'enterprise-y' when that's not the case. The roll-out took awhile, bad timing happened, and there was initial confusion over migration. In the meantime 'some' developers found the next shiny thing without considering angular2 anymore.
They're obviously very different approaches and ecosystems so an AB comparison doesn't do it justice and the comment section of HN isn't a good place for that. I'm just commenting on the developer smell around the framework as I smell it today. Sorry if I came off as 'that guy'.
When I read up about Angular 2 a year ago or so, based on my very shallow understanding it seemed like the perfect combination of the automagics of Angular 1, and the light-weightedness of React. But what do you JS folks think about this?
What gave you the impression of light-weightedness though? My understanding was that Angular 2 is aiming at being a fully featured (and thus heavy) framework.
couple of reasons. one big one is flexibility. angular2 (er, @angular) runs on client, server, native (react native/nativescript) and we hope many other platforms in the future. this lets us packages for common dependencies for various platforms, as well as enabling us to not ship the template compiler for precompiled apps.
the other is providing a single entry point to each of those packages, which makes it easy to configure for rollup/webpack2 etc when you want to use the ES6 source over the CJS.
Since Angular 2 is so different from Angular 1 and there is not a universal solution to upgrade from 1 to 2, do you think there would have been a better PR/current user reaction if it was named something else?
I hear a lot about angular and that it has gotten quite a competition from react, aurelia and vue.
I personally will never use react. but i want to know, in which situations, it would be better to use angular and in which situations it would be better to use aurelia or vue.
This really comes down to your team - try them out and see what feels good for you. React is a great library, and as an angular1 dev before joining the core team, I learned a TON from playing with React and especially Dan Abramov and Redux - most of the same patterns are immediately portable to angular2.
Since angular 2 is very new (not even released) it's hard to have any experience from real projects. I have used both angular 1 and react for over a year each and I don't really see any projects where I would choose angular 1 over react except if that is what the team knows.
Are you going to maintain Angular 1.x for the years to come? Because Angular 2.x is a completely different framework and upgrading doesn't make much sense to me.
One thing that interests me about Angular 2 a bit more than React is the web components support.
With web components finally going native (surprisingly, led by Safari!), will Angular 2 see any big speedups, and will the size of the hello world app come down (200k is kind of huge)?
Also, I've seen a few tutorials on using Angular 2 with Polymer, but it seems complex. Is Google working on making these work together better? Will I be able to create Angular 2 web components and use them with Polymer web components?
I can't answer your other questions competently, but at ng-conf today, in the keynote [1], they announced improvements that drop Angular2 down smaller than 1.x, and that they have plans to continue
When I looked at the Angular 2 beta a couple of months ago, you needed to add es6 shim, angular 2 polyfills, systemjs and rxjs as well as Angular 2, just to get up and running and have a basic Hello World.
Contrast this to Angular 1, where the library on it's own with no dependencies will suffice.
Is this still the case? Are there plans to package Angular2 as a single minified GZipped library?
Lots more work to do here, but we're pretty happy with how the core looks! For those worried about size (which has absolutely been a fair concern over the alpha/beta process) - here's a "hello world" built with Rollup and our offline template precompilation. Clocks in at 200kb min/47k gzipped, with a bit more room from optimization over the next couple of weeks... https://ng2-compiler-test2.firebaseapp.com/
(yes, I know it's not the same under the covers - take it as a comment on the ecosystem, not on the implementation (although it can be a comment on dead code detection too))
FYI they said at today's ng-conf sessions that with the recent release candidate, they have cut that from 200K to 40K and that there's still more room to shrink.
I see a lot of complaints about toy app size/complexity. There's definitely a judgement call to makes about app complexity when someone starts a project with a framework. I inevitably find that development in the middle/end of the project is substantially easier when using a good setup like React/Redux/etc or Angular, and changes are easier to make, whereas vanilla development is (relatively) substantially easier at the beginning of a project.
Yeah, Hello World might be expensive in size, but when you've got a substantially complex and fast app for not much more size, you start to feel the real benefits.
But what is Angular doing with that 200k (which is minified)? It doesn't seem like I should need to pull in the whole of Angular to make a component with a template.
Granted, React is pretty big too, but other frameworks, like Riot.js, have shown that they can be much smaller. Then there's Polymer which gets smaller as web components roll out.
In the competition again native apps, web apps have to load really, really fast. Their ability to run without installation is an advantage that needs to be maximized, an on potentially slow and high-latency mobile networks.
The new npm packages have an ES6 directory included and use the jsnext:main pointer in their package.json files to allow rollup-plugin-node-resolve to pick up the ES6 distro as normal. I'll drop a note in that issue later this week after I've gotten some sleep!
I spent a whole bunch of time learning Angular1, was in a coma for close to a year after a bad accident, wake up and find my projects are all outdated and I have to basically learn a new framework. Decided if I was going to learn a new framework it was going to be something not made by google. React was simple to learn, unlike Angular. Everything you do in angular requires you to learn the "angular way", once you can create components and understand flux react is fairly straight forward and doesn't require you to re-learn web development.
Yes - you also make a great point about React, and switching to React.
We are talking about JavaScript frameworks, the keyword being JavaScript.
It is not as much of a sunk cost to switch to React because it is very JavaScript compared to Angular. Given that your team already knows JavaScript (probably, maybe, hehe) - they can pick up React fast.
And now looking at Angular 2, where people are suggesting writing Dart or TypeScript over ES6 - this seems like yet another unique Angular learning curve.
I'm happy to see Angular2 getting closer to a release, and as many other companies we are in the case of what decision after Angular1.
One thing I think will be a great push for Angular2 is Ionic2 which alone is reason enough but to be honest I prefer the `Aurelia way` when it comes to writing web apps which sounds more natural, Sad to see Aurelia hype haven't took much so far (understandable that it's getting harder to get people on board a new `revolutionary` JS framework).
I too like the look of aurelia. However, I really like the auto import management, refactoring, syntax highlighting. I use Webstorm & didn't see any blog posts or anything about how to set up Webstorm with Aurelia. So I'll go on learning Angular 2 for now.
I will go a totally other route than upgrading. I mean wtf. the JavaScript Part of Angular 2 is horrible.
Since I'm on a Scala Server I possible try to look at Scala JS and rewrite something.
It's too bad that our "application" fit's the SPA scheme so good, but these frameworks changes so much over the years that it's nearly not maintainable will a small group.
Unless you hate yourself I think it's best to with Typescript for Angular2. It is more natural with classes, and less verbose in the long run than vanilla js. Also you will find more documentation and tutorials geared towards the Typescript version.
No problem. People like you have to stick with the old stuff because of this mindset.
I mean WTF is bugging you? It's just code you have to write in order to get the thing running.
You could also complain about the empty object in the angular1 method.
From a limited perspective, writing code in angular can be a little jarring process. Compared to js in the browser and node, js in ng comes in the way of the thought process.
The code blocks written don't tell the whole story - the analog to the .Class is the controller in Angular 1, which one would have to specify a controller name or define it right in the component, therefore giving equivalent lines for the most part.
It sounds like the person is awfully resistant to TypeScript as well, as the syntax for a component in TS is just
Actually I'm not resistant to TypeScript. I just don't want it.
Reasons are:
- Google changes their mind so freaking often that it's simple not a good idea to follow them there. (Just look at GWT, good project however the direction is more and more confusing especially the communication is really really akward.
- Why changing to Angular 2 and TypeScript when there are way many other frameworks that are either in JavaScript or just a little bit better suited for some things?
- Why can't I upgrade in a slow path with small deprecations? (i.e. emberjs, react)
That are the most reasonable. Actually there are some others which has more something todo with our internal things and that ScalaJS < = > Scala is so good at the current stage.
Perhaps the question could be rephrased as: I am happy with how React handles my view layer. What more does angular bring that would make me want to switch, from React + whatever else I'm using as libraries?
I don't really think angular and React are direct competitors.
Half off topic but I want just to add that Webstorm IDE has already quite a good NG2 support. For example you can jump from html to a component function via F12 or auto import unresolved statements.
You see VS Code on many NG2 presentations. I think Webstorm helps more getting quicker into NG2. Also Angular-CLI helps a lot.
I mention this here because many people seem to struggle with the boilerplate code.
WebStorm has been pretty amazing in keeping up with us, a fair number of our team use it. Even more exciting is upcoming tooling integrations we'll get from Typescript - there's a cool GIF in this issue tracking the work https://github.com/Microsoft/TypeScript/issues/6508
I just love how the same people that called me the devil for using WPF back when .NET 3 came out are now calling me about angular with 'have you heard about this new and exciting paradigm?'...
I'm looking forward to trying this out. Having written Ember, Angular, and React apps now, I feel like they are all getting closer, but a lot of rough edges still exist.
Ember: interesting framework, but all too often, you would hear a team mate say "wait, why is that working, it shouldn't be?" Mixed with equal parts "logically, that SHOULD work, what am I missing?"
React: I love the component focus, and redux is pretty slick. However, the insistence on using JavaScript in lieu of helpful abstractions that clean up the code for easier maintainability, is frustrating. The whole point of JSX is syntactical sugar, but the team went with half measures. You also end up with a lot more plumbing code than the other two. Sure, I can reuse some of these components, but in truth, most of your components will be single use.
Angular 1: by far the easiest and most intuitive. Enough magic to make setup and a basic app easy, but not so much magic that you can't figure out why something is working. However, the more complex an app, the less Angular 1 serves. And you really need to use directives as a component, and follow a more react pattern, or you're going to have a bad time. Also, the dependency injection is a nice thought for simple directives, but when you're done, you'll very likely have so many dependencies being injected that unit testing becomes burdensome. And if it's burdensome, it won't be done as much as needed.
All that being said, if your app is primarily collecting data through forms, you can't beat angular. If it's highly dynamic, and you want a more native feel to your app, react is the clear winner. Ember is a neat, but I won't be using it again.
Angular 2 doesn't fix all of my complaints, but it's getting closer.
> However, the more complex an app, the less Angular 1 serves.
That's not really true.
The problem is that all three frameworks are supposed* to require the same discipline when it comes to managing state, but only React forces that discipline onto the developer.
I'm not saying React is better, but learning from React is important to be able to write maintainable applications in any framework. You don't want to have 30 services, each services managing there own little state in AngularJS for instance. Unfortunately that's usually what happens when an app grows with time.
Angular2 does seem to get rid of the dirty checking, allowing better performances. It also has a good router. But does it really bring something new in terms of view layer and state management, considering the cost ?
I like Angular1, it's one js file you drop in an HTML page, no need for nodejs, NPM, a third party language and what not. And it's mature. It's absolutely unfortunate that Angular2 basically forces developers to use Typescript. That's a huge mistake IMHO.
Isn't it ironic that, as we are moving away from fat servers, we are now writing even fatter clients ( which still need a server since one wants in many case to be able to render pages server side and one has to serve static assets anyway ) .
So what is the concrete difference between an API + a node-js server to serve assets and render templates server-side (so with a lot of business logic) + an angular2 client written in typescript , all this VS something like Rich Faces or Prime Faces in a servlet container ? We just rebuild the exact same thing that is hated by most "modern developers", with worse tooling on top of it. Both solutions need a third party language that is not Javascript, both solutions need a compilation step, and command line tools(or an IDE in the case of Java).
Some will say "Well, now the client and server are independent, and if the server changes, one can keep the fat client". But in practice, which side gets rewritten ? the server or the client with the "framework du jour" ?
Aurelia (http://aurelia.io) is the ONLY framework that I have seen where you DON'T see the framework when you look through the code. You see YOUR app and YOUR logic. To me this is incredibly important for the longevity and simplicity of your code base. Please people, do yourselves a favor and checkout Aurelia.
138 comments
[ 8.1 ms ] story [ 229 ms ] threadI guess the first thing on my mind is: can I make Angular 2 work just like React does? Is there any way to use it without making/(being allowed to make) separate HTML templates and CSS files? If not, this is a serious disadvantage. Having the view layer scattered across 3X the files (vs React) would make it very hard to follow the code in a large project.
Also, are there any real advantages over React that would be big enough for someone to consider pushing for a switch? If so, what are they?
Angular 2 has some serious perf advantages over anything else out there, reportedly up to 2x React in some scenarios (i.e. repaint perf). It also is set up for incremental rendering, as opposed to React's blocking rendering loop, which can allow for more flexible UX. With the new bundling system for Angular 2, I believe it is currently a fraction of the size of React (I think the Angular team achieved < 10 KB app framework size, although I haven't checked out the new npm packages to be sure).
React wins out on simplicity though, including how simple it is to communicate between components. React is also currently a lot more mature, with a much more mature third party ecosystem.
Edit: I stand corrected on the size, but the 10 KB minified & gzipped is the Angular team's goal I remember reading.
The two advantages are speed (it's supposed to be faster) and its closer to the web component standard than react, so if/when web components become mainstream it could be a lot easier migrating from angular2. However, both of those wouldn't be my prime reasons for choosing a framework though.
Angular gives a lot of flexibility in code style and structure. You can componetize everything and have all your component files in one folder. You can inline it. Or you can go more MVC style folder structure like I do.
I personally like my html being approachable to junior devs and not being so chopped up and abstracted away from static HTML markup like it might be with React. Not sold on the new tag styles of A2 but I suppose it will just take some adjustment.
Not even remotely the same thing. HTML has a hierarchical structure which isn't a particularly good structure for a web application. Javascript syntax allows far more control over the hierarchy.
Your example is akin to saying putting a tank in an airplane is the same thing as putting an airplane in a tank.
> You can inline it.
Pretty thin separation between inline templates and JSX. But then, I've never understood why people think putting their template in a different file is somehow separation of concerns.
> I personally like my html being approachable to junior devs and not being so chopped up and abstracted away from static HTML markup like it might be with React.
Oh it's abstracted, with completely invalid HTML syntax and template variables. That's not to say that it's bad, I quite like the simplicity of the event/binding syntax of Angular 2. But JSX and Angular Templates are just two sides of the same coin.
Is there a "good" structure for a web application that jumps to your mind?
Throwing on click tags or jquery selectors on a huge HTML document is not a good structure.
I agree with you on the control but my point was that a lot of people that dislike Angular don't like the idea of putting tags on HTML elements which is very reminiscent to inline onclicks and the hackish approach to apps from yesteryear.
onclick="doSomething()" versus ng-click="controller.doSomething()"
Sure, there's a lot more under the hood with Angular but it looks and feels similarly and it scares some people away toward other approaches.
JS used to have a lot of inline code back in the day. Then jQuery came along and devs moved their JS into separate files but everything was still tied to elements and very frail. It was terrible for apps of any complexity. Now we have a ton of options and there is no consensus. However, maintainability is easier and building robust front-ends that don't break when someone moves a div or renames a class is not difficult anymore.
Angular is my favorite but I'm also liking what I'm seeing from Vue for a lot of applications.
We can point our UX designer at this separate file and he can understand it, which would not be the case if it's buried in JS?
A component model is great though. Wicket is the library that gets it. Whenever I write Angular (or Django, or anything) I wish I was writing Wicket.
And React doesn't use HTML either. It uses function calls that can be made to look kinda like XML by using a transpiler.
Neither puts HTML in JS or JS in HTML because neither actually uses HTML. Both build a virtual DOM: React does it explicitly with nested function calls, Angular does it implicitly using flat pseudo-HTML templates as strings.
React is really just a DSL for components that looks kinda like XML but if you consider React Native it is apparent that being able to render those components to HTML (on the server) or to the DOM is just an implementation detail of the renderer (i.e. ReactDOM, React Native, React Windows, WebGL, etc).
"This is the first release candidate that contains repackaging of Angular into individual packages one per each feature area. ... This changes how Angular is installed via npm and how you import the code"
This seems like a pretty big change to include as part of the first RC??
1. Companies currently implementing it not wanting it to change or for there to be a quick and painless migration from 1.x to 2.x. So, less change, more hand-holding. The web changed a lot though, so its change is understandable.
2. Trendsetters and upcoming companies looking for something new fresh and solid: Framework competition from React and the like. Maybe that second group is a lot louder in certain circles, startup-y hackernews being one, but it sounds like Angular will eventually reside in the shadow of React if it stays that way for long. Google pulling the plug on things fairly commonly doesn't help with the uncertainty.
Just seems like anytime Angular comes up in conversation, React isn't far behind. This post is no exception I guess, I just can't see Google maintaining Angular if it becomes Dojo in the eyes of developers.
If it's more than copy-pasta then I doubt it will be received well.
And #2 is spot on -- React is eating Angular's lunch. I'd love to use it at work but I can't, and I don't think I'm the only one.
The Animated library (originally from React Native) gives you some pretty basic but powerful primitives to build whatever animation you need.
http://mithril.js.org/
Recommending React to somebody who's considering Angular is like recommending tyres to somebody who's shopping for a car.
Part of the problem with Angular that no one seems to care about is that Angular 2 was such a big change from Angular 1 it forced companies that depended on Angular 1 to do a complete re-write.
I was an Angular 1 dev and Angular 2 caused me to abandon Angular altogether.
Angular also adds more abstractions on top of JS which is unnecessary and can cause unexpected behavior when transpiled.
Most companies are doing the responsible thing and holding off on worrying about migration until Angular 2 stabilizes more. Even if one wanted to do a complete rewrite due to poor Angular 1 app code, one can then evaluate all options from scratch and choose the best option for their app.
Every library adds abstractions on top of JS - React is no different with your complaint of unexpected behavior.
This reads as an overly emotional post without applying engineering - "this sounds too hard so I'll just run away to another solution" is the vibe I get.
I mean, seriously, that's the main difference conceptually. You just modify some data structure and both frameworks will update some view.
I will also point out that Angular essentially re-implements JavaScript in the form of extensions to html. EG, if you want to iterate over something in React, you use map while Angular makes use of ng-repeat.
One could mitigate this by calling $scope.$apply() after every change. But if you have to apply() all changes, then what's the point of having angular handle synchronization?
Yes, shockingly, we don't save those keystrokes, but we also don't have the elaborate dirty checking. The developer of a component is extremely likely to make sure during development that the update to a state has updated the view. Of course, you could just hook up React or VDOM or mirthril and it's totally complementary to what we do.
React runs its dirty check only after a state change obligates it to. As your model gets larger and larger, dirty-checking the model on every digest loop starts to have performance problems.
Oversimplification can be incredibly misleading.
Good reading material by a team member - http://victorsavkin.com/post/110170125256/change-detection-i... and http://victorsavkin.com/post/114168430846/two-phases-of-angu...
An early beta comparo - http://www.roblog.io/js-repaint-perfs/angular2/opt.html vs http://www.roblog.io/js-repaint-perfs/react/opt.html - should probably update these with the latest RC.
Explanation: In js land, Long term Support means "6 months". so your best bet is to have a framework which makes migrations easy and does not introduce changes.
With angular being backed by google, there is no guarantee if angular will be maintained 4 years down the line.
PS: feel free to keep your million dollar.
> no guarantee if angular will be maintained 4 years
> down the line.
It's interesting to see that the reason why many companies choose Angular (Google backs it) now seems one of it's biggest disadvantages.
Even the earliest pre 1.0 releases of Angular weren't until late 2010.
Don't we all? I wonder if it's really worth it most of the time... That's assuming that new can be solid to begin with.
As of TypeScript 1.8(?) you can set an "allowJs: true" flag in tsconfig.json, which tells TypeScript to include JS files in your build.
Then you can just manually add type annotations and ES2015/2016 goodness to your code and change the suffix to '.ts' on a file-by-file approach.
I'm doing this at the moment with a fairly large AngularJS 1.5 project, using Webpack with awesome-typescript-loader as the build system, and it's working perfectly so far.
Using Angular 2 with TypeScript is almost like using WPF and C# on the desktop - it has that enterprise framework feeling - hierarchical DI everywhere, everything out of the box (DI, routing, events, forms, etc.), classes and OO are the foundation, decorators, even "functional" parts adopts RX from .NET. Using Dart gets you even more stuff working "out of the box" with a functional package manager and build system but it seems like that language might be a dead end so TS is a safer bet. Tooling provided powered by TS is top notch.
React is much more of a JS approach - sure the core library is smaller but in the end you throw in a bunch of libraries to compose your own framework and you're stuck with good old JS decision hell (should I use redux, which routing lib, etc.) - this may be an advantage if you you have a bunch of front end devs that like to sink time in to exploring the ecosystem and chasing the latest fads to keep up to date with what's being supported - but if you need a library to give to your corporate C#/Java devs angular would be my go-to. Coding styles are classic JS mix-and-match pseudo functional + pseudo OO.
Angular 2 feels slightly over-engineered but at the same time I'm more comfortable with this approach - even after using clojure full-time for 2 years - react feels too messy both from a functional/OO and ecosystem standpoint.
Thats the reason i decided against React. After so many years of programming i really like opinionated its so time consuming to figure out which major library component (*flux) will be maintained down the road and have enough momentum behind it.
And the combination of Angular2 with Typescript it really nice
They're both good at what they do, but they have different sweetspots in terms of the problems they're good at solving.
React is a mishmash of various approaches and tools - functional, OO, embeded markup, etc. You can get type definitions for it but it's not really "natural", for eg. support libraries just have terrible type definitions because they don't map to typescript type system nicely at all - which is what I was getting at.
Since virtually ALL available React tutorials, courses, quick starts, etc are written in JS, there is very little support out there for TS.
With Angular2, it's all TS all of the time. And, to me, that's incredibly important.
There are lots and lots of shops that - for one reason or another - don't care about React. And frankly for someone who works with Angular 1.x, React might just not be that interesting.
I think angular2 is a lot more interesting than angular 1.x and has a lot of merit, especially for a company wanting a "batteries included" framework, opinionated syntax or Typescript throughout. A lot of developers seem to hear angular and still think inefficient 2-way binding or 'enterprise-y' when that's not the case. The roll-out took awhile, bad timing happened, and there was initial confusion over migration. In the meantime 'some' developers found the next shiny thing without considering angular2 anymore.
They're obviously very different approaches and ecosystems so an AB comparison doesn't do it justice and the comment section of HN isn't a good place for that. I'm just commenting on the developer smell around the framework as I smell it today. Sorry if I came off as 'that guy'.
the other is providing a single entry point to each of those packages, which makes it easy to configure for rollup/webpack2 etc when you want to use the ES6 source over the CJS.
I personally will never use react. but i want to know, in which situations, it would be better to use angular and in which situations it would be better to use aurelia or vue.
With web components finally going native (surprisingly, led by Safari!), will Angular 2 see any big speedups, and will the size of the hello world app come down (200k is kind of huge)?
Also, I've seen a few tutorials on using Angular 2 with Polymer, but it seems complex. Is Google working on making these work together better? Will I be able to create Angular 2 web components and use them with Polymer web components?
[1] 9:02 mark in https://www.youtube.com/watch?v=gdlpE9vPQFs&t=9m2s
When I looked at the Angular 2 beta a couple of months ago, you needed to add es6 shim, angular 2 polyfills, systemjs and rxjs as well as Angular 2, just to get up and running and have a basic Hello World.
Contrast this to Angular 1, where the library on it's own with no dependencies will suffice.
Is this still the case? Are there plans to package Angular2 as a single minified GZipped library?
Thanks
Yeah, Hello World might be expensive in size, but when you've got a substantially complex and fast app for not much more size, you start to feel the real benefits.
Granted, React is pretty big too, but other frameworks, like Riot.js, have shown that they can be much smaller. Then there's Polymer which gets smaller as web components roll out.
In the competition again native apps, web apps have to load really, really fast. Their ability to run without installation is an advantage that needs to be maximized, an on potentially slow and high-latency mobile networks.
https://github.com/rollup/rollup/issues/280
Do you rollup angular or is it still an external dependency?
Honestly, there is so little continuity that you have the option of just switching to React.
Or perhaps, just maintaining your Angular 1 app - and then assuming the 1.x fork will be carried on for a long time.
That's what I did :)
I spent a whole bunch of time learning Angular1, was in a coma for close to a year after a bad accident, wake up and find my projects are all outdated and I have to basically learn a new framework. Decided if I was going to learn a new framework it was going to be something not made by google. React was simple to learn, unlike Angular. Everything you do in angular requires you to learn the "angular way", once you can create components and understand flux react is fairly straight forward and doesn't require you to re-learn web development.
Yes - you also make a great point about React, and switching to React.
We are talking about JavaScript frameworks, the keyword being JavaScript.
It is not as much of a sunk cost to switch to React because it is very JavaScript compared to Angular. Given that your team already knows JavaScript (probably, maybe, hehe) - they can pick up React fast.
And now looking at Angular 2, where people are suggesting writing Dart or TypeScript over ES6 - this seems like yet another unique Angular learning curve.
One thing I think will be a great push for Angular2 is Ionic2 which alone is reason enough but to be honest I prefer the `Aurelia way` when it comes to writing web apps which sounds more natural, Sad to see Aurelia hype haven't took much so far (understandable that it's getting harder to get people on board a new `revolutionary` JS framework).
Not the OP, but having to write four lines of code instead of one does not look that good. Less is more. Code bloat should be called out.
It sounds like the person is awfully resistant to TypeScript as well, as the syntax for a component in TS is just
That are the most reasonable. Actually there are some others which has more something todo with our internal things and that ScalaJS < = > Scala is so good at the current stage.
I am honestly intrigued as to what Angular2 offers, that other JS frameworks wont?
In my point of view react is easier to use while angular is better for testing.
My personal choice is angular. I'm really excited for v2. But both are super powerful.
I don't really think angular and React are direct competitors.
If your Angular 1 code is working well, doing any of the above would be stupid.
As far as I'm concerned, new JS frameworks are options for new projects, not existing ones.
I admit I've been a bit nervous about angular-cli calling itself still in alpha - probably a good time to take a look at it
Ember: interesting framework, but all too often, you would hear a team mate say "wait, why is that working, it shouldn't be?" Mixed with equal parts "logically, that SHOULD work, what am I missing?"
React: I love the component focus, and redux is pretty slick. However, the insistence on using JavaScript in lieu of helpful abstractions that clean up the code for easier maintainability, is frustrating. The whole point of JSX is syntactical sugar, but the team went with half measures. You also end up with a lot more plumbing code than the other two. Sure, I can reuse some of these components, but in truth, most of your components will be single use.
Angular 1: by far the easiest and most intuitive. Enough magic to make setup and a basic app easy, but not so much magic that you can't figure out why something is working. However, the more complex an app, the less Angular 1 serves. And you really need to use directives as a component, and follow a more react pattern, or you're going to have a bad time. Also, the dependency injection is a nice thought for simple directives, but when you're done, you'll very likely have so many dependencies being injected that unit testing becomes burdensome. And if it's burdensome, it won't be done as much as needed.
All that being said, if your app is primarily collecting data through forms, you can't beat angular. If it's highly dynamic, and you want a more native feel to your app, react is the clear winner. Ember is a neat, but I won't be using it again.
Angular 2 doesn't fix all of my complaints, but it's getting closer.
I appreciate this. The javascript world already has too many abstractions.
>Angular 1: by far the easiest and most intuitive.
How on earth do you find Angular more intuitive than React?
Angular is a behemoth compared to React. This is like saying Rust is easier and more intuitive than Go.
Angular 2 forced me to switch to React because it made me weary of Angular 3 and the new abstractions that that will bring.
It seems also that a lot more big sites are choosing react over angular and I see a lot more job postings for react devs.
That's not really true.
The problem is that all three frameworks are supposed* to require the same discipline when it comes to managing state, but only React forces that discipline onto the developer.
I'm not saying React is better, but learning from React is important to be able to write maintainable applications in any framework. You don't want to have 30 services, each services managing there own little state in AngularJS for instance. Unfortunately that's usually what happens when an app grows with time.
Angular2 does seem to get rid of the dirty checking, allowing better performances. It also has a good router. But does it really bring something new in terms of view layer and state management, considering the cost ?
I like Angular1, it's one js file you drop in an HTML page, no need for nodejs, NPM, a third party language and what not. And it's mature. It's absolutely unfortunate that Angular2 basically forces developers to use Typescript. That's a huge mistake IMHO.
edited
So what is the concrete difference between an API + a node-js server to serve assets and render templates server-side (so with a lot of business logic) + an angular2 client written in typescript , all this VS something like Rich Faces or Prime Faces in a servlet container ? We just rebuild the exact same thing that is hated by most "modern developers", with worse tooling on top of it. Both solutions need a third party language that is not Javascript, both solutions need a compilation step, and command line tools(or an IDE in the case of Java).
Some will say "Well, now the client and server are independent, and if the server changes, one can keep the fat client". But in practice, which side gets rewritten ? the server or the client with the "framework du jour" ?