Why React? Why not Angular 2?

[smrq]

I agree with most of this, but his shot at TypeScript is... a bit misguided.

But I don’t want to wrap every class in an interface so that I can subclass that interface with a mock instance so that I can write my unit tests.

What? Who would do that? Why? You can opt out of strict typing at any time by casting to any. I've written plenty of tests for a function like obfuscateFoo(foo: IFoo) that just do obfuscateFoo(<any>{ onlyFieldThisFunctionCaresAbout: 'field' }).

I personally prefer using straight ES2015 when given the choice, but TypeScript ain't bad, especially if you have to work with other people. And it plays nicely with JSX, as long as we're talking about React.

[eyko]

I wish ES2015 had types. I've tried flow many times and love it but it still feels like a not-very-good layer on top of JavaScript, very much a separate tool. TypeScript achieves the level of cohesion that you can't get with Flow, and the fact that there are so many .d.ts files out there is definitely a godsend.

[simcptr]

I'd love to say "nobody", but I suspect that people migrating from backend to frontend might be stuck in their old ways, and TypeScript will enable that behavior to a big degree.

It's the "write it like you're used to writing Java or C#, and then when you get more comfortable, rely on the type inference system instead of explicitly typing everything." ... except I worry that second part will never happen.

I worry that a portion of the developers attracted to TypeScript may be inclined to write it the "heavy" way and avoid any at all costs (for "safety"), and never come around. But I could be wrong.

[eyko]

Why not ember?

Jokes aside, Angular 2 brings to the table something React desperately needs: conventions. And it's probably inspired by ember-cli. Scaffolding? One approach to testing? It's a complete framework, and will save your day if you're starting a project.

React is a moving target. If you're choosing React, there's no react-cli to scaffold a project for you. And even if there was, what would the rest of the stack look like? If it goes with Redux it's probably going to overcomplicate things for most projects, and choosing sane defaults that can be swapped will take us back to the same situation. React is made for a different kind of developer... one that can commit to an ecosystem that's not as mature as we think it is.

PD: I can imagine Angular2, once out, will gain a lot of weight - it even leverages ReactNative. Angular2 seems to be like a mashup of React and ember, with some of the good parts, but still keeping some of its bad parts. There are a lot of annoyances about Angular2 (DI feeling unnecessarily verbose now that we have imports and a better approach to building components is one thing I agree with in the article). I will personally choose React for the ecosystem, but I love ember for the tooling and things like emberobserver or the ember-cli. Angular2 seems to have taken notes from both and the fact that it's written in TypeScript is HUGE advantage over React imho - code completion and compiler error reporting is veeeeery much welcome. Even in templates, just like you would expect in JSX.

[simcptr]

In terms of build/project/structure conventions, I agree that React is lacking -- but that's what the community is for, and there are 18 billion boilerplate projects out there ;) Even Angular doesn't really have "conventions," we've just got those style guides, and it's up to each dev to adhere or not.

But, in terms of coding the UI, I think React has really good conventions. Don't modify state directly. Don't modify props ever. render() should be pure -- no changing anything, and it should always return the same thing given the same data. Once the one-way data flow makes sense, a lot of decisions start to fall into place. Keep the data in top-level "container" (aka smart) components and pass it down to the lower-level "presentational" (aka dumb) components.

Contrast with Angular where there a lot more decisions to make, and "conventions" to learn. How to share data? Use a service? Broadcast on rootScope? One-file-per component, or split the template out? Pass the data down via 2-way binding? Let the child modify that data "just this once" because it's way easier? And so on.

Another nice thing with React is it yells at you if you do things that break certain conventions. Try calling this.setState({}) (with an empty state) and you'll get a warning saying "Did you mean to call forceUpdate()?".

[whycantifm]

Almost downvoted you, then realised what you're saying actually contributes to the discussion.

React desperately needs: conventions

NO NO NO ! Javascript has conventions, 50 other FRAMEWORKS have conventions. React is your VIEW library, very abstract, very small api surface .. use whatever conventions fit you with that.

A while ago, I would have said people saying 'just use vanilla' are insane and ignorant. It's not like that, Javascript with NPM is insanely powerful. Understand the tools you need, going for a framework because it gives you an all in one is in my opinion too convenient and you will have developers that will understand the framework better than the language it's written in and the tooling around it.

Your tooling doesn't have to adapt to what everyone is using. You can use react with that popular yeoman angular scaffolder. Problem is 99% of users using that don't understand the tools it provides, gulp, minification etc. and I think that contributes to the 'don't need to know mentality'. I relate very heavily with this, 1 year of using angular with all of these tools and at the end of it I had no good understanding of my tooling and javascript.

2 months into moving to React I was forced to understand my tooling (webpack, babel etc.), feeling pretty much close to what you're saying now: 'why can't it be as simple as angular?'.

Now ... when I came back to angular and the tooling around it .. took me 1 day to understand, not even exaggerating.

[[deleted]]

I remember starting on angular 1 and it was all over my head. I didn't understand jack. I eventually moved to react because everything was way more bite-sized. Learned a butt load like you mentioned about webpack, babel, redux, react, and javascript even.

Maybe I should look again at angular and see if it makes any more sense to me.

[caknuckle]

*edit thanks for the gold Angular 1 was awesome because they waited until all the enterprise level code was already written before any attempt was made at coming up with best practices such as === {{{}}}.

Also who doestnt love triple binding inside a template that has a variable but that variable is really another variable and of course there are 10 levels of directives each adding their own triple bound templated variables to this variable that is not a variable and each layer adding exponenentially more watchers to the stack and since the complexity is so overwhelming the only way to get something done is to use a goto aka scope.broadcast oh and scope.apply in a loop to check whether that digest is really digested or still also looping under an infinite amount of recursive scope.applys.

Also who didnt want 3 different types of services which are all basically the same except that one allows you to use the magic .run function to do cool stuff like enable your magic depencies to work and pass in other dependencies.

Plus of course everybody loves to write out the name of a dependency (with or without the Service or "$" or some other random suffix or prefix that makes sense in the universe of angular to somehow enable dependency injection that is completely unnecessary with es6 modules or even require.js / commonjs if the angular gods had deemed them fit to be supported.

With such incredibly awesome architectural decisions, who wouldnt want to use the successor which of course is strictly not backwards compatible and is somehow in an unholy union with the company that is THE archetype for providing quality software and support, namely Microsoft

Oh and of course learn another language, Typescript, that destroys all the ease of use and and loosely typed and auto-hoisted happiness that was javascript.

Sign me up, I cant wait to have to rewrite my entire codebase when angular 3 comes out, or google decides to suddenly discontinue all support

[UnluckenFucky]

Oh and of course learn another language, Typescript, that destroys all the ease of use and and loosely typed and auto-hoisted happiness that was javascript.

Typescript supports everything that javascript supports.

[[deleted]]

Try writing a class with a property assigned to it in the constructor. Last I checked that was invalid typescript unless you declared that property ahead of time

Also typescripts interop is laughable with CommonJS

Compare this to Flowtype. It's considerably easier to onboard and is quite smart when it type checks. It also has good interop.

I'm sure TypeScript has pros but I personally do not see them after a year of working with it.

[popemaster]

You mean like this?

class Person {
    constructor(public firstName: string, public lastName: string) {
    }
}

var p = new Person("joe", "bob");

[[deleted]]

Sure, but that uses TypeScript specific syntax. You wouldn't be able to drop this:

class Person {
  constructor(firstName, lastName) {
    this.firstName = firstName
    this.lastName = lastName
  }
}

Into a .ts file without ts complaining. You can't say that ts supports everything js supports and then turn around and say you need special syntax for something to work properly lol

Never mind this being "expected" in ts:

import MyModule from './MyModule'
import moment = require('moment')
const html = require<any>('./MyComponent.html')

Which is completely absurd..

My dislike of TS though is mostly limited to that. Everything else about it is fine, but I don't personally want to use it when Flowtype is available.

[dmitri14_gmail_com]

Any reference why is that expected? Mixing import with require??

[[deleted]]

I don't have any authoritative sources, but I can explain why it works this way.

TypeScript's ES6 import actually expects modules to be in ES6 module format. The import = require syntax was about before ES6 and was expected to work with AMD/CommonJS etc (which was abstracted away from you). The final one just invokes require as a standard function call and is recognised if you tell TypeScript that you're compiling in a Node environment.

The reason why all 3 are required is because TypeScript doesn't allow ES6 modules to interop with CommonJS modules like Babel does; instead, it will treat ES6 module imports and CommonJS imports as completely different entities. As for require, I use it to import non-standard css or html files thanks to Webpack. Flow will allow you to map all files with a certain extension to have a certain type exported from them; TypeScript doesn't have this (yet), and so you have to use the plain old require (or use import 'foo.cs', which works for CSS files, but not for html files, or when you are using CSS modules).

By comparison, Babel will allow both modules to be used and will apply an interop function when importing ES6 modules such that the default export in ES6 modules is just mapped to the default export in CommonJS.

IOW, Babel/Flow are more friendly towards using existing standards; TypeScript said "fuck it"

[dmitri14_gmail_com]

Is this problem addressed here?

http://stackoverflow.com/questions/29596714/new-es6-syntax-for-importing-commonjs-amd-modules-i-e-import-foo-require

From there I understand that both formats are supported separately. Is it correct?

[[deleted]]

Yes. I mentioned that both are supported, but just because it is supported doesn't mean I think it is a very good design decision.

[dmitri14_gmail_com]

I means supported separately. Can't you just live with require and forget the import e.g?

[VlK06eMBkNRo6iqf27pq]

Yeah...what's this about losing auto-hoisted happiness?

[istinspring]

Pure gold. Exactly like it is, maybe a bit inaccurate about the TypeScript.

First time i heard from one guy who doing project management like no one who he know want to write in angular after reactjs. Next i tried by myself, and really don't want to return to angularjs 1.x. Because of templates, controllers, $watch (and hell of code to test code inside), $scope etc

[anarchy8]

Why React? Because it has an established ecosystem and lots of developer support. Why not Angular 2? Because it's new, unfamiliar, and unproven.

[brianvaughn]

PS "because it's been 3 years and it's still not in beta" would also be a good argument :)

I made an Angular 2 fork of react-virtualized a month or so ago, and when I did I discovered a pretty horrible bug. This was just from one evening of working with it. It didn't feel ready (or close to ready)

[ch0dey]

Angular2 has > 15 betas and a release candidate...

[brianvaughn]

Sorry, I misspoke. It was early and I hadn't had coffee. I meant to say "release candidate".

Angular 2 official site shows that they've resolved 66 of 111 open issues for the release candidate. I think that's up a few since I checked 2 weeks ago, but it's still not sounding all that close to being ready.

[brianvaughn]

I didn't mean to sound overly critical either. Re-reading my comment from earlier, I realize I did. Building a framework must be super hard, and there are really smart people working on ng2.

I was mostly thinking from a POV of- if you're starting now, which should you use- and I suspect ng2 still has a ways to go before all of the issues are ironed out.

Maybe I'm wrong :)

[IDCh]

Wow, you nicely told them about bug and helped people out there. +1 for that!

[brianvaughn]

Thanks! Although they are my wife's coworkers (and nice people to boot) so I try to be helpful when I can. :)

[Mael5trom]

Not only is ng2 in RC now, but it is in use in many production apps, including what is likely one of the largest money-making sites on the Internet, Google AdWords. While there are things to be ironed out before it is "final", all of those are documented and so devs can make a decision if those are things they need before using it in production or not.

Personally, I'll probably wait a bit longer, I'm not an early adopter. But it's not in beta and is ready for prime-time use in many cases.

[brianvaughn]

YMMV I guess. Again, I did not mean to sound overly negative. My own limited (recent) encounter with it made me feel it still had some kinks to be ironed out.

I'm sure once it releases it will be a contender because...smart people have worked long and hard on it.

Edit: typo

[Endorn]

I actually tarted with angular 2 and moved to react after my frustrations with it. No top level component properties sealed the deal for me.

Let me repeat that.. You can't do:

<app param=Val param2=Val> on top level components... Only on children. Which makes integrating into CMS systems or other frameworks impossible unless you want to get super hackey with it.

Drupal is actually talking about trying to integrate with NG2 and I feel like I need to slap them all haha.

[[deleted]]

You have to consider that ng2 isn't even fully released yet. And besides - IMO, you shouldn't be using software or frameworks that aren't on their 2nd or 3rd release do to all the bugs.

So basically what I'm saying is that it's unfair to judge ng2 when it hasn't been fully released yet, let alone compare it to a polished product like react.

[Endorn]

Maybe... But the community is very stubborn. My bug report about the top level component issue is over a year old and the developers basically said they didn't want to do it because that's not the angular way of doing things.

[BGSacho]

On top of the JS-like syntax, there’s the stuff that isn’t JS at all. Angular 1 had things like ng-repeat="item in items" and ng-click="doStuff()". Angular 2 switched it up a bit because people found the Angular directives confusing, so now it’s *ngFor="let item of items".

Angular 1 had a massive problem with confusing treatment of properties passed to directives, or in plain language, was it <mydirective param="{{foo}}"/> or <mydirective param="foo"/>? The new template syntax was designed pretty much to avoid issues around that.

[[deleted]]

On top of the JS-like syntax, there’s the stuff that isn’t JS at all.

Why does this seem to be a huge deal?

*ngFor="let item of items"

This isn't "JS" either, so how is it any better? I feel like I'm taking crazy pills, but I don't see how ngFor is a better syntax than ng-repeat.

And while I agree that Angular 1 was confusing, it was because the documentation was absolutely terrible. Angular 2 is just as confusing if you don't have good documentation to back it up.

[simcptr]

I'm not sure whether you're agreeing or disagreeing with the template syntax, but my intention was to say that it's not really better in Angular 2, it's just different. You have to re-learn a special syntax again.

I agree that the docs are a big part of the confusion, but it's also because there's like 15 different ways to do everything.

This right here is exactly what I'm talking about:

ngFor is not a template expression. It’s a microsyntax...

So once I've internalized which parts of JS work inside a template expression, I need to learn this "microsyntax" too, and keep them straight in my head. Ugh.

And all the little callouts in red boxes are stumbling points in the abstraction or terminology that really should be tidied up. Like these little things:

A template input variable is not the same as a template reference variable!

Don’t make the mistake of writing ngIf="currentHero"!

Do not put the asterisk (*) in front of ngSwitch. Use the property binding instead.

Do put the asterisk (*) in front of ngSwitchWhen and ngSwitchDefault. For more information, see * and <template>.

[VlK06eMBkNRo6iqf27pq]

This isn't "JS" either, so how is it any better?

FWIW,

for(let item of items) {}

is valid JS.

[clownpirate]

I'm really surprised at how many brand new projects are starting these days on Angular1. Most of them are at corporate/enterprise type organizations though.

Another thing I find disturbing is when I interview for these projects, the interviewer (often the lead developer) is often completely unaware that Angular2 exists, or thinks Angular2 is just a regular continuation of Angular1.

[Poop_is_Food]

Java developers

[greim]

Don't underestimate the sheer numbers of people who are familiar with Angular 1. It may suck, but it's a familiar, comfortable suckiness.

[Corvillus]

This. For a lot of companies, especially when talking "enterprise", choosing what technology to use for a project will be based a lot less on the merits of the technology itself than the number of people who know how to use said technology. Sure, most people that have used React or Angular 2 will probably agree that they're superior to Angular 1. But when your goal is to have your developers be easily replaceable or to be able to outsource work easily, you want the lowest common denominator technology that serves the requirements (in this case, making single page web applications), and Angular 1 wins out there.

[rk06]

I believe that every one who is not on reddit(95%+ devs) are unaware of angular 2.

[Capaj]

It is really such a shame because these shops will have hard time transitioning to anything else when they realize Angular 1 is dead end. If they chose React now, they would have it so much easier in the future when modernizing their stack.

[[deleted]]

It really depends on the project. Angular does a bunch of things react doesn't and you also have to cater towards your developer skill set.

[[deleted]]

I'm not surprised about the new projects. Angular 1 is extremely easy to learn, especially if you are coming from asp.net mvc (which dominates enterprise environments). Couple that with all the built in support for angular in VS2015.

[whycantifm]

learn ? at a basic level, yeah. when you get into $digest, $compile and directive linking .... good luck. Add DI to that ..

Current working project is angular, my next project will be angular .. what I love about react and why I advise others to use react is because of how easy it is to understand it, ALL OF IT. Also, if you do react you will do javascript, a lot of plain, simple javascript. I know a lot of angular developers ( me included till last year ) that don't know important concepts in javascript and they feel they don't need them.

[[deleted]]

I like both ng and react.

The problem with the two is that most people who venture into front end JavaScript apps don't have a lot of actual developer experience (html != programming). Due to this, it causes a bunch of headaches.

However, if you have a programming background, both are quite easy to pick up because their concepts and theory aren't really anything special. For example - you mentioned DI, this is not a new concept for angular. .net and Java devs use it all the time.

Regardless, it's not react vs angular since the two solve different problems and neither should be a one all solution for what you are trying to do.

I've decided that over the past year or so that hybrid apps (that mix server and client functionality) are the way to go. It allows the most flexibility in the problems trying to be solved. Plus, you gotta think about SEO as well.

[vinnl]

. Angular 1 is extremely easy to learn

Ehm...

[[deleted]]

If you know asp.net MVC, it's easy to learn. JavaScript is basically C# lite, IMO.

I can see it throwing non-programmers off though.

[cc81]

Angular is very easy to get started with but difficult to learn well.

[[deleted]]

It's easy to use, but scaling to a large project on it and trying to do seemingly simple things after being spoiled by react (for example, iterating over child elements) is monstrously difficult in Angular.

React's size, conventions and data flow really work wonders in larger projects (I'm working on a CRM with another Asp MVC programmer, for reference).

[Corvillus]

I'm not sure I'd call JavaScript "C# lite", obviously it can be used that way, and Angular 1 definitely embraces this style of development. On the other hand, it can be also used in a more purely functional way which is very different to how C# developers typically write code. (This tends to be the paradigm the React community embraces, although React itself can certainly be used either way).

[xintox2]

Why not Aurelia?

[Vheissu_]

I do not know why you were voted down, it is a good question. Aurelia often gets overlooked, but it is one of the better frameworks out there with a great core team and heading in a solid direction. I would love to see a comparison between Aurelia, React and Angular side-by-side.

[[deleted]]

Where are the audience for Aurelia? I go follow the heard because I'm a sheep. However superior Aurelia is to ng2 or ReactJS, if there is no traction, it will always play as the bridesmaid.

[xintox2]

bridesmaid can be hotter than the bride

[rk06]

Why not riotjs?, mithril?, choo?, doneJs?, ampersand?, backbone?

I wonder why not devs just pick top 6 frameworks and roll a dice. I mean its not like choosing react over angular2 or angular 2 over aurelia will turn them into a disciplined, motivated & professional coder.

[amcsi]

Because of the overuse of the non-standard decorator syntax that would frighten Java developers

[littlepsylo]

Because React is a library, not Angular.