3 ms·

> You hardcode the dependency version in the actual URL Websites have been doing this for .. 20 years? It's quite a different paradigm, yes.

godot 6y ago
Before the age of React, when I used to work on decent-sized web sites' frontend, there would typically be maybe a handful of external dependencies; usually just jquery; and later on perhaps a few other powered-by-jquery utility that gives you maybe a carousel or other UI elements. Most of the rest of the JS code is written in-house. 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.
chrismorgan 6y ago
A major difference: transitive dependencies. In the old days, jquery.foo.bar.js would say “make sure you’ve loaded jquery.js and jquery.foo.js first”, and it would be up to you to decide which versions of them to use. Under Deno, modules will declare their exact dependencies and I suppose you the caller can’t control them. Or else they could devolve into some form of dependency injection. 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.)
onion2k 6y ago
Websites have been doing this for .. 20 years? 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.
- jai_ 6y ago
  Web developers have been trying to move away from URLs that describe their content for 20 years? Well that certainly explains the state of the 'modern' web
  - onion2k 6y ago
    Web developers have been trying to move away from URLs that describe their content for 20 years? 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.

godot 6y ago

Before the age of React, when I used to work on decent-sized web sites' frontend, there would typically be maybe a handful of external dependencies; usually just jquery; and later on perhaps a few other powered-by-jquery utility that gives you maybe a carousel or other UI elements. Most of the rest of the JS code is written in-house. 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.

chrismorgan 6y ago

A major difference: transitive dependencies. In the old days, jquery.foo.bar.js would say “make sure you’ve loaded jquery.js and jquery.foo.js first”, and it would be up to you to decide which versions of them to use. Under Deno, modules will declare their exact dependencies and I suppose you the caller can’t control them. Or else they could devolve into some form of dependency injection. 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.)

onion2k 6y ago

Websites have been doing this for .. 20 years? 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.

jai_ 6y ago
Web developers have been trying to move away from URLs that describe their content for 20 years? Well that certainly explains the state of the 'modern' web
- onion2k 6y ago
  Web developers have been trying to move away from URLs that describe their content for 20 years? 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.