In a quickly mutating world of web software development, preprocessors are rapidly becoming the new emperors of the land. And they are steadily carving a grand new path out of a somewhat ancient and rocky past. Let’s talk about how preprocessors are reinventing the ways we are writing, debugging, and even thinking about code for the front-end, and now, similarly, the back-end too.
Generally, when we think of preprocessors we mostly associate them with LESS or SASS compilers. At least, we all should by now. But there are also preprocessors for HTML templating too.
Hated by some, loved by others, HAML is an HTML abstraction markup language that functions as a replacement for inline templating systems such as PHP, ASP, and ERB. It is mostly used in Ruby on Rails applications where explicitly coding HTML into the template should be avoided. HAML can be complied down to standard HTML or ERB respectively and is found to be very easy to learn and understand for newcomers.
Alternatively there is Slim, a template language that aims to reduce the syntax of essential parts of HTML markup without becoming too cryptic. Very much like HAML, Slim relies on tab-strict markup and is a strong replacement for ERB. Though, I find Slim to be a much cleaner syntax and easier to use overall, I don’t think it has picked up as much traction as HAML.
In the realm of CSS, we have SASS. We all know and love SASS. If you don’t, maybe you should read Falling In Love With Sass. It has become a staple in my daily routine because it helps in maintaining the large CSS codebases I encounter. While it’s similarity to CSS makes it easy to learn and use, it’s real power lies in the concept of Mixins, Functions, and Extends.
Compass (For Sass)
Compass is not so much a preprocessor as it is a plugin to be used with your SASS routine. What Compass does is provide a massive library of Mixins and Functions to help promote writing fewer lines of code from the start. To go even further, Compass attaches all of the browser specific pre-fixes for Webkit, Microsoft, Safari, etc., to provide the best compatibility across all major browsers.
Inspired by SASS, Stylus is another interesting alternative. It’s a simplistic stylesheet language built on node.js and is able to run live in the browser. I find this feature really cool and could see it being very useful. Again, Stylus is not as popular as the others, mainly due to the lack of partials, as well as missing out on the support of accompanying frameworks like Compass.
EQ CSS (Element Queries)
Now this just might be the holy grail of innovation for me at the moment. EQCSS, or element queries, are an inspiring concept that takes the preprocessing paradigm to stellar new heights. Though not actually a preprocessor, I am mentioning this to show how quickly we are moving towards on-the-fly processing in the browser. Element queries are a new way of thinking about responsive web design. While CSS media queries act on the width and orientation of the page, element queries are relatable to the content and elements on the page. Without going on a tangent about how much I love EQCSS, I strongly suggest checking it out and trying it out for yourself.
One of the first successful higher-level JS languages, CoffeeScript, also compiles down to JS that the browser can understand while leveraging the power of modern JS features before they are implemented in the browser.
Debugging in the Browser
With all of these wild new innovations in preprocessing, we also introduce some interesting problems. Debugging processed code can be somewhat challenging. But never fear; there are, of course, debugging solutions for even the most heavily processed code. Now days, browsers include debugging tools as standard and are readily accessible on the UI. It’s as if they have been preparing us for this for years.
Browser Development Tools
Development tools in the browser are a great way to debug your code as it is displayed in the various available clients. But this is not always enough. Preprocessed code is often minified and concatenated into one single file. Even when it’s not, it can be next to impossible to track down where a problem exists in code that does not mirror your local files.
React Development Tools
As mentioned before, sometimes we need more than just our browser’s development tools. A good case in point would be when debugging compiled React markup. To do this we require a plugin available for Chrome and Firefox browsers, called React Development Tools, which lets us drill down into the React markup, as opposed to the HTML rendered to the client. Much like source maps, this tool allows us to trace problems back directly to the source code.