Hacker News Reader

Comment by lisivka | Hacker News Reader

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 site, which requires it.

View on HN

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/

2. https://code.jquery.com/

3. https://webpack.github.io/docs/library-and-externals.html

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>

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");

Such style of dependency declaration creates unnecessary dependencies on remote sites, which are hard to fix when dependency is broken.

That's essentially what people are doing already with script tags, except they're not declaring their dependencies anywhere.

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.

Subresource Integrity is the standard for that https://www.w3.org/TR/SRI/

Do you know if this allows consolidation of multiple copies of the same resource from different hosts?

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.

Not currently, because it conflicts with CSP. See https://news.ycombinator.com/item?id=10311020

I thought there was a proposal in the works for adding checksums on script tags. Something like:

Which would allow the browser to use cached copies of files even if from different domains. Not sure where I saw that.

You are thinking of the integrity="" attribute that's part of SRI: 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

Great, thanks for that info!

There's a Firefox plugin that does (parts of) this: https://github.com/Synzvato/decentraleyes

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.

Reply on news.ycombinator.com