[adambeynon]

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.

[jrmiii]

What kind of client side coding are you using it for?

[adambeynon]

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.