Dropbox drops JavaScript, brews CoffeeScript Dropbox has stopped using JavaScript whenever it codes for browsers and has instead adopted CoffeeScript by re-writing 23,000 lines of code. DropBox developers Dan W, Ziga M and Chris V explain their choice in a blog post, offering brevity of syntax as their main concern and citing the following statistics from the company's …
Just so long as they haven't applied the same thought processes to their documentation ... number 9 busses and all that.
However, my thinking these days does tend to go along the lines that developers are out-living their cloudy products these days, so .. why document!
Let's take a light look at CoffeeScript.org, which reveals this intriguing project to our red-rimmed, coffeine-infused eyes, and after perusal, dare I say so good Sir, I thoroughly disagree with your clearly cynical commentariation attitude, which, although often de rigeur in this hive of scum and villany as we presently attend, might well be a tad off-base in this precise case.
> Or did the code suddenly become faster
That might be possible
> less buggy
Better, more compressed syntax means less bugs, yes
> better usable on slow browsers and behind shoddy links
That's a design problem
Overall advantage: YES, GO FOR IT.
"> Or did the code suddenly become faster
That might be possible"
From the article: “The size of the compressed bundle didn’t change significantly pre- and post-coffee transformation, so our users shouldn’t notice anything different,” the trio write. “The site performs and behaves as before.”
So even the devs who did the recoding do not believe that the code has become significantly faster.
"> less buggy
Better, more compressed syntax means less bugs, yes"
No it doesn't. Bugs don't come from the syntax but from the coders and intermediaries. In this case, the coders remain constant, but an intermediary has been added (CS-to-JS compiler). So the potential for bugs actually increases slightly.
> better usable on slow browsers and behind shoddy links
That's a design problem"
Which they could have worked on rather than wasting time recoding into a derivative language.
Last I checked, a line-by-line code audit actually helps to streamline code and fix bugs (especially if you have to interpret it into another programming language). Unfortunately, it can also cause bugs since the "streamlining" process may cause typo or logic errors while they're attempting to condense or fix code. So, it's likely a wash on the other end, or leans more toward bugs (as it's new, untested code whereas the old code was battle-hardened).
I guess that depends largely on the quality of the cross-compiler from CoffeeScript to Javascript.
Having looked at the comparison I agree that CoffeeScript is much more readable. It is not unreasonable to hope this leads to fewer typos and better maintainability and possibly even better security, especially if the code is written by occasional JS programmers.
However, it's another language. Despite the superficially-similar syntax, Coffeescript is definitely not Python, and doesn't behave like Python, so seasoned Python programmers will make no doubt be just as prone to mistakes while maintaining it.
And the implication that a core part of a company's product offering will be maintained by people who only have a passing knoweledge of the language it's written in is both worrying and worryingly familiar.
> I guess that depends largely on the quality of the cross-compiler f
No, it depends on how well the people writing the Coffeescript understood what the original Javascript does, and how thorough their non-regression testing was. The term "week long hackathon" suggests testing along the lines of "it compiles, ship it".
Would you trust your data to Dilbert & co?
"Having looked at the comparison I agree that CoffeeScript is much more readable."
As I understand the comparison though, it is between CoffeeScript and machine generated Javascript, rather than between CoffeeScript and Javascript that a real person might write.
"Well, that certainly bodes well for the site security. Not."
Security would never be implemented in the client (i.e the browser) in the first place. I assume their JS is about putting pretty boxes up on the screen and enforcing user workflow and backed up server side checks which could not be circumvented regardless of what the client side was written in.
But like Closure or whatever the OOJavaScript compiler that google has it does add another step into the design process and breaks the link between written code and running code, and (having not played with CoffeeScript ) I would imagine debugging has to be done at the JavaScript level which may more than remove any benefits writing in your favourite language gives you.
It when things go wrong that you need to be in familiar territory and this doesn’t help.
This post has been deleted by its author
I've been watching the whole Coffeescript thing for a while now, and even dabbled in it a couple of times. I just cannot figure out why you wouldn't just write Javascript instead? With the plethora of libraries around nowadays, writing 'browser neutral code' is just as easy - if not easier - in plain Javascript.
Personally, I find it a pain in the arse to read, it constantly looks like something is missing, and I don't really want to learn a new syntax and stuff to get to where I already am..
I had a very basic example here, but the forums don't keep formatting... https://gist.github.com/3736194
Simple example but it's less painful then JS, I'd say more rubyish than python.
RUBY
>===============
def encode(decimal)
# restrict range of input to 1 .. 3999
max_decimal = 4000-1
exceeds_range = "Only numbers in the range ( 1 .. #{max_decimal} ) are supported"
raise "Cannot convert (#{decimal}): #{exceeds_range}" unless (decimal <= max_decimal && decimal > 0)
# table of translation factors for each glyph in the subset of the roman numerals supported
factors = [1000, 900, 500, 400, 100, 90, 50, 40, 10, 9, 5, 4, 1]
glyphs = ["M", "CM", "D", "CD", "C", "XC", "L", "XL", "X", "IX", "V", "IV","I"]
# factorise decimal representation into roman numerals
result = ""
factors.each_with_index{|numeral,index|
order = decimal / numeral
decimal = decimal % numeral
result += glyphs[index] * order
}
result
end
Coffee
>===============
@romanNumeralGenerator = (decimal) ->
# restrict range of input to 1 .. 3999
max_decimal = 4000-1
exceeds_range = "Only numbers in the range ( 1 .. #{max_decimal} ) are supported"
throw new Error("Cannot convert (#{decimal}): #{exceeds_range}") unless (decimal <= max_decimal && decimal > 0)
# table of translation factors for each glyph in the subset of the roman numerals supported
factors = [1000, 900, 500, 400, 100, 90, 50, 40, 10, 9, 5, 4, 1]
glyphs = ["M", "CM", "D", "CD", "C", "XC", "L", "XL", "X", "IX", "V", "IV","I"]
# factorise decimal representation into roman numerals
result = ""
for numeral, index in factors
# in a more cpu focused language we could just use integer division
remainder = decimal % numeral
order = Math.floor(( decimal - remainder ) / numeral)
decimal = remainder
# this is the js eqivilent of glyph * order in ruby or
# glyph x order in perl
result += Array(order+1).join(glyphs[index])
result
JS
>===============
// Generated by CoffeeScript 1.3.3
(function() {
this.romanNumeralGenerator = function(decimal) {
var exceeds_range, factors, glyphs, index, max_decimal, numeral, order, remainder, result, _i, _len;
max_decimal = 4000 - 1;
exceeds_range = "Only numbers in the range ( 1 .. " + max_decimal + " ) are supported";
if (!(decimal <= max_decimal && decimal > 0)) {
throw new Error("Cannot convert (" + decimal + "): " + exceeds_range);
}
factors = [1000, 900, 500, 400, 100, 90, 50, 40, 10, 9, 5, 4, 1];
glyphs = ["M", "CM", "D", "CD", "C", "XC", "L", "XL", "X", "IX", "V", "IV", "I"];
result = "";
for (index = _i = 0, _len = factors.length; _i < _len; index = ++_i) {
numeral = factors[index];
remainder = decimal % numeral;
order = Math.floor((decimal - remainder) / numeral);
decimal = remainder;
result += Array(order + 1).join(glyphs[index]);
}
return result;
};
}).call(this);
And I see no benefit of using Coffeescript here instead of Javascript, it's just adding another step to the deployment process, and one that doesn't (in my eyes) offer much (if any) benefit.
It seems to exist so that one can say "Javascript? Pffft thats old skool, I do Coffeescript - that's where it's at"
As title, I do think it's a little more readable but there's not that much really, my thinking was that you could prototype code in ruby and make a couple of small tweaks (two lines in the above example) and run it through the translator and hey presto some JS.
Still you could just write the JS in the first place as you suggest, but I do think it's a little more readable but then again I don't really like JS anyway and I do quite like ruby so YMMV.
I see no benefit of using Coffeescript here instead of Javascript, it's just adding another step to the deployment process, and one that doesn't (in my eyes) offer much (if any) benefit.
I can't speak for CoffeeScript, but in GWT (where you write Java that's compiled down to JavaScript) there are a number of benefits. The first is that Java is a statically typed language, so at compile time you can catch many errors that in a dynamic language you'll only discover at run time (if you're lucky). CoffeeScript is probably no better than JavaScript in this regard. The other major benefit with GWT is that it offers something called late binding, where browser dependent code is interleaved with the generic code at the time of a request.
Recently had to do a web based manager app, and did it using GWT/GXT, and the results were great. Being able to use the full IDE support for Java, compile time checks, and generics, definitely reduced the time to market and increased the maintainability of the code. There is also the fact that my backend and frontend code was more or less seamless connected which further reduce the amount of coding needed.
Performance is the only area where there is a slight trade-off, but I can leave with that. I just hope the Dart language takes off soon and make this approach to JS based apps the norm.
I was trying to work out why I couldn't get the CoffeeScript to match up exactly to the Javascript, and then read in the CoffeeScript site 'Instead of using curly braces { } to surround blocks of code in functions, if-statements, switch, and try/catch, use indentation. '
So the CoffeeScript code presentation has, simply because of a change in formatting, changed its logic (if it even translates at all!) while the Javascript, while looking a bit untidy now without indentation, would still function correctly, thanks to the curly braces.
Can't help thinking that code that can be passed between text editors which may not handle spaces and tabs the same way is a recipe for disaster.
To paraphrase Harry Callahan ...I know what you’re thinking: '"Did he tab six times, or only five?" Well, to tell you the truth, in all this excitement, I’ve kinda lost track myself.... you’ve got to ask yourself one question: "Do I feel lucky?" Well do ya, punk?'
I think we're missing a vital piece of information here... CoffeeScript is just an abstraction of JavaScript, the end result of "compilation" of CoffeeScript is a whole bunch of JavaScript... So, is this article reporting 5000 less lines of code in the CoffeeScript compared to the original JavaScript it replaces?
Or is it 5000 lines of code less in the result of the CoffeeScript "compilation" result than the original JavaScript?
The two are different beasts, and different statistics... If there's 5000 less in the former, kudos I see that they might have an argument of making their code lighter and smaller and better maintainable... That's not to say it runs any better as the end result should be very very similar JavaScript to the original hand written. But they have introduced a second level of complexity, that now they have to ensure the output of CoffeeScript (its tools and compiler suite) is correct/legitimate for their purposes. And CoffeeScript users are few and far between in my neck of the woods....
However, if there's 5000 lines less in the CoffeeScript result JavaScript compared to the original then what has been lost in translation... Programmers, by which I mean good programmers, don't just put 5000 lines of additional code into a project for the sake of it... What has the move to using CoffeeScript to more effectively generate JavaScript done?... Has it removed something?.. Optimized something?... Or simply done something more effectively than the original human programmer did?
In short, more information needed here before this item is news worthy...
CoffeeScript is just a preprocessor. The underlying language (if you can call it that) is still JS with all the kludge that JS implies but there a couple of common idioms folded in to the language which you don't have to write by hand.
So for example string concatenation is a little less verbose in CS but will expand to the long hand form in JS. From a coder's perspective the results are the same but one is a little easier to read.
From the point of view of correctness I don't think it is a silver bullet but it does make working in JS less painful and more importantly IMO easier to automate generation.
People are doing this because they know one language and don’t want the benefits of learning another.
It would be nice to have a more advanced language in the browser - JS2 could have offered this but some thought it was 'too advanced' by some - or rather would have allowed the browser to take too much responsibility away from them.
JavaScript is, currently, shit but its not so bad as to prevent a reasonable programmer or programming team writing fantastic apps.
Writing new languages doesn’t, in the long run, make programming any easier - it just shuffles the problem space around a different way. The main problems in browser programming currently are the workmanblamingtool feature and monopolistsinstandardgroup paradigm.
> It would be nice to have a more advanced language in the browser
It would indeed, something more strongly typed would be my preference.
But really it needn't be a "language" at all, just a consistent java/net-style byte code. Then you could compile whatever you like to it.
>JavaScript is, currently, shit but its not so bad as to prevent a reasonable programmer
>or programming team writing fantastic apps.
No, ultimately you can work with anything, it never does anything well though, there's always
a bodge somewhere down the line. I guess maybe that's inherent in the browser platform
rather than the language?
Coffeescript would provide a more terse syntax which would allow the same functionality to be expressed in less lines of code. Less lines of code = less bugs and easier maintenance.
However I would have thought most bugs in JS are less to do with logic in the code and more to do with the shitstorm that each browser flings at it in the manner that it handles HTML, CSS, DOM, XMLHttpRequest etc.
I doubt Coffeescript would help much much there with that so I wonder if their solution is really addressing the main problem they face - discrepancies in browser behaviour. Sure they've cut some lines of code down but is it in the places that traditionally cause the problems in the first place?
Less lines of code = less bugs and easier maintenance.
Please stop repeating this bullshit.
In the first place, the complexity of code hasn't been measured in lines since before the first obfuscated C contest.
In the second place, any adequately incompetent coder can code one crap line just as easily as one thousand.
All I can see here is the same argument from ~30 years ago, from someone announcing that they've recoded their application from Assembler into C.
Or from 20 years ago, from someone announcing that they've recoded their application from C into C++
Or from 10 years ago, that they've recoded their application from C++ into Java.
It's always the same arguments...
for: it's more expressive, it's more maintainable, it's more fun
against: it's a pointless change, it'll introduce bugs, the old way was better
1) ASM to C - easy win, chances are your' ASM is worse than the compiler generated code.
2) C to C++ - rewrite would be a bit strong, wrapping C functions with classes perhaps but rewrite C code rather than wrap in C++ - madness.
3) C++ to Java - stupidity on a grand scale.
Coffee to JS is more like C with a preprocessor vs C without a preprocessor, it's not a paradigm shift.
like
1) reliquishing control over register allocation.
2) Letting someone else manage the container library and using automatic RAII.
3) Going from portable multi-paradigm elegance to overly verbose, badly designed kludge.
It's just a preprocessor, they are cool, C/C++ benefit from a preprocessor, Java suffers the lack of a preprocessor, anything that makes JS less painful can only be a good thing.
Having seen other similar conversions, as long as the devs are happy, feel more productive, and haven't introduced any new bugs then I'm sure CoffeScript is a fine choice.
What interests me are the metrics. Lines of code, tokens, characters - these are all things that you would expect to decrease if you decided to give your team chance to refactor a 23,000 line codebase. I wonder what those totals would be if they'd just decided to rewrite the whole lot in plain JavaScript instead of CoffeeScript.
Javascript is perhaps the shittiest language so I don't blame them for trying to make life easier.
JS is like the only language that people feel the need to keep making redundant ways of writing either through frameworks or things like gwt and coffeescript. That's because JS is pure shit. I'm not surprised either. It has no competition and it's designed by group of self serving people.
We'd be better off with something like python with the dangerous bits removed as a client side language.
What the article fails to mention is that the JavaScript that results from CoffeeScript compilation, always pases JSLint (see http://www.jslint.com/ for info) - which means the JavaScript is way more likely to run error-free on uncommon web browsers. Generally JavaScript that passes JSLint tests is a Good Thing™.
If you want to fit more code in the editing screen, use a language that allows multiple statements on the same line.
When writing assembly code I use an assembler that allows multiple statements per line, which allows me to write single atomic concepts on single lines instead of spread all over the place, eg:
PHA ; Save A
LSR A:LSR A:LSR A:LSR A ; Move top nybble to bottom
JSR PrNybble ; Print nybble
PLA ; Get A back
.PrNybble
AND #15:CMP #10:BCC PrDigit ; Check for 0-9
ADC #6 ; Convert A-F
.PrDigit
ADC #'0':JMP PRCHAR ; Convert to hex digit
"(having not played with CoffeeScript ) I would imagine debugging has to be done at the JavaScript level which may more than remove any benefits writing in your favourite language gives you."
Not really. To me, it appears CoffeeScript is just Javascript with cleaned up syntax... it's just making some bits that in Javascript are unnecessarily verbose much less verbose. (just go to the coffeescript.org site and you'll see what I mean, there's a short code sample right on the main page in javascript and coffescript side-by-side.) It's not like writing in python or perl and having your code converted into completely different Javascript, you'll just have the occasional one line of CoffeeScript that is blown out into 5 or 10 lines of Javascript. So, if the Javasript threw an error, I think it'd be pretty easy to find the equivalent line(s) in the CoffeeScript original.
I give it six months before they regret this. I've seen the regret with Coffeescript where I work and I've seen the regret for cross-compiled stuff for at least two decades. It's the lack of control that does you in. Since the browser runs the Javascript, you can't ever stop thinking in JS and how the CS will generate that JS. In the end you find yourself coding CS specifically to try and get it to generate the JS you want and all is lost. Couple that with the fact you then have to debug in the JS that CS came up with and you'll realise it's a maintenance nightmare.
It seems pretty unfair since they compare it with what CS spits out, not what people can write. For example they claim that
number = -42 if opposite
is equivilent to
if (opposite) {
number = -42;
}
whereas it could actually be
if (opposite) number = -42;
which is pretty much the same as the coffeescript albeit in a more gramitically sensible order. Also, given the coffeescript construct presented, I'd like to see its equivilent of
if (opposite) {
number = -42;
callmethod();
done=true;
}
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
