The Changelog: Software Development, Open Source - Spine and Client-Side MVC (Interview)

Episode Date: December 20, 2011

Wynn caught up with Alex MacCaw to talk about Spine, CoffeeScript, writing books, and working at Twitter.

Welcome to the Changelog episode 0.7.1. I'm Adam Stachowiak. And I'm Winn Netherland. This is the Changelog. We cover what's fresh and new in open source. If you found us on iTunes, we're also on the web at thechangelog.com. We're also up on GitHub. Head to github.com slash explore your fun. Some trending reposts, some feature reposts from our blog, as well as the audio podcast. And if you're on Twitter, follow Change Log Show. And me, Adam Stack.

And I'm Penguin, P-E-N-G-W-I-N-N. Fun episode this week. Talked to Alex McCall from Twitter. He's known for Spine, which is an alternative to Backbone. So these single-page JavaScript apps are really catching on. Yeah. This is a fun little conversation you guys had here. It wasn't too long, though, was it? No, it's a couple

weeks back. The original version of Spine was in JavaScript. He's rewritten it in CoffeeScript, so if you sling the coffee, you'll be interested in checking out Spine. And also a little controversy if Nathan Smith is listening to this you'll be interested in checking out Spine. And also a little controversy if Nathan Smith is listening to this. That's true. Friend of the show. A lot of things going over at GitHub

these days. We need to get these guys back on the show to talk about some of their recent hires and acquisitions. I mean, it would be nice to talk about was it Hubot as well? That's a lot of fun. Yeah, Hubot. I guess that's how you pronounce it. It reads Hubot. It's the GitHub robot for Campfire.

They have adapters for, we use it for HipChat, but they have it for various numbers of real-time chat tools, I guess IRC probably as well. Got to get them back on the show. Yeah, especially, you know, they're reaching out into the.NET world. Azure is now on GitHub, so hopefully we can talk about some.NET and open source. And some Nougat. Some Nougat.

Yeah, we did talk about Nougat a while back, so we do need to talk about that. Yeah. Fun episode this week. Should we get to it? Let's do it. Chatting today with Alex McCall from Twitter. He's the author of the Spine.js project and some other things. So, Alex, why don't you introduce yourself a little bit more about what you do at Twitter. Well, I work on the front end at Twitter.

And I do all sorts of JavaScript and Ruby stuff with the ad platform. In my spare time, I do Spine and also travel and write. I've written a few books for O'Reilly and in fact, a new one is coming out in December. I've just moved from England to San Francisco and I've actually just started at Twitter and I've been here for two weeks. Well, welcome. Congratulations on the move. So I guess the obvious question up front when we're talking about spine is what relation, if any, does it have to backbone?

Well, spine was inspired by backbone. And, yeah, without backbone, there would be no spine. And obviously you can tell by the name that it's related. However, Spine does have a different take on JavaScript web applications and moving state to the client side. It's got a completely different model API. It's got this whole asynchronous UI approach. So there is a similarity there, but there's also quite big differences. What's propelling this movement to moving everything to the client in the last few

years, this trend that we've got with client-side JavaScript applications? What seems to be the technical advances under the hood that's just empowering this? Well, we've got amazing browsers now. We've got amazing VMs and V8, for example, Chrome. We've got a sort of browser wall, which is propelling software companies like Apple and Google to compete and improve their browsers. And it's all in the aim of a better user experience. These client-side web apps are just really fast. And I think that's, at the end of the game,

that's what it's about. It's about speed. Now, Spine's written in CoffeeScript, right? That's correct, yes. Was the first version, was it CoffeeScript from the get-go? No, it was JavaScript originally, and then I ported it to CoffeeScript. Because at the time, I just didn't know about CoffeeScript. What niceties have you found along the way?

Well, it's much smaller. Well, I mean, at least the CoffeeScript is smaller. The compiled source is about the same size. And CoffeeScript has a ton of really nice language features that stop you, A, making stupid mistakes. It sort of uses a small subset of JavaScript, so it uses the good parts. So you can avoid

having things like semicolons and global variables, it'll sort all that for you and I found that that's really useful when I've been programming and I wish I could use I better not say that, sorry

I wish I could never write JavaScript again and just use CoffeeScript because I love it so much. And I use it every day. Let's talk a bit about MVC and how it may be different than some of the MVC frameworks for web apps on the server. When we talk about MVC in a client-side JavaScript application, are the views really views, or are they, in the case of Backbone,

are they really more or less view controllers? What's a view in Spine? Well, I guess it's just a terminology thing. In Spine, I call a template a view, whether that be an echo template or a mustache template uh in backbone views have more like spines controllers um and it's just more of a terminology thing so we were doing a mind map between the two just to for those that may have backbone experience um so if a view in backbone is a template or a controller in Spine, what's the correlation between routers and routers?

Routers and routers? Well, Spine doesn't really have a separate class to do with routers. You do routing inside your controller. Okay. So much less, more like the Sinatra pattern then rather. That's correct. Yes. You mentioned eco. Is that your favorite templating? It is. Um, again, it's one of the reasons is because the syntax is coffee script. Um, and also, uh, if you have a look at the source of eco, uh, it's, it's really clean. It's really

nice. Um, and this is something that a lot of templating libraries have an issue with. If you look at what's going on behind the scenes, it's pretty nasty, and that's not the case with Eko. One of the advantages or the promises of Mustache is to use the same templating project, server-side and client-side. Is that kind of a false goal? I think it's a bit of a pipe dream. I mean, I guess I view it the same as using models on the client-side and the server-side. And it would be great if that was the case, but I haven't really seen

a practical application actually using that because at the end of the day, you're always going to have some differences. And I think what is a little shame about Mustache is that because they've gone down that route, it limits their syntax somewhat because they have to be compliant across all these different languages.

And if you're not using the template on both the server and client side, then there's no point having those syntax limitations. So on the Spine project page, you outline the integration with Rails and the asset pipeline. Talk a bit about how that sets up and what that looks like. Well, it's so simple with Rails. It integrates with Rails generators, Rails asset pipeline. We're just basically piping in Spined JavaScript.

And when you do Rails generate Spine new, it will create a new Spine application in the app assets JavaScript folder. And everything is set up there for you, and then you can generate new controllers and models. And the great thing is if you set up a Rails scaffold and you set up a Spine model on the front end, the two will talk to each other straight away. So Spine sort of works with Rails out of the box. And you've got the same generators for Spine objects as well,

controllers, views, scaffolds? Yeah, that's correct. Yeah, you can generators for Spine objects as well, controllers, views, scaffolds. Yeah, that's correct. You can also generate Spine scaffold, which will integrate with the Rails scaffold over AJAX. You also mentioned HEM. Is that your preferred platform? Well, if you're not integrating with Rails, then that is my preferred platform.

HEM is not to be used in production. It's just in development, and then is not to be used in production. It's just in development. And then you can serve static files in production. But basically what it is, is like bundler for node applications. And it will pull out, you can have MPN dependencies and you can have local dependencies

and it will pull all those out together and compile them into one JavaScript file. And it also manages your CSS. And so that is my preferred method. If you're not going with Rails and you just want to build a Node app, or you're building a mobile app, then just use Hem.

Are you doing a lot of Node development? I do. In fact, there's a developer here called Michael Jackson, and we're working on a new web framework called Strata, which is going to replace Express in some of our projects. And we're also working with a lot of Node and fibers and trying to reduce the asynchronous pattern style in Node. You know, you get into callback hell.

And so Michael and I have been working a lot with Node to try and solve that problem. So what powers the real-time aspect of Spine? Well, Spine isn't inherently real-time. In fact, yeah, you just need to add real-time support to it. It's the same with Backbone. If you have views that are bound to your models, then adding real-time support is pretty simple.

All you have to do is update the models, and then your interface automatically updates. So there's no inherent, I guess, pusher or socket IO support. It's just... That's correct. And, I mean, in a lot of Spine examples, I've used a RPC framework, or you could call it PubSub framework called Jugnaut, which I produced a few years earlier.

And basically your Ruby models, you just have an observer and that will basically send messages to Jugnaut saying this this model's changed these are new attributes juggernaut will send it out to all the clients or the clients have to do is update their models and then their views automatically update so adding real-time support is is literally like five minutes what type of applications are you building with spine well um the main reason i developed spine was for this uh guide app i'm trying to digitize the lonely planets and put them on the iPhone and on the iPad and the desktop. And so this app basically lets you select

countries, places, locations and look at reviews and photos. And it's quite simple, but it's a good stepping stone for other Spine applications. You mentioned local storage here on the Spine project page. What other storage mechanisms does Spine support?

So Spine out-of-the-box supports local storage and AJAX. And with local storage, it's just a case of including that in your models, sorry, including a line of code which imports the local storage module. And that'll persist it when the page closes. That'll persist all the model data. And when you reopen the page, it'll all be there and populated. And AJAX is similar. You import the AJAX module and give it an endpoint.

And Spine will basically just use standard REST calls like POST, PUT, GET get on that HX endpoint to persist your data. Talk a bit about Spine.app. So Spine.app integrates with Hem, and it's basically just a Spine application generator. And you just do Spine.app, app, and it'll generate your app. It'll generate all the directory structure, your MVC, your controllers, your views and your models and it will generate public directory and it will deal with all your CSS. And Spine.app is actually very useful when it comes to building mobile apps because Spine has this Spine mobile project,

it's a sort of extension to Spine and Spine.app basically will generate the mobile project directory for you, which you can then sort of wrap up with PhoneGap. So PhoneGap, is that your preferred method for wrapping these for the App Store? Or the Android Marketplace? Yeah, that is my preferred method, mostly because I just haven't looked at other alternatives. But it works very well for me.

I'm a titanium guy myself, but there's no reason why you couldn't take an HTML5 application like this and wrap it in titanium as well. You know, I'm wondering, once we have a truly position-fix mechanism to have a toolbar at the bottom of the page and ios 5 supports this how much more use we'll have for native platforms if we want to just circumvent the app stores and android marketplaces and just publish our apps well well that's right i mean ios 5 fixed the biggest issue which was um with the scrolling so you know you can have fixed headers and footers and the only other reason uh that i using PhoneGap and integrating it into the marketplace is because I want to access some of the payment APIs, and that's the only way to do it. But if I was just building a mobile web app without needing to access any of the native

APIs, then definitely that's what I would do. I would just use pure HTML and host it myself. What range of devices are you aiming to support? At the moment, it's iPhone. Android's WebKit browser is not up to scratch. The transitions look jumpy, and it just doesn't feel great, to be honest. And I think in a few months' time, maybe half a year's time, Android support will be amazing.

And then you can write once and deploy everywhere. That's the idea. What type of user interface are you employing in your applications? I notice when a lot of HTML5 apps try to mimic native applications, they fall quite short. And so should we just be building something entirely different? Well, I think that's a bit of an excuse to build something a bit crapper. I think it's fine if you're building something completely different, as long as it's as good or better than the native experience. But I find that's often used as an excuse.

And certainly, I've built web apps, mobile web apps, that are very difficult to tell they're not native. You can emulate pretty much everything. You can emulate the transitions. You can emulate all the CSS styles for the header and footer. And it looks practically identical. So you're still doing the drill-down stack controllers type of user interface, the UI table controller type on the iOS platform, that sort of paradigm? Well, what you mean, having tabs and views that sort of flip in and out?

I know that like the drill-down where you have a table of options and you click one and it slides. Yes, that's correct. Yeah, I'm using that. And that works great for mobile interfaces. So you're writing a CoffeeScript book. Yes, it's called The Little Book on CoffeeScript. And it was actually open sourced a while back. But O'Reilly have recently approached me to publish it.

And it's going to be free online through O'Reilly's site. And you'll be able to pay for a printed version if you want one. So what did you learn writing this book? Well, I mean, one of the best ways of learning is teaching, right? And so I learned a hell of a lot about CoffeeScript just by writing the book. Also, I learned a lot about CoffeeScript style. I was lucky enough to get Jeremy, the creator of CoffeeScript, to go through the book. In fact, he's writing one of the chapters. So he taught me a lot about CoffeeScript style and what I should

and shouldn't do, and it makes a lot of sense. Maybe give us a couple of pointers on that. What makes good CoffeeScript style and what I should and shouldn't do, and it makes a lot of sense. Maybe give us a couple of pointers on that. What makes good CoffeeScript style? For example, using and instead of double ampersand. It just reads much better. What about parentheses? Yeah, you don't – Drop when optional?

Yeah, I would drop parentheses unless you need to make it obvious, unless it's not obvious of what's going on. And sometimes if you've got like three or four nestled function calls, then you definitely want to use parentheses. We've also got another book for O'Reilly, JavaScript Web Apps. Yeah. Talk a bit about that one? Well, I wrote this as I was traveling. And it's a book about building JavaScript web applications and moving state to the client side. And the main part of the book is MVC. And we take you through building a model view controller interfaces. It's not language or library specific. All the examples at the end, you have spine

examples at the end and backbone examples and JavaScript MVC, but throughout the book, it's generic. What are some of the gotchas of building single page web apps that maintain state on the client? Well, it's a lot of work and it's also a big paradigm shift. It's quite hard for a lot of developers to get their head around. You have to move all the rendering to the client and it's very difficult to convert an existing app into using this sort of architecture. Usually you have to start from scratch. So it's a lot of work, but I think the advantages are worth it. The really quick UI that you get from advantages are worth it um the the really quick ui that you get

from it is worth it so what does an architecture for these types of applications look like uh you normally just uh build out an api first and then build a user interface on top of that or do you still step out the design first what i do is i start straight out with the design, do the CSS and HTML, and then I do the models client-side and I basically stub out the data for them. And I get everything working client-side because at the end of the day, that's what matters. And then once all that's done, then I do look at the server-side and I have a much better idea of what models and API I need on the server-side once the client-side is finished. What tools do you have to debug these applications on mobile? a better idea of what models and API I need on the server side once the client side is finished. What tools do you have to debug these applications on mobile? I usually just use Safari and Chrome to develop them, and sometimes the iOS simulator.

And that's enough for me. I just use the Web Inspector. Are you building applications that install to the home screen? And do you do anything special with the meta tags that you can do to make a full screen application on iOS? Yeah, absolutely. For example, Spy Mobile comes with a default set of meta tags that prevent you sort of zooming in and set the page title, the page icon, and that sort of thing. And definitely I'm using those in all sorts of applications. You mentioned async earlier. What problems does async, I guess, present when you're building an async UI? Well, again, it's a little bit more complicated.

So the idea is that you never block the user. So they interact with your application, and you never block their interaction. So they interact with your application and you never block their interaction. So let's say they are sending an email. In Gmail, when you click send an email, it waits like two or three seconds saying sending your email. And I'm saying that you either lie to the user or in the case of email, you just put it in the outbox like you would in an IMAP client, and you don't block the UI, because I think that's a really bad user experience. So when you're building out your views in Spine, are you taking advantage of JST just in Rails or around?

Yes, just in Rails. I mean, when it comes to HAM, you can just use common JS modules rather than use sprockets. So do you find yourself always passing data across the wire and buying to that, or do you ever pass markup across the wire? Always data, just JSON data. If you start passing markup across the wire, then you haven't got an asynchronous interface because you rely on the server to render the page.

So if somebody updates, let's say adds a new comment to a blog post, the server has got to respond with that markup. Whereas if you're rendering everything client side, you could display instantly. So you guys still hiring at Twitter? Yes, we are. We're hiring every day. We've got new people interviewing. And if you're interested in working here, then you should definitely get in touch. It's a great team, and it's a really interesting company because there's some really big problems to work on. One last question. So what open source project out there just has you excited that you want to play with?

That's a good question. I think it would be Strata, but we already talked about that. I'll throw another curveball at you. Who's your programming hero? Jeremy Ashinkanis would definitely be him. Yeah, that guy has created Backbone and CoffeeScript. I think that's incredible. He is a programming stud, that's for sure. Well, thanks, Alex, for joining us, and good luck at Twitter.

We look forward to seeing the CoffeeScript book out this, I guess, later this, before the end of the year or early next year? In December. In December. We'll keep an eye out for that. Thanks, Alex. Thank you very much.