Read on Twitter
As we consider swinging back towards URL based package management* I think it& #39;s important to reflect on why we moved away from CDN and <script src> in the first place
https://abs.twimg.com/emoji/v2/... draggable="false" alt="🧵" title="Thread" aria-label="Emoji: Thread"> (a short thread)
*see Deno& #39;s package management
*see Deno& #39;s package management
There were 3 main issues (IMO) with just hot-linking all your dependencies from a CDN.
1. We didn& #39;t have JS modules
2. We didn& #39;t have imports
3. We didn& #39;t have HTTP/2 (or it wasn& #39;t the standard)
This caused some issues. What were those issues? Great question!
1. We didn& #39;t have JS modules
2. We didn& #39;t have imports
3. We didn& #39;t have HTTP/2 (or it wasn& #39;t the standard)
This caused some issues. What were those issues? Great question!
1. Because we didn& #39;t have JS modules & imports, the libraries we loaded attached themselves to the global scope (window.jQuery). This is less than ideal for 2 reasons: Dependencies aren& #39;t explicitly loaded, and 2) any other dependency you run could mutate a library you rely on.
2a. We also had trouble loading our dependencies in order. See, in the good* old days, we would just load all of our dependencies in order (think waterfall) synchronously.
Example:
<script src=" http://cdn.com/jquery ">
<script">https://cdn.com/jquery&qu... src=" http://cdn.com/jquery-plugin ">
*but">https://cdn.com/jquery-pl... kinda bad
Example:
<script src=" http://cdn.com/jquery ">
<script">https://cdn.com/jquery&qu... src=" http://cdn.com/jquery-plugin ">
*but">https://cdn.com/jquery-pl... kinda bad
2b. But then we started loading JS deps asynchronously, which had performance benefits, but it meant that you couldn& #39;t always depend on dep #1 loading before dep #2.
This is when libraries like RequireJS and LoadJS popped up to help us load our dependencies asynchronously.
This is when libraries like RequireJS and LoadJS popped up to help us load our dependencies asynchronously.
2c. Then eventually we got bundlers like Webpack, which allow us to "import" a JS module into another module, and it takes care of all of the magic behind the scenes to make sure our modules are loaded and run in an order that doesn& #39;t break*
*at least not too often
*at least not too often
3. The last reason, tho I& #39;m sure there are more, is because we didn& #39;t yet have HTTP/2, we wanted to load a single JS file, and a single CSS file, because our servers/browsers weren& #39;t equipped to serve/load multiple files at once.
But now, the landscape has changed:
- We have imports + modules in JS (as of ES2015)
- Imports + modules are starting to work in browsers ( #search=module">https://caniuse.com/ #search=module ">https://caniuse.com/... says ~90%)
- HTTP/2 is the standard (HTTP/3 may be around the corner?)
- We have imports + modules in JS (as of ES2015)
- Imports + modules are starting to work in browsers ( #search=module">https://caniuse.com/ #search=module ">https://caniuse.com/... says ~90%)
- HTTP/2 is the standard (HTTP/3 may be around the corner?)
Now, more than ever, it totally makes sense to reassess whether it& #39;s time to reinvent, or at least adjust, the way we install, manage, transpile, and bundle (or not!) our first-party, and third-party dependencies.
(end of thread)
(end of thread)
