5 ms·

How do you actually go about writing isomorphic libraries for browser/deno? It seems like for frontend code you'll have some build system that resolves imports

How do you actually go about writing isomorphic libraries for browser/deno? It seems like for frontend code you'll have some build system that resolves imports to node_modules, whereas deno code imports from e.g. deno.land. How do you write library code with dependencies that can support that and the other differences in the module systems?

deleted 5y ago
[deleted]
sjy 5y ago
Deno uses ES6 modules, which are supported by modern browsers. There’s no node_modules. https://deno.land/manual/examples/import_export https://deno.land/manual/examples/import_export
- tkzed49 5y ago
  Yeah, I guess if you don't use typescript? But isn't that a lot of the appeal of deno? The browser can't import a TS module.
zdragnar 5y ago
Snowpack might be an option
- eyelidlessness 5y ago
  Their companion CDN (and namesake umbrella parent company) is also a first class part of Snowpack. However using CDNs in the browser has some big trade offs. Besides obvious concerns sending any data to consolidated third parties, it’s actually a performance detriment now that browsers are caching per origin. Used to be, using a CDN got you more likely cache hits and better perf on N+1 requests. Now you definitely don’t get that plus you get the extra DNS lookup and whatever performance characteristics of that CDN.
  - chris_engel 5y ago
    There has always been an extra DNS lookup wirh a CDN. Thats even the point of the CDN since based on where you are, you will be served from a location as physically close to you as possible. Where did you get the information from that CDNs arent as good as they used to be?
    - richeyryan 5y ago
      Safari and Chrome now use a combined cache strategy using the URL of the resource and the top level domain of the site loading that resource as the cache key. For scenarios that were previously popular like using the jQuery CDN, you won't get the benefit of the user having jQuery in their cache from another website. You will however still get the proximity benefit you describe. CDNs are obviously still quite useful, just not for getting cache hits on popular libraries. https://www.stefanjudis.com/notes/say-goodbye-to-resource-caching-across-sites-and-domains/ https://www.stefanjudis.com/notes/say-goodbye-to-resource-ca...
      - chris_engel 5y ago
        Yeah thats true - so you explicitly mean CDNs that serve a single thing only. Using a CDN for your static files is just as fine as it always has been.
    - eyelidlessness 5y ago
      > Where did you get the information from that CDNs arent as good as they used to be? The other comment addressed this, but to be clear. One of the common usage of external CDN resources is predicated on a performance benefit: if multiple sites use the same resource, it’s more likely to be cached already and much less likely to be impaired by the drawbacks (DNS hit, external network factors). But since browsers have shipped cache partitioning for very good privacy reasons (as other comment mentions, caches are prefixed by the requesting origin), you get no cache benefit and all of the detriment of a clear cache. Essentially the only reason to use a CDN for third party resources now is if you can bet the CDN will perform better than your local, already DNS-resolved host.
coolreader18 5y ago
Maybe there's a bundler/webpack plugin that supports deno's import system, so it just fetches whatever http urls/analyzes the import maps and turns it into a normal web bundle.
- IggleSniggle 5y ago
  Deno’s import system is just the ecmascript import system. So, it works exactly the same way it does in the browser. Or with curl. Or whatever. You just supply a uri and get the resource at that location. Things like import maps are just a way to make that more convenient during development, but there’s no secret system for pulling these pieces together; it’s just the ecmascript module standard (that didn’t exist until more recently).
- eyelidlessness 5y ago
  Yes there are plugins for this in pretty much every build tool and for Node. But they all have a bunch of caveats and mutual discrepancies.
sdfhbdf 5y ago
Just like you did in the browsers back in the day when you imported code from URLs with <script src="">, the "deno way" is supposed to follow browsers in these regards as well. And you can always use `npm`, `node_modules` and `import maps`[0][1][2] to kind of mimic "nodejs way". [0]: https://wicg.github.io/import-maps/ https://wicg.github.io/import-maps/ [1]: https://blog.logrocket.com/es-modules-in-browsers-with-import-maps/ https://blog.logrocket.com/es-modules-in-browsers-with-impor... [2]: https://deno.land/manual/linking_to_external_code/import_maps https://deno.land/manual/linking_to_external_code/import_map...

deleted 5y ago

[deleted]

sjy 5y ago

Deno uses ES6 modules, which are supported by modern browsers. There’s no node_modules. https://deno.land/manual/examples/import_export https://deno.land/manual/examples/import_export

tkzed49 5y ago
Yeah, I guess if you don't use typescript? But isn't that a lot of the appeal of deno? The browser can't import a TS module.

zdragnar 5y ago

Snowpack might be an option

eyelidlessness 5y ago
Their companion CDN (and namesake umbrella parent company) is also a first class part of Snowpack. However using CDNs in the browser has some big trade offs. Besides obvious concerns sending any data to consolidated third parties, it’s actually a performance detriment now that browsers are caching per origin. Used to be, using a CDN got you more likely cache hits and better perf on N+1 requests. Now you definitely don’t get that plus you get the extra DNS lookup and whatever performance characteristics of that CDN.
- chris_engel 5y ago
  There has always been an extra DNS lookup wirh a CDN. Thats even the point of the CDN since based on where you are, you will be served from a location as physically close to you as possible. Where did you get the information from that CDNs arent as good as they used to be?
  - richeyryan 5y ago
    Safari and Chrome now use a combined cache strategy using the URL of the resource and the top level domain of the site loading that resource as the cache key. For scenarios that were previously popular like using the jQuery CDN, you won't get the benefit of the user having jQuery in their cache from another website. You will however still get the proximity benefit you describe. CDNs are obviously still quite useful, just not for getting cache hits on popular libraries. https://www.stefanjudis.com/notes/say-goodbye-to-resource-caching-across-sites-and-domains/ https://www.stefanjudis.com/notes/say-goodbye-to-resource-ca...
    - chris_engel 5y ago
      Yeah thats true - so you explicitly mean CDNs that serve a single thing only. Using a CDN for your static files is just as fine as it always has been.
  - eyelidlessness 5y ago
    > Where did you get the information from that CDNs arent as good as they used to be? The other comment addressed this, but to be clear. One of the common usage of external CDN resources is predicated on a performance benefit: if multiple sites use the same resource, it’s more likely to be cached already and much less likely to be impaired by the drawbacks (DNS hit, external network factors). But since browsers have shipped cache partitioning for very good privacy reasons (as other comment mentions, caches are prefixed by the requesting origin), you get no cache benefit and all of the detriment of a clear cache. Essentially the only reason to use a CDN for third party resources now is if you can bet the CDN will perform better than your local, already DNS-resolved host.

coolreader18 5y ago

Maybe there's a bundler/webpack plugin that supports deno's import system, so it just fetches whatever http urls/analyzes the import maps and turns it into a normal web bundle.

IggleSniggle 5y ago
Deno’s import system is just the ecmascript import system. So, it works exactly the same way it does in the browser. Or with curl. Or whatever. You just supply a uri and get the resource at that location. Things like import maps are just a way to make that more convenient during development, but there’s no secret system for pulling these pieces together; it’s just the ecmascript module standard (that didn’t exist until more recently).
eyelidlessness 5y ago
Yes there are plugins for this in pretty much every build tool and for Node. But they all have a bunch of caveats and mutual discrepancies.

sdfhbdf 5y ago

Just like you did in the browsers back in the day when you imported code from URLs with <script src="">, the "deno way" is supposed to follow browsers in these regards as well. And you can always use `npm`, `node_modules` and `import maps`[0][1][2] to kind of mimic "nodejs way". [0]: https://wicg.github.io/import-maps/ https://wicg.github.io/import-maps/ [1]: https://blog.logrocket.com/es-modules-in-browsers-with-import-maps/ https://blog.logrocket.com/es-modules-in-browsers-with-impor... [2]: https://deno.land/manual/linking_to_external_code/import_maps https://deno.land/manual/linking_to_external_code/import_map...