5 ms·

It is time to deploy common JS libraries out of band, like native libraries. Download them once, precompile them once, and then use precompiled version at any s

• tlrobinson 11y ago
  That's basically the purpose of public CDN-hosted JavaScript, like cdnjs [1] and what most major JS libraries do [2]. However, I think this is becoming less common with the increasing popularity of module bundlers like webpack. It's still possible with webpack [3], but it's not as easy as a 'npm i react' and 'import React from "react";'. That said, a module bundler could easily automatically swap out local modules for modules hosted on CDNs in production builds (with fallbacks in case the CDN is down). I'm a little surprised this doesn't seem to exist yet, at least for webpack. 1. https://cdnjs.com/ https://cdnjs.com/ 2. https://code.jquery.com/ https://code.jquery.com/ 3. https://webpack.github.io/docs/library-and-externals.html https://webpack.github.io/docs/library-and-externals.html
  • lisivka 11y ago
    I mean, we need <library> tag in addition to <script> tag, which we already have. e.g. <library name="react" version="^5.0"><script src="https://cdn/react-5.0.8.js"></script></library> https://cdn/react-5.0.8.js"></script></library>
• tomphoolery 11y ago
  It would be kind of nice if you could import modules directly from HTTP sources, like Go. For example: import _ from package 'github.com/lodash/lodash/tree/4.8.2'; import $ from package 'jquery.com/version/2.2.0'; Your browser would make the OOB requests and cache the results in a shared directory, which any JS code that's running locally can use. This way, HTTP requests for 3rd-party components shared across websites aren't repeated over and over again for the same libraries. And it could even be extended to CSS: @import package("github.com/twbs/bootstrap/tree/3.3.6");
  • lisivka 11y ago
    Such style of dependency declaration creates unnecessary dependencies on remote sites, which are hard to fix when dependency is broken.
    • true_religion 11y ago
      That's essentially what people are doing already with script tags, except they're not declaring their dependencies anywhere.
  • et1337 11y ago
    Better idea would be to reference it via cryptographic signature. Then you could host your own copy of lodash for example, but still benefit if a client already has it downloaded from a different site.
    • moreati 11y ago
      Subresource Integrity is the standard for that https://www.w3.org/TR/SRI/ https://www.w3.org/TR/SRI/
      • et1337 11y ago
        Do you know if this allows consolidation of multiple copies of the same resource from different hosts?
        • moreati 11y ago
          I don't know. At a guess such optimization would be beyond the scope of the standard - hence up to each vendor/browser/user-agent.
        • woogley 11y ago
          Not currently, because it conflicts with CSP. See https://news.ycombinator.com/item?id=10311020 https://news.ycombinator.com/item?id=10311020
• tyleregeto 11y ago
  I thought there was a proposal in the works for adding checksums on script tags. Something like: <script src='...' checksum='2fd4e1c67a2d28fced849ee1bb76e7391b93eb12' /> Which would allow the browser to use cached copies of files even if from different domains. Not sure where I saw that.
  • woogley 11y ago
    You are thinking of the integrity="" attribute that's part of SRI: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres... That attribute is meant to verify resource contents. The strategy of using it as a cache ID is still being discussed, but last I looked into it, there were some cache poisoning concerns. You might find this thread useful: https://news.ycombinator.com/item?id=10311020 https://news.ycombinator.com/item?id=10311020
    • tyleregeto 11y ago
      Great, thanks for that info!
• m_eiman 11y ago
  There's a Firefox plugin that does (parts of) this: https://github.com/Synzvato/decentraleyes https://github.com/Synzvato/decentraleyes
• cel1ne 11y ago
  Libraries on CDNs have drawbacks as well, like the additional dns-roundtrip. I think what's needed is a heuristic webpack-loader, where you can specify both a self-hosted URL and a cdn-URL. It could work like this: * Load the CDN version and fallback back to the self-hosted version, if it doesn't exist or takes too long. * In certain cases (probability, origin of request, etc.) load the self-hosted version first, but load the CDN in the background, so it get's cached.