Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Opal - Ruby on JavaScript VM - What's Still Missing

DZone's Guide to

Opal - Ruby on JavaScript VM - What's Still Missing

With all these Javascript variants floating around with varying degrees of success, why not have a strongly-typed language compile down to JavaScript?

· Web Dev Zone ·
Free Resource

Deploying code to production can be filled with uncertainty. Reduce the risks, and deploy earlier and more often. Download this free guide to learn more. Brought to you in partnership with Rollbar.

JavaScript VMs are everywhere, and environments running them such as browsers and phones look likely to remain the dominant way for users to interact with software for a very long time. This led to an explosion in the popularity of JavaScript - the native language of that environment.

But JavaScript is a dreadful language. It started a dirty hack, which just so happened to be positioned right and benefited from browsers becoming the universal user interface. It can't even ever get properly fixed like, let's say, Python 1, due to unique backward compatibility cost.

Fortunately, just as you don't need to write Java to run on JVM, or write x86 assembly to run on x86 hardware, it should, in principle, be possible to run on the Javascript VM without writing any Javascript.

So far it's been mostly "Javascript++" style languages like CoffeeScript, JSX, TypeScript, transpiling to older versions of JS and so on. It's something, but all of them are trying to make JavaScript, at best, barely tolerable.

So why not just write in a real language, and compile it to whatever Javascript VM wants?

Opal attempts to do just such a thing, letting you run Ruby in a browser. It's a somewhat different dialect of Ruby, most notably with immutable Strings, Symbol/String unifications, single numeric floating-point type, and a few other compromises to make it run better on the JavaScript VM, but it's mostly good enough.

Unfortunately, I don't think it's ready for serious use just yet. Here are the top 10 things it's missing, in roughly the order of importance.

Out of the Box Source Maps

When an exception happens, the most important information is where it's coming from, and the second most important is the entire stack trace. Exception type and message are usually not terribly informative anyway. With Opal, you get none of that, just some pointer to compiled code which looks nothing like what you wrote.

It's sort of true that it's also a problem with CoffeeScript or JSX, but, with such languages, you can usually figure out what's up from the compiled JavaScript with some practice. Opal to JS mapping is too big of a change, and lack of source maps makes debugging extremely tedious.

Opal absolutely needs source maps, out of the box, in every environment. That's the single largest barrier to productive use.

Decent Test Framework

Opal has opal-rspec.

But, it's just not good enough. It doesn't work with the latest version, doesn't give any meaningful information as to why a test failed, doesn't have any mode other than "run all tests," and is weirdly slow on top of it all.

This isn't even all that surprising, as JavaScript testing is a decade behind Ruby, and the source map issue on top of that makes it even worse. It's a huge productivity killer.

binding.pry

One of best features of ruby isbinding.pry. For that matter, one of the best features of Javascript isdebugger, which is basically a less powerful version ofbinding.pry.

With Opal, you get none of that. You can use `debugger` and try to figure out things from compiled JavaScript code, but that's not exactly a pleasant experience.

Support for Ruby Regular Expressions

Opal doesn't support Ruby regular expressions, it just throws whatever you write onto a JS regexp engine, and it's not even close to good enough. Even something as simple as /\A\d+\z/will completely fail - and, even worse, it will fail quietly without raising an exception.

Of course, you can write JS regexps, but then you lose any hope of sharing the same codebase between regular Ruby and Opal Ruby.

As an absolute minimum, it should raise an exception when it sees something it can't deal with.

Support for Time.parse

Another thing which turned out to be far more annoying than expected is dealing with timestamps. Ruby has Time.parse, which is pretty decent at handling the most commonly used timestamp formats. Opal will instead happily use a raw JavaScript constructor, and quietly give you a NaN timestamp object.

Like with the previous point, the absolute minimum is to raise an exception here, but something resembling Ruby's Time.parse would go a long way towards making Opal useful.

pry-rescue

As a followup to some of the previous points, something that lets you jump straight into pry on unhandled exceptions would be pretty good. Especially if it also worked in the test suite.

Precompilation of Libraries for Better Start Time

Ruby doesn't have a separate compile phase - it just executes code on a fresh VM and that code sets up various methods and classes via metaprogramming. Then it runs the application itself.

That works fine on Ruby VM, but most environments perform really poorly in this mode. The startup time of Ruby on the JVM with JRuby or JavaScript VM with Opal is thus fairly bad.

This is probably the most difficult thing to do, but right now any Opal code using a medium-sized wrapper like opal-d3 will have a much worse startup time than the native JavaScript version.

Once it starts, overhead isn't too bad, but this really needs to be solved for production use.

Better Interoperability With Plain JavaScript Objects

This is another point about debugging, but let's say I get a JavaScript object somewhere, and I want to figure out what the hell it is, or just dump it to the console. Currently, it's going to crash with a helpful message telling me that JavaScript objects don't implement the inspect method. Well, true, but it's an awful debugging experience, as, realistically, we'll be mixing Opal Ruby code with native JavaScript libraries in most use cases.

A Site Like Codepen.io

One of the nicest things about front-end coding is that it's possible to quickly code something in the browser, without going through all the hassle of setting up a local environment and sharing that with others. There's a lot of sites like codepen.io which help with this low-overhead quick coding.

Opal will definitely need a site like that or to be supported by one of them.

A Killer App

And, finally, we get to the usual "Killer App" point. I put it last intentionally - because unless most of the previous points are addressed, there's no killer app which could possibly work.

Deploying code to production can be filled with uncertainty. Reduce the risks, and deploy earlier and more often. Download this free guide to learn more. Brought to you in partnership with Rollbar.

Topics:
javascript ,ruby ,vm ,language ,web dev

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}