 I guess I'm going to go ahead and start, it's 3.30 so we'll kick this off. This talk is Model View Web Sockets. My name is Garen, I live here in Austin. I am the organizer of a few groups here, meetups, and I'm going to apologize to you guys because I'm not feeling really well. So this talk is going to go one of two ways, either it's going to be really hilarious or I'm going to fall asleep halfway through. But hopefully the former. So due to me not feeling well, if you feel like you want to shout out questions in case I do fall asleep before the end, feel free to. So let's just jump right into it. So JavaScript is, historically it's been a pretty simple place. We were doing okay for a while without patterns, without frameworks, without any of the things that we usually see in computer science. And then its potential sort of got the better of it. So we noticed that we could be doing more with it and we started doing it all at once, which was kind of great, but it was also kind of confusing. So now we don't have the simplicity that we used to have, which is not a terrible thing because now we can do more. And thankfully we have patterns that help us combat the complexity that we've introduced. So that's kind of where we're at. And we've been doing a lot of single page applications. There's a lot of this stuff around now and there are some problems with them. There's some questions about them. And hopefully we're going to talk about how to combine patterns and help solve some of those problems. So today we have single page applications just everywhere. And we also see a lot of single page application like behavior in otherwise static pages. So for instance, if you have a third party tool, more and more there's a possibility that that's going to need its own sort of dependencies. It's going to need its own framework and all that stuff. And the systems of dependencies really have something in common with single page applications when you start building up stacks of modules or tools or pieces. You're getting close to something that looks like an application even though it may not have all the things you would expect to see in an application. And you have the same challenges. So these are pretty easy to set up, especially if you're using a framework. But what do you do with them then? How do you scale them? How do you modify them? That's probably the next question that we would want to look at with regard to where we are right now and where we want to be going. There's some tradeoffs like with everything. So obviously the time to render an application to begin with can be an issue. Depending on how heavy the application is and how much of it can live on the server and if your logic is shared or not, your templates are shared. For the same reason SEO can be a concern. And then of course if you have an application that's doing a lot of communication with the server or passing things back and forth frequently, you end up with a lot of HTTP requests which can be difficult to manage and figure out how to package up. So you have to create good packages that have the code that you need when you need it and don't, on the other hand, introduce a bunch of junk that you're going to be storing in memory on the client and not need. So some of the implementation issues that you might see would be creating the scaffolding for the application itself. You have to do a lot of setup with certain frameworks or just even without a framework for some of these things and that could be a concern depending on how quickly you want to get up and running and how certain you are that you're going to need all that. And when you want to redraw, when you want to touch the DOM, you want to be careful with that. And so although it might be easy with these tools and these frameworks that we have available to us to just redraw everything all the time, you obviously have to be smart about that. And by the same token, how client interactions fit into that big picture, whether you want to be detaching events and things like that or whether you can delegate a bunch of stuff so that you have 90 events on the document is a choice that you have to make. And of course, again, the HTTP requests. So I wanted to look at a few approaches really quickly that people are taking just to single-page applications before we jump into combining all this stuff together. Twitter just, this is a recent blog post from Twitter. Did you guys see this blog post about flight? It kind of catches us up with where Twitter's stack is and I think flight is a pretty cool thing. I'm pretty excited about it, but that's not this talk. So basically what Twitter is doing is they have a lot of their HTML rendered on the server and then they're sending it down to the client to be used in a single-page application and they're controlling a lot of this stuff with flight on the desktop, I think, primarily. But they have essentially a very lightweight single-page application and the trade-offs they've made are interesting because they don't want to do a lot of client-side rendering so their application looks slightly different than what others might. Airbnb also had a blog post recently about their stack. Did you guys see this one? Yeah, I'm going to hope you did. So they're doing something kind of cool. They've got Backbone on both the client and server and people have been talking about this. I think SenseNode was released, but it's nice to see more and more people doing it and it's nice that they're doing it with Backbone, which is something that a lot of people are familiar with. So this is kind of cool. I'm also using CoffeeScript if you're a fan of that. Where's that CoffeeScript? There it is. And then Meteor is not actually an implementation, nor is there a blog post. Sorry, I know the blog posts are really exciting. But Meteor is an interesting approach to a full stack application, again, that is node-based and doesn't have as prescriptive architecture as perhaps Backbone, but does offer some sort of architecture. And unfortunately, I linked to the video, which doesn't really give us a lot to look at. So my apologies. But you have models like you would in MVC, but then you have messaging like you would in maybe an event-driven architecture. So speaking of event-driven architectures, let's talk about MVC and EDA and what's going on there. We'll start with the familiar one, or hopefully more familiar one. So the model view, whatever concept has been around since the late 1970s, it's very closely tied to object-oriented programming. It was first implemented in Smalltalk. And now we see this implemented in pretty much all of the popular frameworks that... We've seen historically that this has been implemented in more and more popular frameworks. Java.net, you name it, basically. There's probably an MVC implementation, and it may or may not be the default way to go about doing things even. And traditionally, of course, it was on the back end because we didn't do applications on the front end. So the model in the MVSTAR concept, you could think of it as an object. I like to think of it because it's basically just your data. You can think of it as a place to store data. And they tend to relate to each other like tables in a relational database as well. The view would be the presentational part of the application, OBS. It draws the interface for you and it can interpolate the data that you're sending down from your server. And optionally, it can also track your user interaction, but that depends on the variant of star that you're using. And we'll talk about the stars in more detail in just a sec. So in JavaScript, it looks a lot like traditional object-oriented programming. But once we get to the rapid development craze of whenever the heck it was, we see more and more people wanting to use a good framework with an understandable architecture to get up and running quickly and organize their code quickly. So where that leaves us today is that we have a bunch of options, which is cool. A lot of different variations on the MV family pattern. But we don't have a whole lot of options outside of that pattern or that family of patterns. So cue our introduction to EDA. These are slightly less formal than MVC. I mean, if you can say that MVC is formal at all, I mean, they're all obviously just suggestions and ways to pattern your application. But these suit highly interactive systems pretty well. If you have a lot of IO going on, then you have a lot of events. So why not make your application event-driven? And they're simple, fairly reactive, but you could certainly make them more complex and you could make them less reactive, like with web sockets. And we see this probably more in tools or pieces of applications than running applications themselves. But it's also something that I think we're considering more and more as our applications scale bigger and we pull more pieces into them. So the events and the objects. The objects tend to have less data persisted in this pattern. Again, they don't always have to if you're combining it with something else. But by default, you would assume that you don't have an object that models exactly what's in the database. More likely your objects or your models would be the state of your application or the state of some part of your application. The events themselves cover pretty much everything that you would do with an application. From the user's interaction with the view to the server's interaction with the state or whatever data you're tracking. And of course the messaging that the application does within itself. And this is all really decoupled or it can be really decoupled because you're just passing messages around. So you don't have to set up chains of functions that have to be called or anything like that. You can let all of the pieces of your application manage themselves as they see fit rather than having them be dependent upon each other. So in JavaScript, E is basically what we've been doing since the dawn of time. And that worked for a while until we started getting into actual architectures. So originally, of course, all JavaScript is triggered by client-side events. So everything starts with a client-side event even if it's JavaScript that gets run when the page loads, the page loading is an event. So everything starts with an event and that's evolved over time as far as how we handle it. So we move from the on-click within our tags to where we are now with smart ideas like event delegation and PubSub libraries. But we don't have a whole lot of frameworks that support this. We can manage our events, we can do event delegation, we can do PubSub, but we can't really tie any of that together into an application or a cohesive whole. So my opinion is that MVC and EDA need to get together and make it happen. There are a few differences in how these two patterns or architectures deal with, well, start with data. In MVC, you can expect everything to be in models and the models will be very nice and tidy and that's all they'll do. EDA, you might have models, you might have models that reflect your data, you might have models that reflect something else that are caches or whatever. In MVC, you can easily do crud and it might be difficult to do something besides crud, but it works very well with, again, that sort of database way of looking at the world. EDA, on the other hand, might work better for sort of ad hoc updates if you're not changing an object, if you don't want anything to do with the database or if you want to combine things. The views might be a little bit different as well. In MVC, of course, you have a view that corresponds to your model generally. In EDA, you wouldn't necessarily have that. You'd probably have some sort of composite, not that you can't make a composite out of the views that correspond to your models in MVC, but you'd have no reason not to combine them if you were modeling your view on a state rather than a model that is in turn modeled on something that's in the database. In MVC, your view is often responsible for its own interaction. In EDA, conversely, you'd probably want your interactions to be a first-class component because they are events, they're going to generate events, and so at least the view into those interactions is probably something you'd want available throughout your application and not confined to the view or some part of your application. Okay, so where the action happens, which is the fun part. In MVC, it's all pretty triad-specific, so things tend to happen within their model view controller segment. In EDAs, you wouldn't want them to be confined, but again, to a specific set of models of views and controllers, you'd want them to be available to everything because that's the idea, right? That anybody can subscribe to an event and anybody can do anything they want with it. In MVC, you don't have your objects influencing your controllers. It generally works the other way around. In EDA, your objects would be aware of the events and be able to listen to events much like a view would observe a change in a model. So let's talk in just a little bit more detail about the MV star in the, we're getting to the star part. So I want to kind of try to break down the differences, and this is all kind of up for a debate, so if you want to disagree with me, that's cool. MVC is these tight triads of model views controllers, and the view tends to, or the information in the view tends to bubble up through the controller. A lot of you presenter, you have a model and a view that are paired, and the presenter has the option of working between the two, and it should work between the two. They shouldn't talk to each other directly. You can also have a presenter that kind of floats, and you can do the same thing with a controller, but the sort of interesting differences that the view doesn't directly talk to the model. So a model view view model, you have a model and a view that are super tightly coupled via the view model, which does observer-ish kind of things, like listening for changes on the model and then updating. So the appeal of this, again, this showed up in JavaScript when object-oriented programming was super popular and we had all decided as a species that object-oriented programming was the only way we were ever going to program anything ever again. And it was useful because around the same time we were building web applications on really big teams, or even slightly big teams, and separation of concerns was becoming more and more of an issue. If you have a whole bunch of people, you want people to be able to work on different parts of your application without, you know, merge conflicts. And then shortly thereafter, we were in the age of REST, and REST got really popular, and we were like, oh, hey, if our client-side applications look like our server applications, it will be easy to map the client-side applications to the code that's on the server, and these objects and the data that we're passing back and forth will just fit in. And of course, the bottom line, as far as I'm concerned, of the appeal of MVC and its ilk is that we have awesome tools already, and awesome tools make people excited to use things. So what we're doing right now, we see a lot of lightweight MVC frameworks, or MVSTAR frameworks. The controllers might be in routers and views, or in controllers themselves. We also see really good presenter abstractions, where people have enabled us to do a little bit of magic, I guess, and then we see the real magic, which is automatic binding. We see a lot of frameworks that now will let you write HTML or templates that correspond directly to your model, and you really don't have to do a lot in the middle to make those things line up. So there's a wide variety of approaches that are readily available. The choices that we have to make in selecting one, of course, there's a few. Obviously, we don't need boilerplate, which is kind of cool. We don't have to write all these abstractions ourselves, which is great. But you might ask if you have a really small app, if you need all that stuff, if you need all the magic that you're not writing, and if you need all the setup that you will do for using a framework rather than just writing something bespoke or whatever. And on the other hand, if you have a really large app, like your framework might be good and it might be a good place to start, but it's probably not going to give you everything that you need to do in your application. You're going to need to pull in additional tools to make it function. Basically, your separation of concerns depends on how many concerns you have. So let's talk about what those stars actually mean. So let's start with a controller. This is a pretty straightforward controller. It has interface events, binding to app functions, managing model properties, and rendering and initialization. And this is just going to look at a bunch of to-do MVC code because it's fairly consistent in what it's doing. So we can see our interface events getting declared here. Oh, yeah. Sorry. Bigger. Okay. So this is the controller for... What is it? Spine. And we're wiring up our interface events. We've got a bunch of... We've got a bunch of functions that get added to the object itself. Got some initialization stuff. And it's pretty straightforward. Oh, everything gets bound to functions in the application and we directly control the model properties. So that's a controller. A presenter. This is kind of up for debate. You can fight me on this if you want to. A lot of people think of backbone as more MVP than MVC. So backbone makes an interesting example of a presenter, I think, because it's just doing these sort of events. It's going to do the interface events, the observer events, and then they're rendering an initialization without a direct connection to what's going on in the other layers. So if you've seen... If you've used backbone, this is all familiar. These are interface events. Here's our initialization. Again, rendering, blah, blah, blah, blah, blah. And it's almost the same stuff, but we're not doing a lot directly on the model, and we're not doing a lot directly on the view. We're simply... Oh, I'm sorry, we are doing a lot directly on the view. My bad. But we are kind of keeping the two away from each other. So the listen to here, these observers, is one of the most interesting parts, I think. And the new view model is again slightly different. We do our interface binding there, and then in a knockback in particular, we have some magic interface stuff that happens, which is kind of cool. And then observers. Because it's just a view model, it's not a controller, somebody else is going to handle rendering initialization. So where is this? I'll show you guys these magic functions here, which we don't ever actually declare in here. So these functions are coming from somewhere else, and we're just going to deal with the things that correspond to this particular view, which is to do again. I would recommend taking a look at those in more detail. I don't think we can cover each individually in, what, 20 minutes? So, but just to kind of give you an example of how these things are basically very similar, and the differences between them are subtle. So, now let's talk about what happens outside the client side. We need somebody to make our application worth having. So we always assume that the first renderer is going to come from the server, and that can be data, but it's probably HTML because you don't want to get the data and then have to render the whole page. Of course, the server is going to update your application, or your application is going to update the server, probably a little of both. You might also be storing things locally. So you have communication going in both directions. And this is easy to do when you're using things like CRUD, or a CRUD kind of model, or like a REST kind of model, things that are very compartmentalized and predictable and correspond easily to your properties, your models, whatever. And that stuff becomes highly automatable and fairly predictable. So it's easy to magic that stuff up. I think it's harder when you have to change multiple models, or if you have to do a lot of quick changes to the state, like one after another if you're trying to, if you have some sort of game or something like that, where you're making a lot of quick changes that need to be reflected and you're not sure that you want to push all those to the server. And uploading offline data could be tricky because you have a whole bunch of stuff that you want to upload at once. And again, not necessarily corresponding to a specific model. So that's where we get to WebSockets. If you're not familiar with WebSockets, WebSockets is its own protocol. It runs over TCP on port 80. The prefixes are WS and WSS, or WSS for secure. And it basically allows the server to push data down to the client. If you've done long pulling in the past, then this is essentially a replacement for that, a much better replacement and not a one-to-one replacement because, of course, long pulling is still a request response. And if you're completely, you've never seen WebSockets in action before, that we would look at this guy real fast if it loads. Have you guys seen this? Some of you have? Okay. So this is basically a gigantic Scrabble game. And it goes on forever over the whole world. And you can just keep adding things to it. I apologize if you see any bad words. It just occurred to me that this is the Internet. So yeah, we'll just shut that down. But the idea is that people are playing while you're playing. I should have stayed where I was so we could have seen if somebody was going to put something down. But yeah, so I don't think I can do that. I forget the rules also. But just something like this is a very extreme example, but it doesn't have to be a game, obviously. Talk a little bit more about it. So this is not Comet. Comet was, you know, what we did before we had WebSockets. And what we do still, if we don't have WebSockets available in a browser, it's bi-directional. So either side can push or listen. And again, there's no request and no response. So you don't ask for something and then get it back. You get something without asking for it, whether you want it or not. And then it's your choice whether you want to observe that event and respond to it. It's got cross-origin support built in, which is kind of cool, but also means you have to be careful with it. And the API is just incredibly simple compared to XHR. This is a cakewalk. So it's available now in most of your desktop browsers. Firefox, Chrome, IE, Opera, and Safari. Mobile, not so much. I think it's available on iOS, not Android and not Opera Mini. So it'll work basically on your desktop, but you probably wouldn't want that much information coming down on a smaller device. Anyway, at least not over a great length of time. I don't know. So things that you would use this for, like tickers, if you want to, like, display a bunch of information as it comes in, chat. There's a lot of chat examples. Collaborative editing is my favorite. If you want to do any work with other people in your, like, in a distributed environment, you want to share those updates and you want to see them live, like you do in, like, Google Docs or whatever, but hopefully working better than Google Docs. Of course, games. Everybody loves games. And every single no-knock application that I've ever seen uses WebSockets in some way because, why wouldn't you? And I think that kind of underlines the appeal. It's much easier than AJAX. So let's talk about how we combine those two things to make our relationship with the server a little bit cozier. So if we wanted to take our controller's presenters, whatever, and put a little EDA stuff in there, we're already in pretty good shape. They're already full of events, right? There's a lot of, a lot, we looked at those, just those three really quick and obviously, again, those are very simple applications, simple to do application, but there's a bunch of events going on in there. And so if we have events, we're much closer to being event-driven, right? But we need to free those events from the triads that they're locked into before we can use them globally in the application. We want to be able to have the application subscribe to them and to have anything within the application, anywhere in the application, subscribe to them. And this is, it's trivial. You can use, you can use a small PubSub library. You can write the little thingy yourself. You can use jQuery, and probably if you're using a framework, it already comes with some sort of event system within it that you can easily tap into. And then you want to be able to pipe those events. So the user and server interaction are not, are not events that you're able to subscribe to, usually on a global level, so you have to pipe them into something else to decouple them from whatever segment of the application they showed up in. So if it's, you've got your to-do view and you get a click there, you don't want everything to have to listen to the button that got clicked. You want to be able to publish an event that everybody can see without having to know what the selector is for the button that you're expecting to click from. The nice thing about this is that once you're piping them, you can do all your validation and stuff. They're in the object that generated the event and then pass the global event on only after it's verified or do whatever other modifications you need to if you don't need to do validation. You can have as many subscribers as you want, so the whole application or pieces of the application from all over the place can listen for whatever you're publishing. So putting WebSockets together with this is just the same as putting, connecting it to the server events or the user events and they get chained the same way. And then your specific controllers again can subscribe to global events or vice versa. You can pass WebSockets events in specific controllers up to the global level. And you get the opportunity this way to cache and or bundle your updates. So let's say you're playing a giant game of risk similar to the giant game of Scrabble we just looked at and you don't want to publish the player's move until they've taken their whole turn. I haven't played a risk a lot, but I remember you have to do three different things before your turn is over with. So they need to get their stuff and then move their little guys and whatever else. And only then do you want to update the server and broadcast that event out to the other players. So you have the opportunity to do that, which is kind of nice if you're looking at events that come from different parts of the application in different models and different views. So let's talk about how we would actually implement this stuff. So DIYing this up yourself is really trivial. You just declare a socket. You give it a URL to listen to and a protocol. And then you can do one of two things. You can either send or receive. So you want to listen for an open connection before you try sending messages from the client. You can also listen for messages from the server immediately. Of course you can close the connection if you're not going to be talking to the server anymore. And it's, like I said, really simple API. So we've got some DOM element here that we're going to save. And then we've got this variable s here that's our WebSocket. And we're just passing it the URL and the protocol. And then the first thing we'll do is listen for the connection to be opened, which is on open. And then we can send back a message to the server saying that we're good. And then we can also listen for messages from the server. And notice that this doesn't care what kind of message is coming from the server. Whatever message it is, it's just going to push it into that DOM element. So the server side of this, you can also DIY that part up yourself. But you might not want to at that point. You're DIYing on the client. You're DIYing on the server. That's kind of a pain. And there are so many lovely utilities you can use. They also abstract out things like broadcasting to multiple subscribers. I wanted to show you guys this list very briefly, in case you're not a node person. So pretty much every backend that you might use under the sun has at least one implementation, if not many. Oh, you can't even see that. Sorry, you guys. Where are they? Here. Even Haskell.net. Yeah. So Socket.io is the one that I'm most familiar with and have used most often. Actually, probably the only one I've ever used. So this is exactly the same thing we just did in Socket.io. And all that's really changed is that, instead of declaring a new Web socket, we're just calling this connect function on I.O., which is a global object that we import when we import the Socket.io client-side library. The API is a little bit closer to node or now jQuery. So we use on. And then we, instead of having the name of the event appended to the word on, we just listen for on and then we give it a string that's the type of the event. So connect is a built-in one. So essentially the same as on open. However, the interesting thing is down here, we listen for on new message. So instead of just listening for a message from the server, we listen for a specific type of message. And then if we're expecting different kinds of messages from the server, we can put a whole bunch of these listeners in and we don't have to do any branching within our listener. Oh, and we use the emit function instead of send, also for sending stuff back to the server. We also use send. That's my bad. And of course the API goes on from there, but this is the simple version. So if we want to connect this up to what we've already got, there are a number of ways we can do that. You can add messaging, just sort of ad hoc anywhere you want in the presenter control or whatever. And if you want to just, if there are only certain parts of your application that you want to share, whether it be collaborative or just, you need the server to know right away when they happen, then you're set. Or if you're rolling your own framework, you're not using something, you can use WebSockets for syncing from the get-co, which might be kind of cool. If you are using a framework which is more likely, you can swap out any explicit sync calls within your code with a WebSockets connection with a socket of it. And that way you don't have to use whatever methodology they were, presumably Ajax, they were using to send your info back to the server. Most practically, you could try to find a WebSockets plug-in for your framework. So I wanted to show you guys this one real quickly. Backbone.io, which is, as you might suspect, works with Backbone and socket.io. This is the server implementation, so pretty simple. Basically, we're just... It's not much more complicated than setting up WebSockets, but the important thing to note is that here we've given a back-end called messages, or it's called messages, and this is the messages property. Then here in our index, we just connected up much like we would socket.io, and this is just a friend-in on socket.io, so it wraps up socket.io's stuff. And then down here, we set up this back-end, and that's it. Now, all your syncing happens via socket.io to the store that this thing contains. So you could, if you feel real comfortable with whatever framework it is you use, you could probably write something like this yourself, assuming it's not Backbone, but it's an easy replacement for whatever you're doing if you need to have that sort of instantaneous communication with the server. But I think more probably you're going to want ad hoc kind of stuff. So let's talk about using these WebSockets to actually control the application. I think one of the most interesting possibilities here is getting action based on messages you get from the server. So instead of waiting for the client to tell you what to do, wait for the server to tell you where to go next in the application. You can pipe those events the same way again. And you subscribe on the Models and Views, so you end up with something that's very similar to Model View Presenter, where you have this controller that's listening for WebSockets events, and then your Models and Views just take their own action, and your controller becomes sort of very consistent in what it's handling. So this is like super simple fake example, but here it is. So let's say you have some sort of event store somewhere. Oops. I don't know how I did that. You have an event store, and there's like some simple PubSub or something in there, and you're just going to connect up a socket, and then when you get a new object, you pipe that event, and you pipe the data that you got to a global object-added event. And then somewhere in a collection, you get an object-added event, cool, you add that to your collection, done. You have the same thing on your view. You get an object-added event, you have the container for that view, and you render that data into your container, and that's it. This, I think, is an interesting way to think about replacing all the stuff that you would have wired up in a controller, all the sort of back and forth. And having it directed by the server, which is not something we normally think about in client-side applications, but we talk about putting our templates on the server or our logic on the server, but not generally the control of the application itself. So it's an interesting thing that might suit your application. So there they are, together, MVC and EDA. Really, it's a tool to use within your pattern. It's not a replacement for your pattern. You can use it a little bit to just do ad hoc communication, or you can use a lot to do syncing and every other thing. And it's a piece of cake to add. And that's it. Questions? Thanks.