Interview with Justin Meyer at GOTO Chicago 2015

Hi, it’s Mike with UGtastic, and I’m here at GOTO Conf 2015 again. I’m standing here with Justin Meyer, who gave a talk on how to build single-page applications the right way. Did I say those in the right order? Close enough. You did a good job. So those words were in the title of his talk. Thank you very much for taking the time to speak with me. So about building single-page applications the right way, what was that talk about that wasn’t in the title? Yeah, so the longer title would be that I’ve done consulting for like eight years, front-end JavaScript consulting, built a bunch of different projects for a lot of different companies, and I wanted to see if I could put in one 50-minute talk all the different techniques and strategies we use to make applications, I would say, competitive in kind of the world we are now, where if you want it to be as fast as possible, maintain able as possible, what are all the best things that you should probably be doing, and how do we do them, as an example? Okay, so with your talk, what were some of the high points, or what were some of the lessons maybe that you were trying to bring and surface? So the biggest one was, or what my favorite was, was the model layer that we added. We kind of discovered that when you make a request for page data, or like, hey, I want a list of to-dos, you’re always, in the params that you pass to the server, those always represent a set. Like, I want to-dos for user ID 5, so you put an object with user ID 5 in it. That represents a set, and then if you can compare that set to other sets that you’re loading, you can do all these sophisticated performance optim izations for free. So if you want to, if you have multiple, if you have pages that are making multiple requests at the same time, you can, like, union those sets to make a single request for all data. You can do things like fall-through caching, and the biggest one, of all of them, I thought, was how easy real-time behavior becomes. So normally when you request data from a page, from the server, and you get a list of elements, or a list of items, to-dos, and you just stick that into the browser, right? You’ll use, like, live binding, so if the list changes, well, the page will update itself. You’ll just get that list, but if you can associate the set of data that was used to retrieve that list, and keep a reference to that list, and it’s set, then when a new data item comes in, you can automatically decide, does it belong in that set, or is it in that set and needs to be removed? So all the normal stuff you have to do with the real time of, like, updates come in, and maintaining these lists and what’s visually on the page , you can get that automatically if you have set awareness. Okay. So were these lessons that were coming from your production environments, or…? Yeah, so, from our clients, so we… You’re drifting a little bit. Am I drifting a little bit? Let me stay in. Yeah, yeah, you’re great. So the one from the…the biggest example for the set stuff came from an application we wrote that was kind of like a file manager, and it had real-time connection. So if new files would come in, we’d have to put them in the right place, and also, it would load the folders and the folders and the files into independent widgets, and we wanted to write them so they didn’t have to know about each other, like the folders and the files and folders. So we wrote this layer to automatically detect that you were loading overlapping data, unify it, make a single request, and then kind of feed it back out. So it sounds like, you know, a lot of people look at single -page applications and think, “Oh, it’s just easier to write JavaScript than it is to write server-side code and deal with that.” But it sounds like it’s not really the case. It sounds like there is a lot of thought that has to be put into the architecture supporting a single-page application that isn’t obvious. Yes, if you want to…I mean, it’s…if you’re writing an application, it’s all about how complex your application you’re writing. I do tend to think that writing JavaScript code for the same set of features tends to be easier. Doing front, like, thin-server architecture is definitely easier than writing, you know, from the server’s perspective. Because it’s kind of somehow easier to, like, pull your data in, draw the page all in the client, than to definitely do it on the server. But what my talk was about is if you want those kind of features that people want and expect out of apps now, like Realtime is a good example. Or if you want it to run really fast, you have to…yeah, there’s a lot of sophisticated stuff you have to do. But I think we’ve found ways of making that a lot easier. Okay, okay. And, you know, the ecosystem around single-page architecture… I mean, the ecosystem around single-page architecture is constantly in flux, and ironically, flux. It’s just MVVM, but branded with a new name. So, when people are looking at building a single-page architecture now, and they’re looking at a plethora of options, you know, Angular is God’s…what’s the…some plastic name, I can’t think of it…Polymer. Google has Polymer, yeah. Yeah, Google has Polymer. Yeah. Yeah. Yeah. And, you know, Backbone seems to be kind of on life support . Yeah. I mean, there’s so many choices. I mean, how…do you talk about, like, how you can evaluate how your needs… Yeah. …relate to capabilities, or Ember, you know, that’s another… Yeah. …because there’s so many. Like, do you talk about those kinds of decisions? Not in this talk, but I’m happy to talk about it. Okay. So, I’m extremely biased, because I’m the maintainer of C angeas, which is a framework, and that’s what my presentation is. Okay. So, I’m extremely biased, because I’m the maintainer of C angeas, which is a framework, and that’s what my presentation is. presentation showed, how, at least for what we care about, is I built JavaScript WC like seven years ago, and what we say is that if you would use that and kept with us, we will be able to upgrade you to the latest, greatest features, because CanJS has everything that all the other frameworks have. But you’re absolutely right in that it’s a rapidly changing world, right? Backbone was huge, Angular was huge, now it seems like React is going to eat a lot of Angular’s lunch. One of the first points I actually made in my talk was that how technology choices matter far less than management and user experience choices, and this is actually backed up by data that we’ve accumulated with our company. So the first thing I talked about is how we use checklists to make sure we’re doing the right things on projects. We didn’t go to a client and be like, hey, are you guys doing these things? Let’s figure out a way to do that. But we’ve kept data over the things over time of what we have and haven’t done, and we’ve all wrote what correlates strongest to project success, and things like how long will it be until your first release? Do you do social events with your company? Are you doing user experience testing? It matters far, far more than things. It’s like, are you even running tests? Okay, so just kind of taking a spin on culture as being a, well, I think there was a talk where they, or some kind of common wisdom about that your architecture represents your communication system, and it sounds like you’re kind of in that same spirit of like, if you’re going to be building something, how are you guys communicating, and how is the company going about building its products? Yeah. Not just like, are you doing TDD, but how do you talk? How do you communicate? That’s exactly, like, I think that, so everybody wants to do framework wars discussions, and they’re valid, because there’s interesting differences, and I’m happy to go into that, but my first point I always make is that if you’re looking at a choice of framework is going to matter in terms of success or not with your application, it’s probably not, and if you really do care about success, you do care about those things of communication, are we building the right app for the right people? That kind of things, and I also think that in choice of framework, pick which one you guys can get behind the most, because I’ve been in situations where some people want this framework, and other people want this framework, you need everybody on the same page, just get them on the same page. It doesn’t matter even if you’re going to be like, we want to use Backbone, even though in terms of features, it’s kind of been left behind, if everybody’s together, and you’re all going to invest in it, and everybody’s going to be experts in Backbone, you’ll produce something. It’s going to be way better than the newest bleeding edge framework with all of the bells and whistles. It’s even the same with, it sounds like what you’re describing is PHP versus Ruby versus Python. If you’re a professional, you know what you want to build, you’re going to build something, whether it’s in VB or it’s in Clojure, two ends of the popularity spectrum of who thinks who’s smartest, which we know, it’s the person who makes the most money, but the point is that if you’re having a hard time, if you’re having a hard time, if you’re having a hard time, if you’re happy with what you’re going to be building , and at least you can get everybody working together and wrapping their heads around the complexity of the problem, it doesn’t matter whether you use Flathead, Screwdrivers, or Philips, you’re going to build something. Okay, well thank you very much for taking the time to speak with me, I appreciate it. Thank you, Mike. Thanks. Thank you. Bye.