Something like this is nice, and might appeal to people that want a simple, reasonably 1:1 compilation comparison between the language and the underlying JS implementation.
However, I personally am FAR more excited about something like http://opalrb.org which essentially provides a Ruby runtime in JS and lets you run complex code with real Ruby syntax and runtime library features.
I have been extensively testing Opal with just about everything I can throw at it and am constantly blown away by just how much it feels like I'm really running Ruby code client-side. Incredibly powerful stuff that would be a PITA to write in Javascript is a breeze with Opal. Browser compatibility doesn't seem to be an issue (IE 8, older Android, etc. all working).
Sorry, I know I sound like a fanboy now, and I swear I have no connection to the Opal devs (didn't even know about the project until last week), but since I've really really wanted for some time now to skip the "CoffeeScript" phase altogether and wait until I can write genuine Ruby front-end code that compiles to JS, I am super excited.
Good luck to RedScript though, that's also an interested project and, again, might appeal to people (not me) who want something extremely lightweight.
> Incredibly powerful stuff that would be a PITA to write in Javascript
...care to elaborate on that? Javascript is a pretty versatile and expressive language imho and if you stay away from its dark corners and "anti-features" it's just as good as any other dynamic language (except languages with real metaprogramming facilities like lisps, but this is no the point), so I'd really like an example of a kind of problem/solution/pattern that is easy to express in Ruby code and hard in Javascript code.
Definitely intentional. I like to color up language or throw a curveball in a well-understood idiom. Nobody does that anymore, and they used to do it all the time. Now we just reuse the same tired idioms over and over again. Blah.
Do you think by using Opal or RedScript is possible to avoid learning JavaScript?
Because CoffeeScript is all well and good but I really don't see how it is useful, except from maybe speeding up your development a little, since you need to know JavaScript in order to use it properly.
> Do you think by using Opal or RedScript is possible to avoid learning JavaScript?
RedScript essentially supports JS syntax plus Ruby-like syntax, and allows them to be freely mixed, so you probably need to learn JS for RedScript, especially if you ever have to read code that comes from someone else.
Opal is Ruby, but allows inlining JS (using the mechanism regular Ruby uses for inline shell commands, essentially, the JS interpreter is the "system shell") which I suspect is going to be fairly heavily used in Opal projects until there are more Ruby wrappers around JS functions (e.g., DOM-related ones) necessary for even the most basic web work. So, you probably need to know JS to make effective use of Opal for now, though that may not be true forever.
CoffeeScript doesn't have to eliminate JavaScript to be useful. Just having a better notation for passing anonymous functions as parameters makes such a huge difference on code clarity that I think it's worthwhile.
Does Opal support Native to an extent to allow me to use it with existing libraries such as Backbone without the need of writing extensive wrappers? Opal is an awesome project, but the last time when I looked at it using JS libraries with it wasn't trivial.
It indeed does. While not always perfect, are pretty useful. I account their lack of usefulness to deficits in how JS handles errors rather than the source map itself.
Can we just get LLVM on browsers to compile embedded IF with JS-to-IF (or existing VM) as legacy? Think about it. Every three months, "omg THIS in Javascript!" and every fourth month, "omg THIS language becomes Javascript!" Can we just get an acceptable LLVM sandbox that uses the browser as sort of the OS and -actually- can do everything we need the runtime environment to do instead of giving us more and more relatively fake advances in user-facing software?
LLVM can be compiled to JavaScript via Emscripten. It doesn't get much more portable than that. Not to mention a half dozen or so hardware CPU architectures (http://llvm.org/docs/CompilerWriterInfo.html#hardware)
Not sure to what degree we're talking. ARM + x86 has basically everything covered. Even -if- ARM support is bad now, completing it would be easier than creating exactly the custom toolchains that LLVM was designed to abstract away. Who runs browsers on PPC or whatever that isn't consciously taking responsibility for their access to portable software?
http://llvm.org/docs/HowToBuildOnARM.html
i think he means the LLVM bitcode produced.. the IR.
That IR have target processor specifics in it..
but i think the pnacl guys already think about that, and they have a different "bitcode" (as LLVM people say) from the original LLVM..
anyway.. whats more portable than source code? people should stop fancy binary and closed source.. there are no much secrets left these days anyway.. and if you are a hit, nobody can take you that, just by branch the code and call it other name.. unless you are doing something really wrong..
Yep, it has very close goals when compared to CoffeeScript. However for the most part RedScript ditched the "It's just Javacript" mantra. I also just wanted to learn Regular Expressions and Node so I thought I would make this to prototype an idea.
Absolutely! I should have wrote on the page that it was only intended as an MVP style prototype. Just enough to play with. Hopefully someone wants to write one that will also output source maps :)
Thanks for bringing this to my attention! I didn't realize Rust had an .rs extension. If RedScript can get a real production ready compiler, we can definitely change it to something else.
This is cool but I think the project would benefit from a feature comparison to CoffeeScript, which is the first thing that comes to mind when seeing this.
CoffeeScript is very Ruby-like, but not quite...The big difference, among others, is significant whitespace.
One Ruby feature that I was expecting to be in this was Ruby Enumerable objects. CoffeeScript has nice iterators like this:
ages = for child, age of yearsOld
"#{child} is #{age}"
But not like Ruby:
ages = yearsOld.map{|child, age| "#{child} is #{age}" }
Yea I definitely need to get a better side by side separation. When I originally released it there was little interest and I became too busy with other jobs to continue putting time into it. Maybe next week though!
Had the same argument about a year ago. No, once you override it, it's gone. The value of the font-family property is a single list, not a list of lists.
It's pretty easy for language authors to integrate with Sprockets in Ruby on Rails. They just need to write an interface for Tilt (http://github.com/rtomayko/tilt) . Though that interface needs to be written in Ruby, not JS.
However, I personally am FAR more excited about something like http://opalrb.org which essentially provides a Ruby runtime in JS and lets you run complex code with real Ruby syntax and runtime library features.
I have been extensively testing Opal with just about everything I can throw at it and am constantly blown away by just how much it feels like I'm really running Ruby code client-side. Incredibly powerful stuff that would be a PITA to write in Javascript is a breeze with Opal. Browser compatibility doesn't seem to be an issue (IE 8, older Android, etc. all working).
Sorry, I know I sound like a fanboy now, and I swear I have no connection to the Opal devs (didn't even know about the project until last week), but since I've really really wanted for some time now to skip the "CoffeeScript" phase altogether and wait until I can write genuine Ruby front-end code that compiles to JS, I am super excited.
Good luck to RedScript though, that's also an interested project and, again, might appeal to people (not me) who want something extremely lightweight.