As part of working with Node.js I have been using what seems to be the standard template engine Jade, and for the most part it works as expected, however I’m starting to develop a philosophical objection to this sort of technology. One of the promised benefits of using Node.JS is reducing the number of technologies being used on your stack. That means you have to be proficient in fewer technologies in order to built really great stuff. I see CoffeeScript and Jade as completely removing that benefit.
If you use them, you now have to be intimately familiar with their syntax and idiosyncrasies in addition to the underlying script / markup that they get transformed into. It’s not like you’re replacing Javascript with CoffeeScript. If you have to debug anything, you now have to understand both the Javascript and the CoffeeScript in order to try to figure out where things are going wrong. The same with Jade. If you see a problem in the html, it’s not a simple matter of changing the html. You have to mentally convert from html to Jade syntax in order to fix the problem. I see these frameworks as adding a lot of additional complexity when debugging problems for the very short term gain of typing fewer characters.
No one would use C# if you have to be an expert at CIL to debug it! The tools are good enough that you can happily write and debug C# for years without even knowing that there is a CIL and until Jade and CoffeeScript get to that point, they will be more trouble than they are worth.
3 Responses to “CoffeeScript and Jade Templates? No thank you!”
Node wasn’t about reducing the “technologies” on your stack, it is about using server-side JavaScript. The added benefit is that you can now share more code between client and server.
This goal is easily achieved for any experienced hacker. For example: libraries, templates and immutable data. So far this has nothing to do with language. I could use JavaScript and HTML or CoffeeScript and Jade and get this benefit.
Where languages such as CoffeeScript and Jade shine is their ability to require much less code. I can’t emphasize how important that is. Less is exponentially more. It means less bugs, faster development and less code to read for new team members or maintainers.
One CoffeeScript file I wrote last month had about 500 lines of well documented code. It compiled to 1100 lines of undocumented, yet readable, JavaScript. The CoffeeScript lines are also much shorter. Same goes for Jade. I will never write plain JavaScript and HTML again, ever. Yet I frequently read it.
It’s more work debugging at first until after two weeks your mind effortlessly translates from one syntax to the other, the semantics are exactly the same. In the end you develop faster since you have less to write and therefore have less to debug. Your argument that debugging is more tedious, while somewhat true for beginners, no longer stands when you spend less time debugging less code.
Also, your comparison to C# and the CIL is biased. You are comparing a language which compiles to an intermediate representation to a language which compiles to a different syntax of the same set of semantics.
This may not be the best route for beginners, but who wants to code like one forever? Being a polyglot developer only gives you a broader perspective which is always a good thing
I completely agree that writing less code results in fewer bugs. However I do not believe that you are actually writing less code with CoffeeScript and Jade, just fewer characters. That is an important distinction because despite fewer characters, the resulting complexity is the same. Especially if you’re leveraging some of the great Javascript libraries like underscore. With CoffeeScript you’re mostly getting rid of keywords, brackets and cramming complex statements onto a single line for the sake of brevity.
Furthermore, there is a strong case for using symbols for programming constructs over words!
http://www.ncbi.nlm.nih.gov/pubmed/15648466
http://biology.clemson.edu/bpc/bp/Lab/110/reaction.htm#Simple%20vs.
Why do I feel like I’m telling kids to get off my lawn
This doesn’t hold true for all expressions. Some CoffeeScript expressions cannot be translated to JavaScript without adding stub code. Array comprehensions for instance require much less code in CS than in JS. Not only do I always have less to type, I also often have less complex code. Also, everything is an expression in CoffeeScript. This allows for some interesting patterns simply not possible in plain JS, again saving code, not merely typed characters. Array slicing is another code-generating feature. The list goes on.
Even if the argument was just about less characters to type for the same code complexity, having 50% less to write is still a huge plus.
I completely agree on symbols over words, but that’s an argument in favor of CoffeeScript; I’d rather read -> than ‘function’. Anyways, using a real editor (ie.: emacs or vim but definitely not eclipse or visual studio) will give you a much bigger performance boost than replacing words by symbols.
Sure there are drawbacks to using CoffeeScript and Jade as you mentioned, but in my opinion and experience they are insignificant when compared to their advantages and productivity boosts.
Also, I never had to cram complex one-liners in CoffeeScript and I enforce a column width of 80 characters. It’s way more convenient to have small functions that are later composed together as you would in any other functional language such as Lisp or Haskell. Using a functional style is incredibly more convenient in CS than in JS and it is a much better paradigm than object-oriented for most uses of JavaScript.
I could easily quadruple the number of characters in the source files of my server stack simply by porting it to JavaScript.