Build processes can be obscure. Especially, if you use IDE’s with heavy automation.
So, read on what might happen after your fast start with Backbone.
PS This post is also a reflection on the critique on “too much automation” in The Pipefishbook, where I discussed tools such as Yeoman or Grunt together with Backbone. These build tools can make sense - but this is another blog post. Short answer: If you work towards frameworks to address many users and platforms, an IDE strategy can help. But prototypes are different.
VIM is an editor from the early 90ies. It has a powerful script engine built-in. With this, you can easily add “mappings” to run certain commands to build some files, or, to start a web server. These commands avoid maintaining “expensive” live-reload processes, and get you almost the same amount of fast feedback.
This mapping defines some meta-key or “leader” such as “,”. The leader key is used to avoid interference with other VIM commands.
With this leader key, you can define mappings to cycle through buffers quickly. For example, you can define a key mapping leader-leader as follows:
noremap <leader><leader> :bp <cr>
The real fun starts, when you trigger a browserify build from another mapping:
noremap <leader>b :!browserify ./app/main.js > static/bundle.js<cr>
And, to start a static web server on a command, I use:
noremap <leader>ss :!ss static <cr>
With these basic commands, you can easily write, edit and build things. No advanced IDE or build processes required.
The main browserify options are:
Bundling modules as external to use “require(…)” from the browser console: This is a nice option to work with e.g. a Backbone.Collection from the browser console, as well as from your app.
Once you browserified your project, and you reference a bundle.js from a HTML file, I like to serve these together with SuperStatic. And, as above, I like to start the server from VIM. This usually serves your app from localhost:3474.
When your build process becomes a bit more complicated, typing long commands is boring and error-prone. This is where Makefiles come in. I usually have a some definitions (= targets) for different browserify options.
ext: ## use jquery as external reference browserify -x jQuery ./app/main.js > static/bundle.js jst: browserify -t jstify ./app/main.js > static/bundle.js eco: browserify -t browserify-eco ./app/main.js > static/bundle.js watch: watchify -t jstify ./app/main.js -o static/bundle.js
Thanks for reading and sharing feedback. Happy hacking.