 So, Covistrip, it's great you have a lot of people here and start off I work as a programmer at MapUnity. So, at MapUnity we'll build products where we solve social issues, for example, MapUnity build. So, a couple of reasons why Covistrip actually piqued my interest is one. I intend to develop a few mobile web applications which means I'll be working on JavaScript frameworks using stuff like Backbone and Node for which, of course, I'll be writing a lot of JavaScript code and after playing with Covistrip for a while, I really felt Covistrip is a better way to use JavaScript. We'll get to how that actually is in a bit and the second thing is I'm a Rails programmer. So, how many are Rails programmers here? Okay, that's not bad. So, for those of you who aren't Ruby on Rails programmers, yeah, Covistrip? So, those of you who aren't Rails programmers, the latest version of Rails which is 3.1 made Covistrip as a default, right? So, that was a pretty big decision by the core team and it got a lot of flame or it's... So that's why I really may have to use Covistrip in the future and this kind of forced me to look into it, right? This before we dive into...can you hear me? Yeah. This before we dive into Covistrip, a very known fact, an open secret, JavaScript is truly ubiquitous. I mean, especially since Node came out, JavaScript moved out of the browser, you can run it on your client, on your server and this happened because there's a trend going on right now that you have to have applications that are more responsive, the interfaces are richer and the only way you could do it is using JavaScript because JavaScript is the only programming language that is supported natively by browsers, right? You shouldn't really use stuff like Flash, right? So, no, because I mean, just before I dive in, so, yeah, so before Node.js, writing a chat client in JavaScript was, I mean, let alone JavaScript, writing a chat client, who's going to contribute as it is in Node.js right now? I mean, you can write a chat client in eight to ten lines of code, but it's not that hard. I remember this thing I read on Twitter a few days ago. So in computing, there are only two things that are really hard, right? One is concurrency, handling concurrency, the other is naming methods and stuff and the other is off by one errors, right? Nobody gets the geek joke, right? So a coffee script, Jeremy Ashkenas is the guy who developed coffee script. He also developed Backbone.js and Jamet, which is a packaging asset library. So he puts it really well, it's a thought experiment. As in, before you actually dive into writing a lot of JavaScript code, just ask yourself a few questions, ask yourself what if questions, you know, what if you didn't face the problems you usually face with JavaScript, things like what if you didn't face global variable problems, what if you didn't face the value of this sometimes just dynamically changes because this is a dynamically-scoped object, right? The value of this doesn't just go underneath your feet sometimes. What if you don't have to, you know, wrangle the whole chain of object-oriented JavaScript? So that brought him to coffee script, right? So what is coffee script, really? Coffee script is a language, a little language as he puts it that compiles one-to-one to JavaScript, right? You write the coffee script, compiles to JavaScript and you run the JavaScript in your browser. Of course, the latest news with this is Mozilla is working on integrating coffee script into the browser. So you can natively use coffee script. You could write, you know, natively use coffee script, you can use text slash coffee script tags, but you'll have to use the coffee script compiler in the browser, which is not that great. Right? How many of you sass? You can just nod your heads, sass, so great. So for those of you who don't know what sass is, sass is synthetically awesome style sheets, right? It's a layer of abstraction over CSS and it gives you some awesome stuff like you can declare variables. For example, you can use color codes and put them in variables and usually you have a color palette in your website and it becomes really easy to manage all that if you have variables, right? It also gives you a mix-ins so you can abstract away common code you usually write in style sheets and use, you know, abstract it away and use it multiple times instead of repeating code. So it keeps your code dry. You can also do stuff like you can, if you have a div, you want to darken it. It gives you some math functions so you can darken it by 20% or lighten it by 20%. So it's a layer of abstraction that has taken, that's been taken by the community really well. Of course, hardcore CSS programmers, I have not met any hardcore CSS guys who really have taken to CSS. Anyone here? No? Oh, here. That's great. So because they feel vanilla CSS does the job and you don't really need that stuff. So coffee script in a conceptual level is similar in that it's an abstraction layer over JavaScript, right? Right. So let's show you some code, have some JavaScript code that I'd like to show you. So you guys can see it? Yeah, it's a very simple adder function. It just takes in two variables and adds them up and gives them back to you. So how would you convert this to coffee script? So let's do that now. So in coffee script, you don't need to use semicolons, right? It saves you that pain so let's remove these semicolons. There are no curly braces, again, saves the finger pain. There is no var keyword in coffee script. So every variable you use, the var is automatically attached by the compiler so you don't have to worry about var. Now of course, in JavaScript, you declare variables with var and sometimes assign variables without using var and that can leak variables to the global namespace. So we'll see how coffee script solves that problem. So you don't need the var. In coffee script, the last statement of a set of instructions, for example, in a scope like there's a function, right? So the last statement is implicitly returned. So you don't have to explicitly say return a plus b. So you can just say a plus b. That's it. That statement is returned. The function keyword, this is pretty funny. The function keyword is actually replaced by, that's it, that's the function keyword. And Nike, who is the inventor of JavaScript, got so psyched about this, he proposed this to ES Harmony, which is the next version of ECMAScript, the official version of official name for JavaScript. And surprisingly, it was shot down. I don't know why. So this is it, really. So how you would read this is input a, b, go into the function and you get the output, right? So that's it. Sorry? Exactly. I'll come to that. So in CoffeeScript, one more very important feature is white space indentation, right? Just like Python, you have to indent your expression. One little improvement you could do here is avoid the next line itself and just put it here. So it's really a one-liner right now. And that's about it. Yeah. One more thing is when you're invoking a function, the parents are optional, right? So you can, you can remove that. And that's it. So let's just compile this in here. So you get five. I don't think you can see that now. But yeah. You get five, really. That's it, really. It does the same thing, but you can't see it. Okay. You get the same thing, but with much less line noise and much concise code. So one more thing that's interesting here is I've heard a lot of arguments saying, okay, great. Another alternate JS. It's going to spit out some JS like a lot of other JavaScript interpreters, right? So let's see what this actually compiles to. So there. So that's the JavaScript that compile to. And this is JavaScript you would actually be proud of writing. I mean, of course, there's a trivial example, but really you're not making it. Can you see this? I just try expanding this. This is JavaScript you would want to write. This function you see here is a wrapper coffee strip provides as a safety to prevent global namespace leaks, right? Of course, what you declare the variable for you actually use it. And that's it. It uses the function literal type of functions, which is the better practice. And of course, it says call this right. So this is good JavaScript. It doesn't spit it out. It sings really JavaScript. Yeah. It sings. So you guys read Hacker News, read it. I'm sure, yeah. So a lot of arguments say, great, I have to switch to this because of the syntax, right? For example, Hamel. You guys have heard of Hamel? Yeah. So Hamel is a markup language that, again, abstraction of a HTML, but the difference between Hamel and SAS coffee script is Hamel does not provide you any functional, added functional value. Really, it is just syntax. Nothing else, whereas SAS and coffee script give you much more added value. So it's not just syntax, really. It's really the icing, and people won't jump from JavaScript to coffee script because of syntax. That will be just an added bonus. So the coffee script homepage, you guys have read it. If you guys have read it, it makes a few nice claims. It says it hides the bad parts of JavaScript. You'll see how it does that and focuses on the good parts. It extracts out, can you see it? It extracts out common patterns from JavaScript so that you don't have to repeat code wherever you use that pattern. It gives you an idiom. I'll show you idioms and how exactly it can reduce your code, a better object-oriented programming model. As I said, if you want to write object-oriented programming programs in JavaScript, you'll have to hack around with the prototype chain and have to say, shape dot prototype this. It doesn't feel right, does it? So this is a great book in case you haven't read it, The Good Parts by Douglas Crawford. I've taken a few, I've taken some inspiration from the bad parts. So there are two chapters in this book at the end, is one on awful parts and one on bad parts. So two chapters dedicated to bad parts and took a few of them to show you how coffee script tries to alleviate the pain. So yeah, global variables, this, according to him, and we all know it, is pure evil, right? You forget the word keyword. Can you notice a subtle difference? It's subtle. Instead of the comma, there is a semicolon and boom, it's in your global namespace and your page crashes, right? So it's pure evil. Let's not go there. It's pure evil. Everyone knows and you really shouldn't use global variables. So what's the solution? The solution is, you don't use global variables at all. That's the ideal solution. But of course, there are cases when you would want to use a global variable. In such a case in JavaScript, the best practice is to attach the JavaScript variable as a property to the window object, right? So like, yeah. So for example, in the browser, the global object is the window object, right? So if you attach that as the property to the window object, one, it is explicit that it is a global variable you're using, two, there are no name flashes. So let's see what CoffeeScript does. And CoffeeScript, there are no global variables, really. So as I said, there is no war in CoffeeScript. So every variable that you declare is attached automatically with war. And the function scopes I showed you, which enclosed the code I showed you, it prevents leaks to the global namespace. So again, if you would want to use the global variable, you would have to attach it to the window object. Or in Node.js, I think it would be the exports object. Equality. This is confused, new programmers a lot, it confused me and I'm sure it confused a lot of you as well. I mean, really, the double equals object is not what you think it is sometimes, right? If you're, for example, if you're coming with C, you wouldn't expect this kind of result when you get it from JavaScript. So what does CoffeeScript do? A pro tip here would be to always use the triple equals, right? So CoffeeScript compiles the double equals when you use it to coffee to triple equals. There is no double equals in CoffeeScript. For example, it also gives you some, you know, syntactic storage just to make you feel nice. The keyword is, is synonymous to double equals. The keyword isn't synonymous to not equals, that is inequality. So if you, so what if you really want to use double equals, you would have to escape that with back ticks and that would be raw JavaScript and CoffeeScript code. Fall Z values. There's one more thing Douglas highlights in his book. There are a few values in JavaScript, zero, NAN, not a number, sorry. This is actually Fall Z. It doesn't to make too much sense because zero is a perfectly valid number. You wouldn't want it to be Fall Z, right? For example, that wouldn't work because name is, what's the value of name, undefined, correct, right? So what does CoffeeScript do? Everything is truthy in CoffeeScript except null or undefined. So except null and undefined, everything is truthy and you can use the question mark symbol like in Ruby to check if it's true or false. So basically it'll return false if your value is undefined or null. So this gives you great amount of relief and it's especially useful when you're using the conditionals, let's say X equals X or Y, right? In such cases, you don't have surprises, you know exactly what your code is doing. Coming to a few features, again, ask and ask, yeah, sure. You can sit, sorry, no, it's a pretty good question. False, I think it's false. Do you know the answer? I think it's false. You want to check it out? I'll get to you later. So language features, right? So Jeremy Ashkenos, as I said, he extracts popular design patterns and gives you an idiom so you have to reuse code in your code base. Let's go through a few wins, right? As I said, the last value statement is explicitly return, right? So you don't have to mention the return statement. But for high-performance JavaScript, sometimes in case it returns a very heavy object, you don't want a lot of memory to be allocated, you can just say return and it returns undefined so you don't have that problem. But of course, there are very few cases you'll find yourself doing that, really. Significant white space, as you saw. Everything is an expression. This especially comes in handy when you have, you can suffix if statements, if statements to your, say, let's say x equals 1 and say alert x if x is 1. You can't do the JavaScript, but you can do it in JavaScript because the suffix works because everything is an expression, it's evaluated in runtime. Like in Ruby, you can use the hash brackets to string interpolation. This is especially useful and it's not, you can also put code here. For example, I can assign name to a variable. I can say name dot to uppercase inside the hash brackets. Loops and comprehensions. So what the Y loop does is after it loops through, it returns an array and splats. So splats is useful. You guys have worked with the arguments object JavaScript gives you with every function. So usually use it to test the length of the number of arguments you get. But JavaScript gives you a nice argument says others, right? So it's not others, I have used others, but you can use others, the syntax is actually wrong. You have to use others dot, dot, dot, and that's a splat, right? I'm sorry about that, but that's a splat. So what happens here is the first argument, which is JS foo, gets into current conf and the other arguments PHP cloud doc type HTML goes into as an array to the others array. Please note the syntax error there. It's actually others dot, dot, dot, it's three dots. The existential operator, as I said, to test truthy and falsely values, very useful. I think Ruby guys will be accustomed to this writing in YAML. So if you want to write an object literal, you use curly braces and you separate with commas, which is okay in JavaScript, it's not that bad, but JavaScript takes that a bit further and you remove the commas, you can use it in the YAML format. As I said, the suffixed if condition works because everything is an expression. So you have, again, much less lying noise. This is a feature actually, which is proposed in ES harmony. So here, as you can see, some difficult, you get the arguments, this is especially useful when you return an array of arguments from a function. So it's useful in capturing multiple arguments from the function, right? So this is an example from Crockford. So anyone know what's going on here? So what does the first console log scope return? What does it print? Sorry? So all of you would say, Outer, you seem to viewer my friend and I'm going to talk to you later. Yes. What is it going to print? Sorry? Undefined. That's correct. So your console.log is going to print undefined. And would you know why? Okay. Tell me why. Exactly. Right? So Ascob is declared. So what exactly you're doing, the technique here, or a bad technique really is shadowing. You're actually shadowing your value. For example, this inner function is actually a closure. And it should have access to the scope variable. But what we've actually done is we've shadowed it and we've removed the access to the scope variable. And this is really bad. You shouldn't use shadowing and the ideal practice is to use different names in your inner function so that you have access to your variables that are in the function's closure. Right? Sorry? Yeah. So the first, you understood why the console.log didn't work. Right? Okay. So here, you've declared RASCOP with Outer. That's good. But it's not in this scope explicitly. Right? This is the function. And you again declare RASCOP as inner. So what happens in JavaScript is a thing called hoisting. Right? So RASCOP actually gets hoisted here, gets initialized, undefined, and then gets assigned. So again, it's a bad idea to use shadowing. So don't do it. So CoffeeScript kind of alleviates this. So this is what, this is the behavior you would expect. So when I asked you the question, everybody said outer. So that is the first instinct that comes to a programmer. Right? And when you write a similar code in CoffeeScript, you get exactly what you guys expected. So when you say console.log scope, it actually refers to the variable in the inner function's closure, which it should. But whereas in our previous function, it was shadowing that variable. Sorry? Okay. Yeah, sure. Okay. Yeah. Right. So as I said, told you hoisting. JavaScript does not have a block scope, right? Like C, it has function scope. So sometimes if you declare or assign a variable at the end of the function, that variable is actually available at the top of the function because the variable is actually, you know, available throughout the functions because it has function scope. So the best practice to avoid confusion is to, you know, use or declare variables right at the top of the function, which is what CoffeeScript does. Actually, if I compile the code and show it to you, the variable is actually, it doesn't really declare the scope variable because scope, the variable scope is already in inner scope, which is why it doesn't declare it again. Okay. I have an example for you, but there's no internet, I believe. So let's say, so I need you guys to do a little imagination. So let's say you have a plain page and you just put a DOM element, right? You just put a box, black box, and you bind that with a jQuery callback. And so when I say dot click, it should say, hello, my name. I've written this in CoffeeScript. So usually those things don't work in JavaScript if you write it. The first time, you usually get it wrong. Why? Because the value of this is dynamically scoped. And the time you run that function, the value of this would have changed, and it would be assigned to, let's say, the global object. In such cases, it can cause strange bugs, but CoffeeScript gives you a nicer way to declare that type of function. In such cases, you want to bind the value of this to the value of this when you're actually defining the function. You use the fat arrow instead of the single arrow, instead of the normal arrow. So what the fat arrow does is the time you're writing the function, what is the value of this that is actually bind, that is bound. So this dot name actually works. But in JavaScript, what you would have to do is declare a variable that is self, then initialize that to this, and then use self, and say self, say hello, right? CoffeeScript has class, right? It really does, because let's say you want to write object-oriented programming, as I said, in JavaScript, you have to wrangle with your prototype chain. It's not always nice. Anyone enjoys that? Enjoys writing JavaScript object-oriented style? I mean, it's especially important right now because you have a lot of frameworks like Backbone coming up which include, which encourage you to write object-oriented programming. And it's not great. But CoffeeScript solves that problem. So let's look at it. Okay, first, how does this look? It looks nice, right? You have the class keyword. You have something called the extends keyword and the super. I'll get to that in a bit. So the class keyword is a nicer syntax for JavaScript which allows you to add methods and variables to the animals prototype in this case, right? It gives you a constructor. So at the initial variables are assigned when you create the new object. So for example, cheetah equals new cheetah and dot run. I actually can run this. One meter on this. Okay, monkey patching. So anyone did monkey patching in JavaScript? JavaScript is dynamic. So like Ruby, you can monkey patch it. Of course, one thing you have to keep in mind is the open-closed principle. Ideally, it should be open for extension and close for modification. But that rule can be relaxed if the consumers of the code is you or your team, right? Let's say if you're giving out the code like an API or giving out people the chance to add to the code, it's probably not a good idea. So CoffeeScript gives you the colon colon. What this actually does is it says go to strings prototype and add the function capitalize. So you can use foobar capitalize. So you just added a method to strings prototype and that was how easy it was. So I have a few picks. So js2coffee.org. Anyone use this? No one? So this is a pretty interesting tool. So if you want to try out CoffeeScript or you want to learn how it works, there's a tool called js2coffee. So you write some JavaScript, you go to this website, you put the JavaScript in and it compiles to CoffeeScript. This is hilarious because you write JavaScript, then you put it to Cockstrip and again you compile it to JavaScript and use it in your code. I know it sounds hilarious, but it's actually useful when you're in your initial stages of learning, right? You get to learn how JavaScript works and puts it in CoffeeScript. Don't use this for a lot of code. Just don't, really. Maybe for trivial functions and for little functions it's fine, but the best way to write CoffeeScript is to write CoffeeScript by hand and not use js2coffee. It's a tool you can use in your initial stages of learning. Tinkerbin. I've heard of it. Okay, jsfriddle? Sure. So Tinkerbin is like the next step from jsfriddle, right? So this gives you to run Hamel, SAS and CoffeeScript code. It's actually available at tinkerbin.com so you can use CoffeeScript right there and compile and it all just works. It's great. It's a nice tool. So you don't have to save files and then run the code. You can just do it on tinkerbin.com. CoffeeScript is not natively supported in your browser, right? Only JavaScript. You can put it into your file. So CoffeeTable actually lets you debug your CoffeeScript. It compiles the CoffeeScript it gives you like an extension. So it compiles the JavaScript and shows you what JavaScript your CoffeeScript generated. The little book on CoffeeScript is a free ebook. It's written by this guy called Alex Mekor. So it's a nice little it's really little actually and it's free. That's the best part. There's another book called Accelerated Development that's a paid book. That's a proud book which is pretty good but I think this should do for initial learning. Right. So as I mentioned Hacker News and I've been reading a lot about CoffeeScript over the past two weeks and trying to get a sense of what people who are actually using CoffeeScript in production feel about it, right? So I've scored through threads and the general consensus seems to be that people are enjoying the experience. They like writing CoffeeScript one because it's not an all JS that spits out JS, right? It's an all JS that writes JavaScript that you can actually it's human readable JavaScript. You can easily read that JavaScript and you can debug it. The biggest problem with CoffeeScript right now is debugging CoffeeScript but CoffeeScript tries to avoid the problem by giving you some really nice human readable JavaScript. It just beat Haskell and ActionScript I believe as of today. So it's getting really popular on GitHub. Any Mac users here? Okay, there's this application called POW P-O-W. So it's a really easy way to deploy your apps. For example, use passenger for Ruby on Rails. It's a really nice thing to use in development that's been written in CoffeeScript. Anyone heard of Trello? Trello.com? Okay, great. So Trello is the guys who made Stack Overflow Jeff Atwood and what's the other guy's name? So those guys made Trello. Trello is a project management system. It's currently free. I think it's in beta and it's got a nice JavaScript UI and it's got a gamification kind of thing going on and I believe their stack uses CoffeeScript, Node.js, MongoDB and Backbone. So they're really happy with their experience. This is, I think, a tribute I read on Stack Overflow. Someone said they're really happy with using proper classes, especially nicer syntax stuff and to close the testimony and the love for CoffeeScript. Douglas Crockford in his, I think he gave a conference in Texas where he was asked about CoffeeScript and how he felt about it and he really warmed to the idea. He felt it takes out all the crap from JavaScript. It gives you a nicer syntax and you don't worry about the bad parts of JavaScript that you usually find yourself worrying in. It's great and I believe a lot of CoffeeScript features are influencing the current TC39 ECMAScript committee that is working on bringing out the new version of JavaScript. So my guess is even if you don't invariably use features of CoffeeScript maybe later on as pure JavaScript. So thank you, that's it. This was actually meant to be a short presentation but I kind of stretched it to 30 minutes. Do you have any questions? I'd love to answer them. I'll get back to your question. I'm sorry.