I've toyed with this idea before, though I had considered Lua due to its specialization in embedded environments and relatively simple sandboxing.
Interesting choice, here, in going with Ruby. Ruby is not exactly intended for embedding, and I imagine that a veritable mountain of holes in the script sandbox would need to be plugged before anything like this could see mainstream adoption. On the other hand, people are likely to be a lot more excited about native Ruby support in a browser than they would be about Lua.
Overall, I wish this project much success. It will be a long road, but I hope Ruby is just the first language to be supported in this way...
Mruby has been compiled with Emscripten. There's a demo of it on the Emscripten wiki, where you can edit and run Ruby client side that way, though obviously with the caveat that bridging from Emscripten generated code to "normal" javascript is far from ideal.
Even if it's actively maintained (and maintaining a fork of WebKit, even if it adds just one feature, is super hard), it'll be of extremely limited appeal.
Basically it's a custom, "toy" browser that you have to download and the ruby scripts you write will not be usable by anyone else (because no one else will use that browser).
There's no way this thing gets traction.
Nevertheless: kudos to the author for a cool hack.
You missed the point. This is not intended to be a general browser. It has an enormous potential as an embedded browser in desktop app. iTunes is such an app, one that ships with its own modified WebKit. Things like Fluid [1] and Prism [2] allows you to quickly generate such desktop application using Safari and Firefox, respectively. Now imagine Fluid + Decaf: you can quickly build a desktop application that talks a web services, with Ruby code from end to end! It's huge!
Who cares if it's not ready to be distributed as a binary to the masses? Who says they even want it to "gain traction"? It's a POC, and an awesome one.
Chill out dude and stop thinking about market adoption. It's about the journey, not the destination, remember ?
This is clearly a new creative process that should be treated with respect. This may open the door for seeing other languages in the browser where chrome might like say be bundled with v8, mruby, python vm, etc.
Your children one day will laugh at you saying our parents only had javascript in the browser.
Since when have we only had javascript in the browser? We've had Java applets. We've had Flash. The issue is security holes. The reason our children will never laugh at us for only using javascript in the browser is because we cared about writing secure web applications.
One place that it could succeed is as an embedded browser in native apps. There is already traction for building "native" applications using HTML/CSS/JS and plenty of frameworks that bundle your web app into a native app. There's no reason they couldn't use a Ruby-aware (or Python-, Lua-, whatever-aware) WebKit fork instead and give the app maker more choices.
I'm not saying it's necessarily a good idea, but I'm also not convinced it is a terrible one. I need to think about it more before I decide where I personally land, but my point is that there is absolutely a place for a tool like this.
Really the only reason I see that asm.js should be a halfway point rather than an endpoint is that it's kind of verbose. Even so, gzip makes a lot of that point moot, and it might be possible to make a bytecode with a 1:1 correspondence with asm.js (which could then be parsed using JS in legacy browsers), to make something even more concise.
But including an entire emscripten'd ruby environment on your website just because you don't want to use JS seems insanely inefficient, and no bytecode is going to fix that.
If we could just have shared libraries in the browser, it would solve the problem of having to serve the entire ruby runtime with each webpage. You'd just put a tag in the header indicating you're using ruby runtime version X and the browser would download it and put it in some permanent cache for javascript code. Really, it's high time we got some sort of package management for browsers.
P.S. I mean shared libraries in the abstract sense, not .so or .dll files specifically.
Food for thought -- can you describe to someone why using bytecode would be faster? V8 is pretty damn fast, would it really be made any faster by using a bytecoded VM instead?
There are other reasons to use a bytecode VM besides performance, but the one with the code wins, in this case :-)
The problem, as I see it, with a browser bytecode, is that bytecodes are generally tailored to a specific language. A bytecode designed for JS, for example, is not necessarily something you'll be able to implement Python or Ruby in particularly efficiently. With asm.js I'd be willing to bet that a general purpose bytecode would not let you run any of these languages more than, say, twice as fast as simply pushing the interpreter through emscripten.
This keeps coming up lately and it really needs to be clarified. Asm.js is not a useful tool for running dynamic languages as a browser-replacement for js. It carves out its own heap and has extremely limited interaction with the DOM.
You probably could establish a bytecode for that purpose, but the problem is that putting it at a higher level (where real interaction with the DOM is possible) gives you an impedance mismatch between object (how messages are dispatched) and execution models (how things like exceptions propagate) that can only be overcome at some degree of a performance loss.
I'm not saying that can't be solved, but I don't think anyone's put any serious effort into doing so in a generalizable way.
It's kind of funny that once upon a time, in the early days, there was actually a language attribute to the script tag and at least one browser actually supported embeddable languages.
Sure, it was an embrace-and-extend move, but I'm not sure it was a bad idea even so.
The `type` attribute is still there, it only fallbacks to javascript if not set. Nothing besides common sense prevents browsers from shipping with type="text/ruby" support as done here. It's just not a very good idea.
Well, I don't think that holds any water. Multi-language support wasn't and still isn't a good idea; having one good toolchain and cross-browser environment is already a huge effort and far from done, supporting multiple languages would just fragment the ecosystem and slow down progress.
There is hardly any popular language today you could embed and get better performance than JS anyway, except for Lua, which barely qualifies as 'popular'.
Meanwhile there are a hundred cross-compilers/transpilers out there that give you the kind of syntax you want, without requiring a ton of changes in browsers.
Erik Meier & co used it to enable Haskell as a scripting language (in 1998!). See his "Confessions of a used programming language salesman", HaskellScript
Those who remember the hell that was VBScript in the browser, know that having support for more than one front-end language is not such a good thing. Web developers have benefited from having javascript as the only language supported by browsers.
Language fanboys might bash javascript, but there are many examples of the great things that can be achieved with javascript that make them look really quite silly, and every language has its pitfalls. Javascript is not a bad language, but it is misunderstood and people who misunderstand it are the most vocal detractors.
Opening up the browser to many languages causes the tower of babel all over again. Now front-end devs won't just be required to be a "javascript ninja", they will now have to master many other languages in addition to all of the DOM wackiness that comes with supporting multiple browsers. It's all just too much.
In the early days of the web I worked at a dev shop where we used <script language="perl"> (or python, or a couple others) for server-side templating. It was a pretty nice system, actually.
This project is solving wrong problem. JavaScript is not very popular because it is the best programming language in the world, it's popular because it runs everywhere. Any solution for making better web application (including new programming language) that breaks it will fail. Period.
Except in the world of C, the common denominator isn't the language but binaries. You can write in any language you want so long as you have a good compiler.
There is something to be said for ubiquity that programmers of other languages just don't get. Ruby might seem like a good idea to put into a browser but it will run slow as shit compared to the javascript engines that are in modern browsers. A lot of development has gone into optimizing javascript engines. Ruby, not so much.
Javascript is also the easiest language to learn, requires no boilerplate, and will run inside any web browser since the mid 90s, and the code you write with it can run instantly in any web browser, no installation required, just a URL to click on. There are so many reasons to learn javascript and develop with it, it is really unique and should remain that way. I'd really rather not go back to the days when there were two front-end languages, or worse, coffeescript.
You're assuming the problem is "run everywhere all the time."
Plenty of projects are underway to get code that runs on "some of the machines very well all the time". asm.js, Google Native Client, and now that Blink has become a thing, I'll bet Dart gets it own VM in the most popular web browser in the world.
I wonder if this would work as a platform for desktop apps. HTML+CSS is quite nice for quickly creating GUIs and then Ruby could power the domain logic.
On the one hand, adding to standard browser engines support for multiple scripting languages, instead of just Javascript, is a cool idea, and something that probably should have happened a long time ago.
On the other hand, the fact that this currently requires the user to install it first, seems to make it less portable than a compile-to-JS solution like Opal (http://opalrb.org/). At least until standard support for multiple scripting languages actually does get introduced to browser engines.
But even the combined might of IE and Microsoft (that was long time ago, when Microsoft and IE were mighty) couldn't get it broadly adopted so it's effectively dead.
People still disable Javascript in their browser. We aren't there yet. I'd like to see native haml, coffeescript and sass support in the browser, that seems to me a more realistic dream in the short term.
This is cool! I'd like to see a Ruby front-end MVC framework that takes advantage of Ruby's unique strengths. For example, explicit getter and setter methods like in Backbone and Ember.js wouldn't be necessary anymore with Ruby's properties and dynamic methods. Maybe one could even write a Meteor-esque framework with Ruby.
It wouldn't be as useless as one might assume. There is Opal [1], a Ruby-to-JavaScript compiler, which could potentially be used as a fallback for web browsers that don't natively support Ruby.
Do other browsers support Ruby? I've never heard of this, but the line "if your browser supports Ruby, click here for a sample" implies that Decaf isn't alone in this.
Last time I looked, which admittedly was one of the 1.8.x versions of Ruby, the bison grammar for MRI was 6000-7000 lines including thousands of lines of C code that included a lot of state tracking for the parser to handle the more obnoxious parts of the grammar... Hopefully that's improved in 2.0... Or maybe the Rubinius or jRuby parsers might be better starting points (haven't looked at either)
Nope, it's still incredibly awful. Most of those thousands of lines aren't actually the grammer but the hand-written, full of exceptions, lexer. It has, if anything, gotten even worse thanks to allowing method selectors (the '.') to be placed on the next line, and the (key: value) syntax for hash args.
And all working active ports of Ruby use either the MRI lexer/parser verbatim or a mostly direct port of it. The JRuby port has the good graces to at least break the thousands of lines of lexing out into a few basic functions based on the first char of the token rather than leaving it in a giant switch statement, though.
Great project! It's amazing how much like an OS the browser can be (if that's what we want).
I see the web inspector works -- it would be fantastic to be able to build apps using nothing but the web inspector, save them and serve them, rinse and repeat.
Sweet! I would love to use this with my visual novel game framework (http://rubyai.org). Right now, it converts all of the logic from Ruby to JavaScript.
Interesting choice, here, in going with Ruby. Ruby is not exactly intended for embedding, and I imagine that a veritable mountain of holes in the script sandbox would need to be plugged before anything like this could see mainstream adoption. On the other hand, people are likely to be a lot more excited about native Ruby support in a browser than they would be about Lua.
Overall, I wish this project much success. It will be a long road, but I hope Ruby is just the first language to be supported in this way...