No, I still use Java Script and not CoffeeScript
I still don't see the bloody point.
Poll: Have you moved from JavaScript to CoffeeScript?
171–178 of 178 posts
Re: Poll: Have you moved from JavaScript to CoffeeScript?
#172I love cs with all my heart. It makes client-side programming fun and enjoyable. It made me forget my dream of having someday python running in the browser. Cs is just as good. My only criticism is that sometimes, leaving out parens mames the code hard to decipher. I feel that explicit parenthesis make everything clear, but that's probably because I come from python...
Re: Poll: Have you moved from JavaScript to CoffeeScript?
#173for new projects yes, haven't started migrating old stuff yet. Rails 3.1 will be when I migrate my client's javascript.
Re: Poll: Have you moved from JavaScript to CoffeeScript?
#174for new projects yes, haven't started migrating old stuff yet. Rails 3.1 will be when I migrate my client's javascript.
Re: Poll: Have you moved from JavaScript to CoffeeScript?
#175Earlier quoted context omitted.
You're in luck then. This is precisely what the fat arrow in CoffeeScript is for: creating a function where the value of "this" is bound lexically. So: class Widget render: -> $(".widget-title").click (e) => # `this` is still the Widget instance. # `e.currentTarget` is the DOM element.
I was using the fat arrow, and wanted to keep using it, but switched to thin arrow (using @ to access the element and 'that' to access the class). Here's why: click() works because the callback is given parameter: .click( handler(eventObject) ) Cool. You access @ for the class, and eventObject for the thing you clicked. But I wasn't using click(), I was using load(), which has a different syntax: .load( url, [data,]…
Correcting self: that's the documentation for the wrong .load()! (yes, there's two). The proper docs are http://api.jquery.com/load-event. Which indeed allows the event to be passed to the callback explicitly, so inside the callback @ refers to the object and 'event' (or whatever) .target refers to the image. Problem solved!
Re: Poll: Have you moved from JavaScript to CoffeeScript?
#176Earlier quoted context omitted.
I am strictly a server side programmer and have a problem doing front end work. I want to learn it, but it feels like a sheer cliff to me. The low level CoffeeScript documentation is excellent. What I am looking for and not being a JavaScript programmer this is admittedly difficult for me, is some hand holding on the mechanics. * packaging, how do I import modules or packages? Do these even exist? * debugging, how do…
* npm + bowserify or stich or others * in firebug / web inspector * qunit, jasmine etc repl for node ### REPL ### repl = require 'repl' r = repl.start 'REPL> ' r.context.client = -> exec("open http://localhost:# {config.port}/") ; return
Thank you both for these links, I am off to a very good start.
Re: Poll: Have you moved from JavaScript to CoffeeScript?
#177I have used Javascript exclusively on client and server since late 2008. First Rhino and then Node. Before that I used Rails. I can understand the syntax gripes that some people have towards Javascript but I think this has more to do with a Ruby notion of "elegance" coupled with a lack of familiarity with Javascript then it does with actual issues with Javascript. In fact, I prefer Javascript to Ruby. I have gone the…
You may have been misinformed -- the values of direct, raw, fast code are a big part of the reason why CoffeeScript works the way it does, and why many scripts can end up running faster after getting ported to CoffeeScript. The golden rule of CoffeeScript is to avoid adding any library code to the runtime, and to avoid introducing any special calls, to the greatest extent possible. Many folks rely on a "forEach" (or…
[deleted]
Re: Poll: Have you moved from JavaScript to CoffeeScript?
#178I have used Javascript exclusively on client and server since late 2008. First Rhino and then Node. Before that I used Rails. I can understand the syntax gripes that some people have towards Javascript but I think this has more to do with a Ruby notion of "elegance" coupled with a lack of familiarity with Javascript then it does with actual issues with Javascript. In fact, I prefer Javascript to Ruby. I have gone the…
You may have been misinformed -- the values of direct, raw, fast code are a big part of the reason why CoffeeScript works the way it does, and why many scripts can end up running faster after getting ported to CoffeeScript. The golden rule of CoffeeScript is to avoid adding any library code to the runtime, and to avoid introducing any special calls, to the greatest extent possible. Many folks rely on a "forEach" (or…
I mean "direct" as in as few abstractions as possible, and "raw" as in as close to the metal as possible.
I am used to writing native loops in Javascript, so taking your example I would usually write:
var length = list.length;
while (length--) sum += list[length].amount;
And I know that forEach loops incur additional overhead so I use them when it's convenient, when the arrays are small. I don't need to compile my Javascript just to keep from accidentally using forEach in situations where native loops would be better. I usually try to think about these things when I code and I enjoy being able to decide when to use a forEach loop, when to use a reverse while or a vanilla for loop etc. Sometimes, it's good to be specific in how you write code.
Furthermore, I would write for loops more succinctly than the compiled CoffeeScript in your example. You can use a for loop to declare the "item", "_i" and "_len" variables inside the loop itself without writing them twice. There's no need for the temporary item variable and the for loop is then short enough to be on one line:
for (var _i = 0, _len = list.length; _i I don't mind typing a few more characters if it means I can get closer to the code and serve smaller, faster code to users (or servers). If it means just one less deployment step, or one less 3rd party dependency, or one less leaky abstraction, it's worth it. I think this proves true in the cases above, where CoffeeScript certainly makes the compiled code longer, slower than it needs to be.