Am I the only one who just plain doesn't understand the value these tools provide? From my perspective, why not just _write_ javascript? Seems ridiculous. I mean, they're fun and all, but no one sets out to do a project of meaning or scale and chooses these tools, do they?
no one sets out to do a project of meaning or scale and chooses these tools, do they?
We certainly have (Parenscript) and it's vital for two reasons: (1) there are cases where we need to run the same code on either the server or the client; (2) we get the full power of Lisp macros. The latter means our source code is much smaller than JS we would have had to write by hand. Somewhat unexpectedly, there's a key efficiency issue here: making heavy use of abstractions in JS would make our code significantly slower. With Parenscript, we can write concise source code with nice abstractions that compiles to low-level, efficient (but still readable) JS. It's one of those rare times you get to have your cake and eat it too (an adage that really doesn't make sense, yet still always comes up #1 in the search results in my brain!)
I've switched over to CoffeeScript for all projects where I get to choose. It's an all around better language than js if you tend towards the functional side.
Iteration/comprehensions work like they should[1], destructuring simplifies extraction, there's a prototype binding construct in the language, less line noise, and everything is an expression. I also happen to like indent-significant languages and think it's a great DSL language.
I could certainly produce the same code writing in JS, but what would the advantage be? I'm already doing a build step for combo/minification and if not, a --watch compile gives roughly the same workflow as raw JS. I have to search for a snippet of text rather than going to a line number when I'm debugging, but I think the coding gains/cleanliness is worth the slightly increased debugging effort.
[1] With one gripe, `y = x + 1 for x in 0...10` got changed in August to match up with `z = x if x % 2` and friends (it was special cased) so y is now 10 instead of the array 1..10 and you have to wrap the comprehension in parens.
I enjoy using CoffeeScript on my hobby projects. If you write your server code in a language like Python or Ruby, CoffeeScript makes Javascript more familiar. It adds nice features like list comprehensions, and I prefer the way it handles classes and objects. But no, it isn't for everyone.
The same reason people don't just write in assembly (or more accuratley, C) to write a desktop application very often. Javascript is the assembly language of the web.
That analogy breaks down though. JavaScript is just as much of a high-level language as most of the things that are compiling to it. Most of the time the reason people don't just write in JavaScript is because they don't like it's _style_, rather then with C or assembly, where the goal is to work at a higher level to avoid writing boilerplate and managing things are are unnecessary.
It doesn't break down entirely though. Imagine we were all restricted to C++ for writing desktop software (although that's nonsensical, it's the case with JS and the web) - wouldn't it be reasonable to start developing other languages that compile to C++?
I agree with you esp. when it comes to GWT - going from Java to JavaScript is going from a terrible language to an ok one. There are two reasons why it has become popular:
Java programmers don't want to learn JavaScript
It comes with good UI building tools
If GWT didn't have good UI building tools, Java programmers wouldn't have any excuse not to learn JS and program normal web applications. But here's a tool that lets them use their existing Java knowledge to build halfway decent web GUIs.
This is just another example of how technologies are chosen by considerations other than objective technical merits.
I used to think the same way as you do... I couldn't understand the point of using ruby or java (GWT) to generate javascript (and I didn't understand the popularity of rjs in rails). First, on the contrary to many, I actually like javascript and, second, I founnd that it's just didn't feel like a really good fit...
Now though, I use CoffeeScript but it's very different to the above. It was made with javascript in mind, it's more of a clean syntax for javascript, allowing you to code exactly like you would normally in javascript but in cleaner, neater way..
For the same reason people don't write everything in Javascript. It is not the global optimum language any more than any other language is, and there are tasks where it is easier in programmer terms to write in another language that can have stronger guarantees or a better DSL for some task or whatever than Javascript. As more and more stuff moves to the client an expanding range of client tasks falls under this category.
Most projects do just use straight JavaScript which is a big problem. JavaScript does all the wrong things by default. "for in" loops and "==" comparisons are a couple big offenders, that often appear to do the right thing (but fail later in unexpected ways). Any of these compilers worth their salt will limit their output to properly formed loops and comparisons and otherwise cross-browser compatible code, etc, saving you from a great deal of pain.
One reason is to be able to consistently work with the same language both on the server and on the client. In this way one doesn't need to change gears all the time. I do like JS, but I'd rather use Ruby (or language of choice) most of the time.
CoffeeScript is largely an alternate syntax to JS with a couple of macros added on. That's more like the prima ballerina changing from her pajamas into a tutu.
Indeed, they don't go as far as some of the other ones, but it's still a language that compiles down to JS. It's nice that it's a strict superset of JS (iirc anyway) but that alone doesn't mean that it's impossible to produce slow or bloated JS.
Of course any language that does a lot more than CS is going to be slower, e.g. Objective-J's object system providing method-missing functionality and a whack of other features not found natively in JS.
Define good in this context. I'm inclined to say that if it doesn't have cross-browser bugs and it's fast, then it's good. The output being readable to human programmers probably shouldn't be a goal when JS is being used as a compiler target.
Agreed in principle, but readability still matters a great deal for debugging. There's vastly more browser tool support for JS (e.g. Firebug) than for languages targeting JS. These tools get harder to take advantage of as one's compiled JS gets less readable.
Sometimes I think the holy grail for what we do would be a Slime-like REPL in the web browser that speaks Parenscript, maps to source code, and had full debugging support. In the meantime, though, things like Firebug are indispensable.
I'd define good as it takes full advantage of the javascript language and produces & can be used to create structures optimised for javascript, not the language it was written in.
This is why I think it's better to reduce the context-switch between server and browser and not eliminate it. There's going to be a context-switch there no matter what you do, so there's no sense in paying such high prices to try to eliminate it.
Your lines of code measurement would be more compelling if you used sloccount instead of wc -l. Also, are you counting the lines of code in directories with tests in the name for Mozilla? I don't grok that find(3) incantation fully.
Added emscripten which to my untrained eyes seems like the place where a lot of gains can be made. You can gain a lot by removing the middleman but sometimes you can gain a lot by adding one.
Emscripten is the most exciting project IMO - it's basically a more portable NaCl. I wonder if Google will start using it if they're serious about NaCl.
Hey, creator of Pharen here. I've been procrastinating on another release for a while but still developing it. If anyone wants to check it out there is a better site over at http://scriptor.github.com/pharen.
NS Basic/App Studio compiles Visual Basic style BASIC to JavaScript + HTML5. Also includes an IDE. Targets iOS and Android. (http://www.nsbasic.com/app)
Ah, nice! That's a long history - you've held out better than some of the other tools I remember using for Palm, like CASL, HB++ and AppForge. (Also amusing that Palm got their start on the Newton, with Graffiti.)
This is a great list. I was just thinking about what might be out there the other day. I'm very interested in Ruby --> JS. However haven't tried them. I followed Charles Nutter's work on JRuby for a while and it seems to me that it's extremely involved to actually compile a fully functioning ruby into another language and/or bytecode.
Mascara (http://www.mascaraengine.com/) compiles a typed version of ECMAScript (based on Harmony and other proposals for ECMAScript extensions) into JavaScript. It is backwardly compatible with JavaScript, so you can gradually upgrade code to take advantage of it.
Thank you for posting this list! I don't think I would have ever heard about http://cluecc.sourceforge.net/ otherwise. It seems like a really big deal, I'm very surprised I haven't heard about it before. Def. checking it out.
List of interpreters implemented in JavaScript for various languages would be also nice. I think they can be useful for educational purposes i.e. writing interactive materials on the web.
Fantom (http://fantom.org/) also compiles to javascript. However this platform is supported via direct AST transformation not runtime bytecode generation as for JVM or CLR.
The generated code from that won't run without a JS runtime implementation in CL backing the JS-specific Parenscript forms, which currently doesn't exist to my knowledge (it's not hard to write, just not very useful). This is useful by itself for writing JS analysis and transformation tools and moving JS code to Lisp.
