4 ms·

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

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

Roboprog 10y ago
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)
- rubber_duck 10y ago
  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.
- cc81 10y ago
  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.
cc81 10y ago
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.
- rubber_duck 10y ago
  Sorry when I say Angular I'm always referring to Angular 2 as I have no experience with Angular 1
tracker1 10y ago
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/ http://tracker1.github.io/md-datepicker/ [2] https://github.com/tracker1/md-datepicker/ https://github.com/tracker1/md-datepicker/

Roboprog 10y ago

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)

rubber_duck 10y ago
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.
cc81 10y ago
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.

cc81 10y ago

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.

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

tracker1 10y ago

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/ http://tracker1.github.io/md-datepicker/ [2] https://github.com/tracker1/md-datepicker/ https://github.com/tracker1/md-datepicker/