3 ms·
2 reasons why this could be a faulty approach: 1) Code, specifically library code, which is what npm mostly consists of, in its most ideal state should not hav
by xixixao 6y ago
2 reasons why this could be a faulty approach:
1) Code, specifically library code, which is what npm mostly consists of, in its most ideal state should not have a never-ending variety. On the contrary, we do want to all arrive at one good way of doing a thing. This naturally invites a single central repository over the decentralization of the web.
2) Very few people publish their own websites. Why? It's complicated, costly. This is why Facebook and Twitter fair so well. So even the decentralized web eventually diverges onto a centralized platform that solves the hosting problem. Why reintroduce the problem when there is already a fairly un-problematic central registry?
If the security model is the real winner, I don't see why it could not be back-ported to Node - it likely will be if Deno takes off in any way.
- jclulow 6y agoI don't have an opinion on Deno per se, but I quibble with this part of your point: > Code, specifically library code, which is what npm mostly consists of, in its most ideal state should not have a never-ending variety. On the contrary, we do want to all arrive at one good way of doing a thing. This implies that there is in fact one good way to do most things, but in practice different people want different trade-offs and forcing them into a single codebase isn't possible when the options are mutually exclusive. You can't have a library that is simultaneously strict about types (panics if you pass a string instead of a number, say) and forgiving about types (automatically coerces strings to integers or vice versa).