Stick around, because at the end I'll be asking a very important question; "Is JavaScript only used in the file: protocol for backwards compatibility nowdays?".
Background
So, in my argument for why I believe ES6 JavaScript modules should be allowed in the file: protocol, I restate what a member of the WHATWG, Domenic Denicola, said about JavaScript being allowed in the file: protocol:
This prompted me to ask the question in the title and mentioned above because to me it seems like there are so many more uses.
Modern Uses of JavaScript in The Browser
JavaScript is used for a vast majority of things nowdays.
While it's true that one of its uses may have been, and probably still is, backwards compatibility, I feel like the apple has fallen further from the tree than that.
For example, I have a project called TracerRacers, an unfinished class-project that was meant to be a game, a good example of something using JS for something other than backwards compatibility; it even features the HTML5 <canvas> element, which definitely removes any chance of the JavaScript having been used for backwards compatibility.
JavaScript can also be used to create interactive electronic-documents, documents with small programs embedded inside that run when you interact with an element in it.
This makes HTML, CSS, and JavaScript a good way to parity PDF documents.
One more usage of JavaScript is for saving offline copies of websites.
Sure, while I understand while a lot of the functionality is cut, it makes archiving and using the offline version of a site easier when things "just kind of work".
Expecting JavaScript to Stay Limited to Backwards Compatibility
I believe the expectation that JavaScript is being used in the file: for backwards compatibility, especially nowdays, is absurd.
If Domenic's initial guess of XHR was correct for when they put a "CORS-lock" on new JavaScript, that means it's still being used in the file: protocol sixteen (16) years later, as they were standardized in 2006.
A “Snide” Comment
[I put "snide" in quotes because I'm unsure of the true intentions, but by the dictionary definition it does appear "snide"; showing disappointment or disapproval.]
When creating my GitHub Issue defending JS Modules one of the first responses was from Anne van Kesteren, the same person who edited the documentation for the XMLHttpRequest, remarks:
And, I suppose I owe it to this and Domenic's comment that I'm making this post here before you.
I feel like I'm getting ridicule for using the file: protocol.
Though, a weird oddity is that I never implied file: URLs were "important" per se; I was just using the file: protocol because that's the easiest way to code with JavaScript if you don't have an environment like Node, especially if your JavaScript interacts with HTML elements, which would require you to jump through hoops with a JavaScript environment.
Another thing Anne mentions is that file: URLs should be less necessary to deploy applications.
I haven't went through the whole webapp deploying process without having my hand held by a hosting service, but I would believe that file: HTML documents with JS aren't a necessity as it is. Tell me otherwise in the comments if it is.
Reading Between The Lines
Between Domenic's:
That's why, from our perspective, making module scripts bypass the CORS protocol (and thus the same-origin policy) is a non-starter. It's not about a specific attack scenario, apart from the ones already enabled by classic scripts; it's about making sure that new features added to the platform don't also suffer from the past's bad security hygiene.
and Anne's:
If anything I think we should invest in making them less necessary to deploy applications.
I want to pose the question to the WHATWG, that if I were to make an open letter to them,
Why didn't you just remove JavaScript from the
file:protocol? It wouldn't break the web because everything runs on a server or via thehttp:/https:protocol, so everything is well and good there.
And if you didn't want to remove JavaScript from thefile:protocol, why wouldn't you just adapt your standards to account for the fact it can be used there? Locking things arbitrarily with CORS, in my opinion, is not a good solution.
Posing The Question
After all of this, I'd like to hear what all of you web developer's have to say.
I'd like to hear your thoughts about whether JavaScript is still being used for backwards compatibility in 2022 or if you think it's matured past that point.
Is JavaScript only used in the file: protocol for backwards compatibility nowdays?
Top comments (2)
I've been a 'dabbler' for 40 years, and in the early days, enjoyed making small projects on my desktop, when you could replace your desktop with a HTML file, I would build my own GUI for my machine, links to regular folders, open files, etc.
Once CORS blocked this, I couldn't do it anymore, I would forever be blocked from making small projects, tests, queries, ideas, because of this dang CORS issue with local files.
I managed to use machine Learning and AngularJS to create 'living beings' who added functions to their internal array based on the results of attempting to do something - all from a local file. but I had to jump through hoops to get it working. I don't have a server, I don't want node, I just want to run a html file locally. And yes, sharing with others is a pain.
Now, I use
import("yourfilehere").then(imported => {
lib = imported.libName;
});
to pull in external modules from external sources to stop the modules error, but I'm still stuck on anything local being imported. So many projects lay in wasteland because of this.
Oh, and here's a use-case: I have a laptop, I have solar, battery, I'm on a remote island, without internet. I have a browser, I can write any program I can think of, but I can't use the internet to get node, to get a local server. I can only write in a text editor, and load in the pre-installed edge.