An in-browser loader, bundler and dependency injection builder (using@gardenhq/willow)
Currently a usable work-in-progress.
https://greenhouse.gardenhq.io/o/
- Promised/Asynchronous true dynamic-import loading (via TC39
importorSystem.importlike syntax) - Synchronous static loading (via CommonJS/NodeJS like
requiresyntax) - Local and remote/CDN include paths -
/node_modules/(or other local path) orunpkg - Node-like
__dirname,__filenamefor both synchronous and asynchronous modules. - ES6 module support (only during development, bundling required for your final build as per other bundlers)
- True dynamic-imports
import( "a/" + path + "/" + here + "/module.js" ).then() - Super fast file-watching/live-reloading (file watcher configuration required)
- ES6 transpiling (via Babel), including ES6 modules
- ES6 scope-hoisting/tree shaking (via Rollup)
- Traditional static
requirebundling - Minification (via UglifyJS)
- Sourcemaps (only required for ES6 transpiling)
- 'Safe', in-browser execution and support for environments where no CLI is available (sensitive environments, iOS)
- Zero installation (just use a single script tag, but you can also use the traditional
npmroute if you like) - Almost zero configuration (apart from scope-hoisting which currently requires the addition of a single HTML attribute to your script tag, and file watching set up)
- 'Install size'
- Loader only: ~3kb (can be made smaller by omitting static/synchronous Node-like loading support)
- Bundler (needed during development only): ~400kb, half of which is babel. For comparison,
webpack/browserify/requirejsare ~10MB
- 100% Bundled runtime size:
o~424 bytesbrowserify~415 byteswebpack~243 bytes
Here's a green 5x5 pixel jpeg saved at 50% quality, to give us a 628 byte jpeg.
A CLI with Node is entirely optional, and not required at all. You can get going with module loading with a:
<scriptsrc= "https://unpkg /@gardenhq/[email protected]/o.js"></script>
OR (if you want to use npm/yarn)
<scriptsrc= "/node_modules/@gardenhq/o/o.js"></script>To be able to bundle (amongst other things - live reloading, transpiling and more), use the dev version. This is most likely what you want.
<scriptsrc= "https://unpkg /@gardenhq/[email protected]/o.dev.js"></script>
OR (if you want to use npm/yarn)
<scriptsrc= "/node_modules/@gardenhq/o/o.dev.js"></script>View a 'Hello World' here.Click the [Bundle] button to bundle.
For ES6, transpiling and minification is all done in the browser with Babel and/or Rollup and UglifyJS. You still don't have to use Node or install/configure anything extra, apart from a single HTML attribute on your script tag if you want to switch to Rollup for ES6 imports.
Once you are bundled you can removeocompletely and just load your bundle.
<scriptsrc= "bundle.js"></script>Small CommonJS-only bundles with less than ~50 moduleswill be slightly bigger thanbrowserify(a couple of hundred bytes)at least for the moment, but bundling withoalso gives youresolve,__dirnameand__filename,dynamic-imports etc etc, and of course the ability to write javascript without installing/configuring anything. On the other hand, in some initial comparisons we did with a larger bundle withrequire( "react" )anobundle came out smaller than abrowserifyone. Roughly it seems, once you get over ~50requires,obecomes smaller thanbrowserify.
ES6 transpiling sizes are similar towebpackandrollupas we userollupfor scope-hoisting and tree-shaking.
ocan be used to load traditional CommonJS/noderequirebased scripts using the synchronous runners.js.s.jssimply contains theowrapperand an emptyprocessfor scripts that assume its available. You can change this functionality by simply creating your own 'runner'. This is the equivalent ofbrowserify./your-entry-script.jsetc.
<scriptsrc= "https://unpkg /@gardenhq/[email protected]/o.dev.js"
data-src= "https://unpkg /@gardenhq/[email protected]/s.js#./your-entry-script.js"
></script>// your-entry-script.js
constrequired=require("./module");
// etc etcThings get far more interesting when used with@gardenhq/willowwhich is whyoexists. The fact thatoalso works as a 'common or garden' module loader is a bit of a by-product.
ohas another 'runner' for loading and building javascript container configuration files,b.js.
Essentially you can write your app something like this (here in yaml, but you can also use json or a javascript module):
<scriptsrc= "https://unpkg /@gardenhq/[email protected]/o.dev.js"
data-src= "https://unpkg /@gardenhq/[email protected]/b.js#./container.yaml:main"
></script>#container.yaml
app.main:
callable:"./index"
arguments:
-"@react"
-"@react.dom"
-"@app.some.nice.logic"
app.some.nice.logic:
class:"./LogicCalculator"
arguments:
-"@app.data:property.a"
-"@app.data:property.b"
app.data:
object:"./someJsonMaybe"
react:
object:"react/dist/react.min.js"
react.dom:
requires:
react:"@react"#inject our @react service when we encounter require( "react" )
object:"react-dom/dist/react-dom.min.js"
// index.js - ES6. As pure as the driven snow - no yellow imports
exportdefault(React,ReactDOM,instanceOfLogicCalculator)=>{
///
}// index.js - CommonJS. Almost as pure as the driven snow - no yellow requires
module.exports=function(React,ReactDOM,instanceOfLogicCalculator)
{
///
}Seehttps://greenhouse.gardenhq.io/o/examples/yaml/index.htmlfor a working example of yaml usage.
Everything is loaded asynchronously, and your index.js file will only execute once its arguments (and their dependencies) are all available. Your arguments can be local in node_modules, on a CDN, or on the night bus home from a big night out. Your module will only execute once everything is ready. During development, things are cached, so once you've loaded a file once its available straight away unless you edit it (see reloading). Once you are finished you can bundle, meaning everything is available instantly as you would imagine.
Building your app like this, not only frees you up from a load of plumbing, but also makes everything much easier totestand mock. But if you are here reading this, you probably know that:)
The fact that the container container/injection configuration is completely separate from your code (none of our code is in your code) means you aren't tying your code to anything, apart from a loosely coupled architecture, which has to be a good thing:)
If you don't want to use unpkg as your 'node_modules' you can of course installolocally and use it as you would think (change your script tag to point to your local file innode_modules/.
npm install --save[-dev] @gardenhq/o
You can also use it for backend javascript work, again where the 'unobtrusive', no lock in dependency injection builder shines.
See the docs for more info, or have a look herehttps://github /gardenhq/o/tree/master/bin/ofor a quick example.
Please take some time to read the docs (also a work in progress:) ), and don't be scared to ask!
ISC License
Copyright (c) 2017-present, GardenHQ[email protected]
Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.