3 ms·

There's a big difference between breaking changes which resolve real pain points in a language/framework/library, like the break between python 2 and 3 and chan

by n0us 10y ago

There's a big difference between breaking changes which resolve real pain points in a language/framework/library, like the break between python 2 and 3 and changes that are just for the fun of it, because someone "felt like it was better". I like to view developing software as an investment. You are spending time and money outright, and there is an implicit cost in foregoing other opportunities when you make a technical choice. Investing in react-router is like investing in a clown. It's a total toss-up. The maintainers could all move on to whatever other hip lib and finally it will be stable, or you can continue betting large sums of money on what is basically a coin flip every 6 months: Are they going to screw with the library again (yes) and will it cause a bunch of bugs in my program (probably). It's a bad investment, esp if you try to upgrade. The ironic part of this is that honestly I feel like the V1 API is the best out of all of them. If they had just iterated and brought breaking changes that were actually needed instead of just those that they felt might be fun, the project would be much better for it in my opinion. (I know python <-> react-router comparison is apples to oranges but bear with me)

danabramov 10y ago
I empathize with your frustration but please consider that changes in RR were not done "for fun". They were done to solve plenty of use cases that few (any?) routers in JS ecosystem ever had to deal with (universal rendering, avoiding waterfall of requests, animations). Solving each of these problem introduced some awkward APIs, but the community demanded them with a passion just like in this thread. We all built and learned. This rewrite is motivated by: (a) knowing the spectrum of use cases, (b) throwing out non-composable APIs that made it hard for everyone to extend the router, (c) eliminating a class of bugs caused by router trying to "orchestrate" everything instead of letting React do it. It was not obvious to the authors how to do it from day one. It was not obvious to me or anyone else. Everything is easy in hindsight ;-) It's sure rewarding to solve these problems for the authors, but this has nothing to do with "fun" and everything with creating something future users won't hate. All the churn in previous versions was caused by router fighting with React. Now it works together with React. Let's see how it pans out. And if you're pessimistic, keep using RR3, it's going to be maintained for a long time (you're not the only one using it ;-).

by n0us 10y ago

danabramov 10y ago

I empathize with your frustration but please consider that changes in RR were not done "for fun". They were done to solve plenty of use cases that few (any?) routers in JS ecosystem ever had to deal with (universal rendering, avoiding waterfall of requests, animations). Solving each of these problem introduced some awkward APIs, but the community demanded them with a passion just like in this thread. We all built and learned. This rewrite is motivated by: (a) knowing the spectrum of use cases, (b) throwing out non-composable APIs that made it hard for everyone to extend the router, (c) eliminating a class of bugs caused by router trying to "orchestrate" everything instead of letting React do it. It was not obvious to the authors how to do it from day one. It was not obvious to me or anyone else. Everything is easy in hindsight ;-) It's sure rewarding to solve these problems for the authors, but this has nothing to do with "fun" and everything with creating something future users won't hate. All the churn in previous versions was caused by router fighting with React. Now it works together with React. Let's see how it pans out. And if you're pessimistic, keep using RR3, it's going to be maintained for a long time (you're not the only one using it ;-).