Preprocessors and preprocessed languages, are they any good for us?

ProcessingPreprocessors are tools that translate a certain syntax to generate output files for your project. This article talks about what they are and the advantages when using them.

When you’re using all sorts of languages for your project (ie: your hybrid mobile application) you’ll notice that some languages take more code to write than others. Often this is because of the syntax of the language and sometimes it’s just the way you need to define variables, functions, and other stuff.

Preprocessors do nothing more than pre-processing input into another form so that the output can be used as input for another tool. It’s mostly an optimizing step to create something that will be used as input for the end product.

Let’s look at the advantages that some of the preprocessing languages (and tools) bring along that I’ve been working with recently.

Last year I’ve been working on both native- and hybrid apps and came across some nice precompiled languages. Especially in the hybrid (and mobile websites, if you will) projects, these were the next thing to learn (and use) in order to stay ahead with all those ever-progressing technical advancements. Ow! And parallax sliders, don’t forget those! 🙂 …

Web syntax like CSS and Javascript have been around quite some while and got a lot of resistance because of their maintainability and ease of use kinda, well, sucked. CSS did a nice effort on becoming hot and smoking once more with their version 3 and the world could dance the happy dance once more.

But JS still is.. JS.The great freedom (read: room for many errors and typos) that the language brought us also took on its back great responsibilities. Wouldn’t it be way better if you could use less typing to write all those syntax opening- and closing marks,  variable definition, and other and just code actual logic.

Some sweet preprocessed languages

Here’s a little list of preprocessed languages that I bumped into on my hybrid road to mobile enlightenment:

  • Less CSS
    This is a very nice CSS definition syntax to make your first steps into a preprocessed world. It brings easy to use functions called mixins, variables, relative calculations (e.g.: one variable defining all related colors) file imports (less and CSS files) and more. There are a lot of client apps that will watch your files and compile the .less files to CSS and it’s all community backed.
    Some resource links: Less homepageNet project Less compiler
  • Sass
    This CSS definition syntax can be put aside Less (less or more) when you look at functionality. Although there are people that prefer it over Less since it has a more flexible syntax for looping and function definition amongst others. See this post for an opinion on why to choose Sass.
    Some resource links: Sass homepage, tutorial website, Sass for Sublime 2 editor plugin

So, what are the key advantages to use preprocessors and the accompagnied  like the ones above?

First of all, preprocessors create standardized and best-practice output for the target language. Although it is always good to check if the compilers are updated to latest standards (eg: CSS 3) but in general, mainstream preprocessors like the ones above will generate high-quality code conform language standards.

Added features like function definitions and variables in CSS preprocessors make your code-under-maintenance a more maintainable and flexible. You could do stuff like define one color and let all the other theme colors be abstracts or calculated pallets from that one color using Less Or Sass. Not to mention the for loops and function defining features. All good!

Safer variable definitions are one thing, but actually getting an error with line numbers when your CSS definition has gone wrong make it even more powerful than regular CSS to use a preprocessing language variant. Also, the safe variable definition in CoffeeScript will save you a lot of headaches (both during coding and testing).

 And what’s the catch when using this “magic”?

Well, I’ve noticed the biggest catch is that you’ll want to choose a preprocessor (language) that has great community activity, easy to use tooling and enough tutorials and documentation on the web.
The biggest hurdle after that will be to introduce the awesomeness to your team and let them all adopt it as their new way of working. A good presentation/workshop to show off how easy it is to setup and letting your colleagues work on some small but representative examples could do the trick.
Although I guess that if you have colleagues that like to learn new stuff as it comes around and/or don’t mind working with timesaving tools that are not present in the coding partner/supplier’s main-stock then this one will be a less high hurdle to jump.

All there is left for me to say, is that precompilers make up for all the flaws or risks that original languages bear with them, speed up the workflow and are just natural evolutions because the web is growing harder and faster and so is the need to build stuff the right way, in a fast way and leaving a small and maintainable code footprint is key nowadays. Thinking of it, that was always the goal but now cash burning technology and tools just won’t cut it anymore…

Let me know what preprocessor language or tool you worked with and if it worked out for you(r project) in the comments below.