2

It seems like within the last few years or so HTML/CSS/JavaScript Preprocessors have exploded in quantity and general use. They're still not as common as pure HTML, CSS, and JS/jQuery, but their overall popularity seems to be growing if sites like CodePen are any indication. After reading up on tutorials for Haml, Jade, SASS, Coffeescript, etc. I'm honestly slightly confused. They all have benefits, understandably, but really they seem like very short-sighted languages. With the exception of SASS/SCSS it seems like simple things like creating div tags in an HTML preprocessor or adding events in a JS preprocessor are made very, very simple, but then when you get into more complex functions or template creation, they become even more complex than the languages they're processing for.

All in all without the innate browser support that I doubt any of these preprocs will get none of the languages, to me, feel like they are in the running to fully succeed anywhere outside of their established user base. My issue is that I don't even see a benefit to really digging into any of the preproc languages. Using them I could make a website from the early millenium pretty easily, but really if I need to create a modern site it seems to be a waste of time to get in the know with any of them whereas I could just code it out with HTML/CSS/JS(JQuery).

My question is - Am I missing something in the larger scope of it all? What are the benefits to using these preproc'd languages, especially given the fact that they're not browser supported? As a web developer is it worth it to spend time to learn any of them?

closed as primarily opinion-based by user40980, jwenting, Dan Pichelman, Bart van Ingen Schenau, GlenH7 May 14 '15 at 17:36

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 5
    A lot of people don't like HTML/CSS/JS. Personally, I go as far as to say that all three are pretty bad. Because of this, people don't want to use them. Now, what's easier: writing a preprocessor, or convincing Google, Mozilla, Microsoft, and Apple to all add support for ClojureScript, LiveScript, TypeScript, LESS, SASS, HAML, or WhateverScript to their browsers? – nanny May 6 '15 at 18:39
  • @nanny So what you're saying is that preproc languages are an alternative but don't necessarily offer any outstanding benefits to someone who's comfortable with pure web? It's an aesthetic/syntax choice? – zfrisch May 6 '15 at 19:26
  • I'm not sure how you reached that conclusion. @nanny is saying that compiling to HTML/CSS/JS allows new languages to be immediately usable without forcing every browser to support it. – Doval May 6 '15 at 19:33
  • 1
    @zfrisch It's not just aesthetic/syntactic, much of the time it's functional. For example, TypeScript adds static typing for people that don't enjoy the pitfalls of JS's type system. Also, (sane) CSS variables is more than enough reason to use a CSS preprocessor, imo. – nanny May 6 '15 at 19:44
6

I see plenty of reason why you should embrace pre-processed languages, and I'll try to demonstrate the benefits of those tools.

1. Paradigm shift

In my opinion, the greatest feature of any pre-processed language is the ability you to develop and solve problems in a different mindset compared to the standard HTML/CSS/JS way. In short, pre-processing can lead to (but not always) a paradigm shift.

Why is it powerful ? Some problems are easily solved in one paradigm, some in another paradigm. What's powerful is that you can create any paradigm and convention that maps to HTML/CSS/JS to efficiently solve a particular problem.

The most known paradigm shift is made by C compilers, transforming easy to write C/C++ to efficient but hard to write ASM.

In theory, you could create a mapping between sufficiently complex CSS and JS, any CSS-aware designer could then use JS through well known tools.

2. Offline optimisation

You don't need to be pre-processed to shift paradigm, jQuery is paradigm-shifting at runtime. What's awesome with pre-processed tools is that the cost is (mostly) invisible at runtime.

Using compiled language compared to a library or a run-time toolkit is, in my experience, always better in term of final performance. This is very intuitive, if a piece of code is compiled once into optimised low level code without any dependency, it should perform better compared to the same piece of code executed at runtime by a library.

This is not new at all, compilers were the first (as far as I know) to introduce this kind of transformations and the first to introduce optimisations. This technique was proven efficient many time in the past in non-web environment.

3. Polyfill at the language level

The web world is browser based (boom! mind blown!), these browsers are updated and deployed at different pace, most web developers may have to deal with outdated browsers one day or another.

Up until now, many great libraries managed to fill those gaps for us. Yes, i'm thinking about the great mighty jQuery, many thanks to those who contributed to this awesome library. The problem is that library can only be written inside the scope of the language they're written in, and unlike in ruby, you can't meta-program everything in JS. Sadly, browsers still can't understand ruby.

This is applicable primarily to JS but also valid with CSS and HTML. To implement a new keyword or a new language structure (to solve problems faster, paradigm shift and stuff), you have to use pre-processing. Pre-processing sets you free from many kind of limitation inside the language, unlike libraries.

Want to use the new ES6 right now because your code will be more maintainable than ever? You can! Want to stick with your programming language and target a browser anyway? You can! (use emscripten).

4. Because we can (in a reasonable amount of time)

As the time of writing, compiling (SASS or Coffeescript in my case) is no longer a pain, it's instantaneous and can be triggered on file save with the right toolchain. The build toolchain has evolved too, we see more and more great developer tools like bower, yeoman, gulp, ...

The frontend developer is now armed with a mature toolchain and is ready to tackle every common problem in a matter of seconds. Easy to install and maintain, your build tools and processes should be part of your project and should now be ready to accept a pre-processing step. (even if you only uglify)

Conclusion

Using compiled languages/tools is no longer a pain, and you should use any tool that fits your needs. The fact that it needs to be compiled shouldn't be a blocker.

5

The overarching theme of your question seems to be succinctly summed up in the last paragraph: "What are the benefits to using these preproc'd languages, especially given the fact that they're not browser supported?"

What's fantastic about preprocessors is that they don't need to be supported by the browsers. They are taking the non-native-web input and then transforming it into something that the browser understands.

Why not use vanilla HTML, CSS, and JavaScript? The simple answer is to save you time. That's why preprocessors exist.

Some may save you time by creating fallbacks for older browsers automatically. Some may save you time by creating a more maintainable structure than HTML, CSS, or JavaScript alone. Some may save you time by checking for errors when you compile.

Sure, these preprocessors each have smaller user bases than the core technologies of the web. But that's ok. You are making websites for end users on the internet to see, not just for those who know Sass. At the end of the day, after all the preprocessing, it is only HTML, CSS, and JavaScript at the end.

Also, don't feel like you have to lump them all together - some preprocessors are great, some are not as great, some probably suck.

Pick the ones that make sense for you and your projects.

Not the answer you're looking for? Browse other questions tagged or ask your own question.