8 ms·

Decaf: Ruby in the Browser

126 points by DanielRibeiro 14y ago

api 14y ago
Oh please yes. Make this standard.
- brink 14y ago
  Not standard, but an option would be nice.
- Kequc 14y ago
  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.
  - coldtea 14y ago
    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.
    - UnfalseDesign 14y ago
      I hardly think Steve Gibson is a freak. http://en.wikipedia.org/wiki/Steve_Gibson_%28computer_programmer%29 http://en.wikipedia.org/wiki/Steve_Gibson_%28computer_progra...
      - coldtea 14y ago
        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"
micheljansen 14y ago
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.
- rrouse 14y ago
  If I remember correctly, an earlier version of Appcelerator's Titanium let you do that. But they killed it along the way, I believe.
jballanc 14y ago
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...
- FuzzyDunlop 14y ago
  mruby[1] is aiming to be an embeddable version of Ruby. Still a massive WIP though. https://github.com/mruby/mruby https://github.com/mruby/mruby
  - vidarh 14y ago
    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.
msoad 14y ago
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.
- jballanc 14y ago
  That same logic has been used for decades to discourage programmers from learning any language other than C...
  - duaneb 14y ago
    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.
- nateberkopec 14y ago
  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.
- flywheel 14y ago
  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.
thirdtruck 14y ago
Sweet! I would love to use this with my visual novel game framework (http://rubyai.org http://rubyai.org). Right now, it converts all of the logic from Ruby to JavaScript.
TannerLD 14y ago
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.
- flomo 14y ago
  Internet Explorer supports the installation of additional scripting languages ... or at least it used to.
Skoofoo 14y ago
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/ http://opalrb.org/
- MatthewPhillips 14y ago
  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/Reference/Global_Objects/Object/defineProperty https://developer.mozilla.org/en-US/docs/JavaScript/Referenc...
deleted 14y ago
[deleted]
hayksaakian 14y ago
So is it a browser? a browser extension? Does it replace my local webkit installs with something that supports ruby?
kyllo 14y ago
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/ http://opalrb.org/). At least until standard support for multiple scripting languages actually does get introduced to browser engines. Cool project, regardless!
- kkowalczyk 14y ago
  It did happen long time. It just died because of lack of adoption. <script> tag has a type attribute. IE used to (still does?) support Visual Basic as a script. See http://www.w3schools.com/vbscript/vbscript_howto.asp http://www.w3schools.com/vbscript/vbscript_howto.asp 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.
- christiangenco 14y ago
  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.
nateberkopec 14y ago
Honest question: what are the security concerns here? Ruby's $SAFE isn't really that great.
brenfrow 14y ago
What browsers actually support this?
phillmv 14y ago
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?
- endlessvoid94 14y ago
  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 :-)
  - mistercow 14y ago
    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.
- mistercow 14y ago
  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.
  - anonymous 14y ago
    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.
kkowalczyk 14y ago
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/024514.html 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.
- endlessvoid94 14y ago
  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.
  - kkowalczyk 14y ago
    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.
    - theboywho 14y ago
      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.
      - UnfalseDesign 14y ago
endlessvoid94 14y ago
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.
niggler 14y ago
Why not just write a ruby to JS transpiler? I imagine the yacc grammar could be translated to jison (http://zaach.github.io/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/scriptify.js https://github.com/Niggler/scriptify.js/blob/master/scriptif...)
- vidarh 14y ago
  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)
  - stormbrew 14y ago
    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.
mrpoptart 14y ago
They missed the chance to name this language buby (browser-ruby).
adambrod 14y ago
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 https://github.com/AdamBrodzinski/RedScript
stormbrew 14y ago
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.
- ricardobeat 14y ago
  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.
  - stormbrew 14y ago
    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.
    - ricardobeat 14y ago
      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.
    - jstclair 14y ago
      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/icfp06.pdf http://research.microsoft.com/en-us/um/people/emeijer/papers...]
rurounijones 14y ago
Hmmm, might be very interesting for people running automated tests with browsers using ruby.
deleted 14y ago
[deleted]
senthilnayagam 14y ago
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
- senthilnayagam 14y ago
  * 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
  - senthilnayagam 14y ago
    found a bug which crashes the app everytime, submitted a ticket https://github.com/timahoney/decaf/issues/5 https://github.com/timahoney/decaf/issues/5
ancarda 14y ago
Why not use Dart?
UnfalseDesign 14y ago
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/ https://developers.google.com/native-client/

126 points by DanielRibeiro 14y ago

api 14y ago

Oh please yes. Make this standard.

brink 14y ago
Not standard, but an option would be nice.
Kequc 14y ago
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.
- coldtea 14y ago
  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.
  - UnfalseDesign 14y ago
    I hardly think Steve Gibson is a freak. http://en.wikipedia.org/wiki/Steve_Gibson_%28computer_programmer%29 http://en.wikipedia.org/wiki/Steve_Gibson_%28computer_progra...
    - coldtea 14y ago
      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"

micheljansen 14y ago

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.

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

jballanc 14y ago

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

FuzzyDunlop 14y ago
mruby[1] is aiming to be an embeddable version of Ruby. Still a massive WIP though. https://github.com/mruby/mruby https://github.com/mruby/mruby
- vidarh 14y ago
  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.

msoad 14y ago

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.

jballanc 14y ago
That same logic has been used for decades to discourage programmers from learning any language other than C...
- duaneb 14y ago
  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.
nateberkopec 14y ago
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.
flywheel 14y ago
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.

thirdtruck 14y ago

Sweet! I would love to use this with my visual novel game framework (http://rubyai.org http://rubyai.org). Right now, it converts all of the logic from Ruby to JavaScript.

TannerLD 14y ago

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.

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

Skoofoo 14y ago

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/ http://opalrb.org/

MatthewPhillips 14y ago
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/Reference/Global_Objects/Object/defineProperty https://developer.mozilla.org/en-US/docs/JavaScript/Referenc...

deleted 14y ago

[deleted]

hayksaakian 14y ago

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

kyllo 14y ago

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/ http://opalrb.org/). At least until standard support for multiple scripting languages actually does get introduced to browser engines. Cool project, regardless!

kkowalczyk 14y ago
It did happen long time. It just died because of lack of adoption. <script> tag has a type attribute. IE used to (still does?) support Visual Basic as a script. See http://www.w3schools.com/vbscript/vbscript_howto.asp http://www.w3schools.com/vbscript/vbscript_howto.asp 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.
christiangenco 14y ago
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.

nateberkopec 14y ago

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

brenfrow 14y ago

What browsers actually support this?

phillmv 14y ago

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?

endlessvoid94 14y ago
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 :-)
- mistercow 14y ago
  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.
mistercow 14y ago
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.
- anonymous 14y ago
  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.

kkowalczyk 14y ago

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/024514.html 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.

endlessvoid94 14y ago
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.
- kkowalczyk 14y ago
  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.
  - theboywho 14y ago
    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.
    - UnfalseDesign 14y ago

endlessvoid94 14y ago

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.

niggler 14y ago

Why not just write a ruby to JS transpiler? I imagine the yacc grammar could be translated to jison (http://zaach.github.io/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/scriptify.js https://github.com/Niggler/scriptify.js/blob/master/scriptif...)

vidarh 14y ago
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)
- stormbrew 14y ago
  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.

mrpoptart 14y ago

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

adambrod 14y ago

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 https://github.com/AdamBrodzinski/RedScript

stormbrew 14y ago

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.

ricardobeat 14y ago
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.
- stormbrew 14y ago
  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.
  - ricardobeat 14y ago
    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.
  - jstclair 14y ago
    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/icfp06.pdf http://research.microsoft.com/en-us/um/people/emeijer/papers...]

rurounijones 14y ago

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

deleted 14y ago

[deleted]

senthilnayagam 14y ago

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

senthilnayagam 14y ago
* 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
- senthilnayagam 14y ago
  found a bug which crashes the app everytime, submitted a ticket https://github.com/timahoney/decaf/issues/5 https://github.com/timahoney/decaf/issues/5

ancarda 14y ago

Why not use Dart?

UnfalseDesign 14y ago

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/ https://developers.google.com/native-client/