back to article 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 re- …

COMMENTS

This topic is closed for new posts.

Page:

Anonymous Coward

developers will be developers

This is putting the syntactic sugar before the customer. Or did the code suddenly become faster, less buggy, better usable on slow browsers and behind shoddy links? No? Thought so.

These guys should've gotten jobs writing python instead.

4
9
Silver badge

Re: developers will be developers

Most of the Dropobox infrastructure is written in Python!

0
1
Anonymous Coward

Re: developers will be developers

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!

0
0
Silver badge
Holmes

Re: developers will be developers

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.

6
0
Silver badge
Thumb Down

Re: developers will be developers

"> 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.

5
1
Bronze badge

Re: developers will be developers

"Bugs don't come from the syntax "

but of course, they do. Finding the syntax to match semantics with least possible potential for confusion is active area of research in language design!

5
0
Boffin

Re: developers will be developers

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).

0
0
Silver badge
FAIL

week-long hackathon ?

Well, that certainly bodes well for the site security. Not.

4
1
Silver badge

Re: week-long hackathon ?

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.

3
1
Silver badge

Re: week-long hackathon ?

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.

12
0
Silver badge
Thumb Down

Re: week-long hackathon ?

> 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?

2
0
Bronze badge
Facepalm

Re: week-long hackathon ?

Indeed. Security is ALWAYS an afterthought art DropBox.

0
0
Silver badge

Re: week-long hackathon ?

"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.

2
0
Silver badge

Re: week-long hackathon ? @Charlie Clark.

"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.

0
1
Silver badge
Happy

Re: week-long hackathon ?

Security would never be implemented in the client (i.e the browser) in the first place.

HI DrXym, let me introduce you to Any Web2.0 Developer...

1
0
Anonymous Coward

Re: week-long hackathon ?

> server side checks which could not be circumvented regardless of what the client side was written in.

Cross-site scripting attacks?

0
0
Silver badge

Soon it will need to be standardised for the browser

and then the usual suspects will become involved and stop it in its tracks.

1
2
Silver badge
Boffin

Here's why

The translation process from CoffeeScript to JavaScript generates browser neutral code and they can spend more time writing code in a language similar to one which they all know instead of testing everything in 10 different browsers.

1
2
Silver badge

Re: Here's why

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.

2
0
Silver badge

Re: Here's why

Try FireBug with AceBug and keep an eye on Mozilla/Google's SourceMap project.

0
0

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

6
0

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);

1
1

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"

8
0

I agreee really

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.

0
0
Anonymous Coward

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.

0
0
Thumb Up

So True!

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.

0
0
Silver badge
Thumb Down

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?'

3
0

"It'll be cool" is a fine reason for a software project.

In fact, what other reason is there? :-)

2
1

The answer is simple - Money, dear boy.

The adult's answer could be expressed in many fashions, but Sir Laurence's has stood the test of time, and why reimplement anything for which there's a satisfactory library solution available?

0
0
Anonymous Coward

Rewriting in another language for the sake of coolness?

That's the first step towards qualifying for a career at the Government Digital Service

1
0
Thumb Up

They've made the code more readable and more maintainable - which is fantastic as it'll be far easier to understand, extend and debug.

That's the reason. Fair play to them.

3
1
Anonymous Coward

Which Script has 5 less KLOC?

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...

1
0

Re: Which Script has 5 less KLOC?

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.

1
0

The death of javascript.

The fact that people are faffing about like this to get away from javascript shows that it's fundamentally flawed.

We really need something better in the browser as standard.

2
6
Silver badge

Re: The death of javascript.

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.

1
0

Re: The death of javascript.

> 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?

0
0
Silver badge

Sort of makes sense. Possibly.

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?

1
1
Silver badge
Mushroom

Re: Sort of makes sense. Possibly.

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.

3
1
Anonymous Coward

plus ça change, plus c'est la même chose

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

4
1

Re: plus ça change, plus c'est la même chose

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.

0
1
Happy

Re: plus ça change, plus c'est la même chose

Way back at the dawn of time I *was* an assembly programmer. I'm actually quite glad we've moved on, even though it was fun at the time.

0
0
FAIL

if it ain't broke

don't waste money fixing it...

2
0
WTF?

Re: if it ain't broke

Which is why the Post Office was still using pulse-based dialling in the eighties...

0
0

Re: if it ain't broke

Javascript is broken though.

Even people who dislike the alternatives can see that. At best it's a necessary evil.

1
1
Anonymous Coward

Not sure about the metrics

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.

3
0
Thumb Down

Dropping ?

I do not see where they are dropping Javascript as, in the end, CoffeeScript is leading to Javascript. This is just a new way to generate Javascript and/or manage complexity.

0
0
Coat

Sooo... in summary

They re-wrote the code because they couldn't think of anything else to do and otherwise might have been made redundant...

2
0

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.

0
0
Facepalm

Phython? Whyyyyyyyyyyyyyyy?

"The developers are Python-lovers, "

Lord preserve us from significant whitespace. Anyone who likes a language in which the space character is important enough that it becomes part of the code structure needs a big kick in the head.

0
0

Page:

This topic is closed for new posts.

Forums