Why are preprocessors so divisive?

The genesis of this post is from a disagreement between me and a co-worker on the use of Sass CSS. This was during a project where as the UI Architect, I had decided on using Sass CSS. After a designer was brought on board, he did not want to use Sass. The discussion went something like this:

• Designer guy: I am not familiar with Sass CSS
• Me: Here is some information on it.
• Designer guy: Compile my CSS? I don’t want to compile my CSS.
• Me: Just use the ‘watch’ feature
• Designer guy: I can’t debug my CSS in the browser.
• Me: Use FireSass (For Firefox only)
• Designer guy: I don’t want to use Sass CSS
• Me: WE ARE USING SASS
• Designer guy: Sass is just a fad
• Me: We are using Sass

Multiple meetings were held that followed the same pattern as above. Looking back, I wish the discussions had gone a different way. Not in the sense that who was right or wrong but in the sense that it  could have been handled better. Introspectively, I could have done better.

Later on at the Backbone Conference in Boston, there were a couple of presenters that made statements like “CoffeeScript, you either love it or hate it”. This got me thinking, why should that be? Why are we in such polarized opinions when it comes to pre-processors in front end development? We are not the US Congress or the Senate for that matter. This got me thinking and started me on a path to find a peaceful solution to this issue.

Can you define pre-processors please?

In researching for this blog, I looked up the word pre-processors and found a lot of information. Wikipedia defines it as:

“In computer science, a preprocessor is a program that processes its input data to produce output that is used as input to another program. The output is said to be a preprocessedform of the input data, which is often used by some subsequent programs like compilers. The amount and kind of processing done depends on the nature of the preprocessor; some preprocessors are only capable of performing relatively simple textual substitutions and macro expansions, while others have the power of full-fledged programming languages.”

By this definition, any work done on the code before compilation is the job of the preprocessor. There are two types of preprocessing:

1. Lexical: This is typically macro substitution, text inclusion, conditional compilation, etc…
2. Syntactical: Syntactical preprocessing’s role is to transform syntax trees according to user defined rules.

In the realm of front end development, most of the pre-processing tools are of the syntactical type. However stepping out of the computer science field, preprocessing exists in many areas of our lives. Couldn’t any encryption or decryption of code be considered as a preprocessor to gaining the underlying information. When a court stenographer types all the information in the court, wouldn’t that be considered a form pre-processing? How about short hand notes?

What tools are available?

In front end development, there has been an increase in the number of preprocessing tools thereby causing a bit of a polarized attitude towards them, not just whether to use any preprocessing tools but also which one. The tools that are available are as such:

• HTML
  • HAML: (HTML Abstraction Markup Language) is a lightweight markup language that is used to describe the XHTML of any web document without the use of traditional inline coding. It’s designed to address many of the flaws in traditional templating engines, as well as making markup as elegant as it can be.
    
  • Jade: Jade is a high performance template engine heavily influenced by Haml and implemented with JavaScript for node. http://jade-lang.com/
  • Zen-coding: In this post we present a new speedy way of writing HTML code using CSS-like selector syntax — a handy set of tools for high-speed HTML and CSS coding. It was developed by our author Sergey Chikuyonok.
• CSS
  • Sass/Compass: Sass is an extension of CSS3, adding nested rules, variables, mixins,selector inheritance, and more. It’s translated to well-formatted, standard CSS using the command line tool or a web-framework plugin. Compass is an open-source CSS Authoring Framework.
  • LESS: extends CSS with dynamic behavior such as variables, mixins, operations and functions. LESS runs on both the client-side (Chrome, Safari, Firefox) and server-side, with Node.js and Rhino.
  • Stylus
• JavaScript
  • CoffeeScript: CoffeeScript is a little language that compiles into JavaScript. Underneath all those awkward braces and semicolons, JavaScript has always had a gorgeous object model at its heart. CoffeeScript is an attempt to expose the good parts of JavaScript in a simple way.
  • IcedCoffeeScript: IcedCoffeeScript is a superset of CoffeeScript. The iced interpreter is a drop-in replacement for the standard coffee interpreter; it will interpret almost all existing CoffeeScript programs.
  • Dart: Dart is a new web programming language with libraries, a virtual machine, and tools. Dart helps developers build structured modern web apps. Dart compiles to JavaScript to run across the entire modern web.
  • GWT: Google Web Toolkit (GWT) is a development toolkit for building and optimizing complex browser-based applications. GWT is used by many products at Google, including Google AdWords and Orkut. It’s open source, completely free, and used by thousands of developers around the world.

How to argue correctly about preprocessors

At the Boston Backbone Conference 2012, Andrew Dupont had a great presentation about “How to argue about JavaScript”. This was a result of the famous discussion about semicolons – between Douglas Crockford and the world. Andrew outlined some great strategies and tactics to use when having a discussion (which I will shamelessly steal).

A lot of the times, we enter a discussion holding steadfast to our position and we feel that if we budge even a little bit then we have lost. This is unfortunately mirrored in our political environment and may give us a slight albeit wrong justification.

“In science it often happens that scientists say, ‘You know that’s a really good argument; my position is mistaken,’ and then they actually change their minds and you never hear that old view from them again. They really do it. It doesn’t happen as often as it should, because scientists are human and change is sometimes painful. But it happens every day. I cannot recall the last time something like that happened in politics or religion.”

Carl Sagan

When entering a discussion, one should consider approaching it as a scientific discussion vs. a political debate. Here are some more tactics and guidelines.

Discussion goals and tactics

On August 20th 2012, after hearing Representative Todd Akin’s comments regarding ‘Legitimate Rape’ saddened me as an American and human being. So I decided to post my thoughts on Facebook:

What started as an attempt to be diplomatic while expressing myself, ballooned into a full fledged political discussion. What made it worst was a comment from a friend:

The photo in question is this:

This was just a landmark in Seattle and being a proper tourist, we decided to take picture with it. That’s all. However this is an example of how discussions can get out of hand. In our community, the development community, we have plenty of vitriolic discussions. Let’s not forget the Semicolon war of 2012 or the selective tragedy of 2008.

I try, everyday I try to better myself especially when it comes discussions like this. The following are some of the tactics that I use in order to improve (these are mostly excerpt from the book “Getting to Yes negotiating agreement with giving in” by Roger Fisher and William Ury).

Goals of an argument

An argument/discussion has three goals:

• It should produce a wise agreement, if possible
• It should be efficient
• It should not damage the relationship between the parties

Looking back at my interaction with “Designer guy”, I should have outlined and presented the reasons behind the use of Sass better or tried to reach a compromise for example let’s try it out for a while (a week or two) and re-visit this discussion then.

Tactics for an argument

• Separate the people from the problem
• Focus on interests, not positions
• Invent options for mutual gain
• Insist on objective criteria

In my example, I should have outlined our goals e.g. better development methods which is also a common goal and common interest.

Discussion preparation

When entering a discussion prep yourself in the following manner:

• Retain the willingness to be convinced
• Imagine where others are coming from
• Account for your own taste
• Account for your own emotions

Take a deep breath

When in a discussion follow these rules:

• Be nice
• Speak with surgical precision
• Be honest in your characterizations
• Don’t rise to the bait of others vitriol

If you see me taking a deep breath and counting to 10 (in my head), don’t take it personally.

Conclusion

I consider myself a work in progress when it comes to civil disagreements. However there will be times that one will have to walk away from a discussion. Don’t be afraid to do that, time will sort out the right from the wrong.

Further Reference

• Nicole Sullivan’s “Don’t feed the trolls”