Live data from Hacker News

Why I Don't Use React Router

jkk.github.io

71–79 of 79 posts

Re: Why I Don't Use React Router

#71
post #69

I might be missing something (after reading the article twice) but the author says nothing about why he doesn't use React Router... The only mention I can find is "But the API smelled funny to me, and had not settled, so I continued to wait" that hints that the API is changing and looks weird. But other than that, there is no constructive criticism here. I'm all for being able to write freely about software we find b…

It looked like a risky dependency, simple as that. Despite the HN title, the point of the article was not to talk about React Router. EDIT: Additionally, I'm not saying React Router is bad per se, just that it's not fully baked. I'm glad to see people working on the problem. I look forward to leveraging the fruits of their labor in the future (in fact, I already do - I use the history library on which RR is built).

I still feel that you're not giving reasons of why it's a risky dependency or fully baked. And probably we/you should rename the title if it doesn't convey the article body...

Not that I am defending or even using React Router myself, I'm just saying that it's usually better for everyone if the feedback is better explained than just "It's bad" or "It's risky to use".

Re: Why I Don't Use React Router

#72

Yep, this is a thing I push with my team all the time. Always vet your deps. In the long run is is WAY worth it. In the short run the cost is rather minimal unless you have devs that cannot actually deliver on the needs the dependency covers.

> unless you have devs that cannot actually deliver on the needs the dependency covers.

You say this off-handedly like its not a big deal. No single person or company understands all the dependencies from the app all the way down to the electricity. That's the real reason we use dependencies - for things that aren't core to our business, that we don't want to have to understand.

Re: Why I Don't Use React Router

#73
post #5

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? I'm dealing with a bunch of people now who did something like that. At the time they made these decisions they might have had good reasons, but now they're doing other stuff and the custom things they wrote are a huge liability. Don't write it unless you intend to…

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…

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

An unspecified question is "What is the cost of ownership?" (which you alluded to in discussing the size of the project.) I've written plenty of code that could have been replaced by a library. I've put out OSS projects that I actively discourage people from using because the function of the library was so straightforward that its just not worth the dependency (even if its my own, completely flawless code ;) ) Moreover, in most of these cases the code churn even over several years is almost zero. That's a metric that should be looked at a lot more often when evaluating dependencies.

To your point, the cost of ownership is completely negligible in most cases, and all developers are doing by including a new dependency is saving a small amount of time up front with a heavy backside cost.

Re: Why I Don't Use React Router

#74
post #52

Earlier quoted context omitted.

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.

I'd argue that's a strength. Note how scala is modularizing its standard lib in Dotty, and TypeScript is doing that same for stdlib typings.

Standard libs are great, but they need to be modular. If they're modular then they are versioned separately from the language, and at that point there's no difference between a well specified and maintained lib (eg lodash) and a stdlib.

Re: Why I Don't Use React Router

#75
Every ecosystem is full of "half-baked" libraries. JS has more as the ecosystem is bigger and the barrier to entry is very low. It's the nature of open source, it's also the nature of open source to evaluate dependencies.

Re: Why I Don't Use React Router

#76
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.

That node_modules directory was created using Node.js v5.10.0 and npm v3.10.5.

Re: Why I Don't Use React Router

#77
post #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…

There's also Navigo, a minimal router - https://github.com/krasimir/navigo

Re: Why I Don't Use React Router

#78

Yep, this is a thing I push with my team all the time. Always vet your deps. In the long run is is WAY worth it. In the short run the cost is rather minimal unless you have devs that cannot actually deliver on the needs the dependency covers.

> unless you have devs that cannot actually deliver on the needs the dependency covers. You say this off-handedly like its not a big deal. No single person or company understands all the dependencies from the app all the way down to the electricity. That's the real reason we use dependencies - for things that aren't core to our business, that we don't want to have to understand.

I guess I just assumed everyone understands that no team will have the ability to cover all your needs. So you actually need to judge when your team cant deliver, then pick the dependency to pull in.

Re: Why I Don't Use React Router

#79
post #67
post #58

Earlier quoted context omitted.

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.

Thanks for sharing this and introducing me to 750words, I just finished my first entry! The analysis provided after just a single writing session is awesome - I can't wait to see how this affects my writing, focus, and ability to communicate with myself and others. Did you see a shift in sentiment, focus or elsewhere in your analysis as you prepared to make your writings public? For instance, I notice a pretty even d…

The only writings I make public are short essays I write during the day about victories and frustrations at work. When I am following the "morning pages" habit, I am usually extremely short on focus.

I am extremely pleased with how journaling improves my communication — when I find myself quoting that morning's pages, I get feedback on how decent my predictions were.

I feel more prepared, having hypothesized these circumstances in the morning, the afternoon offers fewer surprises (and novelty still fits nicely in contrast).

Post reply on HN