Hacker News Reader

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.

Note that Typescript with React is totally possible.

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.

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.

I'm using ts-loader, have you tried both and found awesome-typescript-loader to be better? I'm trying to decide if I should switch to it..

This is exactly what we're doig.

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)

As someone that works for a #1 company, I am living that anxiety. We all know it will be inevitable, and we all know it will be hell rewriting it.

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.

Just out of curiosity what exactly can you do with React that you can't with Angular 2?

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.

That's sounds great but it does not really play out in a real world if you need to animate transitions to make UI look nice for example.

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.

Animations work really well with React!

The Animated library (originally from React Native) gives you some pretty basic but powerful primitives to build whatever animation you need.

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.

Implicit vs explicit binding.

React with redux allows to write most of the code in a purely functional / no side effects manner, which makes testing code almost a joy.

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.

What exactly do you mean? What is better then having a reliable, easy to write unit tests which cover most of the logic and run very fast?

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.

That's nice but then you don't have the "angular is the standard and I don't have to choose anything" advantage anymore.

But my code is more flexible, less dependent on the framework it's deployed in. So I can more easily survive things like "migrate to ng2"

And there will be something that will eat React's lunch soon too, just a matter of time.

React is not the only competitor either. Aurelia and Vue are there to make up for react's problems.

Mithril is also a pretty good competitor.

http://mithril.js.org/

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.

I have the feeling they're both just for a different crowd.

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.

React is just about dirty-checking the view, while Angular dirty-checks the model.

I mean, seriously, that's the main difference conceptually. You just modify some data structure and both frameworks will update some view.

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.

Oversimplification can be incredibly misleading.

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.

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.

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?

Can you trust the web as we know it to exist in 10+ years?

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.

short answer: "No".

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.

> With angular being backed by google, there is

> 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.

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...)

You're about 3 years out I'm afraid: https://github.com/angular/angular.js/releases/tag/v1.0.0

Even the earliest pre 1.0 releases of Angular weren't until late 2010.

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...

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'.

> looking for something new fresh and solid

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.