So, I recently made an Issue on the official HTML repository, whatwg/html, titled with a similar name, #8121, "Suggestion: You should be able to load module-scripts in the file:// protocol.".
But, rather than go in-depth onto why I think we should allow this, I'm going to reiterate over my list of reasons why this should be supported.
If you want to read a more in-depth description and reasoning you can read the Issue.
- In the end module scripts have the same effect as loading in multiple dependencies through
<script src=""></script>. - For every HTML file that relies on a dependency you must write out all the
<script>tags needed to point to every required file, and the scripts have to all be in dependency-resolution order. - It will be hard to debug if you have a lot of dependencies and miss one file or have a typo.
- You can't have any of your scripts, dependencies or your main JavaScript files, be
asyncor you risk them loading in the wrong order. - Testing JavaScript code, especially packages, is more difficult without easy access to modules.
- The ES6
import/exportsyntax looks way nicer than a bunch of<script src=""></script>s being spammed. - It can confuse people who don't know about CORS, especially for someone who doesn't understand why this would be an error in the first place.
- It already has been the source of confusion as at least three StackOverflow articles have been created on the premise of "Why doesn't my module work in the browser?".
- Almost no changes need to be made for it to be utilized by browsers (or by web developers).
- The only reason it isn't allowed is because "New features shouldn't be allowed to get around CORS. No exceptions.".
Top comments (1)
As I stated in a comment I made, an eleventh (11th) reason for allowing module scripts in the
file://protocol would be that it could be helpful for website or graphic design classes where you're making a website and then you learn modular programming on the side.