The panelists talk about refactoring JavaScript Apps Into a Framework with Brandon Hays.

Special Guest: Brandon Hays.

 

  We got Spiderman covered. 

  Should we talk about JavaScript?

  Hey everybody and welcome to episode 112 of the JavaScript Jabber Show. This week on our panel, we have Jamison Dance.

  Hi friends.

  Aaron Frost.

  Hello.

  AJ O’Neal.

  Yo, yo, yo, coming at you live from the wonderful world of Mario Kart 8.

  Joe Eames.

  Hey there.

  I’m Charles Max Wood from DevChat.TV. And this week we have a special guest, Brandon Hays.

  Hi from Austin, Texas, which is hot and humid.

  You want to introduce yourself really quick, Brandon?

  Yes, for the everybody who doesn’t know me? 

  Yeah, for the one or two people.

  Yeah, for the universe. So yeah, I’m Brandon Hays. I am a software person at a consultancy I help run called The Frontside. It’s a catsultancy. Actually, we’re pivoting into catsulting. We primarily focus on Ember.js these days. Historically, a lot of Ruby on Rails and JavaScript, and these days primarily Ember.js. So, thank you welcoming me to the Angular podcast. [Laughter]

  Oh, the trolls begin.

  Oh, yeah.

  Oh, this is… Yeah, I hope you guys are ready for that. This is going to be fulltime.

  [Chuckles]

  We’re not usually belligerent with the guests but I guess today we’ll make an exception. 

  Well, I know you in person so I feel like the gloves will come off.

  [Chuckles] Yes.

  That’s right. Don’t make me sick my [inaudible] expert on you. [Laughter]

  Oh, geez.

  Alright. Anyway, we brought you on today to talk about migrating from the jQuery world to the Ember world.

  Yeah. And then somebody else brought something up that I think we probably should cover first, and that would be Mario Kart 8.

  Yes.

  So, I just bought Mario Kart 7 for the 3DS. I do not own a Wii U yet. But I am captivated by a meme that is completely, completely taken over my life, and it is the death stare Luigi.

  Oh, it’s real. It’s so real, man. It’s amazing.

  Is it in the game?

  It’s in the game. It’s so good. 

  I want to just meet death stare Luigi, not in a dark alley or anything, but meet him and shake his hand. It is the most beautiful meme. There’s already a subreddit dedicated to it. I had no interest in purchasing a Wii U until seeing this meme come to life. And now, I must, must own one.

  [Chuckles]

  Yeah, you should. You definitely should. [Chuckles]

  Then you need to get the ITV app and make two other panelists happy. [Chuckles]

  That’s right.

  I was going to say they missed an opportunity to have dubstep turn on. So, you can slow down the replays of a game and they should have just enabled the wub when you go into slow motion.

  [Dubstep sounds] That’s probably true. But the slow motion I discovered this morning and that was amazing.

  That’s hilarious.

  My sister has the controller and she just accidentally hit the button. And then all of a sudden it goes [makes reverse sound effect], reverse. And we’re like, “What? Let’s see that red turtle shell again. And again. And again.”

  Alright.

  So yes, that’s the most important topic of the day.

  Alright. I’m glad we got it out of the way.

  [Chuckles] So, I guess it’s weird that I’ve had a lot of attention that I paid lately to the topic, to this specific topic. And I care a lot about it. But I try to understand that not everybody’s coming to stuff from the same place. I know that a lot of people like people who run podcasts like Angular a lot. [Laughter]

  And I honestly…

  Oh my gosh.

  It’s just going to be like this all day, guys. So, I don’t have a lot to offer in contrast to Angular because I haven’t used Angular a ton. My business partner has and we settled on our preference. But mostly, I started using Ember and it was such an accelerator off of the way that I’d done my JavaScript before. And you probably know this. When you start using a tool and it does a lot of work for you and it saves you a bunch of time, it’s hard not to fall in love with it. It’s why I sleep with my power drill under my bed.  

  Yeah. You name your kids after it, yeah.

  [Laughs] Yeah, exactly. [Laughs] Yeah, like little Ridgid and Makita, my son and daughter.

  Yeah.

  Yup. But because I’ve gotten so much productivity out of building applications with Ember, I’ve really actually come to enjoy it a lot and I’ve come to enjoy working with it. And started realizing, I actually learned a pattern for dropping Ember into existing applications from my business partner. And I started looking around and I realized not a lot of people were doing anything like this. Most Ember tutorials you see are you start from first principles, you start from building a single-page app. And that’s really their main selling point, right, is if you’re just dropping stuff in, Angular’s a really great choice. If you’re just starting from scratch on a full single-page app, you’ll get a lot more of a head start if you start with Ember. And those are all debatable points which I look forward to. But in general, that’s the perception that I’ve found in the JavaScript community, certainly between people who will fight and draw blood over which framework to use. 

So, my experience was we liked using Ember and we liked Ember’s object model a lot. And then the component system came out. And Ember has really worked hard to, at best they can pattern that after the W3C component spec so that it will eventually have some sort of compatibility with it. And we started realizing, you could just take these Ember components and stuff them into the page and start gradually refactoring existing non-Ember applications toward Ember. And we did that for a few clients. And it’s gone really, really well for them. And for some people, they just stick with one or two components. And some people use it as a lever to start bringing in more and more functionality. And eventually, we’ve done months of work on something and then near the end of it, we’ll actually drop Ember’s router in. And it’s been really fun to build stuff that way. 

It’s a way that not a lot of people think you can do this, without having to start completely from scratch. And so, the experience of doing that, that’s where I decided I was going to submit a talk proposal. And then everything unraveled for me after that. [Chuckles] But I’m curious to know if you guys, primarily if you guys do server-side applications with JavaScript sprinkled into it or if you primarily do single-page applications. 

  I’m a single-page guy. I don’t know everyone else.

  I’m a single-page guy.

  Single page all the way.

  I tend to do the other. I tend to be the backend with JavaScript sprinkled in. But that’s really just because I spend most of my time doing podcasts and client work. And most of the client work doesn’t…

  [Inaudible] look good.

  [They’re usually] not interested in or doesn’t call for a frontend framework like Ember or Angular.

  Yeah.

  So, I have a question about this. How do you, if you’re refactoring an existing application, how do you know when it’s a good choice to refactor it into a different application framework or just clean up the code in general? Because if you have… jQuery spaghetti is bad, right? You can write applications without frameworks that are jQuery spaghetti.

  Yup.

  And you can clean up the jQuery spaghetti without dropping in an application framework. So, how do you decide when to use what?

  That’s a really good point because I think what happens for a lot of people is they start looking at the tool. And you can become obsessed with the idea of using this tool. It’s a tendency of anybody who becomes enamored of something to start looking at everything as a potential problem for the solution that you have. And as I was writing this talk, so the way that it wound up going was I thought, “Okay. Well, I’ll just take this and I’ll draw up, create a little talk,” and I wrote a lightning talk about it. And then started writing this talk and actually created this big, giant ball of jQuery spaghetti. And it was a nightmare to actually do. And I thought it was going to be really fun to get into this mess. And I highly recommend people go check out this code and look at how genuinely bad a JavaScript developer I am. It’s pretty embarrassing stuff. 

So, what wound up happening is, I got to a really bad point. And I talked to a few people about it. And I actually was asked that specific question. It was like, “Wait. Do you have to refactor this to Ember or could you just break this up into nice JavaScript prototypes and instantiate objects off of it. And is there a case to be made for that?” And it depends on what you want to accomplish. And so, my experience is this was a very stateful interaction. So, I know that I’m moving a bunch of state around. There are nested states involved. So, I know that I’m going to be managing nested states. Those states are going to involve what I would consider models of some kind. Those states are acting on things that have a certain type. And it’s going to involve a lot of data binding. 

it’s really stateful, there’s a case to be made for data binding meaning stuff like real-time validation or stuff that you want to automatically update based on the state changes, I really, really like using staying as far away from DOM manipulation as I can. And tools like Angular and Ember are really good about helping you get, run away from DOM manipulation, which almost all of the pain that I felt as a frontend developer has been messing with the DOM and leaving stuff in an inconsistent state. So, that’s the case that I would make for using a framework. 

Now, which framework you use is, that’s a totally personal decision. But what I want to make the case for is that Ember is a contender in this space. It’s that Angular has generally been accepted as the only option people have and Ember’s actually pretty good at this. Those components are really great at managing these things. And I really like Ember’s model. I really like the Ember model layer and its object model. So, I’m waiting for somebody to come slit my throat. [Chuckles]

  You’re too far away.

  [Chuckles]

  I’m on my way, buddy.

  [Inaudible]

  We’re into more slow deaths over here.

  [Chuckles] Okay. Somebody’s actually been mercury poisoning me for months and I figured it was in anticipation of this eventuality.

  It’s the CFL manufacturers. [Laughter]

  I’m going to have to warn Stanley. You’re onto him now.

  Just as a note, you cannot kill yourself by ingesting mercury because the lining of your stomach shields you from absorbing it and it just passes through you. Fun fact. 

  I don’t want to know how you know that. [Laughter]

  Anyway, so when I’ve done migrations from jQuery spaghetti over to something else, and granted these are only on my own projects where I have my own jQuery spaghetti, I tend to season it and make it into Ember or Angular spaghetti. In other words, I open up a controller, and I jam my jQuery spaghetti in there into its own function. And yeah, then I start to refactor it. But is that the right step? Or is there a better way of doing it?

  That’s actually a really great first step. They finally posted the talks from RailsConf and it’s out there. And it walks people through step by step one example of making a mess and then digging out of it. But one thing I found in every single time that has been really helpful has been to take the spaghetti code and put it in jail and in some bootstrap function that you eventually start slicing that code out, and realizing what parts of that code aren’t needed anymore. And the most important thing, and I hope this isn’t too controversial, the most important thing to me is I don’t know how personally I feel about test-driven development, but I know I feel very strongly about test-driven refactoring. I do not know how refactoring can be done without good tests. It’s just too risky. Everything feels too risky to do a refactor. 

And so, what you do is you close the door on the closet and put everything in there and run away. What my experience is it took a lot of work for me to get to where I felt like I could confidently test Ember applications. I think it’s more challenging of a testing story than Angular historically, than plain vanilla JavaScript as well. I think they’re working very hard to make that not be the case anymore. But when we were getting started, I’m just so glad though that I spent the time to get a test framework set up so that I could cleanly test these things. So, I write a basic integration test around the whole thing and say, “Hey, when I click this I should see this. When I click that, I should see that.” And these are not tests that touch the model layer. It’s purely an integration test. So, to me that’s the most important step. And it took me just in the one component that I was writing, it took me about four or five hours to get a test suite wrapped around it. But that was so worth it. That four or five hours bought me the confidence to go back through and refactor this application. 

And so, the first thing is I put this thing in code jail and then have an Ember component stuffed into the page that just does exactly what my old code did. And then I can feel really confident about saying, “Hey. I wonder if there was a model in here that can hold on to some of this data for me, first and foremost.” And as you start pulling code out of this stuff and you rerun your tests and they still pass because when you click something, it does the same thing as it did before. I’ve never had an experience where I didn’t have to refactor my tests a little bit as I go through a refactor to say, “Oh actually, I had this class over here but I’m putting it here now, because reasons.” But in general, there are very little changes upfront being done to that test suite. And then I can add model and unit level tests later if I feel like it. But it’s the integration tests that saved my life.

  But how do you test the spaghetti? 

  So, testing jQuery spaghetti is not that hard, actually. I thought it was going to be a lot harder than it was, because all you’re asking for is to say when I click this thing, so render this thing to the page, when I click this thing I should see this other thing. So, if I change the value here and click submit, I should see a message saying success. If I put a bad value in there, and the validator is supposed to catch it, and what’s interesting, as I went through and was writing the UI level tests for my JavaScript, jQuery, just total nightmare of a mess, I found bugs in the implementation, in my jQuery implementation, that I went in and fixed inside this gross, complex, mangled, gnarled, state thing. But I was able to actually find and fix a few bugs so that I knew that it was going to be consistent across when I actually did the refactor. 

And people, I don’t know if you guys have a preference on test framework. I find them all to be pretty much the same. I don’t know if that’s blasphemy. But we’ve used all the ones that I can think of. And I don’t really care about what test framework you use. It really is just a question of making it in the before just do something. Click on something, put a value in there. And then assert that something else shows up in the DOM. And that style of testing has served me really well. I don’t know. There may be holes to poke in that. But that style of getting, of bootstrapping your test suite by just asserting this, you visually can see something that’s visually different than was there before.

  So, one other question I have regarding moving from jQuery spaghetti over to Ember is that Ember has its own data model things. From what I understand, there’s an official one. I’m not sure if it came out to finally be, “Here’s what we recommend you use.” I know there was another one, Ember Data, or something like that, that was [maybe] the blessed child before.

  [Chuckles] Yeah, man. It’s true. And it can be really confusing. And I think there are a lot of things in JavaScript land that can feel like that sometimes. And I have people that might, I have friends that will get mad when I say that, where it feels like there’s often a paradox of choice. And I think Yehuda gave out just a magnificent talk at RailsConf about there’s an experimentation phase and then it’s time to shake hands and agree on some shared solutions and move forward on top of those shared solutions. So, there’s a time to fight over stuff that’s valuable. But then there’s a time where it’s time to shift from fighting over stuff and then work together on something crappy and they get better. 

And in Ember land, the data story was really bad for a long time. The first version of Ember Data, I still help maintain some apps that are running it, and it was very ambitious but it’s just not that great. I think Yehuda and Tom would be willing to admit that. And certainly, they admitted it by starting over. And so, I’ve been helping run the Ember user group here in Austin for a year and a half now. And it was more a support group than anything for a long time. And we did persistent framework shootouts. Everybody was arguing over Ember Persistence framework versus Ember Model versus Ember data. And the new version of Ember Data is the thing that everybody can agree on. You can use Ember Data or you can use just plain AJAX. 

My recommendation at this point is just to use Ember Data. It’s been a very long time since I’ve written an AJAX call against a server. I know that if I set things up correctly and well once, and it’s much more adaptable to all kinds of different APIs than it used to be, so if I just set things up at the adaptor level once and that’s very little work depending on how resourceful/restful your API is, there’s very, very little work involved in getting that off the ground. And it saves so much time in writing this AJAX layer yourself. I do very, very little of that now. 

  That was actually the question I had, was that in jQuery land there are some things that make managing the data easier. But in Ember, you just use something like Ember Data and it just handles all that for you. So, how do you wind up migrating your, “I’m going to grind through all these objects,” to, “Hey, I’ve got this model library that handles all that grinding for me and just gives me a nice interface to it”?

  There are a couple of, and I think it will be instructive if people want to dig through the code too, but there are a couple of places in the code where I actually, you can see where I pull out old AJAX queries and move them to, when I bootstrap the application and insert it into the DOM, the first thing I do is I go get the model. I load the model which will perform. It will create a promise that goes out to the server automatically for me, grabs the data off the server, and maps it back into a model. And now, when I create that component, I have it wrap this model. And that data is just sitting there waiting for me. And it’s part of the components so I just say, “Hey component, instead of making this whole AJAX request, just ask yourself for this piece of data in your model.” 

And so, it actually is a great, it was the first and easiest way to start removing code out of that code jail. The first thing I did was to identify what models. And the best way I know to start with that is to say, “Okay. What models am I fetching against the server in these AJAX requests?” Hopefully, you’ll never have a one-to-one mapping, if you have a server-side model and your client-side models. They’re not exactly the same. And even the same named models may represent somewhat different things. But my experience is very much that the first and easiest thing to extract are those models and say, “Okay. This thing is called, in the talk, it was called a [gift post] where it has some data on it.” I was going out to the server and asking for that and then mapping that data back and placing it somewhere on the screen. And instead now, I’m putting it in a pool underneath. 

So, the way that I visually have a mental representation of this is there’s this pool of data now that I’m gathering. And this model layer, it’s completely bound. I have all of this data. Any data that I load goes into this pool of data underneath my application that I can then just ask for and it’s right there. And so, I love, a pattern I really like in building Ember applications is loading as much data as is reasonable upfront. That way, you have lots and lots of stuff to play with when you start building these APIs. And it feels, it really does change the act of programming back from when you’re writing jQuery spaghetti code it feels like you’re just fighting yourself and fighting yourself as soon as you’re trying to do more than one or two things with it. And when you create this pool of data underneath, it feels like you’re just snapping things together. And it encourages you to play and it encourages you to try stuff that you might not have tried otherwise. Anyway, that’s the second step I would say, is extracting those models.

  And then what? After you [inaudible] models.

  And then [chuckles]. Okay, so…

  Don’t leave us hanging.

  [Chuckles] There is more. After that, I like to pull states out if you’re using stateful interactions. And this is where I diverge from Ember gospel and canon. Because in Ember they give you so many great tools to manage state with routes. If you’re doing states in your web application, it might be time to start thinking about something that plays with state really nicely.

  Hang on. What do you mean by states?

  Okay, so for instance, in this thing a small form sounds really simple. This actually came out of a client request that sounded like it was going to be a ten-minute feature and it turned into a twoweek nightmare, because they say, “Hey, we just want an email submit form. We want somebody to submit their email to invite somebody to come do this.” But then you have to think about, okay so this thing, they said, “Now the first thing that needs to happen is they don’t need to see this unless they click a button.” So, there’s a state where it’s not visible. And then there’s a state where it is visible. And then there’s a state while you’re editing it where this thing is either valid or not valid, because they need real-time validation that that’s an actual email address so people don’t submit garbage into the form. And then you click submit and now there’s a loading or in flight state. And they want to show, “Hey, this thing is loading. You need to disable the button while this is in flight.” And then when it comes back, you need to know whether it was a success or an error. 

And that sounds really simple until you actually try to build it, when you try to build it piecemeal out of jQuery. And usually the stuff we get asked to build is significantly more complex than that. So, something as simple as that, you can identify all of those different states and say, “Hang on.” And I’m a pretty visual thinker and so it’s like, “What am I looking at?” I’m looking at something that is not visible. Now, I’m looking at something that is in a valid state, something that is in an invalid state, something that is currently loading, something that is successful, something that has failed. And so, I like to identify those states and say, “Okay. This thing is pretty stateful.” And then there are meta states above that in your application that Ember’s router is really designed to map to, which is a user is viewing an index of posts but they’re also, they click on one of them and they want to show a single post at the same time. So, there’s a typical, I don’t remember the name for that visual pattern. What’s that pattern called? Something master…

  Master-detail?

  Master-detail. That’s an extremely common pattern that you’ll see in applications built with stuff like Ember, those types of stateful interactions where you have one state that stays there for a really long time. So, I’m kind of [sighs] I’m sorry for camping on that term. I don’t know a better term to represent state in this small detail, like loading, error, that kind of stuff, other than to also call that state. So, I’m referring in this case more to in the small. In the large, by the time you get to this large deal where you want to actually update the URL based on the state that you’re in, that would be the large state. And that’s where you might start considering using something like router.js. Have you guys seen that, by the way?

  Router.js?

  No, I haven’t. Tell me.

Is that TJ’s thing?

  No. It’s extracted from Ember’s router. It’s Alex Matchneer who I think you guys know I have a long-standing rivalry with that I manufactured literally out of nowhere. But it doesn’t matter. It’s real now. I don’t know what it is, but there’s just something about him that I just, I guess if I push the joke too far, you guys won’t realize that I’m joking, that I think he’s really smart and great. But I…

  Push it further.

  I worry about publicizing to the community this rivalry. But he is a jerk and he is the worst. And I think people need to know how bad he really is. He created an extraction of the router library in Ember called router.js and we actually just worked on a project in Backbone where we extracted, or we pulled that router in and built a Backbone app around it. And it’s been a total lifesaver. 

So, managing state in the large, if you want to update URLs based on stuff in a server-side framework, I like to let the server handle that for as long as possible. Moving to a router is probably the last thing I want to do. I would move every interaction that you can underneath the umbrella of all of these models, making sure that you have models on the page, making sure that everything’s nicely backed, that these states in the small for managing little bits of loading, little bits of these little small interactions are handled. And then you can wrap it all up. Really, by the time you’re done with this, moving to a single-page application is simple as creating a router that replaces what your server used to do, which is just rendering how many five or six different pages you have, and then rendering those components inside the views.

It’s a one-day, two-day changeover to take the remaining server-side code out from underneath your app and move to single-page application, which is really fun. That’s about the most satisfying day of work you’ll ever have, is removing the server entirely from the equation and realizing that you could just do anything. You could deploy this thing via CDN now. Your options open up so much when you decide to commit to a single-page application. So, I’m a big fan of SPAs.

  So, we’ve talked a lot about how to do this specifically with Ember. I wondered if any of the other people on this show had experience doing it in general or with other frameworks and how that compares to Brandon’s experience. 

  Well, it certainly sounds like Brandon has put a lot more thought and effort into this particular paradigm. 

  Please restate the question.

  [Laughs]

  So, say I don’t use Ember. How do I apply this? Or do I just ignore this episode?

  No, no, no. You got to expand the ‘this’ to specifically what it was you’re asking. 

  Do you mean refactoring?

  [inaudible] refactoring.

  Oh, the refactoring.

  [inaudible] refactoring spaghetti code.

  The same thing the episode is about.

  I got a big jQuery jumbled mess, right? Well, I’ve done the same exact process with Backbone, Knockout, and Angular, and from Backbone to Angular. So, I’ve done it a few times. But certainly, Brandon’s put a lot more thought into codifying exactly what the process is. My experience is always just shotgun. You go and you take pieces and you just start overhauling them massively until they’re into the new framework. And I would say that as much as, as often as not, it’s a matter of, “Oh, we want to use a new framework because we want features and this thing is just a mess. We just don’t even want to touch it anymore.” And so, the refactoring is a sanity-saving exercise if not more, if nothing else.

  So, let me ask this about that. Have you been able to do this without tests? Because I literally can’t think of how it could be done. 

  Well, yeah. But I wouldn’t say it was effective. 

  I don’t want to be that guy. I’m not the testing advocate guy. 

  Right.

  And arguing over TDD, the Rails community all wanted to do that for a little while and it’s pretty much close to the last thing on the list I want to do other than actually do the jQuery refactor itself.

  Well, I find myself on a funny side of the fence because I am the testing advocate guy. So, I am a huge fan of TDD. But I’ve definitely been on places where I haven’t used testing even in refactorings and in plenty of places. And I think so many projects get refactored without tests. By far, the vast majority of refactoring goes, happens without tests. Across all computer science, I have no doubt in the confidence of that statement. [Chuckles]

  The vast majority of it happens without tests. 

  Okay. So, I should be careful then about saying that personally, I don’t see how it’s done. I understand that it is done. But the test coming to your aide is one of the most wonderful feelings.

  I think you should be confident to say that if you do it without tests, you’re not smart. But whether it can or can’t be done is different.

  [Chuckles] I can confidently say you’re probably going to have a bad time.

  Right, right.

  Prove it, Joe. Tweet it. Proof that you believe it. [Laughter]

  What do you want me to tweet? I’m going to do it right now. 

  Do it. Prove to us that you believe it that much.

  What do you want me to tweet?

  Just whatever.

  Just whatever. [Laughter]

  Asinine comment he’d like to tweet

  [Inaudible] the best [inaudible] tweets. [Laughter]

  What did you say, Jamison?

  Tweet Jamison is the best and that will prove it to me that you believe what you just said.

  I dare you, Joe.

  [Chuckles]

  And as I go through these and call these steps, I want to be careful about making it sound like this is a codification. It’s more like pattern recognition. Like, “Hey, I’ve done this three or four times. And I’m noticing that each time I do it, it feels like I’m doing stuff in this order.” And so, I worry that… recipes get written because people cook a certain way or write their code a certain way. And then people take those recipes and go, “Okay, these are facts.” Well, no. This was a person’s experience. And so…

  Yeah, but I think you’re, aren’t you missing out on something there? And that is for those who aren’t master chefs, what you need is a recipe. And then moving from, “I’m just following footprints,” somebody else’s footsteps and thinking that this is okay to, “Becoming the master chef and inventing on my own,” means I follow somebody’s footprints for a while and I started seeing things that the original person either didn’t see or just never showed me. And so, now I’m off on my own. And for all the other people that never get to that point who are just following in the steps, they’re still moving likely in a better place and in a better direction and a better place than they would have done without your steps, so without your codification. 

So, for you to say, “This is a bad thing, for me to talk about this stuff and people to just blindly follow it,” I kind of disagree with that. If you’re blindly following it, you’re probably the type of person that just doesn’t care enough about that particular thing to invest otherwise and you’d rather have somebody tell you, “Just do it this way and this is a good way,” and then accept that and go on with it. And for those who really care a lot, they’ll come up with their own thing as they follow you along.

  Right. We don’t need a repeat of the Node community.

  Well, so the other thing is if you’ve read ‘Pragmatic Thinking and Learning’ by Andy Hunt, he talks about the different levels that people go through. And one of the things he talks about is the beginners. They basically do follow a recipe.

  Right.

  And that’s how they gain experience, because they get in there, they bang against it, and they figure out how it works. And yeah, and then as they level up they figure out, “Okay, well this doesn’t work under these circumstances,” or, “I’m a fan of this other way of doing this particular part of the process.”

  Right. There’s a really cool, Stanford Online is doing a class called ‘Math versus Mathematics’. And in their little thing they say people who took high school math didn’t learn Algebra, or they didn’t pass Algebra. They passed Direction Following 101. [Laughter]

  Interesting.

  That is my math knowledge right there.

  Right.

  I know how to do what the textbook says.

  Which is misleading to one extent, and that is if you learn to follow directions first and then you learn the underlying principles and stuff, and the few teachers that really can get people to just understand the underlying principles right from the beginning, those people are magic. Most of us, we’re following directions for a while and then we start, for the subjects we care about, we start to adapt them for our own purposes and learn mastery.

  I think that’s incredibly, incredibly well put. A great point. So then, without issuing a full retraction, I can say that my basic hope is that by laying this stuff out, people can see that there’s a path. This is one possible path you can walk. And if you were to walk this path, it is likely that you’ll  be more likely to find success in taking a bunch of garbage code that, whether you wrote it or somebody else wrote it, and walk out the other side feeling relatively confident about your ability to manage and scale and add features to a codebase. And I think every developer’s had that experience. That’s why in Katrina Owen’s talk that she gave a few years ago, that refactoring is very therapeutic to walk away from something and know that it’s a little easier to use than it was before, that’s really nice. 

And so, giving people a set of tools, whether or not they’re perfect, and that’s the other thing, is if you’re willing to put this, a recipe, out there, and that’s what open source is all about. You put a recipe out there and say, “Hey, here’s what I think the right thing to do is,” and let people argue with you about it, because there’s probably something to learn about what somebody else’s experience is in it. And so, I think really, publishing this stuff and giving the conference talk was my way of saying, “Hey, this is something that we have locked up in our vault. It’s a pattern that we use to refactor stuff.” It may not be perfect, but it works for us. We will actually be better at this if we publish this out into the world and let people come poke holes in it. So, yay open source. So, no offense, SWIFT.

  But I think I’m going to be sticking around the OSS community for some time.

  Well put, well put. 

  Alright, nerds.

  So Brandon, have you done refactoring to any other JS frameworks or just Ember?

  So, I’ve done refactoring to just plain JavaScript objects before. But I don’t claim to be the world’s greatest JavaScript developer, so I can’t vouch for the quality of code that came out of it. So, pretty much Ember is my first experience with JS frameworks. And I’m a framework guy. And so, it appealed to me in that way. But I can say we have now taken a Backbone app built from scratch a Backbone app. No actually, we’ve actually refactored a Backbone application but we did it more wholesale, because there was a Backbone application that had very little code in that didn’t really meet at all the business’s, there’s basically a proof of concept. 

So, I can’t really say that I have. I’ve built things in other frameworks, but I’ve never really applied this pattern. But what I can say is I’m pretty confident that these patterns, and so, I hope that people that are fans of Angular or fans of another framework are looking at the patterns, are able to look at these higher level patterns of the first thing you do is extract the code in a shell, in a jail that emits itself. And then start pulling the code out of it. And if you can, use models to represent as much of that code as possible, abstract away talking to the DOM. Angular and Ember are really good at getting you out of the DOM. I think Backbone, bless Backbone for being…

  [Laughs]

  The first to do this. But Backbone talks a lot of talk about getting the truth out of the DOM and I don’t think that that’s accurate. My experience with Backbone is it’s very difficult to get your truth out of the DOM. And so, Angular and Ember in my experience are much more similar. But then finding the states, then performing more clean-up and having more than one component collaborate. So, I think in Angular that would be like, man, I’m so terrified to use this word wrong, am I using transclusion wrong if I say transclusion does it? Like when you need multiple Angular directives collaborating?

  They might need to transclude. 

  Okay. 

[Laughter] 

  I’m totally using this wrong.

  I think that was the nice way of saying you used it wrong. 

  I don’t know either.

  Transclude is like a decorator, right?

  Is not transclusion what we conventionally call decoration?

  Okay.

  Pretty much.

  But you can use multiple Angular directives in concert together against a shared data set. Is that fair to say?

  Yes.

  Okay. So, I believe this pattern would really hold strongly for people primarily in Ember and Angular, and Backbone if people are willing to do a lot more of the legwork themselves of setting up data binding and stuff like that. And so, yeah, these are very applicable patterns. 

And then finally, the last bit is just anything that you were doing in the view you lose stuff along the way of. And using jQuery to show and hide things, I really prefer using CSS for that because CSS can just have a state that is represented. And so, you have these stateful things. Sometimes in certain states, things are visible. Sometimes they’re invisible. You can use CSS animations, which there’s a lot of arguing out there in the world right now about whether those are more performant than JavaScript or not. But I tend to really, I really like them, even if they’re a little more awkward to write than if you were just say, “Hey, show me or hide me.” Now you have to go into the CSS and say, “In this state, it’s shown. In this state, it’s hidden,” and then use animations.

  I would say that what you’re talking about is also probably fairly possible with a Knockout and/or, Knockout/Durandal and possible even React, right?

  Yeah, I would say I haven’t used React very much. But I’ve seen a lot of work from Ryan Florence lately trying to basically glue a router onto React, which is a big missing piece. And honestly, for this pattern, I’m not really talking about a router. And so, React is probably a good fit. Like I said, my preference, my personal preference is for Ember because I really like the model layer. I’m React-curious at this point. And I like a lot of what I’m seeing in the JS community. 

I feel like we’re at the tail-end of this experimentation phase and I really love that people are like, “Wait, wait, wait. I have one more idea,” and they’re trying to get their homework in before everybody coalesces around a single idea or model. So, you have Pete Hunt coming in with React, which is like, “Hey, hey, hey, wait, wait, wait, I have this really cool idea about how to do virtual DOM stuff,” and it’s incredibly exciting. That’s exciting work and I think it’s affecting how Ember is doing its job. 

  So, it sounds to me though like what you’re saying, and I know that there’s more steps and here I’m going to try to oversimplify maybe a little bit of your process and that is you’re isolating the code but then you’re also identifying states and hooking up binding to those states, right? 

  Yeah.

  That’s a very key piece in what you’re doing.

  Exactly.

  So, anything basically but Backbone, at least plain Backbone, has that opportunity. Well, all the main ones have, all the ones we’ve talked about have binding. So, all of those would fit. Backbone would if you brought in a binding library.

  Yup. Yeah, absolutely. There are probably people who still prefer working in Backbone. I don’t know if any of them are in this podcast. 

  They’re not.

  But when I use another framework and I come back to Backbone, I get mad, because anytime something does something for you automatically, it’s like rolling your windows down with an old, like why we call it rolling windows down. 

  With the crank?

  Yeah. It’s like cranking your windows down, or even turning your car on with the crank. There are things that just happen for you automatically that you get mad that that convenience has been removed from you. And so, I don’t know that there’s a lot in Backbone that I can vouch for anymore.

  So, this segues into something that I wanted to talk about in this episode, and that is have you read the article, ‘No more JS frameworks’ by Joe Gregorio?

  Man, I want to say I read it, but it didn’t leave enough of an impression for me to be able to comment on it intelligently. But I can pull it up and argue with you guys about it. 

  [Laughs]

  Well, he just basically makes this thing and says, “Look, the frameworks that we’re building in JS need to start going away because between everything that’s coming out with ES 6, object observe, and then what’s coming with web components, what we really need is just shivs and then just good JavaScript,” or shims sorry, not shivs. 

  [Laughs]

  Shank shivs dude, yeah.

  I think you’re [going to need] shanks.

  We need shanks. 

  [Laughs]

  I could use a few shanks now and then.

  Sharpen the toothbrush, eh? [Laughter]

  That’s the gist of it. I’m probably oversimplifying it. If he listens to this, he’s probably going to get angry at my oversimplification of his article. But that’s kind of it. And he just says, “Angular, Ember, Backbone, all this is all garbage. We should just be writing.” And he makes some good points. That one, you have to learn the framework. And you’re going to have to learn HTML, CSS, and JavaScript anyway. So now, you’re just tacking on a framework. And they don’t hide the complexities of those three. It bleeds through all the time. So now, you've just got four things to learn instead of three, which I agree with that part of it. He’s right. You can’t just learn the framework. You have to learn the other things, too. But he just then says, “We don’t need this. What we need is shims, a good ES 6 transpilation, and then just using what’s in ES 6 and web components by themselves and just writing good JavaScript.” That’s what he says. So, discuss.

  No.

  [Chuckles]

  That’s not what you need. So, Backbone was great, right? It served a huge purpose. And everyone was able to build their own custom framework. But unfortunately, you had to build your own custom framework. And everyone’s Backbone implementation looked different than everyone else’s back when implementation… and when you’d walk into someone else’s code it looked completely different than anyone else’s because it didn’t come with anything besides some basic layering stuff. And so, you had to get all of your own other pieces. And everyone got different other pieces to go onto it. And a framework normalizes out the Frankenstein of the framework building. And so, I disagree with the statement that frameworks need to go away, even with all the beautifulness of ES 6. I still think frameworks have an important part in JavaScript apps.

  The other thing is that every language is in flux. JavaScript’s in flux. That’s why we have ES 6. It’s getting better. Ruby’s getting better. Objective C is going away. So, all of this stuff is changing. And as the languages get better, all that really does is enable people to do more stuff. But the way that they do more stuff is they contribute to libraries that abstract away the ugly pieces and make some of this stuff easier to deal with. And so, even though you can’t completely abstract away things like the DOM, HTML, CSS, JavaScript, any of the other stuff, you can’t completely abstract away some of the other pieces and the impedance mismatches between them, we need these libraries and these frameworks to make the pieces that we can easy or automatic. It just makes programming so much nicer. 

  So, I don’t think that you need a framework for 100% of projects. But if you’re building something that is like something that someone else has built…

  I think it will save you time in the long run. I think the key phrase you said, Chuck, well the key word is abstraction. And if you don’t use a framework, you’re depending on the platform itself to provide your abstractions or your own brain to provide them. The platform provides some abstractions, but they’re generally pretty low level. And your brain is probably bad. You might come up with one or two good ones for every ten awful ones.

  If you’re not using a framework, then you’re creating a framework. 

  Exactly.

  You’re doing one of the two. Every time I start with a little tiny, tiny thing, I’m like, “I’m just going to make this one little demo that does this one,” and then no, because then I end up having to rewrite that in a framework because it ends up going into production. So, I might as well just start out with if I’m doing a stupid little dinky one-page form to show off, I might as well just git clone my Angular template that I’ve already got, and then I take less time to write the little form logic to show to the client, and now since I’m going to be building it for them anyway, it’s at the right place to start. 

  That’s actually a blog post that Ryan Florence wrote. I’m not saying you, I mean you can come up with the same idea separately.

  Yeah.

  But he wrote a blog post called ‘You Can’t Not Have A Framework’ that talks about that same idea. 

[JOE]:  Beautiful.

  I think that was on the tip of a lot of people’s tongues. And I’m glad he wrote it. He wrote it just much more succinctly than I would have. I’m given to loquacity and using big five-dollar words when a small one will do.

  Loquacity, dude.

  Yup, yup, I went there.

  Now I think I will hunt you down.

  [Inaudible] what point in your SAT?

  I got a 450. I guess I’m going to express a strong opinion on this, and I don’t do that very often because I don’t…

  I’m going to call you out as a liar.

  [Chuckles] Okay. I’m going to express a strong opinion on this. I get an opportunity. I like running the consultancy because I get an opportunity to work in a lot of other people’s code. I feel like I’ve learned a lot from working in other people’s code. And my experience is that everybody sucks at making frameworks. It’s that everybody thinks they’re better. It’s weird. We all talk about impostor syndrome, but when it comes to frameworks we’re primarily on the other end of the DunningKruger spectrum where we think we’re better at this than we really are. I think most people generally for at least a while as a developer think that they’re better at making frameworks than they really are. Or often, like you said, we get lulled into this thing of before we do this three or four times we think, “Hey, this is just really small. I’ll just do this. It’s a one-off.” But we’re just not very good at building frameworks. And so, most of the bespoke custom frameworks, and when I say most, I mean 100%, of the bespoke custom frameworks I worked in tried to solve the same problem as a well-known, widely used framework much, much worse. And you wind up spending, things can take anywhere from two to ten times as long to accomplish in a lot of these bespoke frameworks. It’s been my experience. I’ve only been doing this for a couple of years. So, it’s possible, I reserve the right to be wrong about the 100% part. But my experience has not been good with custom frameworks. And so, I really like jumping in with a group of open source people, especially if I’m solving a shared set of problems.

  Well then, I can just hand it over to you. 

  Yeah.

  I need help on it. Well, you know the framework. I know the framework. Go, go, go. 

  Actually, this week I read an article. It was called ‘Everyone should build a framework’. And there was this cynicism in its title that I didn’t catch as I read the title. But I got it when I read the article. And it was, we all complain about the framework sucks this, the framework sucks that, and it’s not flexible here and there are problems there and performance that. And it says everyone should build their own framework. They should get so mad at their framework they should build their own so that when they get a third of the way through it, they can realize, “Oh man, this sucks. This is really hard work and it’s not easy to do.” 

And I don’t know how you would approach, even with the most robust libraries out there, even if web components actually worked today and all the other things were a thing that you could count on, I don’t know how you would structure your code without some sort of framework giving you some opinions to follow. And I don’t know how your code would scale. And when I say scale, I don’t mean performance. I mean across a team of 30 or 40 developers. If everyone could just potshot their own conventions onto it and had no restrictions on it, I don’t think your code would scale across the teams. And if it somehow did, I don’t think it would be maintainable long-term. So, frameworks give you more than simply performance and some glue in your [inaudible] models.

They give you convention and sanity for long-term maintenance.

  Yeah. And there are maybe people who disagree with that. But I agree very strongly with that. I’ve had very good luck and good experiences. And yes, I do spend a lot of my time fighting with my framework. It’s not a mature ecosystem yet. I spend less time fighting frameworks in the serverside land where the frameworks are 5 and 10, 15 years old, rather than JavaScript land where the frameworks are 2 years old or less. 

  True enough. 

  Yeah, but I think that’s a feature of frameworks in general is that when you start out with it, you tend to do things the canonical way. You go read the Ember guides. And so, you do things the way they tell you to do it in the Ember guides. And then eventually, you get to the point where you need something that’s a little bit different. It’s not exactly the way the Ember guides do it. And so, you wind up struggling against the framework a little bit because it’s possible, but it’s not friendly to that approach. And then you get to the point where you want to do something that’s totally outside the framework. And so, then you have to wrench it around, bend the bars back a little bit, so that you can get the room to maneuver to do what you need to do. I think everybody runs into that once you’ve been dealing with the framework long enough and you’re comfortable with the way that it handles things.

  I just wanted to say, maybe part of the productivity thing is with framework maturity. But it’s also, and if your framework only existed for two years, you can only have two years of experience with it. So, if you’ve been using Rails for ten years and this client-side framework for two years, that’s eight years’ experience difference that you have, not just that the framework has. 

  And that goes back to my question earlier of how people have four years of experience with Angular when it’s only existed for two years.

  This is a long troll. It’s like the fourth episode in a row.

  Yeah, and then two years of…

  AJ…

  I’ve got two years of experience with SWIFT so far. 

  AJ, you got to let the troll go, bro.

  It’s two years of man hours of experience with it, because I read the book five times.

  [Chuckles]

  That’s right. Joe has been in SWIFT ground hog day for the last…

  Jamison’s got four years [inaudible].

  I have…

  Are you up to four years, Jamison?

  I don’t want to say anything about it.

  Wow. 

  I got so grumpy at all the SWIFT jokes yesterday.

  It’s the same joke, right? There’s only one SWIFT joke…

  800 of them.

  Just told every way. 

  800 million of them.

  Now, there are 800 million and 2 of them because of this podcast.

  I think there’s been at least 16 this episode and I haven’t heard them yet, so I’m enjoying still. 

  [Laughs] It’s just the one joke.

  I should start an iOS podcast and talk about that. 

  I think the developers are glad to have a second joke after the two problems one. So, I thought it was refreshing.

  There we go.

  Yeah.

  Well, let’s go ahead and do the picks then. Aaron, do you want to start us with picks?

  Yeah. I’m going to do one pick for this. I apologize, but I’ve only got one. So, when I was a kid I read a book called ‘Hatchet’ by Gary Paulsen. I don’t know if any of you guys read it. Yay, nay?

  Loved it.

  Yup.

  When I was a kid. 

  I did. I don’t remember anything from it.

  Okay, so a lot of folks, they loved it. And I loved it. It was awesome. And I found a book. The synopsis was like, “Oh, this is a ‘Hatchet’ for adults.” It’s called ‘The Martian’. And the synopsis is astronauts on Mars, mission fails, they got to escape, and one guy gets left behind. And he’s an engineer luckily. And he has to figure out how to survive. And so, this is really ‘Hatchet’ all over again, except for instead of being in the woods in Canada, you’re on a different planet. And it was really, really, really interesting. It’s like a logbook of his stay on the planet. And anyway, super, super good book. So, I recommend it to anyone who’s looking for a good read. 

  And when you say engineer, you mean mechanical engineer, because if he was a software engineer, he would just try and make a webpage and we would die. 

  No, he was an Ember developer. And so, he was going to be able to… [Laughter]

  He was going to make it off of Mars based on that. It was pretty awesome. [Laughter]

  That sounds awesome.

  Yeah.

  Oh. Awesome. Jamison, what are your picks?

  I have two picks. One is a talk from JSConf EU 2012 called ‘JavaScript is the new Punk Rock’. It’s actually about the web audio API. And it’s the kind of talk that I would love because it couldn’t be delivered as a blog post. It’s a lot of live performance and live demos and interacting with the audience and stuff. And I also learned a little bit about the web audio API. So, that was great.

And the other one is LittleRiakBook.com. Somebody tweeted it out. And I’ve always had a passing interest in Riak, because it sounds awful and I want to understand why people use it. [Chuckles]

  And this is a good introduction to Riak and the problems it tries to solve. So, those are my two picks.

  Nice.

  Alright, AJ. What are your picks?

  Okay. So, first off, I think the first thing I need to pick is the Amazon horse mask. And the reason for that is because emoticons are dead and sarcasm is a lost art. So, the horse mask is the only way to let people know that you’re kidding if you’re on Twitter. [Laughter]

  So, for those of you that don’t know, I started this big flame war and I didn’t even realize it was a flame war until the end. It’s like, “What the hell, man?” and then I was like, “Whoa, that was strong. Where did that come from?” And then I realized that I thought we were joking and it turns out… But now, I’ve got a horse profile on Twitter. You can follow me. If it’s tweeted there, you know that whether or not I actually believe it, you’re not going to take offense to it anymore. [Chuckles]

  And oh, there are so many things I could pick. We’ve talked enough about Mario Kart so I’ll let that one lie as it is. And I think I’ll save some of my other stuff for next time. But I’m going to pick ChanceJS. ChanceJS is awesome because, and I know everybody else has known this for forever but I just found out about it so excuse me. But it’s awesome because you give it a seed and it will give you random data based on that seed. And it has lots of things like phone numbers and gender and titles like Mr. and Mrs., Dr., names. It’s got all sorts of just fun little shortcuts in there that you need. Bu when you’re doing your testing and you want to test on some random data, you can get the same random data every time. So, your mocking and your testing will go a lot smoother because you’re getting the same fake password every time because you base it around a seed. 

And so, there’s this other site that I picked once before that’s RandomUser.me. And I was using and it went down and that made me sad. I guess I shouldn’t have been using it the way that I was. But well, I was. So, I had it generating some random profiles on a test site. And it went down for a day or two. And so, I didn’t have my random users. And so, I used ChanceJS to build a random user service. And so that, it just was a happy story and I was super happy because it was random but it was only, it was testable random. Yes. Huzzah. 

  Alright. Joe, what are your picks?

  Alright. I’m going to pick three things. My first pick is going to be the, real recently Pluralsight launched a course on Ember of all things. And so, it just happens to serendipitously coincide with this podcast. So, I’m going to pick that course. If you’re looking to learn Ember, that’s a great way to do it. 

I’m also going to pick the movie Maleficent. Went and took my whole entire family. We had 12 people, extended family and friends, went to see Maleficent on Saturday and it was awesome. I absolutely loved it. Great movie, totally worth your time. 

And then, last I’m going to pick the board game Lords of Vegas. I’m not sure if I’ve picked this in the past. I played it at a board game convention a few months ago and had an absolute blast because it actually involves rolling lots of dice. So, it’s a little bit like playing in Vegas except you’re actually playing a regular old board game like Settlers of Catan or something like that. But you just have a lot of dice rolling and they really incorporate the theme of what Vegas is like into this game where you try to build casinos on the strip and make more money and get a bigger monopoly than your competitors. And it’s a super fun game. And I really enjoyed it. And there’s already an expansion pack out for it. So, that would be my third pick, is Lords of Vegas.

  That sounds like so much fun. I’ve got a couple of picks here. The first one is it’s a library that I’ve been playing with for a client of mine. It’s called dc.js and it incorporates D3 cross-filter which is something that’s written by Square and a couple of other things. It’s a charting library. And all the charts are, it connects them. So, you select something on one of the charts and it shows you that segment of the data on all the other charts. It’s really awesome. And it took me a little bit of work to figure out how to get everything to plug together. But I’ve just been insanely happy with it. And I’m probably going to use it on other projects. 

The second one is a book I’ve been reading, ‘Strong Fathers, Strong Daughters’. So, if you’re a dad and you have daughters, there’s just so much good stuff in there. It talks about some of the scary stuff out there with the influences that your daughter has to deal with and how you as a dad can be an influence to help your daughter make wise decisions. I’ve really been enjoying the book. 

And then I want to pick the Ember Guides just because they’re a handy way to pick up some of the Ember stuff.

And finally, there’s a dice game. Joe’s pick made me think of this. It’s called Left Right Center. And it’s a really simple game. We were playing with my kids. Basically, you roll the dice and then you have tiles or chips. And you put the chips in the middle or right or left. And whoever winds up with chips at the end winds. So, it’s a simple game but it’s a lot of fun. And we’ve been enjoying that. So, I’ll put a link in the show notes for that as well. Brandon, what are your picks?

  Okay. So quickly, my first pick would be, we talked a little bit about router.js. I think people generally recognize Ember’s router as best in class, even though, if I may continue to emphasize, Alex Matchneer is literally the worst human being on the planet. 

  It’s a great, great routing library. And it resolves promises for you. It does a lot of great stuff. So, that’s my first pick. Please check it out. If you’re doing stuff that doesn’t have a router built into it or does routing that doesn’t meet your needs. We’ve had a lot of fun integrating that into Backbone and just not as much fun in the rest of Backbone.

Second pick is Philips hue. We had a big meetup here recently. And my partner Charles gave a talk where he did a bunch of cool visualizations using data binding and then bound it between servers with web sockets and then bound it to the Philips hue. It was a color picker that had a bunch of color visualizations and then had lamps all around the office changing their color based on what he was doing in Ember. And it was really fun, really dorky. And I just want to say it’s a great way to exercise the power of $200 to make light bulbs change color. So, if you find yourself with that specific set of capabilities and needs, $200 can turn into cool light bulbs.

A Link Between Worlds has completely consumed my thoughts. I haven’t played video games in, well let’s see. I have a five-year-old so, in five years. And I bought a 3DS recently and Zelda: Link Between Worlds is, I don’t know if it’s just because I’ve been Stockholm Syndrome after so much time in iOS gaming, causal gaming land, but people are saying it’s the best Zelda in many years. And I think it was, I just finished the game the other day and just was like, “Wow. Nintendo. Well done. Thank you.” It was a beautiful experience. So, highly recommend that as well. And those are mine.

  Very cool. Well, if people want to find you, if they want to hire your consultancy to make their Backbone easier, where do they call you? [Laughs]

  Or if they, yeah, if they have an unruly cat, we just really will do anything. So, I’m tehviking on Twitter. The consultancy is at fronside.io. And check us out. We’re pretty good at this Ember stuff and we really like it. But mostly, seriously, if you have any cats that you just cannot, cannot tame, we’re ready to move into the catsulting space.

  Very nice. Alright, well I guess that’s it. We’ll wrap this up and we’ll catch you all next week.