Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I Don't Use React Router

jkk.github.io

Post reply on HN
Print view View original

41–50 of 79 posts

Re: Why I Don't Use React Router

#41

Post by vmasto »

pyre wrote: post #20
SwellJoe wrote: post #17

I recently started working seriously with node.js (I've tinkered over the years since it was launched, and we provide some support for it in our products, but never actually built anything with it). I went looking for a library to deal with logins, authentication, password resets, etc. Normal stuff that most web frameworks have some solutions for. I found a package on npm that sounded like it did everything I wanted…

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

Re: Why I Don't Use React Router

#43

Post by prodigal_erik »

pyre wrote: post #20
SwellJoe wrote: post #17

I recently started working seriously with node.js (I've tinkered over the years since it was launched, and we provide some support for it in our products, but never actually built anything with it). I went looking for a library to deal with logins, authentication, password resets, etc. Normal stuff that most web frameworks have some solutions for. I found a package on npm that sounded like it did everything I wanted…

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

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 version of lib3 works.

Re: Why I Don't Use React Router

#44

Post by jkkramer »

jkkramer wrote: post #33
WhitneyLand wrote: post #19

Justin I think you are conflating a couple issues here: 1). OSS critiques should be more polite 2). People are stupid for not doing due diligence First, I agree criticism should be constructive. Yet there is nothing wrong with 100 people saying here they don't like React Router and in fact such feedback is crucial for the authors and the community. Maybe you agree; but ironically the tone of your post seemed have a b…

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.

Re: Why I Don't Use React Router

#45

Post by FLGMwt »

vmasto wrote: post #40
Scarbutt wrote: post #29

Earlier quoted context omitted.

Does the 24 copies all get bundled into the final JS file in the case of a browser app?

Of course not. Also the modules he lists here are mostly for tooling purposes.

Are you sure? I could see multiple downstream versions of utility libraries like lodash and jQuery used in runtime dependencies.

Maybe not as bad as 23, which doesn't seems as likely for non-toolong stuff, but I'd still expect some divergence.

Re: Why I Don't Use React Router

#47

Post by hinkley »

Chris_Newton wrote: post #38
hinkley wrote: post #30

Earlier quoted context omitted.

It's the "smart" ones who are the worst, unfortunately. But I think there space for both the cut and paste crowd and the deep knowledge folks. In most industries the tool makers are separate from the users. The latter aren't worthless or subhuman because they don't do the former. In most industries there's a place for fast people and there's a place for perfectionists. Tooling is not a volume business but needs a ver…

In most industries the tool makers are separate from the users. True, but I’m not sure software development is one of those industries. Someone who makes pencils is not necessarily an artist, and vice versa . They require different skills and have different goals. But where do someone who draws with those pencils, someone who makes colour-by-numbers books, and someone who uses the pencils to fill in those colour-by-n…

My thought is that we're too young for it to be separate, but it'll come, and probably not too long from now.

Re: Why I Don't Use React Router

#48

Post by hinkley »

jfoutz wrote: post #18
hinkley wrote: 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…

I think a good heuristic is, is it your business? I'd try really hard to avoid implementing address verification. Unless i worked at UPS or FedEx. I'd try really hard to avoid implementing spellcheck. Unless i worked on Word. If it's a core to survival thing, yeah, you should probably roll your own. If you can't beat OSS state of the art, well, you've got a problem. The other heuristic i think is generally good, go f…

Sure, I use this one too. If it's not your core competency buy it from someone else.

Re: Why I Don't Use React Router

#49

Post by mason55 »

prodigal_erik wrote: post #43
pyre wrote: 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…

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?

Re: Why I Don't Use React Router

#50

Post by jkkramer »

dustingetz wrote: post #42

I just wanted to say that the clojure ecosystem is littered with the carcases of half baked libraries. Including some of my own. Its not a JS problem, its the beauty of open source & low friction sharing.

You're not wrong. But it feels worse in JS. In both cases lib authors would do well to set proper expectations - if your lib is half baked, be up front about it.
Post reply on HN