Decaf: Ruby in the Browser | Hacker News Reader

Decaf: Ruby in the Browser

trydecaf.org

126 pointsDanielRibeiro60 comments

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[1] is aiming to be an embeddable version of Ruby. Still a massive WIP though.

https://github.com/mruby/mruby

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.

It's a cool hack but it's pretty much DOA.

It's a modified version of WebKit. WebKit devs won't allow this to be part of WebKit itself (https://lists.webkit.org/pipermail/webkit-dev/2013-April/024...).

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.

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.

Reading the comments it's clear that majority people do not understand what it is, mostly because the title is misleading.

It's a custom, toy browser with Ruby support, not "Ruby in the Browser" (where the implication is that the browser == chrome or firefox or safari).

I'm just trying to clarify that so that people don't get the wrong impression from the misleading title.

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.

Stop thinking about market adoption.

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.

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!

[1] http://fluidapp.com [2] http://en.wikipedia.org/wiki/Mozilla_Prism

So, why aren't we talking about browser bytecode you guys? Why is everyone's solution "whelp, you're stuck with js".

Is asm.js going to be a useful halfway point?

I largely agree with you.

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.

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.

Well, we sort of have that in the from of CDNs, but taking it any further than that sounds like a very sticky security situation.

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.

language was a different attribute pretty much only used by IE and its ActiveX language embedding (which was pretty much only ever used for VBScript).

What I'm getting at in a somewhat snarky and roundabout way is that VBScript killed multilanguage support in browsers.

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

PDF: [http://research.microsoft.com/en-us/um/people/emeijer/papers...]

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.

Pretty cool... the only problem is users are not going to demand Ruby in their browser :/

I created RedScript to try and bring Ruby syntax into the browser, still pretty experimental though (and not the real thing!).

https://github.com/AdamBrodzinski/RedScript

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.

That same logic has been used for decades to discourage programmers from learning any language other than C...

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.

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.

MOAR Javascript, please.

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.

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.

If I remember correctly, an earlier version of Appcelerator's Titanium let you do that. But they killed it along the way, I believe.

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.

Cool project, regardless!

It did happen long time. It just died because of lack of adoption.

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.

I agree, and was also going to bring up the Opal solution.

Ideally, browsers would expose some kind of assembly-level language and you could define your own interpreter.

Oh please yes. Make this standard.

Not standard, but an option would be nice.

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.

Let me put this as clear as I can. In 2013, nobody, and I do mean nobody, cares for people that "disable Javascript in their browser".

Those people are freaks anyway.

I hardly think Steve Gibson is a freak.

http://en.wikipedia.org/wiki/Steve_Gibson_%28computer_progra...

If he disables his JS he very much is one, at least browsing-wise.

Not to mention that the whole entry screams "freak" in lots of places. I mean, how is this at all typical of the average programmer:

"Gibson is an advocate of assembly language programming, and prides himself on writing smaller applications mostly in Intel x86 assembly language"

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.

[1] http://opalrb.org/

JavaScript can do getters/setters through Object.defineProperty[1]. MVC libraries tend to use methods in order to support legacy browsers.

[1]https://developer.mozilla.org/en-US/docs/JavaScript/Referenc...

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.

Internet Explorer supports the installation of additional scripting languages ... or at least it used to.

Why not just write a ruby to JS transpiler? I imagine the yacc grammar could be translated to jison (http://zaach.github.io/jison/) , and it's really easy to grab those script tags (e.g. https://github.com/Niggler/scriptify.js/blob/master/scriptif...)

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.

So is it a browser? a browser extension? Does it replace my local webkit installs with something that supports ruby?

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.

Great work.

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.

This reminds me of Google's effort to run C and C++ code on the client side of the browser.

https://developers.google.com/native-client/

trying it now, few interesting facts,

goto the web inspector console, make sure the page_context = rb

* Ruby 2.0.0

> RUBY_VERSION "2.0.0"

Yay

* automated string conversion does not happen, you would need to do it your self

>Time.now

Time {}

>Time.now.to_s

"2013-04-08 19:47:14 -00700"

* top most object is not Kernel

>Time.ancestors

[Time, Module, Object, Kernel, BasicObject]

curious to know what standard libraries are included, hope will update the post with new findings soon

* ObjectSpace.methods does not work, so no global introspection.

* eval works >eval("2+3") 5

* able to extend objects

* browser specific classes Window(possibly a singleton), EventTarget, Console , BarInfo

* if you open multiple windows, it acts like a seperate irb instance, though console history is available

found a bug which crashes the app everytime, submitted a ticket https://github.com/timahoney/decaf/issues/5

Hmmm, might be very interesting for people running automated tests with browsers using ruby.

Honest question: what are the security concerns here? Ruby's $SAFE isn't really that great.

They missed the chance to name this language buby (browser-ruby).

Why not use Dart?

What browsers actually support this?

Reply on news.ycombinator.com