It's not just Angular. To me it feels like everything in the JS world releases way faster than it's reasonable to keep up with these days.
It feels a lot more stable than before, where every project had homegrown framework stuff on top of backbone.js or jquery, or then using ember.js. There was just an awful lot of difficult discussion on how to design event-bus abstractions, global state management and general architecture
To me it feels like the frontend ecosystem has stabilized a lot, since the react paradigm is very robust and versatile. For most difficult problems, the solution is somewhat clear. Sometimes more, sometimes less elegant, but at least the timeconsuming disussions have become less frequent within a team
Asking because I'm just getting into React, and not really clear on best practice yet. You seem to know a thing and have an opinion; will you share them?
I don't understand why people bloody their foreheads on react-router. The thing it is doing is simple enough to re-do by hand in any application.
You see the same thing with flux implementations: flux libraries change rapidly, because there's not that much to the underlying concept and it's easy to mess with them. But most apps probably don't need flux at all.
Next also makes it easy to do server rendering and/or pre-rendering of routes.
* Route parsing: just use pathToRegexp. Yes, it's a dep, but it's an easy, well-understood one that does one simple thing you can get your head around. Or: don't use route paths with parameters at all (it's overkill for a lot of applications) and just use a trivial switch statement.
* Nested routes: why bother? The routes we're talking about are totally artificial. Having a formal, declarative route system in the first place is already a lot of "engineering". Just define your routes so they don't do that.
My argument is that the hand-hacked system that does this will be approximately as capable, future-proof, reliable and performant as the first production system anyone builds with react-router will be, the learning curve is shorter, the code you're building won't have APIs shift out from under it, and the final system will be trivial to port to react-router once that library stabilizes, if you ever wanted to bother doing that.
--React developer
As I said upthread, there's a spectrum of routing needs for applications. There are ways to use React (for real) where the server handles routing, because you're not running the whole app as a single page (but still want easy, clean dynamic behavior from React). There are serious applications that are single-page, but don't use a formal router because their application doesn't decompose into "routes". And there are applications --- not enough of them, if you ask me --- that just write their own routers, because 98% of what you need for a router can be accomplished in ~20 lines of code.
It's a similar story with Flux and Redux. Dan Abramov has been trying to convince people for years to start with just props and state and resist the urge to introduce a Redux dep before it's actually needed. He's not saying that to ease the learning curve. He's saying it because a lot of those apps will never need or benefit from Redux. For a lot of applications, Redux isn't worth the trouble. Moreover, just like with routers, the Flux pattern started with an idea about how to structure code, and morphed into a library dep. But Flux isn't about libraries! It's about code structure. It is not only possible but probably easier to structure your data in a Flux pattern without introducing Redux. The original Flux "library" was just EventEmitter.
It is in fact not fair to compare the API turnover for Angular to vanilla React plus two optional ecosystem components that aren't actually part of React. But more importantly, it's time to stop giving developers the impression they aren't building a "real application" if they don't have an extremely complicated router library and a whole bunch of thunks and reducers.
A thousand times, this. I am working on Redux-enabled app that answers "no" to all 5 of the questions to consider when trying to decide "do I have to put all of my state in Redux?" [0]
IMO it's now all so much more complicated than it needs to be. Admittedly this is my first exposure to Redux, but rather than "you might not need Redux" I'm leaning towards "you almost definitely don't need Redux"
Sure, you may not specifically need react-router or redux, but you do need to route and you do need to manage state. So you either build your own router / state management engine or you take one off the shelf.
Yes, I do think it's fair to say: If you don't need routing, you have a toy app or at the very least are annoying the crap out of users who try to bookmark things. React-router is not "extremely complicated". On the other hand, your homegrown router may very well be a few years of revision while you learn all the lessons the react-router team learned before building v4.
Redux is a different matter; I loathe it and do not use it. Component state is great! Until it isn't. Angular has a great story around this with injected components. React... well, you bring in a library like Redux or MobX or you do something else on your own. Personally I do "something else". But Angular has a clear story here, and you aren't saving yourself any code by using React.
There's more; fetch libraries and scss resources come to mind, as well as the whole build system itself. Not to mention the actual UI component libraries.
In my short year in the React ecosystem I've gone through quite a lot of version churn, just with all the libraries that surround React. It's real and I don't see this as a "benefit" over Angular.
Nobody ever built an SPA in production with just React.
There are no obligations whatsoever to keep your project cutting edge and even less of reason to migrate to a more popular framework. It's not as if browser support for Angular 1 would stop.