Oops, time flies!
It's been a long time since I last wrote about webruby. 2014 is a really busy year for me, mostly busy in places other than programming :) Anyway, I'm back here, and I'm confident to say that webruby is not dead. In fact, I've recently upgraded webruby to the latest version of mruby with emscripten SDK. This solves a lot of existing bugs in mruby, and will also give us better experience in the better.
Okay, back to the topic of this thread. I will probably write about this upgrades, but let's leave that to a future thread. I've been wanting to write this for a while: someone posted a comment on my webruby tutorial asking:
why not using opal?
I've answered this question once when I was doing Q&A for RubyConf China 2013, but at that time, I know so little about Opal that I didn't even know Opal can do bootstrapping!
I've thought about this question for a while, and here's my conclusion: I think Opal and webruby are 2 quite different way of running Ruby on the web: while Opal translates Ruby directly to JS, webruby compiles the whole mruby VM(written in C) to JS, and runs mruby bytecode directly. Both implementations can parse Ruby code right in the browser now without a question, the targets used are different: JS for Opal, and bytecode for mruby.
I won't go that far to say this is definitely advantage for webruby, since I believe at one time the legendary Mike Pall recommended language creators target Lua directly, not luajit bytecode. But it's worth pointing out this is a difference. Depending on the exact application you are building, one might be more appealing than the other one.
Below is a few points I want to make about webruby, I won't classify them as benefits over Opal, I just like to call them as interesting behaviours of webruby:
- Webruby shares the same parsing as mruby, so if there're any parsing changes at mruby side, all we need to do is updating mruby code. There's no need to implement the special parsing code again. Webruby will always(well, the exact answer is mostly, since the underlying C compiler might have different semantics) have the same syntax and semantics as the official mruby implementation.
- In webruby, C-interoperability is possible via emscripten. Existing C code can be brought to the web, either due to performance reasons, or legacy reasons. Certain wrapper code is needed for interop between Ruby and C, of course, but it still saves a lot of efforts IMHO.
- Portability is an area that I think webruby certainly has an advantage: if you have a mruby codebase already running in other environments such as embedded boards, Android or iOS, porting to the web via webruby might not be a hard task. See this for one example on this, those awesome developers use webruby to build a Web IDE for their mobile payment system. What's also worth mentioning is that by portability, I'm not talking about Ruby alone! For those embedded systems, I consider both Ruby part and C part as a single codebase. Code written in both Ruby and C can be ported to webruby with certain efforts.