js preprocessing still?

For a long time I stood firm in the belief that since web browsers know JavaScript and CSS, everything should be written in vanilla JavaScript and CSS. No fancy pre-processors and no crazy sourcemapping for debugging.

grunt then gulp

Grunt was my entry drug to pre-processors. I was hesitant at first, but soon started to notice the benefits in simple things like easy minification (no more java -jar yuicompressor.jar [a big ass string]). That inevitably moved to automatic easy minification, followed by string replacements in the index.html for environment variables and the like – you know, good honest misuse.

Soon though everytime I saved a file this juggenaut of automation would sweep through my files and take longer to complete then a swift cmd+tab, cmd+r to reload the browser window. The result was confusion and/or irritation followed by a unknown wait, before trying again.

At this point gulp was the quickness, so obviously rather than change my method I opted to throw the same amount of work gulp’s way. It dealt with it fairly well, reducing the idle time between page refreshes. For a time.

reintroducing negative speed

ES6 entered my life. Everything it makes easier and all the new features it adds makes it hard not to want to use it all the time for all the things. With the added ease of tools like Babel doing all the heavy lifting you don’t need to spend much brain power considering browser compatibility. Success.

Compiling your entire codebase from one version of a language to an older quirkier version every time you save is, as you can imagine, pretty taxing. I’ve again gone back to waiting between refreshes, allowing me to join the compiled club.

xkcd 303

I resigned to this way of life (sword fighting on office chairs) and got on with it.

systemjs

Recently I attended a meetup in which Jack Franklin built a simple app using ES6 Modules (+1), React (+0), SystemJS (+not sure yet) and jspm. It was a good demo and, for me, highlighted a shift back to a time before pre-processors, relying on the browsers ability to process JavaScript.

Of course it’s not as simple as including the JS files you want in your html page, but there also isn’t an overly complicated setup process. I won’t try and explain the process, but I recommend watching the demo to see for yourself.

I’m not saying this is the future, I’ve not tried it out yet, but I do like the seeming shift in attitude away from the monolithic background tasks that have quickly become an accepted part of front-end development.

If you enjoyed the read, drop us a comment below or share the article, follow us on Twitter or subscribe to our #MetaBeers newsletter. Before you go, grab a PDF of the article, and let us know if it’s time we worked together.

blog comments powered by Disqus