Hacker News Reader

Comment by bigtunacan | Hacker News Reader

As DouweM said; there is a case to be made for having the whole stack in a single language.

While I use different languages server side, Ruby (either with Rails or Sinatra) is my go to option more often than not these days.

I have used CoffeeScript extensively, but this has always been on contracts where the decision was made by someone else.

It is important to learn and use real JavaScript (IMHO) rather than all of these transpiled languages. This is the route I take when I have a choice on the client side; I use JavaScript.

If I were to use a transpiled language though Opal makes more sense (IMHO) than CoffeeScript if you are working on a project with a Ruby backend. At least then you are creating a uniform stack and hopefully getting some type of productivity boost for your development team instead of always context switching between different languages.

View on HN

>I have used CoffeeScript extensively, but this has always been on contracts where the decision was made by someone else.

>It is important to learn and use real JavaScript (IMHO) rather than all of these transpiled languages. This is the route I take when I have a choice on the client side; I use JavaScript.

I've been using Rails and Coffeescript. Intuitively, I feel like using Javascript directly would be better somehow, but I prefer the Coffeescript syntax. (I started using it just because Rails nudges you that direction.)

What are the benefits of using Javascript directly instead of Coffeescript in a Rails environment?

I don't think there would be much benefit except possibly some minor performance gains. But then to even take advantage of these you would likely have to be extremely proficient in native JS.

Personally, I don't really see much of a downside to JS transpiled languages. You are already working with a high-level scripting language. The incredible amount of benefits you gain from using something like Coffeescript or Typescript far exceed any negligible downside to them.

(You do have to trust that the transpiled language is good however. You don't want to accidentally start using a bad language that fails to transpile or is simply harder to work with than native js. With Coffeescript/Typescript being very popular, I would consider them both "safe".)

If you don't know JS really well, I wouldn't recommend Coffeescript. It's hard to tell what will work correctly and what won't unless you're quite familiar with the actual code the Coffeescript is compiling down to. I don't know how true this is for other transpiling languages, but it's definitely true for Coffeescript.

I'm a pretty experienced JS dev, so I know exactly what my CS is compiling to and what that's going to do. If I didn't, CS would make me tear my hair out within a week. As it is, it's just shorthand for JS with a bunch of quality of life improvements (?, no var, etc).

This is a good post by wycats that discusses this:

https://meta.discourse.org/t/is-it-better-for-discourse-to-u...

It seems to me that complaining that you need to use "real JS" instead of a compiled-to-JS language for web apps is like saying you need to use real machine code instead of a compiled-to-machine-code language for an other kind of app.

That is an apples to oranges comparison. Hence the terminology difference between transpiler/compiler.

A transpiler is a very specific subset of a compiler that takes one language that has a "similar" level of abstraction and compiles it to a different language with a "similar" level of abstraction.

C++ compiled to machine code is not at all similar to CoffeeScript transpiled to JavaScript.

If you are working in CoffeeScript/TypeScript/Opal you are still likely to need to understand JavaScript to best leverage existing JavaScript libs/frameworks and to build on or debug those tools when necessary.

A couple of problems arise when you introduce something like CoffeeScript. Now you have added yet an extra layer of knowledge required to the infinite pool of required knowledge

Problems

1) Knowledge required

Now your team is required to know

CoffeeScript(Replace with other transpiled language here) + JavaScript + HTML + CSS + Backend Language of Choice

2) Hiring pool

Eventually you will need to hire someone. This presents a problem from both the employer and employee side

Employer Side (Pointy Haired Boss)

We use CoffeeScript/TypeScript/etc... so we need to post that as a job requirement.

Employee Side

Really smart potential employee who wants to apply knows JavaScript; sees posting requires CoffeeScript. This employee hits indeed.com and sees there are <1000 coffeescript jobs total, versus >43,000 javascript jobs. Employee decides to stick with JavaScript and doesn't apply.

This is a bit of an old interview and I don't know Jeremy Ashkenas personally so I don't know his current stance of CoffeeScript, but I'm going to post it here since it's from the horse's mouth and I believe it illustrates why using JavaScript is really a better choice.

"If the question is 'why is CoffeeScript not a DocumentCloud project?' - it's because I can't justify using it for the main DocumentCloud development. Imagine trying to hire someone. 'You'll have to learn to use a new language that we made up...'" - Jeremy Ashkenas

http://readwrite.com/2011/01/07/interview-coffeescript-jerem...

3) Future proofing

I'm just going to link back to the same wycats link someone else posted, because it's much more elegant than how I'd put it.

https://meta.discourse.org/t/is-it-better-for-discourse-to-u...

Reply on news.ycombinator.com