URN-based Libraries

I wanna be able to stick <script src="preloaded:jquery"></script> on my website and have it work. This basically involves bundling those libraries with the browser (or having the browser load them from a predefined location as needed) and having a registry somewhere of libraries browsers need to carry. Semantic versioning should be enforced, so an old webpage gets automatic XSS exploit protection as newer versions of libraries fix those exploits. This also has the added benefit that not only can the browser reuse/shared memory bytecode between webpages, significantly lowering RAM usage, they can also AOT-compile the libraries for even lower RAM usage and significant loading speedups.

Pros:

• Increases website security
• Significantly speeds up loading (if implemented correctly)
• Significantly lowers RAM usage (if implemented correctly)

Cons:

• Browsers need to implement it correctly if they wanna take full advantage of what this allows. Most browsers do already have a bytecode cache, which they could use for this, which would reduce loading times, but that won’t be enough for lowering RAM usage. Further work would be needed to add shared JIT state for such URN-based libraries, thus using the same JIT-compiled code for all webpages and significantly reducing RAM usage.

this idea seems to keep bubbling up every few years … https://stackoverflow.com/questions/3279091/why-web-browsers-dont-have-jquery-built-in … and i’m fairly sure arguments against this sort of thing haven’t changed dramatically either

TC39 is working on a javascript-standard-library that proposes adding higher-level libraries to the browser. Is this something that can be used for what you’re proposing?

https://wicg.github.io/kv-storage/ is being deployed as a built-in module as an example.

Please re-read, I’m asking for a locally-served embedded CDN for popular JavaScript libraries, with some extra semantics like enforcing semver for the purposes of not being forced to include all historical versions of the included libraries (thus also forcing bugfixes onto webpages), as well as optional AOT-compilation to further reduce RAM usage and load times.

A lot can be optimized when you control the whole CDN. Moving the JavaScript CDNs into the browser is really the way to go.

Why is a locally-served embedded CDN required for this when there is already an effort to support builtin modules in the browser? If performance is an issue with JS files served via a CDN, you can easily cache the resources.

This is already possible using various available means.

At Chrome, Chromium DevTools local scripts can be loaded at Sources => Snippets => New snippet => write script in center text area => give snippet a name => right-click on name of snippet at left panel click Run.

Alternatively simply use <script src="file:///path/to/local/script"></script>.

decentraleyes (browser extension) makes webpages snappier but doesn’t reduce memory costs associated with loading the same scripts multiple times. additionally they still have to be parsed and compiled whereas a built-in browser solution would be able to skip those steps.

what part of that doesn’t make sense? why don’t other ppl understand the benefits of this?

Do none of the alternatives meet the requirement? Which browser are you targeting? At Chromium you can currently utilize requestFileSystem() to store arbitrary data associated with a specific domain.

At both Chromium and Firefox it is still possible to load resources from the local filesystem from file: protocol using XMLHttpRequest() (--allow-file-access-from-files flag necessary at Chrome, Chromium).

what part of that doesn’t make sense? why don’t other ppl understand the benefits of this?

Cannot speak for anyone else. Do not mandatorily use any particular library. Therefore do not need the browser configuration folder to store any one library. Though if that was needed could use requestFileSystem() or XMLHttpRequest() or simply load the file or directory with <input type="file>. Since Native File System is now implemented at Chrome, Chromium one or more directories (local "CDN"s) can be selected from the local file system. Meaning the user takes the responsibility to download, modify and make available the libraries they intend to use, then that code can be loaded from their own local filesystem, instead of including libraries in the browser by default that might not be used at all by the user.

jQuery, React, Angular, etc., i.e. “popular” libraries, from perspective here, do not necessarily bring any capability to the browser that is not already possible using code shipped with the browser (HTML, DOM, JavaScript).

If there is a proposal to be made for shipping certain code with the browser would contend that shipping local speech synthesis, speech recognition code - and exposing the already shipped media decoders, media encoders, media container writers code to the user for possible modification would be of at least equal benefit relevant to shipping jQuery with the browser, which do not currently have any need for at all.

Definitely agree with the above comments. We don’t need jQuery to be stored in the browser — it would be competing with features already available in modern browser APIs. However, I do think the web could benefit from having builtin, higher-level libraries baked into the browser, which is already being done (see link I posted above).

Maybe its worth exploring what specific features from the libraries (like jQuery, Angular, etc) you would want available locally in a browser and propose those to browser implementers?

See also

• Service Worker Sample: Cache Video Sample
• Lab: Caching Files with Service Worker

I want what’s known as “please optimize RAM and daily bandwidth usage”. Both of which are extremely important on mobile, but desktops also benefit from the former.

The browser uses 20GB of RAM because every website is loading its own jquery from its own CDN and the browser can’t do anything to optimize it all into one because it doesn’t control any of those resources. Additionally if a few of them do share a CDN they are exposing the user to third-party tracking. And in either case it’s a waste of mobile data, which tends to have caps regardless of where you live. In general, resources aren’t unlimited yet, with the exception of storage (256GB SD cards are a lot cheaper than they used to be, you don’t have to suffer with your videos on internal storage anymore). Please optimize for it.

I love y’all but if you focused the efforts you’re going through to put an end to this optimization idea towards actively preventing web developers from using jQuery etc such that this idea isn’t needed then the world would be a better place.

If the concern is simply browsing site which request scripts that consume resources it is possible to

• Turn off JavaScript entirely while browsing on a handheld device.

• Use Lynx to browse the Web, which does not support JavaScript.

• Clear cookies, cache, storage after navigating away from the page.

What happens when the stored version of jQuery is different from the version of jQuery used by the website? Will a request need to be made at each load of the site to determine if the locally stored version is the same as the site is using at that moment?

The Web is insecure. How is the claim of increased website security substantiated?

Speed could be affected. Though to substantiate such a claim would require testing variations at the same machine. What tests have been run to verify that loading a local resource - at different browsers on the same machine - “Significantly speeds up loading”?

Am not certain how RAM usage will be decreased where the same amount of code is loaded into the browser whether the request for scripts is local or remote? (Though this could very well vary depending on how the specific browser implements reading and potentially storing in memory local files)

If website uses jquery 2.0 and browser ships jquery 2.1, website gets jquery 2.1 as specified by semver.

this reduces RAM usage through shared memory - rather than loading many copies of the same thing (and it would be the same thing with help from semver), we can load it once into a shared space and reuse it as many times as needed.