Live data from Hacker News

Why I Don't Use React Router

jkk.github.io

51–60 of 79 posts

Re: Why I Don't Use React Router

#51

It's great to someone express this point. Though it's hard to beat the convenience of dropping someone else's library into your codebase, each new dependency adds more security surface area and bloat to your application. I wish people considered this balance more carefully. In general I think a littlw NIH is a good thing. Even if there exists a library that does what you want, it might also include much more that you…

NIH is also kinda what leads to the proliferation of so many very similar, but slightly different, modules in npm. everybody thinks they can solve X problem better than the previous dozen people who solved it. Maybe it's driven by ego, maybe a sincere belief that their new way is better enough to justify a whole new project (and the division of talent available for solving that problem), etc. There used to be a feeli…

There's a big difference between acting on NIH for your own project, and acting on it and then publishing it. It takes a considerable amount of work to prepare code for general use. On the other hand, if it's used in a specific way within one codebase, that may actually make much more sense than reaching for a library that is designed to do that one thing and a dozen others.

Re: Why I Don't Use React Router

#52

Earlier quoted context omitted.

Even if your code is better than the OSS alternative now, are you going to be able to maintain it at that level, given all of your other responsibilities? 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? Th…

True, but Javascript libraries tend to be pretty small and deal with well-known concepts. Many experienced dev's have seen a router 10x by the time they've come to React-Router, and the entirety of the source code can be read in a single day. If you both (a) have experience and (b) have read and understood the entirety of a library, then you are in the best position to claim that you can do it better in house. The pr…

One of the weaknesses of Javascript is its absolutely terrible standard library. In comparison to languages with solid, comprehensive, "batteries-included" standard libraries, you spend a lot of time re-implementing basic functionality. Or you import jQuery, or LoDash, or underscore, or use pieces of Ember or Angular, or React, etc, etc. Or some bastard abomination of all of those.

Re: Why I Don't Use React Router

#53

Earlier quoted context omitted.

Yeah maybe. To me it feels like many in the community complain and shirk responsibility, and some stern words were needed to counterbalance that position. If the community wants stability in its projects, it needs to learn what it takes to achieve that.

Further thoughts: choosing an unstable library and then criticizing it for being unstable seems silly. There are two sides: library authors need to value things like careful design, real world testing, and backwards compatibility. Library consumers need to advocate for the same things, plus learn how to identify risk (semver isn't going to save you), and take ownership of their choices.

> Further thoughts: choosing an unstable library and then criticizing it for being unstable seems silly.

If so many people (apparently) missed the "expect this to be unstable" bit, I wonder if it's just a question of not being signaled effectively enough on Router's home page. Which I can understand since no developer actually expects, let's say, their v3 to actually be completely revamped into a v4. If they knew ahead of time, they'd presumably just have chosen the v4 design.

I guess it's kind of catch-22. Maybe the right thing here is to explicitly say "we currently fully expect this to be stable for the foreseeable future, but cannot predict the future, and are prepared to break everything if a better design is discovered"?

EDIT: I suppose another way to alleviate the problems would be to pledge support for the previous version for a period of time... but no developer working in their spare time really wants to do that. (For very understandable reasons.)

Re: Why I Don't Use React Router

#54
post #41
post #20

Earlier quoted context omitted.

> I've gotten to where I only install stuff via npm when I'm on a free connection; I normally work on mobile broadband, which is very expensive You could always use this: https://www.npmjs.com/package/npm-proxy-cache It caches the package listings and the packages that you download. It will act as a pass through that with a limited TTL on the cache, but there is an option to fallback to the cache if you can't connect…

You're being unfair. You're obviously using npm 2.x, we've since moved to 3 for a very long time now where the dependency tree is flattened and this issue is avoided.

It's better but it's still an issue when multiple version of a module are needed.

Re: Why I Don't Use React Router

#55
I really need to get my blog up and running so that I can write about things like this.

My view is that dependencies are someone else's solution to my problem of technical debt.

I'd be a straight-up liar if I claimed to be proud of every line of code I've written, either for an employer or for myself. Sometimes you just have to hammer a square peg into a round hole and be done with it because deadlines. Or lazy. Or boredom. Or whatever this project is going nowhere anyway, so wtf? Hack the shit out of it.

I always tell myself I'm going to get back to that later and clean it up, but I often don't because, well, moar deadlines.

Dependency updates--particularly breaking ones--are things I love to hear about. Dependency updates give me an excuse, both professionally and for my side projects, to revisit stuff that I knew was janky and crappy and broke when I wrote it, but have since come to accept.

Security updates are absolute gold in this game of not wanting to suck but still having to meet deadlines.

"Sorry boss, but there's a vulnerability in lib x. We have to update. But it's breaking. So now we have to refactor. Two weeks, at least. Maybe more."

I just got rid of a crap-ton of bad code while I was updating for that dependency. Oops.

Re: Why I Don't Use React Router

#56
Don't get it. It's FOSS. npm install the version you want. A new version released you don't like? Keep using the old version. Don't like the old version? Write your own. Fork it. It's free and awesome global collaboration!

Re: Why I Don't Use React Router

#57
post #49

Earlier quoted context omitted.

The problem isn't pinning, the problem is that it's routinely accepted for dependencies to disagree about which version of a library is ready for production use, because npm doesn't treat that as a disaster that should block deployment until the community coordinates their acceptance testing. Basically, if lib1 and lib2 each use lib3, I don't want to upgrade anything until both lib1 and lib2 agree that a newer versio…

What if there is a breaking change in lib3 and only lib2 upgrades? Does that mean lib1 can just never be used again because of something lib3 did?

If a new version of lib2 moves to a half-baked version of lib3, I want to stay on the old version of lib2 (and lib3) until the community agrees that the lib3 change is good and everyone has migrated to it. Having two different versions of lib3 in process is begging for bewildering bugs, and it was a serious mistake for npm to let that happen (much less by default!)

Re: Why I Don't Use React Router

#58

I really need to get my blog up and running so that I can write about things like this. My view is that dependencies are someone else's solution to my problem of technical debt. I'd be a straight-up liar if I claimed to be proud of every line of code I've written, either for an employer or for myself. Sometimes you just have to hammer a square peg into a round hole and be done with it because deadlines. Or lazy. Or b…

I didn't get my blog up and running until I a) started keeping a journal on 750words.com and b) started writing in a spiral-bound notebook every spare half-hour.

Those two habits and https://blot.im made blogging nigh-effortless. Like dandruff, I get it for free.

Re: Why I Don't Use React Router

#59
If you're looking to jump ship and your projects use Redux, you might find https://github.com/FormidableLabs/redux-little-router to be a nice alternative. RRv4 still hoards URL state within a component, while Little Router just puts it in the store. This makes deriving most of your app from URL state a reality.

Check out https://formidable.com/blog/2016/07/11/let-the-url-do-the-ta... for more on how we differentiate from the RR philosophy.

Re: Why I Don't Use React Router

#60
post #58

I really need to get my blog up and running so that I can write about things like this. My view is that dependencies are someone else's solution to my problem of technical debt. I'd be a straight-up liar if I claimed to be proud of every line of code I've written, either for an employer or for myself. Sometimes you just have to hammer a square peg into a round hole and be done with it because deadlines. Or lazy. Or b…

I didn't get my blog up and running until I a) started keeping a journal on 750words.com and b) started writing in a spiral-bound notebook every spare half-hour. Those two habits and https://blot.im made blogging nigh-effortless. Like dandruff, I get it for free.

Oh my problem isn't that at all. I have no problem writing endless amounts of crap that no one will ever read. It's just that I really care about my writing, and I want it to have a perfect home. So I'm constantly writing and rewriting blog engines.

In this case, the perfect is the enemy of no one. A blog engine is the one side-project that I don't just hack. It's my one and only place for writing pure, elegant code.

And I won't let myself write at length again on someone else's platform until I get this exactly right.

Everyone wins: I don't clutter the internet with inane crap; you aren't tempted to read it.

If I ever decide to start publishing my writing, the best part of it will be the code that presents it.

Post reply on HN