5 ms·

Here's a litmus test for if you should use Angular or React: how do you feel about the fact that React has ~4 major routing libraries? I've written a book on b

Here's a litmus test for if you should use Angular or React: how do you feel about the fact that React has ~4 major routing libraries? I've written a book on both Angular 2+ and a book on React. I've talked w/ hundreds of developers on both sides and I can tell you that people with different constraints (and backgrounds) will have a different response. The author of this article cites "more ReactJS libraries on npm" to imply that React is the better choice. Some people love a la carte infrastructure and the power that comes from choosing each element in your stack. Some people love to have those decisions made for them, because they just want to build their app. It's often cited that React is "simpler" than Angular, and if you look at just the core that's true. But by the time you pick a data architecture, styling choice, router, etc. you're back at the same level of complexity. Actually in React, you've spent a lot of time researching which components you want (and if they'll even fit together). The pro here is that you get just the stack you want! The competitive evolution of these libraries means that you _can_ have 4 routers and pick the best. But also, if you'd just picked Angular, you just use their router and move on. Here's another litmus test: Do you want 'string' templates or JSX? (Now, I know it's technically possible to do either in both frameworks, but it's almost never done in practice.) Almost everything that seems "more complex" in Angular is a result of string-based templates. DI, AOT, the *ngIf and `let` syntax, is all because you're doing templates in strings instead of code. How do you feel about that? Would you rather write templates in JavaScript/JSX? Then use React. Do you have designers doing HTML on your team? Then use Angular. (Also the other opens by citing webpack, npm, and third-party libraries as a React-specific benefit, but that makes no sense because angular-cli uses Webpack, it's on npm, etc.)

albedoa 9y ago
> The author of this article cites "more ReactJS libraries on npm" to imply that React is the better choice. Some people love a la carte infrastructure and the power that comes from choosing each element in your stack. Come on, that is not an honest reading. The author uses those numbers to demonstrate the health and maturity of the respective ecosystems. The power of choice is a bonus for those who choose to leverage it.
- emodendroket 9y ago
  I don't think you're getting the point being made here. More choice also means more headaches like "do these two things work together?" which is not a problem in angular-land where you need very few dependencies that are not part of the core application.
  - albedoa 9y ago
    No, you don't understand. The GP said the author cited those numbers for that reason, but the author did not.
erichmond 9y ago
Our litmus test was that we invested years into Angular 1.2/1.4, and when 2 came out it was so radically different that we would have had to have effectively learned a new framework. At that point we switched to React. Everything you're talking about is great in a vacuum, but stable APIs and backwards compatibility is more important to organizations in the real world. I can't trust Angular as a framework anymore, as past actions are indicators of future behavior.
- atom-morgan 9y ago
  > it was so radically different that we would have had to have effectively learned a new framework. At that point we switched to React. Yet the end result was still the same. Another lesson in branding for Angular.
  - emodendroket 9y ago
    I still can't believe they looked at their framework reaching escape velocity and gradually becoming the thing to learn and decided to turn around and announce a backwards-incompatible framework with no migration path that took away two-way binding, the marquee feature that sold everyone on it. Of course they backpedaled on some of that but the damage was done.
eropple 9y ago
> The pro here is that you get just the stack you want! I don't disagree with the facts-on-the-ground of your post, but I think you're drawing a mighty false equivalency and this line highlights it. The pro here, for a React-based stack is that you are forced to understand the tools involved well enough to make meaningful decisions (if you're a competent developer). By the time I was done evaluating routing libraries, I was confident in my ability to write my own, effectively--and so I didn't have to because I was able to adopt the library of my choice's mental model immediately. If you "just want to build your app", your app is gonna blow up (not might, will, given a long enough timeframe) and you're not going to be equipped to fix it. Passive consumption is unwise for programmers. We've seen it bite people forever (be it the "all things come from Microsoft" era of .NET that they're just shaking now or the "Spring does it for us" era of Java or most of Rails pre-3.0).
- jashmenn 9y ago
  The history of technology is using the progress of others as a foundations on which to build something new. Once it works, it's a given, a building block. No one can understand it all the way down and we need to be careful about saying what 'real developers' do or don't do.
  - eropple 9y ago
    It's not a given at all. All of your abstractions break. These high-level abstractions break much, much more often than lower-level abstractions (because they try to encompass more, it's a surface-area thing). There are abstractions that are so fundamental to doing your job that you must, must must must, understand them at an implementation detail and then use them to improve productivity. The stump-dumb-simple routing layer of your JavaScript handwavey crap is one that You Really Just Gotta Know; it's literally central to everything you do in a SPA. And yet the overwhelming majority of AngularJS folks I have ever met--and, to their discredit, way too many keypuncher ReactJS folks, but a significantly smaller proportion--have no idea what to do if their web framework spits the bit. And my contention is that having to make choices means the likelihood of a baseline understanding of what chose choices mean is way higher. There are plenty of capable developers who work on and choose to use AngularJS. I've worked with great ones. But, like the other environments I mentioned before, it sure seems like they brought that capability to AngularJS rather than had that capability fostered by AngularJS in a pedagogical manner. And that's troubling to me, because these folks are going to be writing software that you and I depend on, too. I'm not hanging people for not being able to work meaningfully with the JavaScript runtime or understand how the browser works internally (though these are handy to know, most of my knowledge of JavaScript comes indirectly from embedding first SpiderMonkey and then V8 in a game engine once) or how their OS handles process segmentation to sandbox off their web runtime environment (not a super complicated topic but, sure, out of scope) or how their OS handles memory (this one, ditto) or or or--I'm saying you gotta understand the thing your hands are on all the time and that tools that attempt to swaddle you in a nice comforting "you don't need to worry about that" are gonna put you in a real rough place when that doesn't hold.
ivosaur 9y ago
> how do you feel about the fact that React has ~4 major routing libraries? I think it's worth mentioning that the API for the largest one of these (react-router) has had breaking changes with every single release, and takes a totally new approach to routing each time. So the question is more, 'How do you feel about changing your approach to routing every time you write a new app?' Or maybe I'm just too old and bitter for React haha
- dfcowell 9y ago
  Old versions of libraries don't disappear when new versions are released. You can npm install react-router@^3.0.0 and keep using what you know.
  - joshschreuder 9y ago
    Sure, if you're ok with having wildly fragmented documentation for all the different versions of the one component making it difficult to troubleshoot any problems you're having with your version, which becomes increasingly more out of date.
dfcowell 9y ago
There may be 4 different routing libraries, but the complex decision-making with React happens up-front, which may involve (at most) a day evaluating the options and making a decision. My biggest problem with Angular is the sheer surface area of the API and the dependencies between the different modules. Angular as a framework has 10+ different components, all of which are deeply integrated. All of this is wrapped up in Zone.js which produces some of the least helpful stack traces in history. A React app may be a composition of 4-5 key libraries (state management, routing, authentication and potentially a form helper) but each individual library has a much smaller API surface area and the decoupling makes it easier to debug. I recently rebooted a project that was built in Angular in React after over a week of trying and failing to debug a wide range of subtle issues in our implementation of universal rendering which absolutely broke AoT compilation. I won't deny that there's a high possibility that our code was the problem - it's just that there were no useful stack traces showing where to look and digging through the different libraries was a mission and a half. There's a lot to be said for composing a few independent libs with small APIs, rather than having a gigantic framework whose documentation is only skin deep.

albedoa 9y ago

> The author of this article cites "more ReactJS libraries on npm" to imply that React is the better choice. Some people love a la carte infrastructure and the power that comes from choosing each element in your stack. Come on, that is not an honest reading. The author uses those numbers to demonstrate the health and maturity of the respective ecosystems. The power of choice is a bonus for those who choose to leverage it.

emodendroket 9y ago
I don't think you're getting the point being made here. More choice also means more headaches like "do these two things work together?" which is not a problem in angular-land where you need very few dependencies that are not part of the core application.
- albedoa 9y ago
  No, you don't understand. The GP said the author cited those numbers for that reason, but the author did not.

erichmond 9y ago

Our litmus test was that we invested years into Angular 1.2/1.4, and when 2 came out it was so radically different that we would have had to have effectively learned a new framework. At that point we switched to React. Everything you're talking about is great in a vacuum, but stable APIs and backwards compatibility is more important to organizations in the real world. I can't trust Angular as a framework anymore, as past actions are indicators of future behavior.

atom-morgan 9y ago
> it was so radically different that we would have had to have effectively learned a new framework. At that point we switched to React. Yet the end result was still the same. Another lesson in branding for Angular.
- emodendroket 9y ago
  I still can't believe they looked at their framework reaching escape velocity and gradually becoming the thing to learn and decided to turn around and announce a backwards-incompatible framework with no migration path that took away two-way binding, the marquee feature that sold everyone on it. Of course they backpedaled on some of that but the damage was done.

eropple 9y ago

> The pro here is that you get just the stack you want! I don't disagree with the facts-on-the-ground of your post, but I think you're drawing a mighty false equivalency and this line highlights it. The pro here, for a React-based stack is that you are forced to understand the tools involved well enough to make meaningful decisions (if you're a competent developer). By the time I was done evaluating routing libraries, I was confident in my ability to write my own, effectively--and so I didn't have to because I was able to adopt the library of my choice's mental model immediately. If you "just want to build your app", your app is gonna blow up (not might, will, given a long enough timeframe) and you're not going to be equipped to fix it. Passive consumption is unwise for programmers. We've seen it bite people forever (be it the "all things come from Microsoft" era of .NET that they're just shaking now or the "Spring does it for us" era of Java or most of Rails pre-3.0).

jashmenn 9y ago
The history of technology is using the progress of others as a foundations on which to build something new. Once it works, it's a given, a building block. No one can understand it all the way down and we need to be careful about saying what 'real developers' do or don't do.
- eropple 9y ago
  It's not a given at all. All of your abstractions break. These high-level abstractions break much, much more often than lower-level abstractions (because they try to encompass more, it's a surface-area thing). There are abstractions that are so fundamental to doing your job that you must, must must must, understand them at an implementation detail and then use them to improve productivity. The stump-dumb-simple routing layer of your JavaScript handwavey crap is one that You Really Just Gotta Know; it's literally central to everything you do in a SPA. And yet the overwhelming majority of AngularJS folks I have ever met--and, to their discredit, way too many keypuncher ReactJS folks, but a significantly smaller proportion--have no idea what to do if their web framework spits the bit. And my contention is that having to make choices means the likelihood of a baseline understanding of what chose choices mean is way higher. There are plenty of capable developers who work on and choose to use AngularJS. I've worked with great ones. But, like the other environments I mentioned before, it sure seems like they brought that capability to AngularJS rather than had that capability fostered by AngularJS in a pedagogical manner. And that's troubling to me, because these folks are going to be writing software that you and I depend on, too. I'm not hanging people for not being able to work meaningfully with the JavaScript runtime or understand how the browser works internally (though these are handy to know, most of my knowledge of JavaScript comes indirectly from embedding first SpiderMonkey and then V8 in a game engine once) or how their OS handles process segmentation to sandbox off their web runtime environment (not a super complicated topic but, sure, out of scope) or how their OS handles memory (this one, ditto) or or or--I'm saying you gotta understand the thing your hands are on all the time and that tools that attempt to swaddle you in a nice comforting "you don't need to worry about that" are gonna put you in a real rough place when that doesn't hold.

ivosaur 9y ago

> how do you feel about the fact that React has ~4 major routing libraries? I think it's worth mentioning that the API for the largest one of these (react-router) has had breaking changes with every single release, and takes a totally new approach to routing each time. So the question is more, 'How do you feel about changing your approach to routing every time you write a new app?' Or maybe I'm just too old and bitter for React haha

dfcowell 9y ago
Old versions of libraries don't disappear when new versions are released. You can npm install react-router@^3.0.0 and keep using what you know.
- joshschreuder 9y ago
  Sure, if you're ok with having wildly fragmented documentation for all the different versions of the one component making it difficult to troubleshoot any problems you're having with your version, which becomes increasingly more out of date.

dfcowell 9y ago

There may be 4 different routing libraries, but the complex decision-making with React happens up-front, which may involve (at most) a day evaluating the options and making a decision. My biggest problem with Angular is the sheer surface area of the API and the dependencies between the different modules. Angular as a framework has 10+ different components, all of which are deeply integrated. All of this is wrapped up in Zone.js which produces some of the least helpful stack traces in history. A React app may be a composition of 4-5 key libraries (state management, routing, authentication and potentially a form helper) but each individual library has a much smaller API surface area and the decoupling makes it easier to debug. I recently rebooted a project that was built in Angular in React after over a week of trying and failing to debug a wide range of subtle issues in our implementation of universal rendering which absolutely broke AoT compilation. I won't deny that there's a high possibility that our code was the problem - it's just that there were no useful stack traces showing where to look and digging through the different libraries was a mission and a half. There's a lot to be said for composing a few independent libs with small APIs, rather than having a gigantic framework whose documentation is only skin deep.