 So, last evening we concluded our first day of talks on a very positive note, literally a positive note, and I'm pretty, pretty sure that I won't be able to deliver as exciting performance as Joseph did, but I'll do my best. Thank you for joining me and let's get this party started. So, my name is Bojidar. You probably cannot pronounce this, but do not be alarmed, do not be afraid. I come from Sofia, Bulgaria. I work at TopTow and I'm very thankful that they made it possible for me to come here. And you can call me Buck just as my friends do. And I know what you're thinking, but I have been known as Buck for 20 years, way before I became a software engineer. So, presumably, this has nothing to do with the quality of my code. Before we get to the gist of the talk, I'd like to set the proper scenery so you can get an idea of where everything started. So, a few things about me. The most important thing, I'm very fond of bears and to hear that everyone in Berlin is, so that's cool. I'm an emacs fanatic. I'm generally open to everything in life, but nobody in this world can convince me that there is an editor better than emacs. You saw a glimpse of the power of emacs last evening. And if I know we were going to do live coding in emacs, I would have done a totally different talk. Funny thing, the tool that Joseph was using to do the live coding is written by me. But I didn't know somebody could use it in this way. This was mind-blowing for me. So, this is how I see myself. You probably don't see me like this. Anyways, I do a bit of open-source work, mostly related to Ruby, Closure and T-Max. If you're into these sort of things, you can check out my GitHub profile. Most importantly for you, perhaps, I love Ruby very, very much. And I'm not very fond of JavaScript. I can talk all day about my issues with JavaScript, but I won't. I will just show you a single image. Clearly, there are some issues with JavaScript. And if this image doesn't convince you, you can check out this website, which has all the arguments in the world, so no need for me to reiterate them. So, why am I here? The first two things that I said are part of the reason, my lack of lawful JavaScript and my lack of Ruby. But the other thing that actually drove me to come here was this survey about the recent state of the Ruby community. According to it, 96% of all Rubyists are doing only web development in Ruby. And of them, 90% are using Ruby on Rails. It's kind of sad, but absolutely everyone seems to be using Ruby only to do Rails web development. And this is kind of worrisome because it seems that our beloved community has a bus factor of one. If something were to happen to Rails, if there is another cool framework in another language, Ruby seems to be dead in the water. And even more troubling for me, Rails is so omnipresent in our community that it is actually driving the development of the Ruby language, which is kind of insane. This is the change walk for Ruby 2.2, the latest release. Let us count how many times the word Rails appears in it. One, two, three, four, five. I don't know about you, but I have yet to see another language which is so dominated by a single web framework. This is pretty worrisome. My good friend, Yuan, is worried. His suitcase is worried. And I'm worried because it is worrisome. And what is even more disappointing is that the amazing members of our community have been working for years on tools like JRuby and Ruby Motion, which allow you to do so much more than web development in Ruby. You can be writing iOS and Android applications. You can be writing desktop applications. You can be doing machine learning. But no, we are Rails, Rails, Rails. We are so attached to Rails. And we love to make fun of JavaScript. We love to emphasize how much better Ruby is and the Ruby community. But let us have a look at all the things that the JavaScript people are doing with it. So we see that they are doing client-side applications. They are doing server-side applications. They are doing native iOS and Android applications. They are doing native Windows phone applications. And they are doing a ton of desktop applications. Imagine this 10 years back. It seems to me that something is going right in the JavaScript community. And it seems to me that right now, the possibilities with JavaScript are truly infinite. There is just one tiny bit of an issue. Nobody really loves JavaScript. Nobody ever said that JavaScript made them happy, right? And there has been this quest to find a language that will step into the shoes of JavaScript and will bring balance to the realm of the JavaScript programming world. You're all familiar with one of those attempts. Most of you are probably familiar with CoffeeScript, other worthy challengers for the crown of JavaScript would be PureScript and Dart, more recently, Elm. I encourage you to check it out because I do feel that Elm is pretty legit. And perhaps more importantly for this particular talk, there has been attempts to port established languages that normally do not run in JavaScript environments like Scala and Clojure. Clojure is super legit. You should definitely check it out to JavaScript. And why would somebody be doing something like this? Nothing put it better than the famous creator of Clojure when asked why his team is involved in porting Clojure to JavaScript. He said, well, because Clojure rocks and JavaScript reaches. And this is so, so true. And you know what? I can think of at least one more language that kind of rocks. And rumor has it that it is also better than JavaScript. And I have the numbers to prove it. I Googled for Ruby sucks, 1.7 million results. And then I Googled for JavaScript sucks. And you know, I have an education in statistics. So I know that this is scientifically correct. But on a more serious note, there are plenty of advantages that Ruby has over JavaScript. Some of them are, we don't have this. So we do not have any of the disrelated issues. We have somewhat same Boolean semantics. There hasn't been the need for a book, Ruby, The Good Parts Yet. Although I do have a talk, Ruby, The Bad Parts. So it's not only rainbows and unicorns in Ruby land either. There is no WTF, ruby.com yet. We have a solid core library which makes the existence of libraries like Underscore.js a non-issue for the Ruby community. We have an extensive standard library which adds a ton of battery power to the Ruby language. And do you really need more? You should be convinced that Ruby is a better programming language. And I guess I've been preaching to the choir so far. So let's get down to business. Without any further ado, I present the hero of this presentation, Opal RB. A tool which aims to replace JavaScript with Ruby everywhere where you would normally be using JavaScript. I would love to begin with a brief history of Opal. Most people haven't heard about Opal so far, but it's not a young project. Its initial release was over five years ago and there have been applications in production for at least three years now. Opal's popularity recently spiked when the VOTE web framework was introduced in the end of the previous year. VOTE is a truly magical piece of software. It allows you to share the same model, view, and controller code on the server side and on the client side. People were so impressed by its capabilities, but they didn't think very hard about where this power comes from and it comes from Opal RB which is at the core of the VOTE framework. The development of Opal is very active. Its team is pretty energetic and the latest release landed just a few weeks ago, so cool things are happening there. The very proposition of Opal is pretty simple. You don't have to write JavaScript anymore. You can replace every single usage of JavaScript with the beautiful Ruby code that you know and love. And how do we achieve this? Well, Opal is, at its heart, a Ruby to JavaScript source-to-source compiler, aka a transpiler, and this means that you feed it Ruby code and it produces the equivalent JavaScript code. There is no new VM. There is no new byte code. There are no translation layers. You're just running JavaScript code on a JavaScript virtual machine and you didn't introduce much additional complexity in the process. Opal throws in the mix an implementation of Ruby's core library and a partial implementation of the standard library. And I really feel that this is a very, very strong value proposition. I know that some of you right now are thinking but we already have CoffeeScript, DHH has blessed it, so it has to be the true way, the true successor of JavaScript. But let me quickly walk through some issues that I have with CoffeeScript myself. So first of all, it doesn't have a different core library. It has the same basic rather Spartan library that JavaScript has. So this really limits you to what you can do out of the box with it. There is no equivalent of Ruby's extensive standard library and let's face it, no way we sugar coated CoffeeScript is Ruby. Only Ruby is Ruby and this is deep, profound and simple and we have to come to grips with it. So here's a very basic example of what Opal program looks like. It's Ruby, no need to explain what is going on here, right? This beautiful Ruby code gets compiled to this pretty ugly JavaScript code. Don't try to read it, it's not worth your while. The important part of this code is here. Let me zoom this for you. If you make the effort to read it, you'll see that although it's a bit ugly, it is actually pretty readable. Unfortunately, I have a ton of ground to cover so I'll be skimming over the implementation details. Just trust me that this code is comprehensible, although initially it doesn't look like this. So the magic in Opal happens in the Opal compile method. You feed it a Ruby string and it produces an ugly JavaScript string but we can pretty this up. So it looks like a real program right now and the essence of this program is just a small portion of it which is really, really easy to understand. It is easy to understand because Ruby and JavaScript are not a million miles apart and mapping the concepts of Ruby to concepts in JavaScript is not the hardest endeavor in the world. Usually Opal maps self to this. It maps Ruby methods and Ruby blocks to JavaScript functions. It maps Ruby strings to JavaScript strings, et cetera, et cetera. And if this isn't enough for you, you can always drop down to the bare metal and invoke native JavaScript code if you feel the need to do so. Perhaps you want to interact with a third-party library which doesn't have a native Opal wrapper right now. This is super easy to do. Opal have basically acquired the syntax used in Ruby to share out to external programs for JavaScript interop. In hindsight, this was a rather bad solution because originally Opal was envisioned as something that would be used only in the browser. Now you can use Opal with Node.js, IO.js, et cetera, et cetera. So this will probably be changed in the future but for now it is a reasonable compromise and this is how you can use this in practice. This is an actual snippet from the core library of Opal, the implementation of array length. Simply delegate to the length implementation of the backing JavaScript array. Pretty simple and even more importantly, pretty fast. You can do more complex interop, of course. You can have multi-lines of JavaScript code. You can interpolate Ruby code into the string which will be evaluated on the JavaScript side and this will work as expected. If you want to play more with a particular JavaScript object, it is a good idea to wrap it in a native Opal object which allows you to retrieve its properties like the elements of a Ruby hash or you can invoke methods in a pretty simple, pretty straightforward manner on this object. And in Opal 0.9, we have a very exciting development coming along, a brand new JavaScript interop which makes it even more simpler to invoke JavaScript methods on Ruby objects it makes it pretty simple to use splitting in method invocations. You can use some rather advanced things like passing a block in place of a JavaScript function argument. You can quickly interact with properties and indices. You can quickly invoke JavaScript operators and even global functions are wrapped in a pretty uniform and pretty idiomatic Ruby API, I'd say. And to top this off, you can actually call Ruby code generated by Opal from JavaScript. So if we have this very simple bar method in the full class, calling it from a JavaScript program is as simple as this. You instantiate an object and you call the bar method on it. Every Ruby method is, every Ruby methods name is prefixed with a door sign in the generated JavaScript code. So the question that is really important is not how Opal works because it really works more or less like Ruby. The question is whether it is any good and this boils down to a simpler question. Is a program written in Opal simpler than the equivalent program written in JavaScript? Assuming that the complexity of a typical JavaScript program looks something like this, what would be the complexity of the Opal program? Most people believe it would be this. The performance would be problematic. The file size of Opal would be problematic. Debugging will be crazy complex. The Ruby compatibility would be so-so and you know you have to deal with the issues of the host language itself. And if you compare those, it seems that you're not actually gaining anything. And if the real comparison is something like this, probably you should be sticking with JavaScript right. But let me alleviate some of your concerns. First of all, Opal is fast. I do not have time for fancy benchmarks, but trust me, it is blazingly fast. There are some issues with performance. For instance, we cannot map to native JavaScript operators. So there is some performance issues there. There is no native JavaScript hash type. So there are some performance issues there as well. But overall, the performance differences are negligible. The file size, not a concern. So Opal minified and g-cipped is just under 50 kilobytes. And for these 50 kilobytes, you get the power of the core library, a portion of the standard library. This is a pretty sweet deal if you ask me. Debugging, well, at the very worst case, you have to deal with JavaScript. You saw that the generated JavaScript code is not the ugliest JavaScript code in the world. Trust me, I've seen worse written by humans. So if you're familiar with JavaScript, most of the time you'll be able to do the mental mapping of JavaScript to Ruby script in your heads. If you're not familiar with JavaScript, we've got your back, we've got source maps. And when you're using the source maps, you'll be getting Ruby stack traces in your browsers. You'll be able to click on the lines of those stack traces and you'll get into the Ruby code straight into your browser. It doesn't get much better than this, right? So, sure, there is some overhead to debugging, but it is not what most people would expect it to be. And as far as Ruby compatibility goes, there has been a ton of efforts to ensure the best possible compatibility. Right now, Opal is more or less Ruby 2.0 compatible. It is tested against the very same Ruby spec that MRI and JRuby are tested against, although let's be honest, a lot more tests are failing for Opal than for MRI and JRuby, but we'll get there eventually. We implement most of the core library, which is pretty neat. We haven't implemented much of the standard library, but there is plenty of room for contributions from you, right? And there are some notable differences that everybody should be aware of. So, true and false are mapped to JavaScript's Boolean type. In Ruby, there is no Boolean type. All numbers in Opal get mapped to JavaScript floats. Strings are immutable, symbols are strings, et cetera, et cetera. Most of those are pretty small and there aren't a huge issue in practice. When porting code from Ruby to Opal, generally people have to just remove the usages of mutating string operations. And to some extent, you can argue then that immutable strings are actually an improvement. All of those compromises were done in the name of performance. Everything could have been wrapped in a more Ruby-friendly way, but this would have come at a terrible performance cost. So, for performances sake, there are some compatibility hurdles. But in the end of the day, allow me to speculate that Opal's actual complexity looks something like this. And if you put it into perspective, it seems that there is some benefit to using Opal over JavaScript. I know that my friend, Yuan, is very impressed. His suitcase is impressed, and I hope that at least some of you would be interested enough to explore Opal further. So, let me give you a few pointers for your journey towards Opal mastery. If you want to get a sense of the power that Opal gives you in the browser, you can check out the Opal IRB project. It is something like IRB, which runs in a browser, a web console in a way, pretty sweet. If you're a Rails lover and not a big CoffeeScript lover, just drop this gem into your Rails application and you can replace every single usage of CoffeeScript with Opal, and it is going to work. Trust me about this. It's pretty sweet. It hooks into the asset pipeline and does magic. We've got a pretty cool gem called Opal browser, which wraps the entire browser set of APIs into a beautiful idiomatic Ruby API and allows you to write code like this, which is allegedly better than the equivalent JavaScript code. And if you still want to use jQuery, although you really don't have to do this, we've got your back as well. There is an Opal jQuery gem. This is how using jQuery from Opal looks like. Pretty sweet, right? And we have wrappers for React, for React Native, and for a ton of other popular JavaScript libraries. And because our beloved community leader, DHH, feels that no Ruby implementation is worth his time until it has some active support implementation, we have this as well. So let me close by sharing a few thoughts about the future of the project. Where are we heading, or at least, where should we be heading? So first of all, we should implement all the missing things. I'd really love us to get a bigger feature parity with MRI and the other popular Ruby implementations. And this is going to happen, but we need your help. We need much better documentation. Getting started with Opal is kind of hard, mostly because the documentation is pretty scarce. So this is one really good way to get involved into the project. There are rumors that a book on Opal is in the works. I really hope that the rumors are true because this will be so, so sweet. But one can only hope. We need, obviously, more Opal wrappers of popular JavaScript libraries because it is easier to use an idiomatic Ruby API than to drop down to the native JavaScript code. And there is this brand new WebAssembly project which was announced really recently. Assembly language for JavaScript virtual machines. And if we were to eventually target it, Opal and JavaScript will be on the very same footing as far as the JavaScript virtual machine is concerned. I don't know if you can comprehend it, but this is groundbreaking. This means that JavaScript will no longer be the dominating language in the Web. So I hope that this is going to happen, but it is at least five years away into the future. And in the meantime, just contribute to Opal in any way that you'd like. There is really a ton of work, a ton of simple beginner-friendly tasks and a ton of pretty challenging tasks. So there is something for everyone. You can go visit the official GitHub organization, pick an issue and start hacking. The project is pretty inviting. And I think that many of the issues that have to be resolved are pretty interesting. And I'm going to conclude with a basic slide of just a few resources to get you started. It was an honor for me to be here. Thanks for your attention. Thanks for having me. Okay, we have time for two or three questions. Who's got one? Raise it high. Hi, great presentation. Is there a way to use gems with Opal? Can you repeat this louder? Use gems with Opal. Ruby gems. Yes, you can use Ruby gems with Opal, but the problem is that the Ruby gems have code which is compliant with Opal. And most of the gems don't do it, so the canonical way to do this right now is to have conditional code in the gem. If you're on Opal, don't do something which will break on Opal. So this is totally viable, and simple gems will run out of the box. They will just be compiled to JavaScript code that works as far as you are not doing something which is not supported on Opal. So this is also pretty sweet. Thanks a lot, that was great. Which JavaScript standard is Opal targeting right now and how are the plans and keeping up with upcoming standards? So it is targeting JavaScript free, I think. So the generated code is compatible with browsers as old as Internet Explorer 6, which is a fit zone. And I'm guessing that we won't have to support this for the foreseeable future, but this is the current state of affairs. The JavaScript code compiled, generated by Opal, will run on pretty old browsers. Hi, thanks for your talk. I actually heard about an incident this year at Opal.ab at the GitHub repository. So do you have a code of conduct right now or do you develop one? Yes, the project has a code of conduct. The incident was unfortunate, but it is behind us. And I do believe that both parties involved share some of the blame for how this was handled. Trust me, the project is welcoming. This was a really unfortunate incident. Great. Thanks again, Boždar.