[Feature request] Add <library> tag, similar in purpose to <script> tag

[vlisivka]

As developer, I need <library> tag for my products, which will allow me to implement future-proof solutions for my clients.

Currently, I need to bundle libraries with application, to be independent from third-party sites in long run (because I cannot predict what will happen to a CDN in 10 years from now), so browser needs to download/parse/compile common libraries again and again for each site. Moreover, critical bug fixes or missing support for new platforms are not introduced into legacy code, which makes them vulnerable.

I need a tag, which will allows me to offload library loading to browser, so browser will be able to download library, from trusted source, and compile and optimize it ahead of time. Moreover, if bug-fix for library is released, browser can use bug-free version of library without modification of code at my site. Moreover, developers can release browser-specific versions of same library, e.g. optimized for specific kind of Firefox or specific version of Firefox.

Proposed syntax is: <library name="LIBRARY_NAME" version="LIBRARY_VERSION"><script src="https://.../library.js"></script></library> , where LIBRARY_NAME is well-known name of the library, as registered at CDN, e.g. "react", and LIBRARY_VERSION is version of library in SEMVER format , with optional "^" to indicate that upgrade to next minor version is allowed, when it is released, e.g. "^5" (5.0, 5.1, 5.2, ...) , or "^5.0" (5.0.1, 5.0.2, ...), or "5.0.3" (5.0.3-1, 5.0.3-2, ...).

Example:

<library name="react" version="^15.0"><script src="https://mysite/js/vendor/react-15.0.1.js"></script></library>

[domenic]

Let's go through https://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F. In particular, step 1:

Forget about the particular solution you have in mind! Solution time is later!

So let's forget about the library tag idea. It's not relevant to this thread.

It seems to me that in terms of step 2:

Write down a description of the underlying problem you're trying to solve. What are the use cases? A use case is an actual user wanting to do something. Then list requirements for each use case.

your use cases are:

• (A) Getting some auto-updating sem-ver style library inclusion.
• (B) Getting versions optimized for specific browsers
• (C) Avoiding download/parse/compile costs for common libraries, while avoiding CDNs because you "cannot predict what will happen to a CDN in 10 years from now"

Is that correct?

Can you perform step 3?

Get more people involved. Send your use cases and their requirements to whatwg@whatwg.org. Ask fellow Web developers about their opinions (but remind them of step 1 above). Adjust the list of use cases and requirements as appropriate. Say which use cases are important and which are just nice to have.

This issue tracker is fine instead of the mailing list. But can you find other web developers who have these problems, and have been unable to solve them with current technology? Can you separate these use cases into must-haves, i.e. cases where you simply cannot build a successful web app today, versus nice-to-haves? I am not sure I see any must-haves here.

I can easily believe other developers want (A), as seen by the prevalence of systems like npm.

Have other developers expressed a desire for (B)? I don't see a lot of libraries offering browser-specific versions of themselves. Can you point to evidence that such a use case is so common that we need to include it in the platform? Such evidence would be, e.g., a survey of all the libraries on npm, or all web pages on the http-archive data set, showing that ~5% of them have browser-specific versions of the same library included.

Have other developers expressed concerns about the unreliability of CDNs, your (C)? Have they found browser vendors more reliable? Remember, we've seen the extinction of two browser rendering engines in recent history: Opera Presto, and Microsoft Internet Explorer. And, do you anticipate browsers implementing this in any other way than just hosting their own CDNs? That seems to me like exactly what would happen.

Let's skip ahead a bit to step 5:

Research existing solutions. Come up with new solutions. Try to keep the solutions as simple as possible, maybe only addressing the important use cases and leaving the nice to have use cases for later (when there's implementation experience). Send this list of solutions, old and new, again to whatwg@whatwg.org. Ask browser vendors for feedback. Maybe some particular solutions don't fit with the browser's architecture, optimizations, etc., and just are not going to be implemented no matter how much you like them. Strike those solutions and don't grieve about the loss!

I think there's clearly ways to accomplish both (A) and (B) without involving new features that every browser must implement, and that web developers must wait ~5 years or so before being able to use reliably (as old browsers die out). (C) is trickier, but as I said, it's not clear that avoiding CDNs in favor of some vague system involving browsers is actually going to get you any reliability benefit. Maybe there is a better way of avoiding CDNs than involving browsers? Cryptographic hashes, perhaps? It would be good for you to research other ways people avoid this problem. Maybe (C) was a nice-to-have instead of a must-have, in which case we're done here: all the must-haves are accomplishable today already, so asking every browser to implement something just to solve a nice-to-have use case is not going to happen.

I'll stop there, but as you can see, there's a process here, and proposing a concrete solution (your library tag) comes wayyyy later. The most important steps that you need to work on is steps 3 and 5.

[vlisivka]

Step 2: Cases:

Must have:

1.a) (as user) Security fixes and bug fixes. Millions of sites are vulnerable because of JS libraries with bugs and security holes (e.g. jQuery). They cannot be fixed automatically even when fixed version of library is released, so millions of them remains to be vulnerable years after security hole disclosure. More over, it is impossible to fix these sites without their consent. In the past, Google substituted vulnerable version of jQuery at their CDN with fixed version, which is violation of CDN contract, but great demonstration of the problem and the solution.
We also see lot of broken sites at mobile browsers, which are also demonstration of the problem: site uses broken version of library even when fixed version is available.

1.b) (as developer): Future proofness. Currently, I see no LTS versions of popular libraries, e.g. "LTS jQuery" search produces zero results. It is technically possible to implement LTS, e.g. Google CDN allows to link to major version of jQuery instead of explicit version, so this is feels like form of LTS, but it is voluntary effort of Google for few libraries.

Nice to have:
2.a) (as developer) Independence from third-party sites. To meet requirement that site must work even in isolated environment (typical requirement for corporate sites, network equipment, etc.), I must bundle libraries with site, so my site is independent, because link to third-party site is direct violation of contract. However, it is better to share libraries with other sites for improved performance.

2.b) (as user) Optimizations. For example, Mozilla team can develop optimized versions of popular libraries or functions, e.g. reimplement them using WebAsm, use Firerefox specific features, or even compile to native code with hardware acceleration. Apple team can do same for their Safari. However, these optimized versions of libraries cannot be used at third-party sites without their consent, so there is no way to do that.

2.c) (as user) Trust. Currently, every site downloads lot of javascript libraries, which are verified by nobody and not even signed. As I saw at our national revolution, our government security agency substituted SSL certificate for popular CDN's and Google sites (Chrome reported that) and supplied modified versions of JS libraries, which reported additional information to an IP. IMHO, popular libraries, at least, must be download and checked by browser using trusted channel.

Step 5: Existing solutions:

It looks like Google Hosted Libraries with 14 libraries is example of such system: https://developers.google.com/speed/libraries/#libraries . However, cases 1.b, 2.a, 2.b, 2.c are not met.

[vlisivka]

and that web developers must wait ~5 years or so before being able to use reliably

If this feature will be widespread in 5 years, then it is OK. This feature is for future proofness of sites, which I develop right now. Nothing will be broken if I will declare dependencies using <lib> tag, but if 5 years later something wrong will happen with library, future browser will still be able to show site properly without need to fix a site.

[jimmywarting]

The Integrity attribute could be useful in a sense that it could allow you to cache the same jQuery library from two different CDN's. it would also be secure against modifications.
I think i would almost rather want to use that instead of semantic versioning. It's crazy how many change google's hosted libraries code

[domenic]

integrity="" is already specified: https://w3c.github.io/webappsec-subresource-integrity/

[vlisivka]

Integrity attr will pin version of a library, which is not an intended behavior for library tag.

[annevk]

I'm going to close this. While I appreciate the idea, I think there's much more work to be done here by libraries themselves to provide the stability and security you are looking for. Some of that might require standardization work, but as-is this proposal is too big to be adopted. Going for smaller pieces such as subresource integrity that at some point might allow for shared caching is a better path to success.

[vlisivka]

It looks like you misunderstand the goal of the tag. Idea is to implement something like npm or bower, but at browser side, while tag is just specifying version to fetch by browser-side bower. This cannot be implemented as a library by same reason why bower is not a library. Reopen ticket, please.

[domenic]

To reopen this ticket, we'll need implementer interest. So far no browsers we know of are interested in becoming package managers.

[vlisivka]

Implementer said that I need to open ticket here first, to attract more developers, so this is classical "egg and chicken" problem. :-) Maybe we can breed a little chicken in form of a browser plugin?

Plugin must do following things:

• disarm default script tag inside of lib tag, to prevent it from loading;
• if requested API is already implemented by the browser: do nothing;
• if requested API is not found in latest metadata from repositories, then load default implementation from script tag;
• if requested API implementation (polyfil) is found in cache, then inject it into page;
• if requested API is not found in cache, but found in metadata of one or more repositories, chose a version which fits this browser best, download it, validate it signature (using separate keys for separate repositories), compile it to bytecode if necessary (e.g. it can be precompiled and optimized by browser vendor), store it into cache, and inject into page.

How this logic can be implemented? I know how to use GreaseMonkey, by I am not sure that I can block a script in the page from loading. :-/ Any hints?