Join the DZone community and get the full member experience.Join For Free
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.
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.
One of best features of ruby is
debugger, which is basically a less powerful version of
With Opal, you get none of that. You can use
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.
Another thing which turned out to be far more annoying than expected is dealing with timestamps. Ruby has
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.
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.
Once it starts, overhead isn't too bad, but this really needs to be solved for production use.
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.
Published at DZone with permission of Tomasz Wegrzanowski , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.