4 ms·
People wouldn't change to the new one, because names are extremely sticky, so what's the point?
by Sammi 1y ago
People wouldn't change to the new one, because names are extremely sticky, so what's the point?
- skydhash 1y agoIf they need the new one, they will switch to it. And you have the right to drop support for the old one after a while (hopefully giving everyone the time to migrate).
- Sammi 1y ago> If they need the new one, they will switch to it. I already gave my argument on why this won't happen. People stick to what they know and trust. They don't change because there is some other thing that is supposedly better. It has to be 10x better before people will migrate off one thing to another. If you want to do incremental improvements to a thing, then you'll have to do incremental improvements to that thing.
- diggan 1y ago> They don't change because there is some other thing that is supposedly better. It has to be 10x better before people will migrate off one thing to another. That's the point, and it makes sense from their perspective, I'd probably do the same as well. Creating a new library instead of changing the existing one lets people chose between those two approaches. Want the latest and greatest but with API breakage? Use this library. Wanna continue using the current API? Use this library. Instead, we kind of force the first approach on people, which I personally aren't too much of a fan of.
- skydhash 1y agoAs I’ve said in other comments. If you’re developing a library, you can commit to its API and do security and optimization fixes and build a new one where you try a new design/approach. Merging the two together is always a bad idea.
- diggan 1y agoOk, that's fine by me. They can continue using the original library for whatever reason they want, including because of the name.
- pier25 1y agoThe point is API stability. Not enough people in the JS world care about this.