Then we can all eventually move forward from this mess of non-standard module formats and loaders.
import Vue from 'vue'
import jQuery from 'jquery'
global.jQuery = jQuery // to get the next line to
work
import Bootstrap from 'bootstrap'
import 'bootstrap/dist/css/bootstrap.css'
Then my head explodes. Why would importing a .css file from my JavaScript ever be a thing supported by any tooling. What is that line trying to communicate? What does it even mean to my current scope? (hint: nothing)import became a giant "do something cool on this line" that maybe the tooling you're using knows how to translate via (say) a webpack loader.
For anyone wondering, that line gets translated to the browser dynamically including css on the page.
The way I typically thought of dependencies with browsers was to bundle them all together. Is there some new solution to this problem?
But to appropriate someone else's full exact name for another purpose is kind of rude – especially if that person makes their living from their public image/name.
"Johnny"
1. lazy-loads files
2. handles JS/CSS/images
3. handles nested dependencies
4. makes it easy to manage dependencies among team members
5. is extremely lightweight
I realize that many teams use RequireJS to manage dependencies but I saw an opportunity to make a library that could accomplish many of the same things but with a much smaller footprint and a simpler API. I hope you'll give it a try and let me know what you think!When you use that, you have dependency management supported by the browser natively.
In that light, are custom dependency loaders still needed?
var exports = {};
function require(modname) {
if (modname == 'jquery') return $;
else if (modname.startsWith('.')) return exports;
else { console.log("Unknown require()", modname); return exports; }
}
(Of course you've gotta <include> the modules ahead of time -- I actually use this for http://8bitworkshop.com/)