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?
Pre-Processors vs Pure Web
javascript;programming languages;html;css;web
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 shiftIn 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 optimisationYou 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 levelThe 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)ConclusionUsing 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.