When it comes to debugging, I just use the standard chrome dev tools with source maps. Variables and properties on objects all compile using their ruby names, so viewing local vars and ivars in the debugger is easy. I only ever debug the generated javascript when I am debugging a bug with Opals runtime/internals/compiled code.
Various projects. Two recent ones are a POS system running on the iPad. The app is wrapped using Cordova for native scanner/receipt printer access, but the rest is built in Opal with a Sinatra backend. So lots of client models, lots of UI rendering using our opal-haml integration. Considering the POS system is dealing with thousands of product lines, performance on the iPad is great. Also, testing using rspec for all the opal client side code as the models are shared on the backend. Testing the same code using the same specs on both client and server is really nice, and saves a huge amount of duplication. It all comes from some extensions to Vienna which treats the opal stuff as a view layer replacement. Hoping to blog most of it soon, including the Cordova integration.
The example in this post is definitely a bad example of inline js in Opal. This is better handled by the `Native` bridge class, or writing a wrapper for it.
On the other hand, being able to drop down to native javascript anytime you like is a huge win.
Opal creator here. Debugging in Opal is no problem at all with source maps. I only need to look at generated code when Im working on improving the compiler/fixing bugs. Developing end apps always results in using the chrome debugger stepping through source-mapped code.
About the raw JS, to use my current app as an example, I have one line of inline JS (using `...` notation) which is just to initialize FastClick. Writing a ruby wrapper wasn't worth it for one method call. Anytime I see more then 1 line of inline JS inside a file, a ruby wrapper ends up being a much better idea, or indeed using the `Native` class which handles all the corner issues of calling native JS libs.
I think the problem with Opal is the documentation, which needs huge improvements, to show the proper/realistic development experience with it.
Im using it for an internal project. There is an associated `vienna` gem, that is for building rich web apps (think sproutcore, cappuccino). It is not open source yet, but will be once the project its been written for is finished.
When it comes to debugging, I just use the standard chrome dev tools with source maps. Variables and properties on objects all compile using their ruby names, so viewing local vars and ivars in the debugger is easy. I only ever debug the generated javascript when I am debugging a bug with Opals runtime/internals/compiled code.