silly less / coffeescript deps #766

tj opened this Issue May 7, 2013 · 37 comments


None yet
tj commented May 7, 2013

pretty brutal that you can't build the thing without these executables... please consider removing these dependencies, it's nothing but annoying

tj commented May 7, 2013

handlebars too apparently

tj commented May 7, 2013

ew nevermind the entire driver is coffeescript

@tj tj closed this May 7, 2013

@visionmedia, we rely on LESS and CoffeeScript for both the web UI and the JS driver-- it's proven to be useful in our development process.

However, we provide a source distribution with all these assets precompiled specifically because on some platforms these tools behave unpredictably. It's detailed in our build instructions:

You can always find the latest source builds here:

tj commented May 7, 2013

I don't use things I can't read / contribute to, I'd seriously consider removing at least the coffeescript because that's something people will want to contribute to more so than the CSS.


I appreciate your comments on our use of CoffeeScript. We've found it hasn't been a deterrent to contributions, but your point is well-taken-- you're welcome to look at the compiled JS output from the latest build package-- the output is located at drivers/javascript/build/rethinkdb.js.

The compiled version is well-documented and readable-- check it out!

tj commented May 7, 2013

the rest looks sweet though, just a little disappointing to run across that. I think build steps are pretty important personally, if it's not reasonably smooth you're just opting-in to a big black box that you have no hope of contributing to. Something to think about though! cheers


The issue isn't that you use coffeescript. It is more that you are claiming to have a "javascript" driver/module but it isn't cause you use coffescript (which is a separate language). To me, this is confusing for anyone but the initiated. I can crosspile python to js, but that doesn't mean I am publishing js modules like that :/

By all means, continue to use whatever you love and keep making cool stuff tho!!

jdoliner commented May 7, 2013

Hmm, this actually makes some sense to me. How hard would it be to make the driver be pure javascript? Could we just take the compiled coffee script and start editing that by hand?

neumino commented May 7, 2013

Or we can just say that we have a node driver.


I take issue with this comment:

We've found it hasn't been a deterrent to contributions

How do you know?

Edit: I ask because I had this same dilemma presented to me a number of times; and every time, the impact to potential collaborators outweighed the benefits to the development process.


@kenperkins because they mantain the project and are happy with the level of contributions?

IMO there are more important things to worry about right now than back-porting the node driver to js, like the ~250 open issues, optimizing performance or supporting secondary indexes :)


Hi all, I'm the one who nudged @wmrowan to use CoffeeScript to write the driver. I'm his boss, so the responsibility is mine.

Firstly, I was a little hurt to find that folks made disparaging comments and then edited them when this issue got twitter attention. Nothing makes the team here happier than knowing that people are taking the time out of their day to play with Rethink. We always welcome criticism, and we try and take full responsibility for all technical decisions. However, we really don't appreciate finding curses in our inbox. Everyone is in this together to make technology a little bit better -- could we please keep things civil?

As to using coffee for the driver, it makes our development process much easier but I can see how it can be confusing to the community. I'm going to reopen this issue and do the following:

  1. Make build instructions without extended dependencies (less, handlebars, etc.) described by @mglukhovsky above (#766 (comment)) much more prominent on the build page.
  2. Revise the wording on the site for the JS driver to make it clear that it's written in CoffeeScript.

In addition, we'll see if we can change the build process to build Rethink without the web UI if any of the dependencies (handlebars, etc.) are missing and Rethink wasn't downloaded via a source distribution. This should be pretty easy, but we have to discuss this a bit first.

Thanks to everyone for your feedback -- please keep it coming!

@coffeemug coffeemug reopened this May 8, 2013
@jonathanong jonathanong referenced this issue in expressjs/express May 8, 2013

silly javascript #1613

0x00A commented May 8, 2013

i'd be excited to try this if it was just written with javascript :)

rubenv commented May 8, 2013

@mglukhovsky @coffeemug Language discussions are nothing new, don't be discouraged by this. I've written my thoughts about those over here:

In short, as a maintainer, pick the tool that's most productive for your task, the core team will do the bulk of development anyway (and has to support it).


Coffeescript is considered hard to pick up now? I can understand the argument if Rethinkdb was written in something like Arc Lisp or Brainfuck, but come on.

mtrimpe commented May 8, 2013

I also appreciate the irony of the author of a CSS preprocessor complaining about the use of what's essentially a JavaScript preprocessor.


@mtrimpe he doesn't ship Express with Stylus, there's a difference. Also, I fail to see the negative tone in TJ's comments, he just wanted those dependencies removed, and when he realized everything is written in CS he closed this issue. There's some serious overreacting going on here.

@on-topic: I had many situations where I needed to read / alter the code of some module because the documentation didn't cover 100% of the use cases and fortunately it wasn't that hard. That's why I always prefer modules written in plain JavaScript instead of CoffeeScript / Dart / etc etc. Sure, this is a personal preference and I have nothing against this driver being written in CoffeeScript, only thing is I just won't use it.

This situation reminds me of the Riak driver:


That's why I always prefer modules written in plain JavaScript instead of CoffeeScript / Dart / etc etc. Sure, this is a personal preference and I have nothing against this driver being written in CoffeeScript, only thing is I just won't use it.

Your opinions are 100% valid for you, and I'd love to read them on your blog, discuss them on HN or Reddit, and so forth. It's a vital topic. I don't even disagree with you much: My library is written in vanilla JavaScript but the tests are in CoffeeScript ;-)

But is this really a bug or feature request? Somehow, I think not, and I suspect that the issues tool is not the best place to make this kind of contribution.


I don't use things I can't read / contribute to

Come on. It’s coffeescript! It does not differ much from javascript. It compiles to JS almost 1:1, unlike clojurescript and stuff.

This is really weird excuse to not using great piece of software. Personally, i’d use and contribute to dart, coffeescript, typescript, livescript or coco projects if they’re cool.

tj commented May 8, 2013

I honestly cannot read coffeescript, we use one coffeescript project, an exif parser and it's already becoming a pain in the ass because we need to make mods. I closed the issue because yeah, it is what it is but there's no disputing that it absolutely makes contributions more difficult. I would be equally disappointed if it were dart or similar. This applies to anything though, I look at the source of every single thing I include as a dependency, if it's extremely messy (even if it's js) I won't use it.

0x00A commented May 9, 2013

@paulmillr CS:JS does not compile 1:1, that's just not true at all.

Coffeescript is a fun toy for people who think clever syntax is the most important aspect of programming.


@hij1nx of course it does. Of course it is. Y U NO like toys?

almost 1:1

chaplin ❯ cat src/**/*.coffee | grep --invert-match --extended-regexp '^\s+#' | wc -l
chaplin ❯ cat lib/**/*.js | wc -l                      
chaplin ❯ coffee -e 'console.log (2467 / 1944).toFixed 3'
tj commented May 9, 2013

@raganwald hence why I closed the issue :p


Quite right!


any status on this? i'd love to help because the driver is way ahead of mongodb, but i'm not touching the source code in its current form.


rewriting into ES6 w/ a transpiler would be pretty cool. that's what the author of autoprefixer did (coffeescript -> es6) and i don't think he has any regrets.


👍 for rewriting into ES6, 👎 for CoffeeScript

Also please please please put this in a separate repository so people don't have to clone the whole rethinkdb when fixing something in the driver. If you want the driver in this repo for the tests then just require('rethinkdb') where necessary.


There have been some thoughts on adopting as the official RethinkDB node.js driver. Rethinkdbdash is written in JavaScript directly. It doesn't have capabilities for connecting to the server through HTTP yet (we need that for the web UI), so we have to implement that first.

Note that we will still be using less and coffeescript for the web UI code, so the dependencies won't change.


@joaojeronimo regarding putting drivers in a separate repository, please see #1740

niieani commented Nov 18, 2015

👍 for move to ES6 or to rethinkdbdash. TypeScript could be even more awesome, since that would offer autocompletion just like the one in the Web UI, but in our IDEs.

niieani commented Nov 24, 2016 edited

Would the rethinkdb team be interested in a PR that converts the current CoffeeScript driver to TypeScript / ES201x?


Please don't do typescript, the point of this PR is to have the rethinkdb driver in a common language for everyone that you don't have to transpile and more people understand/write/work with than any other language, writing the driver in typescript is just as bad as coffeescript except with a different syntax and type safety at compile time.

niieani commented Nov 25, 2016 edited

@joaojeronimo For backwards compatibility you'd need to transpile modern-style JS to ES5 anyway, so that's not really saving any steps.

TS is simply JS with optional typings, it's not a different syntax, unlike CoffeeScript.

The upside of TypeScript (aside from type safety and better maintainability) is that, if at any time in the future the team decides to ditch TypeScript and switch to pure JavaScript, they can strip the type declarations using one simple command (tsc -p . --target esnext). Et voilà, you're back to using pure JS!

It's not possible to do the same with CoffeeScript, since CS includes many features that JS simply does not have, and the code transpiled by CS is filled with overly verbose, convoluted and hard-to-read JS with extra helper methods.


Well this is not about to turn into a JS vs TS conversation. My point is more people write/understand Javascript than both typescript and coffeescript and probably all the AltJS languages combined, if you want to have more people willing to contribute to a community project then you go with Javascript.

Your point about typescript compiling to JS is as valid as if it were with coffeescript, typescript also brings non JS things to the table like async/await and others.

niieani commented Nov 25, 2016

I'd like to leave this decision to the rethinkdb team -- rather than wasting time discussing the merits of one over the other -- I'm happy to help with either a TS or a ESnext conversion. Ultimately they'll be working with it the most, so they've gotta be comfortable with the language choice.

I proposed TS as the better alternative, since the team is in the process of converting horizon's client to TypeScript (there's a WIP PR by @deontologician), so it seemed natural that the rethinkdb driver would move to TypeScript too.

@joaojeronimo async/await is not TypeScript. It is a stage-3 proposal that will ship as official JS, most likely in the ES2017 standard, and most of the major browsers already have implementations ready, in fact Chrome ships with await/async enabled by default.

While it might sound contradictory, contributing to a TS codebase is much easier than to a JS one, because of things like self-documentation through types and autocompletion. You can dive into the code and understand it much quicker than a raw JS codebase.

Plus, it's easy to refrain from using any TS-specific features in the code (actually, the only TS-specific feature are public/private fields in class constructors, the rest is all standard JS + some stage-3 ECMA proposals).

I'm not going to speak about TS vs JS anymore in this topic, since many things were said about that on the internet and it just seems like a pointless flame war -- also -- there are 19 participants to this topic, so lets respect their time and their email inboxes. 🐧

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment