Hacker News Reader

Comment by n0us | Hacker News Reader

I normally try to keep comments here reasoned and civil but the amount of churn in this library is almost so much of a joke that it should become a meme. At this point it's almost more expensive for me to continue updating than it would be to just fork the library and maintain the upgrades myself.

Any time I have to touch react-router I just resign the idea that I'm going to have to take at minimum a day to work out the bugs that pop up with every upgrade, (even minor changes).

> Why the huge change? (AGAIN?!)

> tl;dr Declarative Composability

The huge change is because the maintainers are apparently unwilling or incapable of either A. Creating something good enough on the first, second, or third attempt, or B. are completely oblivious to the needs of devs trying to create practical software and don't understand that project stability is just as important as a good API.

Thanks but no thanks.

View on HN

I know. I hate it when people learn stuff writing free libraries to support new technologies and then release upgrades informed by what they've learned.

I've watched React Router grow from one-of-a-handful-of-experimental-routers-for-React-on-GitHub to the most well-known third-party library in the React ecosystem (tied with Redux). In that time, Michael and Ryan have learned plenty. They've also taught plenty. Libraries that experiment with their APIs, like React Router and React Motion, help all of us understand how to wield React better. I learned how to use contexts by dissecting React Router v0, when they were still an undocumented feature.

I understand the frustration that upgrading creates. (My first React project was creating an isomorphic server - I was definitely sensitive to changes in the routing API.) Still, I hate seeing a whinefest every time a free library makes a change that an app author disagrees with. You're always welcome to {fork it, build/use something else, help maintain and give feedback on API direction}. Michael and Ryan are enormously friendly and welcoming to external input.

Trying to embarrass the creators or turn them into some sort of open-source pariahs helps nobody.

If that were true why the pathological method renaming between versions. Maybe this is the equivalent of a 1.0 and now they are finally going to keep things stable but how can you trust that "this time".

If what was true?

One of the things I admire about the tech community is their willingness to just give away their code for free. This is a cultural fact that has underpinned such an enormous collective gain of everyone in the entire world that I get genuinely worried when I see people get that mad at open source maintainers.

I look at the scientific community and their inability to share their data with one another out of paranoia, publishing incentives etc... it's not just bad for science, it's bad for their community - their ability to enjoy each other's company on a daily basis.

So you know - I just feel you gotta be kind to open source maintainers. They didn't break anyone's app. They just released new code that you don't have to use.

Also, there is one massive part here that people are missing. From the release notes:

>We intend to keep supporting the 3.x branch indefinitely (published separately on npm to aid in migration), although there will likely not be any future major versions based on that code. 4.0 is the future, but we won't leave you hanging if you want to stick with 2.x/3.x.

It's not like they are pulling what Bootstrap did and just leaving everyone on the old version out to die. They are going to be supporting the 3.x branch indefinitely.

If you don't want to move, then don't! It's not going to suddenly explode, they will still accept changes for that branch, and bug fixes will still happen.

In fact, 3.0 is still being developed. I just pushed out beta.1: https://github.com/ReactTraining/react-router/releases/tag/v...

Glad to hear it! I'd recommend putting more info on your support of 3.x/2.x in the FAQ linked here for when other places eventually pick it up.

The only reason I knew that was because I took at look at v4 yesterday when i was bumping up some of my dependencies before our freeze.

With the recent Bootstrap issues still fresh in many's minds, and the already bad reputation that many think the JS ecosystem is "doomed" to continue, it would help to really drive home the point that you aren't just hanging everyone out to dry.

The guy is pissed and he has a legitimate reason to be so; he doesn't try to embarrass anyone, I guess. The lib authors may be the most friendly guys of the city, it does not have much to do with the issue.

In all fairness, this is a problem that plagues the whole JS ecosystem and not just this lib, but it's no reason not to mention it anyways.

Nailed it - I really do not understand what it is about the Javascript ecosystem (and particularly the React part IMO) but comparing it with the Elixir ecosystem where the underlying language is probably evolving faster even than JS is, Jose and Chris seem to make 90% the right decisions up front and not have to make massive fundamental rearchitectures every 10 minutes.

It's classic shoulders of giants. Elixir is built on Erlang, a 30 year old language/system/community, and a vast array of knowledge on how to do functional/concurrent/systems programming.

Web apps were a completely different beast as little as three or four years ago. Despite the incredible progress of the last few years we still don't know the best way to go about architecting SPAs, of course things are going to be a little hairy.

Not trying to defend anyone here but I think you're making the wrong comparison. React (the library) isn't changing. Just like Elixir, JavaScript (the language) is changing for the better and almost everything is backward compatible. What folks are upset with here is react-router, an optional, third party routing library dependent on React. Authors should be allowed to improve their own projects otherwise they become stagnant as the libraries and languages they depend on evolve. It's why semver exists.

Much of React-Routers problems can be traced to the fact that it uses React components as its API. Yes, there's an alternative API in v3, but it doesn't seem to be very well thought through and is hardly ever used in examples.

Another issue with React-Router is that fundamentally in a web-based system, the router is the core of your framework (middleware, hand-offs to controllers/views, etc. are all built around the abstraction that the router sets up). With React-Router embracign React Components as their API, it means that your entire application must be built to the same abstraction---entirely within the React system, with components nesting other components.

I feel the problem of making a large javascript application client-side is best dealt with by keeping React as the view only, and putting everything else (router, dispatcher, models, etc.) in the form of another abstraction and not defaulting to component based architecture because that's simply what React does.

I agree. I don't necessarily want my routes to be declared in react. I'm currently looking into using router5 (https://github.com/router5/router5). The library also has integration plugins for react and redux.

Also, check out https://medium.com/@mweststrate/how-to-decouple-state-and-ui.... Michael Westrate talks about using your state container to control routing, instead of letting the components do it then syncing current route to state container. He is the author of mobx and uses it in his example, but I imagine it would work for redux scenarios too.

I've seen that article. :)

It came at a great time, in that it really crystallised some ideas I had been having about the friction of using React-Router. So I buckled down and wrote my own router component with HistoryJS & Crossroads.

Surely there's more fog of war when coming up with better browser-side abstractions than on the server-side.

> I've watched React Router grow from one-of-a-handful-of-experimental-routers-for-React-on-GitHub to the most well-known third-party library in the React ecosystem

> Libraries that experiment with their APIs, like React Router and React Motion, help all of us understand how to wield React better

If I read this correctly, you believe that it is still in experimental phase? I don't have any problem with people learning and experimenting, but using major release versions a your petri dish is obnoxious for all the thousands of people using react-router even if it is convenient for the core maintainers. There is a difference between an upgrade and an overhaul, with the extent of the changes over V2,3,4 they might as well have just released a completely new routing library or just maintained an experimental branch to figure out what actually works before releasing a series of major breaking changes in quick succession to the greater world. I'm aware that breaking changes are necessary sometimes, but rapid churn is not necessary, esp once you are post 1.0 release. If there were some burning reason to release an upgrade then that would make sense but this release does not even address some of my major pain points with the API.

I also am not complaining about the cost and personally I don't see any validity in the "it's free so I am beyond reproach" mentality that open source people seem to have. What makes you think that I would thank someone for something that was free even if I didn't want it? Or that anyone would for that matter. Thanking people regardless of what they did, just because they did it for free, is one way to erase market signals which govern the direction of open source projects. I would rather just be candid and honest so that maybe people will remember that me and other devs in general are negatively impacted by breaking changes and therefore will consider keeping projects stable.

I also didn't "try to embarrass the creators" and the only person on here to made this personal was you, who decided to name the maintainers by first name.

Or you could just not use it, or follow your original thought and fork it and maintain the older version. It's MIT licensed, so you're more than welcome to do whatever you want.

Instead of doing any of the things that'd require work (like the creators did), you insult them. They must be oblivious or awful at software, right?

> The huge change is because the maintainers are apparently unwilling or incapable of either A. Creating something good enough on the first, second, or third attempt, or B. are completely oblivious to the needs of devs trying to create practical software and don't understand that project stability is just as important as a good API.

> personally I don't see any validity in the "it's free so I am beyond reproach" mentality that open source people seem to have. What makes you think that I would thank someone for something that was free even if I didn't want it? Or that anyone would for that matter. Thanking people regardless of what they did, just because they did it for free, is one way to erase market signals which govern the direction of open source projects.

Damn. Most of the time people follow their reasoning with, "I am paying for this, so do the stuff I want exactly how I want." But, This is the first time I've seen someone using the free-market to excuse being a dick to someone who's giving their work out to the world for free. The amount of entitlement mentality in this person is so unreal, I'm literally almost exploding in rage here, because I can't believe anyone would treat anyone else like that.

To the maintainers: 99.999% of people out there are not like this person, and we appreciate your work very much. Thanks for putting that work out there. Your effort is also unreal, but a kind version of unreal!

I know. I hate it when people learn stuff writing free libraries to support new technologies and then release upgrades informed by what they've learned.

I think there is some responsibility incumbent on the person implementing the library to actually vet the library for good design and pattern implementations, to ensure they are not adopting someones learn as they go projects (if that is an issue they are trying to avoid). This seems to be endemic in the JS space, as an example, I was surprised at how many people jumped on Angular 1.0 give it's serious design flaws that where evident with just a cursory look at the overall architecture of the software.

Routing stateful apps using string URLs is not a solved problem. Which thick-client app gives you a universally shareable string that restores it to a specific predictable state? How is it even possible? It took a confluence of web technologies, however ill-wrought, to make that possible today.

No one has yet figured out a clean abstraction that solves this - yes it is hard to imagine that we still have new problems that were not solved in the 1960s by the Greats. This is not a computer science-y problem; it falls into the spectrum of craft and art than science. It'll be beautiful when it is framed correctly and an elegant solution comes out. From the looks of it, the authors of this library (along with the rest of the client-side router ecosystems) are the closest.

The FAQ satisfactorily answers why they are trying this approach - React brought the concept of 'mounting' UI elements, and it applies equally well to routing as well.

I do share the pain of having to keep up with a changing API; and it is especially biting when it feels gratuitous (which I think is not at all the case here), but let's chalk it up to the cost of being in the bleeding edge, working in one of the most well-paid professions in the world.

This is a really logical and thought out response. The evolution with React Router isn't meaningless. It's simply good people trying (and succeeding imo) to innovate and create good, well-formed software.

JavaScript as a language has a lot of churn, and many times unnecessarily, but there is nuance.

The only API that works well and give you all the flexibility is the one that the browser exposes. If you stick to something that is close to how the browser behaves, you should be fine.

In the React ecosystem I have seen that people sometimes want to abstract too much with no real pragmatic advantages. The result is that the abstraction become verbose to use and get in the way for coding things that produce a better user experience. Things that used to be simple to build.

Keep it simple. Make it more complex only when it is necessary.

All fair points, but we still have the problem of giving our users a URL to our rich web app which can take them into a node inside a nested state hierarchy. And not all applications can be purely server-side. You can't for example build a spreadsheet on the web as a series of request-responses.

> but let's chalk it up to the cost of being in the bleeding edge, working in one of the most well-paid professions in the world

Slightly off-topic, but I have observed that front-end engineering posts seems to have lower salaries compared to back-end engineering posts for the same level of seniority. My working theory is that there is a higher supply of front-end devs - most of the self-taught devs I've encountered work on the front-end (Flash -> HTML/Javascript, or Designer -> dev).

It all depends where you live and what is considered front end or web developer. In NYC if frontends get paid less it's only $10k less at most. They're still making up to six figures with less than ten years of experience.

> Routing stateful apps using string URLs is not a solved problem. Which thick-client app gives you a universally shareable string that restores it to a specific predictable state?

Google Maps seems to have solved a version of this problem. There is a unique URL for every position and oriention of your view of the world, including street view.

But even then it doesn't log you in as the user who sent you the link. (That would be crazy.) The link will probably also not include any user-specific display preferences. If Google Maps had a "kilometers from you" widget in the corner, you would not expect that value to be reconstructed from the URL.

So really URLs are not keys to the entire state of the app. They represent a "location" which is both abstract and very specific to the application.

Personally I think of the URL as just another input to the state of the application, really not that different from user events, HTTP responses, etc.

I'm with you. I'm so sick of this library. About the only thing they got right the first three times was the name of the package yet they have dragged everyone through countless iterations of regurgitated API churn to keep it instead of just creating a new one.

Maintaining react-router and keeping up to date for a production site is a full time job I don't want.

I realize I sound like the a whining open source leech but there is a huge opportunity for a stable library to emerge and capture mindshare here.

Where is Facebook during all this? Someone needs to step up and solidify this critical react ecosystem component and it seems like it should be them. Obviously.

Per comments from the React devs, Facebook handles routing needs with their own internal stuff. They don't use anything like React-Router themselves, so they have no need to build or open-source something like that.

One thing worth adding is that along with Redux, React Router has been vocally blessed as the right solution by Facebook employees. This means it occupies an unusual position within the ecosystem in that it's a de-facto standard, and fairly critical to many projects.

It definitely suffers from a documentation problem (the new examples are genuinely great, but previous versions were very light on practical examples and best practices).

Thankfully, I've never had to deal with routing in any of the applications I've worked with. (Primarily internal stuff that is true "applications in a browser", rather than stuff addressable by sub-URLs.) So, I've managed to avoid all this complexity. Wasn't until relatively recently that I even understood what client-side routing actually involves.

Personally, I think that routing in general is one of the major causes of "Javascript Fatigue", and is proof that building complex software is inherently complex.

I will say that despite its "de-facto standard" nature, there's certainly a number of other options out there. I keep a list of Redux-related addons and utilities, and there's a couple dozen entries in the "Routing" category (https://github.com/markerikson/redux-ecosystem-links/blob/ma...). Again, I haven't used any of them myself, but they exist. And that's _just_ "libs that relate to routing and Redux", much less "libs that relate to routing and React, or routing in general".

There is now ui-router-react, the React version of UI Router for Angular, an extremely popular router for Angular 1 - it is such a defacto solution for Angular that even Google uses it, and the core got extracted to be agnostic to Angular.

https://ui-router.github.io/tutorial/react/helloworld Look promising!

If you are interested, this is what my team uses and it works REALLY well for us. It uses the standalone Express 5.0 router, so any pattern that works in Express works here.

https://github.com/wesleytodd/nighthawk

2.x and 3.0 are not deprecated at all. We're working on another release of 3.0 in fact (hopefully a beta before we go to final 3.0.0). We plan on supporting that version indefinitely, as there is a whole ecosystem of projects and libraries that depend on it. We're not pulling the rug out from underneath anyone and running 3.0 isn't "running the old version".

4.0 represents what we think is a great building block for routing in React applications. But it is not a hard requirement to use it. We think people are going to be more jazzed for 4.0, but there is so much stuff built around 2.x/3.0 that it would be moronic for us to force you into this new structure.

Please, keep your deps at "react-router": "< 4.0.0" if you want to. You won't be penalized for doing so, I promise you.

It's a little late now, but I might suggest in the future of that rather than radically change an API interface, even between major versions, you launch it as an entirely new package. While I really appreciate the work that you guys have put into this library, I think what everyone is really frustrated about is the heavy change between versions. This creates a lot of logistical headaches and perception problems that have upstream consequences, some technical and some political.

I was just talking with an acquaintance who's at a company that invested millions of developer-dollars in cutting-edge tech. 7-10 years later, after a long period of a few developers keeping everything together with duct tape, the whole thing is getting thrown out.

Why? Well, some of it's solid code. That might be worth keeping. But some of it's technologies that fell out of fashion. And there's a bunch of stuff that people wrote in a frenzy, so there's a bunch of tech debt. And even if they stripped it down to the bones, there's a lot of upgrading to do just to get back to where they could do new work with modern libraries. From the business perspective it was easier just to glue together a bunch of outsourced services.

I'm sure those developers all meant well by picking cutting-edge tech. But as Dan McKinley says, we should generally choose boring technology [1]. As you describe, the costs of keeping up with interesting things is substantial. On rare occasions, it's really worth paying that cost. But, mostly, as with my acquaintance's company, the costs can accumulate while your attention is elsewhere, pushing code bases into a sort of technical bankruptcy.

[1] http://mcfunley.com/choose-boring-technology

What would be the boring technology to pick for starting a web + backend project today?

python/ruby/java on backend. React/Ember/Angular on front end. The core libraries are relatively stable, it's mostly supporting libs that will burn you if you aren't careful.

Probably PHP and plain JS, which is why I think that argument doesn't make sense. New web stuff is currently so much better than the old alternative that dealing with tumultuous stability is often worth it.

I think there's a middle road. What you're mentioning is pretty extreme. Rails/Django/Spring and Angular/Ember are all considered boring and very stable while not nearly as outdated as your example.

Is it? I used to happily make very complex sites using Apache Wicket on top of Java. It lets you make composable, extensible components (including inherited markup). It is type safe (the cools kids are finally rediscovering how important this is for maintainability with Flow & TypeScript). It supports replacing components using AJAX. Sure, it's not great for client-side SVG rendering or the various other cool things you can do with React and co, but hand on heart, I can't honestly say I find doing all this stuff in JavaScript to be "so much better". Quite the opposite for the majority of intranet-type sites, in fact.

Care to show me your math on that over a 10-year time scale?

I'd be curious even to see it for the technologies you mention. But as others point out, there are plenty of things newer than PHP that have become pretty boring.

java

Several boring but good things

Spring Boot (Java) is really simple and boring yet a lot of capabilities underneath

Also, ASP.NET (c#) - similar deal

Django or Flask (Python)

Backbone.js, jQuery, Bootstrap (JS front end)

Express (JS backend)

Sinatra (Ruby)

PHP 6

Maybe Angular or Ember or even basic React+Flux in the front end if you can contain your enthusiasm

For hosting, find a boring PaaS and avoid the container mud wrestling

For pity's sake use PostgreSQL or MySQL, MongoDB burns

Django or Flask (Python) Express (JS backend) Sinatra (Ruby)

What would you suggest out of these for quick prototyping and just side projects?

Postgres and Flask. Create it as a package, not an individual module. Front-end it with gunicorn and nginx. All monitored by supervisord.

https://realpython.com/blog/python/kickstarting-flask-on-ubu...

Flask is awesome, sure, but you will have to do a lot of mundane stuff with Psycopg2 (may all gods help you if you choose to dive into sqlalchemy!). OTOH, Rails ORM is awesomely simple and just works for 95% of the cases.

Bottle (Python). It's very minimalist and tries very hard to get out of your way, but it usually provides enough for prototyping and quick spur-of-the-moment things.

The latter is also when you might appreciate the fact that its markup language is really just embedded Python (PHP style) - you're trusted to not abuse the power, but you define what "abuse" is.

There is no PHP6. Went from 5.6 to 7.

Yeah I meant PHP 5.6 , my bad

For my first project ever on Java - I did an API on Spring Data Rest and connected to a db I designed on Oracle (requirement).

I was pleasantly surprised at how much functionality I got for free once setup. I probably spent as much time on setting up Oracle and xml/config stuff as dev but it was still super fast to get a solid API built.

I really like how you, tomca32, and nous all are suggesting multiple language/framework options. I think a lot of the way these technology choices go wrong because people want to pick the best option, rather than a good-enough option that matches local conditions. The former strikes me as a local, narrowly focused tech optimization; the latter, looking at the bigger economic picture of the project.

Rails on the backend. Angular on the frontend. Both are big, stable frameworks with tons of support, plugins, thousands of tutorials / SO Q&As. Whatever problem you encounter with those, somebody already solved it.

This is the case with any mature framework. Rails and Angular just happen to be my favorites, but Django, or Spring and Ember can probably work just as well.

Angular 1 to Angular 2 anybody!?

If you are using Rails, Angular is rarely necessary from my experience. Even if you have a lot of SPA-type functionality, jQuery can handle it pretty well in the asset pipeline.

I agree with that. I felt that the question really asked what frontend boring framework would I choose, but you are right.

I try to avoid having to put up Angular or anything big on the frontend and just scrape by with jQuery. However, when the interactions are supposed to be "rich" and have a lot of animations, drag/dropping, complex forms that validate on the fly, etc etc...things can get really complex. Then you're back to the old dilemma: you are either going to introduce a full-fledged framework, or write one yourself. In those situations, I pick Angular.

- Angular 2 also looks fine, but that defeats the question which asked about "boring", stable frameworks

Rails and jQuery. Seriously. This is at the top of list of the most maintainable, well documented web app methods that exist.

One of my favorite articles. Also another argument for why we need a boring, stable, un-opinionated, cross framework compatible routing library.

> At this point it's almost more expensive for me to continue updating than it would be to just fork the library and maintain the upgrades myself.

Ok...what's holding you up?

I get the frustration, but if you like an older version you learned, just stay with it and maintain it yourself. Or do your own thing completely with another routing solution. Or roll up your sleeves and write your own. Maybe in a year, if the new version still looks like the way to go, put in the effort to switch over. You have a multitude of options.

People act like the authors of the library are intentionally toying with them. And this is for something that presumably no one has paid for!

The sense of entitlement that erupts every time some non-contiguous jump in progress happens is the far worse meme, to me.

Also, they will be supporting the v3 version of the code "indefinitely". So it's not like he/she would even need to fork the project to continue to support the old version...

I've been using react-router 0.13.4 for almost a year in a project and it works perfectly. I found no reason to upgrade and am now glad I didn't bother.

Same here. I don't understand why people always feel like they need to have the latest and greatest version, and then complain when shit breaks.

How about this: if it ain't broke, don't upgrade.

No way, I can't do that! I'll get ridiculed for not being on the latest and greatest, and if I complain and take shots at the people building critical code for me to use for free, I'll get pats on the back by my peers!

Magpie-Driven Development at its finest!

I have to agree with that.

The javascript ecosystem in general is extremely fragile.

I have lost weeks and weeks worth of time investigating how X and Y silently broke again.

And I say that as a hardcore webdev who is very well familiar with Javascript.

Sometimes just makes me want to kiss it goodbye and go back to server or backend development for some sanity and stability.

> I have lost weeks and weeks worth of time investigating how X and Y silently broke again.

How does code just magically break on it's own? Either you did something wrong, or you're keeping details back. Code doesn't just work today and not tomorrow on it's own.

Stop blaming others for your mistakes.

My guess would be he/she did not lock the versions in package.json, but used "wildcards" (I consider `1.x` a wildcard.) Happened to me once, took about a day to figure out. I really dig `Gemfile.lock` in Ruby land for this purpose.

So I was correct in saying they did something wrong. :)

npm follows semver and expects libraries to do the same, whether they do or not is up to the library author, but npm can't know if the library does or not. Therefor the user didn't pay attention to the library they are using and blindly installed it and set constraints that caused breaking changes to get into their code. Once again, not the ecosystems fault, but the developers fault.

No you were not, what I was referring to had nothing to do with locking down version numbers.

I said "fragile". That doesn't mean something wasn't objectively "my fault".

Yes the bytes don't change themselves, I was the one making some changes here and there so in that sense it's my fault. But that's a very mechanical and shallow way to think about it.

Javascript as a language and ecosystem makes it extremely easy to create mistakes. In that sense a mistake that I make is partially Javascript's fault too.

Some people look at what I said and think "programming languages need to be better" and some think "humans need to be better".

The people in the second group don't help moving things forward. They just blame people for not being "smart enough" until the people in the first group set a new standard for what things should look like.

I'm with you. First when I thought of building a SPA application with React on my side project; I tried React-Router, the API was not that easy to grasp at first for me.

Then I have build my own router with `popstate` event and I'm quite happy with it. All the navigation history is pushed to redux. It turns out that it works really well for my needs and application.

Have a link to your router?

Sorry, no. However, you can find the same pattern being used in the sound-redux project-https://github.com/andrewngu/sound-redux

We did something similar that uses the Express router: https://github.com/wesleytodd/nighthawk

The one thing we didn't do was layer on top of a flux solution. Seemed more future proof to not tie to anything other than a routing style. If you wanted to do that with our solution it would be as simple as writing an action to do the url change.

I built a React app for a large Ecom site recently using the same strategy. It handles all URL updates with the History API, and simply AJAX loads the same URL with a query param to hydrate the app with JSON. Works really simply, and doesn't require Redux, Flux, or React Router.

>The huge change is because the maintainers are apparently unwilling or incapable of either A. Creating something good enough on the first, second, or third attempt

Well, it was "good enough" to be the #1 used solution and be adopted by almost everybody in the ecosystem, even if it wasn't "perfectly nailed" the first, second, or even third time. So, there's that.

If there are some better developers out there that can do it better and with less churn, where are they, and where's their project?

>B. are completely oblivious to the needs of devs trying to create practical software and don't understand that project stability is just as important as a good API.

Well, given the rate of churn in the NPM world, they aren't unlike anybody else...

This is one of the major reasons I try to stick with more well established libraries when I can. For example, when choosing our teams universal routing solution, I used the Express router instead of going with the NEW SHINY react router.

Of course this did mean wrapping it for use on the FE, but that was as easy as copying code form Page.js (another old school project).

https://github.com/wesleytodd/nighthawk

If you're sick of the churn, I've been maintaining Andrey Popp's original React-Router-Component [1] for the last few years.

It's a simple router that hasn't changed much. I've tried to keep it extensible and simple.

1. https://github.com/STRML/react-router-component

You guys should switch to Ember, you never will have this problem and you get the best router ever. :)

Maybe should switch to jQuery, then no router was required. lol

Yeah, instead of this problem Ember will give you other problems:

https://www.google.com/search?q=site:https%3A%2F%2Fwhat.thed...

>At this point it's almost more expensive for me to continue updating than it would be to just fork the library and maintain the upgrades myself.

I got burned by this in my last big project, we resigned ourselves to never upgrading past 1.0.0-beta4.

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)

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

In the large scheme of things, is a day that big of a cost to move to a newer routing approach?

React Router and the problems dealing with minor updates was one of the several libraries(around 6) that sparked me to write the Sad State of Web Development

Do you have a better suggestion for a routing library at the moment ?

and imagine my surprise when I found out Node 7 exists already

sounds like hell!

Yep. I feel javascript library authors forget it's lines of code spent, not lines of code written. How would they feel about a contractor who had to rebuild their house 4 times? "Oh, they're really good about revving their design, this is great!"

Nope, library authors are trying to create a good product. When they fail, some of them try again. I'm an open source author myself, and comments like this make me think twice before sharing something. Maybe it's better I just keep that code to myself and not bother with the whole community thing. ;-)

I think a more apt analogy would be a public book library that gets rebuilt 4 times. On the 4th time though they built it alongside the old building instead of demolishing it.

Reply on news.ycombinator.com