Why I Don't Use React Router

Recognizing the responsibility for your own actions does not preclude you from being frustrated and at times outright angry at the outcomes of those actions. In this case I (wrongly) assumed that after a 1.0 release the library would be relatively stable and have been repeatedly duped into believing that this time the major version release would be the stable one. I don't really see anywhere that people were issuing an outcry for V4, so I am still confused as to why it was so urgent to release it. It wasn't perfect but it was fine. Unfortunately in my frustration and confusion I chose to write a very strongly worded comment that apparently some people did not like.

> To be clear: developers that release libraries and then iterate the API in public do not deserve personal scorn for doing so

I have never gotten the impression that react-router was someone's personal library, rather it is a community project that is maintained by notable members of the javascript community and it is my belief that delivering half-baked stuff to the people who counted on them, and who they led to believe could count on them, is not a fair thing to do. I don't believe it is unreasonable to be frustrated with fickle leadership from people who stepped up to lead the project. If they can't deal with the criticism or don't have the time/effort/inclination/whatever to lead in a way that is agreeable to most of the community then perhaps someone else could lead. When projects have thousands of stars on github, making rapid successions of breaking changes throws all of those people for a loop.

If you do in fact view the repo as your personal project and want to make huge changes all the time, like every 6 months, I don't think that the version with thousands of stars is really the place to do that. Why not just do it on your own where it isn't going to affect so many people.

Note: Neither this, nor my original comment should be taken as personal attacks on the maintainers although I am aware that both are probably over stated. I'm sure they are all extremely talented developers and kind people.

If someone was able to produce better code in some way before, despite any OSS alternatives available at the time, why would anyone assume they could not also maintain and develop that code more effectively than the same OSS community and projects in the future? That makes no sense.

A lot of developers seem to make dubious assumptions today about the quality of something they could import compared to the quality of what they could build in-house. There’s little reason or evidence to support a lot of those assumptions, but people continue to make them regardless, because hype and inexperience are things.

If you’re talking about a huge OSS project with many contributors, quite a few experts involved, well-established infrastructure and funding, and so on, then sure, it’s a tough thing to beat. I couldn’t set up and maintain a new operating system with the same capabilities as something like Debian or FreeBSD, and neither could any other small team.

But most OSS isn’t like that. Lots of OSS projects have only a single main developer, or maybe a small team of contributors, and those people may or may not be as skilled, experienced, dedicated or simply available as your in-house team. Lots of OSS projects effectively get abandoned, sometimes even well-known ones with lots of contributors, major commercial backing and a large user base. Lots of OSS projects are highly unstable, and if you depend on one that needs constant updates to keep it working, that’s an overhead of its own. There is precious little evidence that OSS quality is better in general than something a good team could have built in-house.

And even if none of those things were true, your own in-house development would still be focussed on your specific needs and priorities, instead of trying to be a generic tool with potentially a lot of functionality (and risk) you don’t need, and potentially being steered in a future development direction than doesn’t meet your needs as effectively.

Don't write it unless you intend to own it.

The flip side of that is that if you do want to own it, writing it in-house may well be a better option.

Obviously there has to be a balance, and reinventing the wheel (or a sports car) for every project isn’t necessarily a good use of time and resources. Bringing in a good external tool or library that solves a problem for your project effectively can be a huge win, particularly if it’s in an area that isn’t a core part of your own project.

However, I believe the current culture in some parts of our industry is crazily biased towards bringing in external libraries to do every little thing. That is a very dangerous trend that we must challenge, because we’re writing an awful lot of awful software as a result.

What I wrote wasn't entirely in response to the HN thread. Similar thoughts about the JS community have been brewing for a while and the discussion prompted me to speak my mind.