« All Episodes

17: Volt and Isomorphism with Ryan Stout, part one

Published 2/11/2015

Today I'm joined by Ryan Stout, the developer behind the powerful new Ruby web framework Volt. Ryan and I discuss why he created Volt, the motivations for developers to move towards "isomorphic development", and how Volt addresses some of those motivations.

Ryan Stout on Twitter: @ryanstout (note: not to be confused with @stoutryan, the comedian.)

Check out Volt: VoltFramework.com

Support Developer Tea: http://www.developertea.com/buy-me-tea

Transcript (Generated by OpenAI Whisper)

Hey everyone and welcome to Developer Tea. My name is Jonathan Cottrell. I'm your host and today I have the privilege of interviewing Ryan Stout. Ryan is the creator of Vault, which is a web framework for Ruby that allows you to write just one place, allows you to write Ruby, and that Ruby actually works both on the front end and the back end. And it's a powerful framework. We talk a little bit more about that in depth during the interview. The interview is two parts, so you'll want to make sure that you catch the second part later on this week. I talked to Ryan for quite a while after the interview, and I think that Vault has a fantastic future. I believe it's something that all developers, all web developers at least, should be keeping their eye on. I hope you enjoy the first part of the interview with Ryan Stout. Ryan, welcome to the interview. to the show. Hey, thanks for having me. Absolutely. So today we're going to be talking with you about really about the term that you kind of coined, the isomorphic development. I really appreciated that you took on the opportunity and made that term your own. Volt is a framework that embodies the spirit of that term, isomorphic development, of writing code once. So I'm excited to talk to you about that. We'll talk about the specifics of the framework, but the basic idea is that Volt allows you to have a front-end and a back-end system all developed in Ruby, right? That's right. And I actually, I should just say too that some other people had used the term isomorphic before I actually started using it. So I can't actually... Credit where credit's due. I can't actually take credit for that. But yeah, so the general idea is, you know, as web developers, we end up writing a lot of the same things on the back-end and the front-end. And so Volt is really sort of an attempt to share that code. And once you have the same code on the front-end and the back-end, it really kind of opens up a lot of other simplifications is how I would put it. And you can kind of put... Yeah. ...a lot of the same things on the back-end. Yeah. And so I think that's a really good way to kind of push a lot more code into the framework instead of needing to manually write all these things. Sure. Yeah. So, and the framework is ready for production today, right? Actually, I wouldn't say it's quite ready. Okay. There's quite a few things that we're still kind of working on. And we have a pretty big community that's building a lot of things on it. But I definitely would say if there's something you're going to go try and put in front of... Yeah. ...a really large group of people right away, it's probably not there yet. More so because of missing features, if anything. Okay. Yeah. But we're pretty quickly closing that gap, I think. So as time goes on, we've kind of got this big list of things and we're checking them off pretty quickly. So I think in a pretty short term, you're going to see larger and larger production apps on it. And we hope very soon. So... Yeah. I think... And so part of the reason I'm doing this is because I think it's really important to have a lot of people on the front-end. And I think that's a really good way to do that. And so part of what we're going to talk about here in a couple of minutes is like comparing... Not comparing, but really talking about this in view of something like Rails or Sinatra and where it sits and what it's good at versus what those things might would be... I won't say better, but more suited for. So I'm interested to see what your opinion is on that. But before we talk about that, I want to talk about this thing that you're doing on Fridays, like pretty regularly, right? Which is the office hours. Yeah. So I've started to see a lot of open source projects doing this. And I really like the idea. They're basically doing a Google Hangout and there's a regular scheduled time for it. So I know a lot of people, they want to have this more like face-to-face experience with the core team of developers on projects. And so it's nice because you can go on there and myself and a bunch of the other big contributors will discuss some things. As I mentioned, we're going to be doing a lot of stuff on the web. So if you're interested in that, have a lot of stuff on the web. So if you're interested in that, we're going to have a lot of stuff on the web. as far as the future of Volt and the direction and implementation specific things. And so it's nice because a lot of people just kind of sit and listen. And so they can kind of get a feel for what's going on. So we do that. And then the other thing that we've been using a lot is Gitter. I don't know if you've seen that. It's sort of similar to like a HipChat or something like that. And it's, but it's really geared around your GitHub projects. So... Oh, I have seen that. I was trying to remember because I knew I had heard that and I had seen it somewhere and I've actually gone and looked at it. I haven't actually participated on it, but I know, I know about it. Yeah. So we use that quite a bit. It's sort of a, it's sort of like a nicer interface around. It's sort of similar to what you'd use IRC for, but it, you know, it's web-based and then there's mobile apps and things like that. So it's nice. It kind of gives you that. Also gives you a little bit more asynchronous-ness than IRC does. Since messages are persisted and you can search them and things like that. So we've been, we've been using that a lot and we actually have a lot of people kind of at any given point, there's somebody in the room kind of talking about something. So... That's really cool. Yeah. So if I'm coming, well, let's start from the beginner perspective. If I'm coming into this world as a beginner web developer and Vault is like the first thing that I've experienced, I think it's a, it's kind of different than the average framework. I think it's a, it's a little bit different than the average framework. I think it's a little bit different than the average framework, of course. Right. So can you kind of give a beginner developer's perspective on like a 30 second history of why Vault exists and what it does different from, you know, an average framework? Yeah, I think one of the things, maybe to put things in perspective too, is I've always kind of been what I would consider a full, full stack developer. And by that, I mean, I would do front end and back end. And, and a lot of people come to me with kind of prototype ideas and are like, let's, let's do this and see, you know, if it goes. And so for me, kind of the top priorities are being able to build something quickly and then also not needing too many tools, I guess, if that makes sense. So, so yeah, yeah, there's, there's kind of an inherent cost right now, as far as if you're a front end and a back end developer, you've got to learn two totally different systems. And so I think that's a really good point. And I think that's you also have to learn kind of all the technologies to sync in between. And while that's not hard, I mean, it's something you can definitely do. There's kind of all this added complexity of, you know, you're thinking one way on the client and you're thinking another way on the server. And so what, what we try to do with Vault is basically make those two so that they behave very similarly. So we have where, you know, when you're writing models, for example, it doesn't really matter whether you're on the client or not. You're just going to have to have to have a lot of different things. And so when you're on the client or the server, they behave the same way. And then when they're on the client, they just kind of automatically sync back to your, to the server. And so things like that really let you kind of simplify things because you're not, you're, you're sort of just building one large app instead of you're building a front end app and a back end app, if that makes sense. Yeah, absolutely. And, and so I, I've familiarized myself with Vault. Recently, I actually like, you know, got things going on my machine and started playing around with controllers and all that. And so what was, it was really odd at first because I'm used to writing puts and seeing that output in my, in my console, right? I'm sorry, in my, in my terminal. And so I was like, I was looking at, looking for it in my terminal because I'd still was wrapping my brain around how the framework works. And then I looked over and I was like, maybe I'm looking in the, maybe something's not acting like I expected to. And I looked in the browser and I saw like Ruby looking out like object to string output in the console. I was like, that is that it was jarring for me, but I think it was a good jarring because I realized this is fundamentally a different way of doing things. And I can't think about it the same way that I think about, you know, Rails development or, or Sinatra or whatever. Because fundamentally I, I have to keep in mind, that this is going to the front end too, right? Like it's, it's not just one, it's not, it's not like separated necessarily, but it's the same concern. And it's actually interesting. You know, one of the questions we get a lot is what's running on which side. I'm actually working on a blog article now to kind of help explain that. But one of the ways I like to tell people is that pretty much everything you're writing, but tasks, for tasks, actually runs on the client side and then certain things. So for example, when you save a model, it's going to run the validations on the client side and on the server side. Um, so that, you know, someone can't tamper with it on the client side, you know? Um, but generally actually a lot of, a lot of Volt is sort of more resembles a front end framework. Um, and then you get the niceties of, like I said, you don't have to rewrite your validations and permission logic can be shared. Um, so that's, that's a good point. Um, and then you get the niceties of, like I said, and all that. So, um, and then kind of the other thing that we have, um, in the works is being able to render your views preemptively on the server. And then once that, once the page loads and downloads all the JavaScript, the compiled, the Ruby compiled to JavaScript, uh, once that's loaded, it'll, it'll kind of tie into the bindings and, and automatically pick up from there. So, so that'd be nice once we get that out because you'll get, uh, you know, where a search engine can crawl your page and, uh, it looks like a, you know, normal backend serve page, but then you get the dynamic updating on the front end. Right, right. Yeah. Which up until this point, just for anybody who's wondering, that's something that you have to do piece by piece in, in other framework lands. Thanks so much to Ryan for being on the show. Uh, make sure you catch the second part of that interview later on this week. Uh, we'll release it, uh, through iTunes. As usual and all of our normal channels. I hope you're enjoying the show. If you are enjoying it, drop into iTunes and leave us a review. It's the best way to help other developers, just like you find developer tea. Make sure you check out Volt. You can go to volt framework.com and take a look and play around with Volt. Uh, and then maybe you can build something as a challenge between now and the next time that you listen to, to Ryan. As always, you can connect with me on Twitter at at developer tea, or you can email me at developer tea at gmail.com. You can always check out the show at developer tea.com, where there's also a contact link in the nav at the top. And of course, until next time, enjoy your tea. Bye.