This is awesome. I'm really curious to see if the Ruby community will ever fully embrace something like Opal.

Having used ClojureScript a bunch it's pretty nice to compile whatever backend programming language you're using to Javascript to use in your UI. Makes it really easy to share data structures between the front and back end. Would be really interesting to see more Ruby code written this way.

As someone who has been trying to spread the word on Opal for a few years (including this talk http://funkworks.blogspot.com/2014/01/opal-new-hope-for-ruby... for full affect, For watching the video I would start with the uncensored https://vimeo.com/82573680 and then switch to http://www.youtube.com/watch?feature=player_detailpage&v=GH9... when it's done), it surprises how little interest the Ruby community has taken in opal.

I would in part attribute this to not enough documentation and examples, but otherwise I'm surprised.

This is about as comprehensive a list of opal resources as exists ATM

This is the resources link I forgot to post http://metaruby.com/t/opal-resources/201

I think the term is isomorphic, but I am not sure.

For Ruby you can look at http://voltframework.com - uses Opal underneath.

I believe isomorphic has fallen out of favor (as it's being reclaimed for its original specific meaning) compared to Universal.

on HN maybe. Nowhere else.

Perhaps but it won't help it's case that it's actually wrong. Isomorphic is correct - they share similar structures but often aren't the exact same.

Universal implies a level of parity on server and client that just isn't there in almost all apps that are isomorphic.

It's just plain wrong.

To be fair, on that front, Clojure is a dramatically more simple language. edn is a really well defined set of primitives.

Ruby has an incredible amount of cruft, gotchas, and a massive stdlib.

You may be interested in the opal-phaser game development library / wrapper: https://github.com/orbitalimpact/opal-phaser

The interesting question that Opal brings to the forefront is to what degree do Rubyists, like myself, use Ruby for the exact toolset it provides (aka everything in the MRI, all the gems, Rails or Sinatra, etc.), or to a certain extent because of the syntax and design principles found in corelib/stdlib and third-party DSLs, etc. -- aka the "Ruby way".

In my case, I've discovered that I love Ruby as a language/philosophy even more than I love Ruby as it's been precisely defined for the last couple of decades. And so, what that means is that "alternative" flavors of Ruby, like RubyMotion for native iOS and Android dev, and Opal for compile-to-JS scenarios like browser-based client-side development (or even Node.js-based development), are extremely appealing to me. I'm even interested in non-Ruby languages that are heavily influenced by Ruby such as Crystal.

I should note at this point I'm pretty heavily invested in the Opal ecosystem (I'm the publisher of the http://www.opalist.co newsletter for instance) and have shipped production apps that include real-world Opal code, so of course I want the project to be successful. But I came to that conclusion in part because I took a hard, hard look at the future of web development and decided I simply did not want a career as a Javascript programmer. Sure, I can write advanced, modular, well-crafted JS code. But can and want to are two different things. :)

Also check out React.rb [0] ruby wrapper for react

[0]: https://github.com/zetachang/react.rb

This is the first time I've heard of Opal (and I think it's pretty neat). Has anyone written about sharing ruby code between the frontend and backend with Opal (or something like it)?

Volt http://voltframework.com/, and Clearwater https://github.com/clearwater-rb/clearwater are exactly what you're looking for

I've been blogging about it as hard as I can over at http://datamelon.io/blog . Hope that more people spread the word- it's going to be an amazing technology.

Thanks for that, I've been following your series - good stuff.

Personally, I might jump into Volt once it becomes more mature.

I've written a fair amount via this tag on my blog http://funkworks.blogspot.com/search/label/opal

I'm committed to providing content for opal newsletter http://opalist.curated.co/issues so that will be ongoing. Hope there's some interesting info in there

I will be writing some articles on "isomorphic rails" -- I figure that has big reach and gives you the best of both worlds * shared ruby code and views on front and back end * everything else Rails does without having to learn a new server framework

For a multitude of reasons.

* Some people don't want to context switch between a different front-end and back-end language.

* Some people want everything in one language / environment for easier deployment / tooling / package management

* Some people just plain hate writing Javascript.