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.

Why not? Ruby-nuts have been trying to reshape JS into Ruby for years now. Might as well just go full balls on it.

Oddly enough that was done years ago via Silverlight of all things. http://www.rubyinside.com/ironruby-silverlight-ruby-in-brows...

Apologies if you just used a neologism, but I believe the phrase is "full bore".

"Full balls" is pretty colloquial, but I imagine it was intentional. It makes sense to me.

Kind of like "balls out" or "balls to the wall." Or even "balls deep." Y'know?

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.

> 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

You have a weird concept of "useful" if "speeding up your development" isn't a part of it :-)

the quote is "maybe speeding up your development a little"

> 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.

It's amazing how many people on the web aren't interested in making their lives easier.

Try using promises, and a small utility function to convert library functions that take callbacks to ones that return a promise.

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.

Kernel::Native

Does Opal generate source maps? That's a pretty big deal as the source generation gets further away from 1:1.

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?

This is precisely the aim of Google's pNaCl (portable native client): http://www.chromium.org/nativeclient/pnacl.

I think asm.js aims to fill this niche.

Well, that and Emscripten[1], which is the tool Mozilla used to bring Unreal Engine 3 into the web[2].

Note taht Emscripten is actually entitled An LLVM-to-JavaScript Compiler

[1] https://github.com/kripken/emscripten

[2] https://blog.mozilla.org/blog/2013/03/27/mozilla-is-unlockin...

I'd rather have Lua in the browser.

LLVM isn't portable.

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..

Security problems up the wazoo.

s/IF/IR/g

Wasn't adding Ruby-like syntax and syntactic sugar to JS the whole point of CoffeeScript in the first place?

Although this is much closer to plain Ruby.

It's a language mimicking ruby, inspired by coffeescript, which is a language inspired by ruby. We've come full circle!

I always felt CoffeeScript was closer to Python then Ruby. But maybe its just the significant whitespace that stands out to me.

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.

CoffeeScript was inspired by Python, Ruby, and Haskell.

Very cool! But maintaining all those regular expressions will soon be a pain. You need a real lexer and parser :)

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 :)

The file extension should probably be .red, not .rs. rs is taken by Rust.

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.

Agreeing with you, I filed it as an issue: https://github.com/AdamBrodzinski/RedScript/issues/1

.red is already being used by Red - http://www.red-lang.org

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}" }

ages = "#{child} is #{age}" for child, age of yearsOld

damn, i was expecting a coffescript like ruby.

I was expecting a coffescript Scala...

Coffee chip salad?

But seriously, yeah, I had in my mind Ruby blasphemously morphing into Python or something.

I'll take Ruby -> JS though :)

Reading the project website (http://redscript.org/), I got overly annoyed by:

- the non-monospace font

- the separation of RedScript and the compiled JS bit by the use of multiple spaces

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!

I agree with your second point, but the code is monospaced for me.

It's only monospaced if your machine has one or more of these fonts installed:

    Monaco,"Bitstream Vera Sans Mono","Lucida Console",Terminal

Font stacks should always end with a generic font family keyword. In this case: "monospace".

Font is already "monospace" in your browser by default rules. It's reset that breaks things, see stylesheet.css:5 # unrelewant omited

    pre {
    	font: inherit;
    }

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.

Example: http://i.imgur.com/8TLBd.png

It doesn't work with inheritance and it also won't work if the very same selector is used. E.g. if you add:

    .comment{font-family:foo}

to the current stylesheet, you'll get Times New Roman (or whatever your browser's default font is.)

Hence this line:

http://www.w3.org/TR/CSS2/fonts.html#font-family-prop

"Style sheet designers are encouraged to offer a generic font family as a last alternative."

I like this a lot more then I like CoffeScript.

You should write a new language called Rucoffee. It's CoffeeScript that looks like Ruby. Will definitely give you 100+ stars on Github.

Definitely check out CaféAuLait: it's French that compiles into CoffeeScript.

It would be awesome for something like this to become part of the Ruby on Rails toolchain down the road.

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.

Hey man... Pineapple would like to say..... awesome work!

Haha, thanks! Want to help write a real compiler? ;)

I hate javascript but this is pretty cool.

What do you hate about JavaScript? What's so wrong about it?

You need to learn (and understand!) javascript before hate it...

love this.

although i am annoyed that the redscript and subsequent javascript examples are merely split by spaces on the website.

I agree, I need to work on a better side by side example. I just pasted them into vim side by side and called it a day so I could ship it.