Hacker News Reader

With JavaScript ordinary developers hit a wall at some point and can't make further progress. Like Java has shown, how good the language is seems secondary to how good the implementation, the runtime, is.

JavaScript runtimes have kept on improving and with the V8/Node.JS combination have started taking over the server-side code.

With careful engineering, developers can get even further with just JavaScript the language. I wonder for instance whether using the Google Closure Tools can bring more gains there. Such tools help with checking the code for common pitfalls and the style guidelines also help a bunch. Plus, they might help with deployment, with the packaging for the specific program you've written so you don't need to package up all the library with it. Then you don't need to feel ashamed of making use of lots of library code, if only the part of it that you're using gets deployed.

Still, working with JavaScript directly can also bring debugging challenges, even more when you're trying to debug code that has been mangled since leaving your library source files.

Languages like CoffeeScript and Dart have success because the alternative in pure JavaScript is still quite painful, as I've mentioned above. It's a mistake to dismiss languages like CoffeeScript and Dart because you want that 50% extra performance.

Still, CoffeeScript is a concept. It could be said to have been over-engineered in places. Some of the stewards of JavaScript would have found it better if it was more like a JavaScript with JSLint turned on and some niceties on top of it.

Just to clarify one thing, it's very unlikely that you'll take a 50% performance hit when moving from JS to CoffeeScript. That may be true for Dart as well--I don't know.

Also, since CoffeeScript transcompiles to JS, it will generally reap the benefits of future improvements to JS runtimes, packaging tools, etc.

I have high hopes for dart, but so far it produces absolutely crap javascript. http://www.reddit.com/r/programming/comments/ml62k/hello_wor...

With JavaScript ordinary developers hit a wall at some point and can't make further progress.

Can you elaborate a bit on this? I still feel like I'm new to JS and am interested in what lurks ahead.

Thanks for the great response Jeremy.

It's a ton of fun to write. That's why. I absolutely love writing it. That alone is why I didn't pull the plug on it at work.

I have great feelings of guilt for posting that article w/o talking more about the things I really enjoy about the language. I'm having blast with my SnackJS CoffeeScript branch. https://github.com/rpflorence/snack/tree/amd-coffee

I think every JS developer should give CoffeeScript a spin in a side-project.

Heh, you're framing the question in a way that is more likely to elicit positive CoffeeScript comments, but I'm happy to oblige.

In order to adopt any new language, you obviously need to eventually believe its benefits are greater than its hurdles.

CS had a few hurdles for me early in the process. I had to install it, and that was simple. Then I had to learn it, which was fairly easy. It helped me that I had a fairly strong foundation in Python, Ruby, and JS, and the subset of CS that I initially learned is largely a blend of those languages. The language is small and well-documented. (Hopefully we keep it small--there's a bit of creeping featuritis in the community.)

Debugging is the only ongoing hurdle. It's never been a big issue for me. Obviously, I try to write the code correctly in the first place, and CS's nice syntax helps me focus on writing correct logic by removing the need to deal with JS boilerplate code. When I still manage to write incorrect code, I use all the debugging tools that I would use to debug JS. Someday my ability to write large JS programs may atrophy, but I'll never forget how to read it or make simple modifications in the debugger.

Even if the hurdles of CS were relatively minor, it would be pointless to use CS if it gave me no benefits. For me the benefits of CS are its writability and readability. It's that simple.

I'm already sold on CS, but I could still suggest ways to minimize the hurdles. First, keep the language small and simple. Second, no matter how good the current docs are (and they are pretty good), continue to refine them. Finally, do everything possible on the CS side to facilitate debugging, which mostly comes down to line number support.

* Keep the language small and simple.

* Continue to refine the documentation.

* Work on source map support (when it lands in browsers).

I think you've basically just outlined the current roadmap ;)

I think the blog post was a good one - it pointed out the problems.

Instead of defending it - go make it better. Address the items put forth right ?

1. work to get native debugging 2. clean up the looping mechanism

etc...

Instead of taking this guys post and saying 'negative criticism', see it as 'positive criticism' - he is reviewing it, showing what can be better, showing the obstacles.

I think part of developing a truly good library, is the ability to improve it, take criticism, expand and grow - not to cling to the original concept and defend all day long.

Personally I'd concentrate on the debugging, secondly, I'd work to improve the overall syntax, maybe providing alternative, more structured for some - others that don't like that can continue to use the same.

But again, rather than everyone just spamming here on how it 'rocks' or how it 'sucks' - would be better to take these observations and go and say 'how can we improve' - this is golden feedback here!

If you want to help with the debugging aspect, the current bug in CoffeeScript is here:

   https://github.com/jashkenas/coffee-script/issues/558

There are relevant bugs open in WebKit-land, and Mozilla-land as well, and should be pointers to those in the comments of the referenced bug.

I don't understand what the big deal is. If you don't want to use coffeescript then don't use coffeescript.

Are there examples of large(ish) projects or production websites using primarily CoffeeScript?

It seems like CS has a fanbase among purists who enjoy the syntactic elegance. But in more pragmatic environments the extra pain in the develop-debug lifecycle would seem to be a showstopper. I just wonder how many developers end up voting with their feet when confronted with that choice in the real world.

P.S. Another argument against that wasn't mentioned: CoffeeScript represents an additional barrier to entry for opensource projects. Shipping compiled JS code is not unlike shipping a compiled binary... and if you want people to participate and contribute, requiring CS knowledge is an extra hurdle that most JS devs will shy away from.

I agree wholeheartedly, hence the initial question...

Here's a few examples of production sites/apps off the top of my head:

http://getcloudapp.com/

https://posterous.com/

https://widescript.com/

http://basecamphq.com/mobile/

http://itunes.apple.com/us/app/ars-technica/id393859050

In my case, Rails 3.1 is the answer. I never felt the urgency of a better JS so much as to look for solutions, but having it already integrated into the workflow makes you really appreciate it. Except when debugging, of course :)

those who care and think that they need an abstraction on top of JS / feel like it's a good approach / can't understand or find it hard to use plain JS, are free to use it.

I think people can have positive or negative opinion about things. deploying application frontend of which was written in CoffeeScript was the biggest mistake in my entire career, but I don't blame coffeescript, it was me stupid choosing a technology that doesn't suit the task.

people use many libraries that are generally bad, and asking "how do people still use it" and claiming that it's super-popular is very lame and doesn't really explain anything, and never is a counter-argument.

i don't like it, that's my opinion, it didn't work well for our projects and we have rewritten most of things, and will rewrite the rest of CS back to JS.

it's ok that people use it. some of them will face same issues we did and come to same conclusion. others will be happy, since it solves (THEIR) problem. the rest will never be smart enough to grasp why (and wether) it's good or bad. it's trendy and looks cool, so they'll stick to it.

you've done a great job when created it, but our problems are still better easier and more stably solved by plain js.

thanks.

    > deploying application frontend of which was written in
    > CoffeeScript was the biggest mistake in my entire career

... can you elaborate on this?

there were many problems with Barista during deployment. Some things that worked perfectly in development somehow stopped working later on, because of required recompilation. We were deploying in a high-security area, where there's no internet connection, and having to install Node or JS runtime was not good. But again - that was my stupidity, did not foresee that.

moreover, barista did not recompile assets until we touched / saved / modified the file.

We do not have direct access to production system, so all the bug reports are sent in JS, and we need to figure out how things happened and sometimes it was quite difficult to locate a precise place where it occurred.

now, we have to compile everything and package js files when preparing an updating version of software (again, no SSH connection, no internet connection, only tarball / zip update packages).

and, in general: even though everyone says that CS handles everything that JS does plus more, we found that it's easier to handle factories, mixins, scopes, inheritance and more with plain JS. it was always easier to read and understand, and no overhead for development or production, felt more natural. classes are not something we missed in JS, and comprehensions stuff seemed more like a syntax sugar, not something we really missed.

So - it added a complexity and made people to use CS features instead of things that fit more naturally to JS ecosystem. We've had several issues with syntax (e.q. hash assigned to a variable with a function inside or smth like that), but we worked around them on early stage.