The Changelog: Software Development, Open Source - The Ruby Racer (Interview)

Episode Date: May 11, 2010

Wynn and Gregg Pollack did a special LIVE episode at Red Dirt Ruby Conf where they sat down with Charles Lowell to talk about embedding JavaScript engines in Ruby.

Welcome to The Change Log, episode 0.2.3. I'm Adam Stachowiak. And I'm Winn Netherland. This is The Change Log. We cover what's fresh and new in the world of open source. If you found us on iTunes, we're also on the web at thechangelog.com. And we're also up on GitHub. If you go there, you'll see some trending repos, some feature repos from the blog, as well as the audio podcasts. We're also on Twitter, so follow us with changelogshow, not the changelog. And I am Adam Stack. And I am Penguin, P-E-N-G-W-I-N-N.

I'm fresh back from Oklahoma City, Red Dirt RubyConf. Yeah, it's a lot of fun up there, I bet, huh? Yeah, it was. A lot of smart folks. Got to see a keynote from Jim Wyrick and Dave Thomas. Oh, yeah. A couple of guys that have forgotten more Ruby than I'll ever learn. A lot of JavaScript going on, too. Interviewed Charles Lowell, a.k.a. CowboyD on Twitter and GitHub about RubyRacer.

He's got some exciting projects here. Yeah, some embedded JavaScript within Ruby. One embeds the I guess RubyRacer embeds the Google V8 engine, and Ruby Rhino embeds Mozilla's Rhino JavaScript engine. I have to apologize up front

for the audio of this interview. We did it live. We'll do it live. Okay, go O'Reilly. We did it live there at the conference, and live events are always fun. Yeah, there's always some sort of glitch you've got to deal with, and quality of the audio is always one that goes first. So please excuse that, but otherwise it's a fun episode,

commute-friendly format this week. A couple of programming notes. We'll be at Texas JavaScript on the 5th of next month, 5th of June in Austin, Texas. Great lineup there. Yeah. Also be at Less Conflate on this month as well. Next week, as a matter of fact, out in Atlanta, Georgia. Is that next week?

I thought it was 3010 that you were going out there. Yeah, yeah, yeah. Well, yeah, it's 100 years from now, right? Well, millennium. Millennium for now. Either way. Either way. It's in the future. But lots and lots of fun. But, yeah. Well, yes, 100 years from now, right? Well, millennium. Millennium for now. Either way, either way. It's in the future. But lots and lots of fun. But yeah. You have a DeLorean you're going to get out there?

I think so. Yeah, I'm going to get to 85 and zing my butt over to Atlanta. Let me know how the future turns out, buddy. Will do. Cool. Let's get to this episode. Episode 0.2.3 of The Change Log. I'm your host, Wayne Nuttall. We're joined today by Charles Law and Greg Pollack from Ruby 5. Greg, why don't you, I mean, excuse me, Charles, introduce yourself, tell the folks who you are and why they should care. My name is Charles Gold.

I work with Frontside Software, and we build user interfaces for a variety of platforms. That's what we do a lot at Ruby. Lots at Ruby. Tell us about the Ruby Racer. The Ruby Racer is the V8 JavaScript that we're embedded in Ruby. Tell us about the Ruby Racer. The Ruby Racer is the JavaScript that's embedded in Ruby. So what it means, the fact is that you can evaluate JavaScript from its inside Ruby and you can call Ruby functions from inside JavaScript. Okay, this is Greg, by the way. Yeah, I know I did a presentation earlier today, but as

a Ruby developer, I can look at this and I totally see the value in being able to write Ruby to test my JavaScript. Sorry if it sounds ignorant, but what I'd really like to learn more about are some use cases where I really might want to write Ruby that writes JavaScript, JavaScript that writes Ruby. What are some use cases? Where might this be really useful that it's not totally obvious? So you can do things. One of the examples I gave was if you have templates, for

example, you want to evaluate on the server and on the client, if that template again was just written in JavaScript, then you can evaluate them in both places. And so you're not going to do it in yourself either with the templates or with the actual code that evaluates the templates. If that makes sense. So these templates you're talking about, something like Mustache.js? Yes. For the folks that may not be aware, who's used Mustache.js?

A few hands. Why don't you give the folks some background on what this is. Has anyone used MustacheRV? Have you used them in client? Have you used this technique where you use them in concert? Where you use the same templates on the client server? Okay, so Mustache is a templating engine that has both an implementation in JavaScript and an implementation in Ruby. But it has the same syntax. If you use one implementation with the same syntax, that would guarantee you get the exact same result.

Why is an interpreter like this, I guess, required for that sort of thing? Well, because if you're like I said, if you're using the exact same implementation, like suppose you want to

suppose you want to extend your syntax, right? You're gonna have to do that. If you're using two different languages, two different implementations, you're going to have to change both of those notations. So any change that you're making is gonna be recognized twice. You have a burning environment

that's gonna be recognized and tripled. So if you can bring the exact same implementation to all your different run times, then you're cutting that out of the equation. So in the case of template rendering, the one way maybe you can look at this is like you would normally have to do all the template rendering on the server side,

but maybe you could save some CPU cycles by pushing that off to your clients, letting the clients do the work and using the same format, the same language. Absolutely, and you're just sending data to the client. You're not actually, you know, you're not sending display data, you're sending the data that's rendered on the client. So earlier today you said that sending HTML over the wire was an abomination. I believe a certain Rubyist out there took issue with this. He'll remain nameless for this two-year-old's GLV. Why don't you explain to Glenn what you did by that?

To clarify, HTML itself is not an abomination, but using it as a data structure is an abomination. His question was, isn't this what the browser does? Well, for the browser, one person's code is another person's data, and so forth. I mean, the browser does use its data to render, but from our perspective, it's a view. And using a view to house data, to me, is a smell.

So for those that didn't catch the talk, you're proposing an alternative that sends what? Just JSON, pure JSON. Or something else, if that strikes your fancy. Can I ask a question? Sure, a question from the audience. Can you measure the 33 times faster than a shove a chunk of HTML that doesn't

bother you. Well, you work for Google. I mean, come on. You've seen the banana and the potato chips and everything like that. It shouldn't matter. In the age of Chrome. So the question was the performance impact of each approach, right?

Right. It might be slightly less performant, although, honestly, I have not noticed that rendering it on the client is less performant. I mean, not so much that it would actually even cause me to investigate, I suppose. So ironically, the question was from a Googler. And in Ruby Racer, you're actually embedding Google's V8 engine. Yes. So this is one of those few gems out there that actually requires Python. Yes, it requires Python to build.

So you don't actually ever see it, but when you're installing, in its current form, it does take a while. And then it says compiling native extensions. it does take a while. And then it says compiling native extensions. This might take a while. It's actually using Python and SCONs, which is what V8 uses for its build system to build the V8 binary. So, yeah, I think you need Python 2.4 or greater to install this gem. Talk a minute about consuming this particular project.

So you can evaluate JavaScript context by passing a Ruby object, or you can have a Ruby object be the context. Yes. So you can actually, if you have any arbitrary Ruby instance, you can set up your JavaScript context so that that Ruby instance is the global object. So any properties that that Ruby object has are global properties. Any methods that it has are global functions.

And so, for example, if you could actually have a browser object that had a window property and a document property and an embedded DOM and so forth, and that would be how you would implement a browser in Ruby, or at least the skeleton of one. So if you have a Ruby object as a global JavaScript value, does Douglas Crockford still cry?

You'd have to ask Douglas about that. Back to templating for a second. Mustache.js, you mentioned any other templating engines out there that are your favorites? JSON template is one that I like very much. It's a

very functional style templating system. That also is, I believe, from Google. Any love for underscore JS? Nope. I have never used it. Blasphemy. Smacking on the hands of the ruler.

Check out episode five with Jeremy Ashkenaz. I thought I pronounced his name correctly. One of the things you mentioned on your readme here is that RubyRacer is designed to let you evaluate JavaScript as safely as possible unless you tell it to do something more dangerous. Can you talk a little bit about what you might use this for? By default, when you instantiate a JavaScript context in the RubyRacer, you don't have anything except for the standard JavaScript objects.

So even though it's possible to call Ruby code, you can't. You have to explicitly inject into that context the code which you can call. And that's important because one of the primary uses of JavaScript is to safely evaluate untrusted code, just like you do on the browser. And so it's important that by default it be safe. So once you start exposing bits of your application via JavaScript, in other words, making Ruby classes and Ruby functions available, then you do so at your own peril,

and you need to make sure that those functions are safe. So that's what I'm getting at. By default, it is safe. So you can almost use it to expose some sort of API that allows people to write JavaScript, which gets evaluated server-side? Yes. It gets evaluated as Ruby.

So even though it looks like you're calling JavaScript, you're actually calling Ruby. Interesting. So this might be used for some sort of API where people have to write some sort of JavaScript code. JavaScript is kind of universal. People have to write some sort of JavaScript code. JavaScript code is kind of universal. If people had to write really complex code, which then gets evaluated on your proprietary

locked-behind-closed-door server that they couldn't be running on their own, this would be a way to allow them to write some pretty sophisticated API logic. Precisely. It allows you to provide an API that allows users of that API to extend it and use it in ways that you had not foreseen,

in the same way that the browser allows servers to program it to make it do new and interesting things, things that have taken us really advanced to state-of-the-art in the last five years or so. And so to give a concrete example, and another one that I showed here that we've used it for is to actually, for an image server. So being able to pull down images and then have a set of JavaScript functions that actually are bound to Ruby functions that modify the image before it's returned

so you can enhance the image in pretty much arbitrary ways. There are any arbitrary combinations of primitives that you provide on that server. That's cool. One other web service that reminds me of, there was a voice over IP web service that we were working with at Envy Labs for a while

where basically you had to write code and then either you could upload to the server or you specified you know go to this url download this code and we'll execute it using our voice over ip servers and whatever you know it whatever happens happens after that point and they were trying to they actually had like a ruby implementation this is i think the trovo api which we'll talk about what we're talking about in ruby 5 this week um And so they tried to implement it in different languages. You could write in Ruby, you could write in Python, you could write in JavaScript.

And they did a couple other languages maybe. But it kind of makes sense that JavaScript seems to be sort of that standard library that if you're going to support a language that gets interpreted by your application server side, it seems to be the standard. And I totally see the value in being able to specify, you know, have a sort of sandbox, so to speak.

It sandboxes your Ruby code so that, you know, you can let people run JavaScript against it without having to worry about them doing anything dangerous. Yeah, it's a super lightweight virtual machine in a box, basically, that you can take with you wherever you go. And it's light by purpose. I mean, there's only nine standard objects in the JavaScript library, or standard constructors.

You can fit all of them on your two hands, and that's a feature. So JavaScript everywhere. Someone made the comment in one of the talks today that C was the lingua franca of computing, especially in the Unix world. And I think perhaps JavaScript may be unseating

it at some point. It's not as entrenched on the server, but with the rise of Node.js and some of these server-side frameworks, it seems like everybody is using JavaScript these days in places that we normally didn't use it before. How many folks are using JavaScript in their applications? How many folks are using it server-side?

Oh, wow, more hands than you think. Talk a minute about what makes JavaScript special and why JavaScript, this renaissance of JavaScript in the last couple of years. I mean, I honestly don't know if I'm qualified to talk to the renaissance of JavaScript on the server-side, because from I mean, I honestly don't know if I'm qualified to talk to the renaissance of JavaScript on the server side, because from my perspective, I like to use it for its original purpose, which is a language for embedding and providing safe interfaces.

So, I mean, while I think that Node is interesting and the CommonJS movement is useful, and the project is useful. For me, that part of JavaScript is just not as interesting, frankly, just because it's yet another language and doesn't bring along all the things that I think really make, don't really highlight the things that I think make JavaScript really special. And that is the fact that you can completely control the environment.

You can control its heap size. You can control how the instructions get executed, and you can embed other interfaces into it safely. It's not just on the server. It's on the client as well. Just in my brief career, I guess I've been doing web development for about 12 years now, and it seems like that early on, I guess we were shackled to the DOM, right? And so JavaScript was something that we handled with kind of like hazmat gloves,

and we had all these server-side routines that created the JavaScript for us. Whereas in the last few years, basically since Prototype and since jQuery came along, there's been this sort of rebirth of JavaScript development. I think we're finding a lot of the things that we like about Ruby are things we like about JavaScript as well. Absolutely. Talk a minute about Ruby Rhino and how it relates to RubyRacer. So the Ruby Rhino is the JRuby counterpart to the RubyRacer. And as the name might imply, rather than being based on the V8 JavaScript interpreter,

it's based on the Mozilla Rhino JavaScript interpreter. I've taken some care to make them API compatible so that you can, but I'm going to say there is some discrepancy in the API, but the idea is that you can use the exact same code in a JRuby application with a little bit of glue to bootstrap and say, okay, I'm using the Rhino, not the Racer, but starting from there being able to run the exact same code. I forget for a moment that we have a Googler in the room. What's the main differences between the two?

V8 and Rhino. Okay. Well, the main difference from my perspective, obviously one being written in C and the other in Java, is that probably the most important is that the V8 is not multi-threaded. So if you're going to be using it in a multi-threaded app, you're going to have to lock the interpreter, basically a global interpreter lock.

V8 has the same thing as Ruby and Python and all that good stuff. Whereas Rhino is multi-threaded. You can enter context from all different threads. The threading is really great on the Java platform. So that's probably the biggest difference for me. And then obviously with the Ruby Rhino, you get Java integration inside your

JavaScript as well as from Ruby because you're using JRuby. This is an abbreviated version of the show since we have the second podcast to record. This is usually where we ask, and I'll put you on the spot since I don't think we've got a single episode of the changelog, but this is normally when we ask the folks what's in your open source radar, what projects

other than the ones we just talked about, have you excited? Which ones have me excited? Gosh, well, I've been looking at env.js. I don't know if anybody's ever heard of that, but that's basically a complete DOM implementation in JavaScript that is somewhat cross-platform. So you can, with just a little bit of native code, whether that's root, and by native I mean native platform, it can be Ruby, Java, or C,

you can have a DOM implementation up and running. So I think that's really, really interesting. And that lets you do more simulated browser stuff. So if you want to do screen scraping and complex interaction with websites programmatically, that plays a big part along with unit testing, your JavaScript code. I'm also looking at JS DOM,

which is another Mason implementation that's not quite nearly as far along, but shows some promise in terms of being maybe a little bit more flexible. So let's see, what else? I say, just look what I'm following on GitHub. That's the best place to check it out. The GitHub page is github.com forward slash cowboyd.

So you also have your own podcast? Yes. You want to plug in? Oh, absolutely. I have the drunkenretired.com podcast, so you can go to drunkenretired.com. It's not drunk and tired. I actually tried that earlier. I didn't catch it. It's not drunk and tired.

That's a totally different side. That we try to do every week with my good friend Michael Cote from Red Monk. So you should check it out. Talking about? Yes. Well, talking pretty much about life, the universe, and everything. Our motto is it's better than half the stuff out there. That's our motto.

Cool. Thanks for joining us. Thank you for listening to this edition of The Change Log. Point your browser to tail.thechangelog.com to find out what's going on right now in open source also be sure to head to github.com forward slash explore to catch up on trending and feature repos as well as the latest episodes of the changelog safe in your arms As if no passion shown Was mine alone

Open Open All roads to try Bring it back, bring it back to Open Outro Music