It's official: mruby-browser is now called WebRuby!

Published on:

After a pretty long discussion and fix(Thanks to Alon for the awesome job in fixing this issue!), now setjmp/longjmp in emscripten works well. The C++ dependency in mruby-browser can be finally dropped, and all the mruby tests can pass without any particular hack. We can now say that the basic building block is there, and I can turn to focus on more interesting stuffs. It is also at this time that I think a new meaningful name is needed for this project. The original mruby-browser sounds too much like an experiment instead of a project for everyone to use.

The first thing came to my mind is RubyScript. With something already built called CoffeeScript or ClojureScript, it is not so hard for this particular name to come to my mind. However, Google tells us that someone has already uses this name. It looks quite like a hackathon project(20 commits in two days, and no commits since then for over a year). But I still do not want to take the risk that this guy(or lady, it is so hard for me to judge this by the name, can anyone give me a hint?) may want to bring this project back to life. Let's try something else.

What's worth mentioning is that someone is building MobiRuby, which brings mruby to iOS. Well, I'm bringing mruby to the Web, so what about WebRuby? Google tells us that there aren't so many people using this name, one is using this as a repository for a web course, while the other is just a sinatra-based web backend. Well, I will just pick this one as the name:)

Besides changing the name, I also change the build script a little bit. Now we can simply put mruby source code in src folder, the source code will be parsed and compiled when building the project. Only the final generated bytecode will be included in the js file or the webpage. This saves us the time for parsing the source code online. If at some point we need to parse the mruby source code online, we can easily bring this back since the parse code is still included in the generated js code.

Personally, one good thing about owning an open source project is that you can decide the priority of each feature:) As a developer who always dream about creating games, my next thing to work on will be a wrapper for OpenGL ES 2.0 API. I still haven't thought of some beautiful ideas on a calling interface between mruby and c(or js), so I think I will first focus on some particular library wrappers. Since mrbgems is already in HEAD, it becomes a natural idea to pack this library as a mrbgem. The reason for choosing OpenGL ES 2.0 over WebGL is that OpenGL ES 2.0 is more general, and maybe it can also be used with mruby in iOS or Android development. What's more, emscripten provides a translation between OpenGL ES 2.0 and WebGL, so we can simply take advantage of that instead of write yet another wrapper of WebGL.

Just as I said before, it is really fun working on this:)


comments powered by Disqus