> You hardcode the dependency version in the actual URL
Websites have been doing this for .. 20 years?
It's quite a different paradigm, yes.
Websites have been doing this for .. 20 years?
It's quite a different paradigm, yes.
Working with node backend in the past few years, most of my backend services typically list a dozen dependencies or so in package.json, and those in turn have a bunch of other dependencies of their own. Among these there's probably lodash, some schema validator (ajv/joi/etc.), maybe an xml parsing/building lib, some unit testing framework, db query builder, and so on.
I'm not saying this to be pro-node and attack deno or anything; I just feel like the statement of "websites/browsers have been doing this forever" isn't exactly an apples to apples comparison.
Web developers have been trying to move away from that paradigm in order to make sites faster, more reliable, and smaller for almost as long.
Well that certainly explains the state of the 'modern' web
My comment wasn't about URLs describing their content, but rather the assumption that goes along with it that every network request will always work perfectly. Once you realise that things do actually fail occasionally you should realise that local caches and bundling things in to a smaller number of requests can improve resilience.
That's not really an issue with Deno because it does things to mitigate the issue (eg caching packages locally), but websites that loaded libraries using separate requests for each one were horribly prone to failure if one thing was missing, and slower overall if the browser couldn't fetch everything in parallel, so devs invented things like bundlers to fix the problem. Then came things like code-splitting and tree-shaking to reduce the size.
This could lead to many copies of a library being loaded and included, rather than just one via deduplication as other packaging systems tend to do.
(The article talks about the potential need to remap dependencies, which could allow you to resolve this sort of duplication manually, but says that the current implementation should probably be avoided.)