HTML
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.
HAML
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.
Slim
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.
CSS
SASS (Scss)
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.
Stylus
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.
JavaScript
Now we are beginning to see preprocessors for the likes of JavaScript with Type Script, Facebook’s React and Babel, and the forthcoming and wildly anticipated ES6. Preprocessors are making their way into every facet of web software development and holding strong. I find this to be a good thing but some might see it as just making things more complicated. The thing to take away from this is that these tools aim to steer coding standards in a unified direction.
React (Babel)
Though this section is titled “React,” what we are really talking about here is Babel. Babel is the processor for Facebook’s React, used to compile the JSX language down to standard JavaScript. Think of JSX as a JSON expression language that describes the JavaScript we want to write. The beauty of Babel is that it allows you to use modern JavaScript features of ES6 before major browsers adopt them.
CoffeeScript
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.
Source Maps
For necessary reasons, as a front-end developer, I find myself required to use source maps to aid in debugging lots of joined CSS. But source maps are also relevant in debugging JavaScript. Source maps hold information about your original files, before being compiled, minified, and concatenated. Allowing you to trace a problem back to their source, right down to the line.
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.
Conclusion
Wow, so much to ingest here. You might be thinking, “I had no idea preprocessors had so much agency in the development of web software today.” Well, now you know. They are not just for compiling CSS anymore. And while they are arming developers with advanced local environment chops, we are also beginning to see them pop up as on-the-fly processors in the browser. But with all of these new and interesting toolsets, the single most important thing a developer can have is a solid knowledge of the core language. Be it HTML, CSS, JavaScript, or any other programming language. A preprocessor is only as good as the standard code it outputs. So know your language of choice first. Take advantage of preprocessors second. Thank you for reading. Now go make something.
