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