Hacker News Reader

JSX has zero community adoption? Or was there a missing comma in there? Of the React code I see, I would estimate that JSX adoption is high 90s.

I've used both Angular, played with Angular 2 and React. Plus many other MVC (and MVVM) libraries. I would say that the state managed React model is far more scalable than the traditional MVC 'observable' model. Sure, you can use immutability in Angular-2, but with React you have an architecture built around simplicity with the need to integrate different artifacts.

JSX helps React to scale because it extends type safety of TS or Flow into the UI DSL. JSX allows the developer to deal with the DOM as an object graph expression, right in the language. From a strongly typed perspective, this works much better than templates or embedding code into HTML.

You are obviously a thoughtful person who knows a lot about the subject than I do. I didn't mean to disparage the articles that make these claims. In most instances they go on to say some of the things that you just did. They do almost all start out by pointing out the V vs MVC distinction though, and I was just trying to point that out in the jokey spirit of the article.

>I think the tooling and approach it leverages fall in to a category that's prooven to scale with "enterprise grade" developers.

I think react is proven to scale too and it's being used by a lot more large companies than Angular 2.

Just a few months ago I tried to do the hello world tutorial on the angular 2 web site. I tried to do the javascript version and I couldn't get it to work. I then tried the type script version, still no luck. It wasn't until a while later when I tried again and they had updated the tutorial that I was even able to get hello world to run.

I've programmed some large web apps in angular 1 and while I never fully understood the depths of angular 1 I was still able to leverage the parts of Angular I needed to build fully functional apps.

Now coming from Angular 1 I feel like I'm in a somewhat new world. Then I tried react. It was simple, it didn't require me to completely re-learn everything I know about web dev. I wish I had tried react sooner. If it's good enough for facebook and the hundreds of other big websites that use it, then it's good enough for me.

I put "enterprise grade" in quotes on purpose. React stack (not React alone) being used successfully by a 9-5 Java or C# shop is not something I'd be willing to bet on.

Sure it's simple as far as hello world apps go, but once you start adding state management, routing, etc. you start seeing that it diverges from conventional architecture approaches. Not saying that's necessarily bad but it does not mesh well with enterprise development - I hope you understand what I mean by this.

And tools that help ensure consistency/quality in that kind of environment like TypeScript are very unsatisfying with React and various libraries, for eg. look how tedious Immutable.js typed records are, and check out typings for Redux related libs - bunch of any typed parameters and return values. Flux basically has no support outside of React and it wouldn't even run on Windows last time I checked.

So like I said - it depends on the context - if we're talking a bunch of JS frontend devs I'd say go for React if it fits what you're trying to do. If you're a .NET/Java shop Angular 2 is probably going to be a better fit, patterns like DI, OOP, etc. are all at the core and it's a full stack framework you just pick up and follow it's conventions/best practices/design decisions - way less decisions than React and way better docs (for the stuff not included in React I mean, React documentation is decent).

Enterprise? Beam me up, Scottie, there's no intelligent life here :-)

I have a pretty good idea of the -- "just following orders", OOP-factory strongly typed except for all the XML and annotations, never heard of FP, idempotent, immutable, nor higher order functions, etc -- kind of developer that "Enterprise" probably implies.

(I understand these people know ways to get some stuff done, and just want to go home, but holy cow it gives me a bad case of "COBOL fingers" and/or eye-strain working on those code bases -- spend some time to learn how to shorten things up, please)

That's not fair :) But it's true a lot of people just don't give a shit and will spend more effort avoiding learning than it would take to learn something so you're forced to cater to lowest common denominator.

I agree but I will just note that knowing about FP, idempotent, immutable and higher order functions does not mean a developer is able to create maintainable applications in a reasonable time frame.

I introduced React (alt as flux implementation) to a C# shop that develops internal tools within a large enterprise. We had one application before in Angular but people seem to like React much more and the uptake has been fast.

DI in Angular 1 feels different than in C# land and is mostly used due to a missing module system. That exists these days and that makes it easier.

Routing is the same. Most modern Angular guides even recommends you routing to directives and pretty much using them as react components to prepare for Angular 2.

But the biggest thing about Angular is that you need to learn tons of things that are NOT familiar to a .NET developer. scope, transclusion, different types of bindings (represented by strings ...), template language etc.

If they are not feeling familiar enough with the web to learn React then I don't think they can create a large angular application without creating a mess either.

Sorry when I say Angular I'm always referring to Angular 2 as I have no experience with Angular 1

    webpack, babel, babel-preset-es2015, 
    babel-preset-react, babel-preset-stage-2, 
    react, redux, react-redux, react-router, 
    react-router-redux, redux-thunk, redux-actions

Those provide the core you need in a react application imho... if you want a "service" abstraction similar to angular, you can use axios. Yes, there is slightly more boilerplate to setup when you get started... and understanding smart/dumb components and higher level abstractions takes a little work. Once you get past that, and understand how Redux's tooling works for building your state management, it gets simpler still.

In the end, there are FAR fewer surprises with React + Redux then there are with Angular 1 or 2. One of my single biggest issues with every angular project I've worked on, is that it's hard to find what you're looking for...

I see a string of "foo-class" rendered as part of the output in the browser, I go search for "foo-class", and I find it... It's in a .html file, now I need to find where that is referenced, find it... and now I'm looking at controller/directive for the foo.html... there's an attribute (directive) on one of the elements in the template... WTH does directive-foo come from? I search for "directive-foo"... not found... oh yeah, I have to search for "directiveFoo" to find it, again the templates are separate from the controller/directive, and this ball of mess continues...

In a react app, I find the top component, I want to know where FooComponent comes from, I see the import statement above, and go to that directory... the end. No searching for strings past the first search.

That's just tracing the rendering stuff... as for the logic, there's some disconnect there, but in the end, once you understand the rendering path of the components, vs action creators (which use services, redux-thunk), vs. modyifying the state tree (dispatch) through reducer(s)... in the end it's simple, easy to follow, enhance, extend, modify.

Working in a large (or even relatively small) angular app is an exercise in ever-increasing frustration... doing the same in a well-organized react app, much simpler.

That doesn't even go into the size of the min+gz libraries you start with in either/or. I have a preact+redux module/app that is a standalone datepicker modal control... in the end, 16.2kb min+gz [1] (the demo site, gh-pages wasn't compressed last I checked). The source[2] is pretty clean and well structured.

It's easy to grow a react+redux application organically... the same cannot easily be said for angular (1 or 2). And although Angular 2 is much better, I'd still prefer react + redux any day of the week.

[1] http://tracker1.github.io/md-datepicker/

[2] https://github.com/tracker1/md-datepicker/

I understand the feeling. I've had 13 years of experience with web apps and most of those were not SPAs, but I did get to build something with an early version of Angular 1. Recently I was looking at Angular 2 and React for a new project, but fortunately I stumbled upon Aurelia which feels far more natural to me based on all my web app experiences over the years. Having just the view portion of React was not enough for my needs and Aurelia isn't lacking anything I need for this project compared to Angular 2, plus I could eventually even use React with Aurelia if I ever felt the need. Aurelia plays nicely with lots of other tools.