4 ms·

What is a good use case for this? Interesting project otherwise! :)

by shocks 12y ago

randall 12y ago
Ruby aficionado programmers who think coffeescript is too pythony perhaps? :)
- bigtunacan 12y ago
  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.
  - csbrooks 12y ago
    >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?
    - path411 12y ago
      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".)
    - benaiah 12y ago
      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).
    - radq 12y ago
      This is a good post by wycats that discusses this: https://meta.discourse.org/t/is-it-better-for-discourse-to-use-javascript-or-coffeescript/3153/19 https://meta.discourse.org/t/is-it-better-for-discourse-to-u...
  - dragonwriter 12y ago
    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.
    - bigtunacan 12y ago
      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-jeremy-ashkenas#awesm=~oGljICP4yb2Hxu 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-use-javascript-or-coffeescript/3153/18 https://meta.discourse.org/t/is-it-better-for-discourse-to-u...
DouweM 12y ago
There's something to be said for writing the client and server app using the same language. Node.js serves a similar use case.
- nbevans 12y ago
  What is the thing to be said?
  - evolve2k 12y ago
    Sorry if you were attempting to troll but if not 'there is something to be said about..' is a phrase which translates along the lines of 'there are definitely good things that could be said about..'
    - scotth 12y ago
      He's asking what those things are.
  - dragonwriter 12y ago
    The thing to be said is that client and server often share functionality, and if they are in separate languages, code for that shared functionality is necessarily duplicated in two different languages and must be maintained twice.
lukasm 12y ago
Say you have a function that validates a file written in ruby. Now you want to have client side validation in the browser for good UX. The spec for validation may be complicated or you are not sure about the implementation (no docs, person that written it just left). This is internal format with no good parsing library. I'd try it out.
- dragonwriter 12y ago
  Or you're completely sure about the implementation, but it may change in the future (because requirements evolve) and you don't want to have maintain two different versions.
deleted 12y ago
[deleted]
lukesan 12y ago
What about something like rubular.com inside the browser?
viseztrance 12y ago
I never got to using opal, but I was quite intrigued after watching this https://www.youtube.com/watch?v=GH9FAfKG-qY https://www.youtube.com/watch?v=GH9FAfKG-qY
lloeki 12y ago
I have a few developers that can't wrap their head around too much languages without popping one out. The less variability we have, the more robust the final code will be. Theoretically, all developers are ideal learning machines with a robust CS background and a powerful abstracting mind with infinite time to learn and jump around languages at will, with perfect understanding of each language caveats and idiosyncrasies. In practice, one has to build stuff. This kind of things, while not a perfect solution, allows my team to produce better code more reliably.
griffinheart 12y ago
I was entertaining the idea of using this to make a code combat for ruby when it was open sourced.

What is a good use case for this? Interesting project otherwise! :)

by shocks 12y ago

What is a good use case for this? Interesting project otherwise! :)

randall 12y ago

Ruby aficionado programmers who think coffeescript is too pythony perhaps? :)

bigtunacan 12y ago
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.
- csbrooks 12y ago
  >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?
  - path411 12y ago
    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".)
  - benaiah 12y ago
    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).
  - radq 12y ago
    This is a good post by wycats that discusses this: https://meta.discourse.org/t/is-it-better-for-discourse-to-use-javascript-or-coffeescript/3153/19 https://meta.discourse.org/t/is-it-better-for-discourse-to-u...
- dragonwriter 12y ago
  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.
  - bigtunacan 12y ago
    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-jeremy-ashkenas#awesm=~oGljICP4yb2Hxu 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-use-javascript-or-coffeescript/3153/18 https://meta.discourse.org/t/is-it-better-for-discourse-to-u...

DouweM 12y ago

There's something to be said for writing the client and server app using the same language. Node.js serves a similar use case.

nbevans 12y ago
What is the thing to be said?
- evolve2k 12y ago
  Sorry if you were attempting to troll but if not 'there is something to be said about..' is a phrase which translates along the lines of 'there are definitely good things that could be said about..'
  - scotth 12y ago
    He's asking what those things are.
- dragonwriter 12y ago
  The thing to be said is that client and server often share functionality, and if they are in separate languages, code for that shared functionality is necessarily duplicated in two different languages and must be maintained twice.

lukasm 12y ago

Say you have a function that validates a file written in ruby. Now you want to have client side validation in the browser for good UX. The spec for validation may be complicated or you are not sure about the implementation (no docs, person that written it just left). This is internal format with no good parsing library. I'd try it out.

dragonwriter 12y ago
Or you're completely sure about the implementation, but it may change in the future (because requirements evolve) and you don't want to have maintain two different versions.

deleted 12y ago

[deleted]

lukesan 12y ago

What about something like rubular.com inside the browser?

viseztrance 12y ago

I never got to using opal, but I was quite intrigued after watching this https://www.youtube.com/watch?v=GH9FAfKG-qY https://www.youtube.com/watch?v=GH9FAfKG-qY

lloeki 12y ago

I have a few developers that can't wrap their head around too much languages without popping one out. The less variability we have, the more robust the final code will be. Theoretically, all developers are ideal learning machines with a robust CS background and a powerful abstracting mind with infinite time to learn and jump around languages at will, with perfect understanding of each language caveats and idiosyncrasies. In practice, one has to build stuff. This kind of things, while not a perfect solution, allows my team to produce better code more reliably.

griffinheart 12y ago

I was entertaining the idea of using this to make a code combat for ruby when it was open sourced.