132 JSJ MV Frameworks with Craig McKeachie

00:00
Download MP3

Chuck’s JavaScript Mobile Roundtable: November 5

Text “MobileJS” to 38470 or Visit JSPowerUp.com

02:13 - Craig McKeachie Introduction

03:24 - Chuck’s Announcements

05:07 - Supporting Yourself While Writing

07:26 - Learning Frameworks vs. Projects

  • Date Pickers

08:32 - Audience for Book

10:49 - Comparing Frameworks

Recommendations Chapter in Book

13:58 - Narrowing Down Frameworks

16:24 -  Choosing Framework Technology

19:13 - Differences Between Frameworks

24:14 - Questions About Choosing a Framework

36:30 - Problems/Edges with Frameworks

41:35 - Documentation Quality with Frameworks

43:39 - Writing the Book Today - Changes

Chuck’s JavaScript Mobile Roundtable: November 5

Text “MobileJS” to 38470 or Visit JSPowerUp.com

Transcript

CHUCK:  Alright, let’s make a podcast![This episode is sponsored by Frontend Masters. They have a terrific lineup of live courses you can attend either online or in person. They also have a terrific backlog of courses you can watch including JavaScript the Good Parts, Build Web Applications with Node.js, AngularJS In-Depth, and Advanced JavaScript. You can go check them out at FrontEndMasters.com.]**[This episode is sponsored by Codeship.io. Don’t you wish you could simply deploy your code every time your tests pass? Wouldn’t it be nice if it were tied into a nice continuous integration system? That’s Codeship. They run your code. If all your tests pass, they deploy your code automatically. For fuss-free continuous delivery, check them out at Codeship.io, continuous delivery made simple.]**[This episode is sponsored by Hired.com. Every week on Hired, they run an auction where over a thousand tech companies in San Francisco, New York, and L.A. bid on JavaScript developers, providing them with salary and equity upfront. The average JavaScript developer gets an average of 5 to 15 introductory offers and an average salary offer of $130,000 a year. Users can either accept an offer and go right into interviewing with the company or deny them without any continuing obligations. It’s totally free for users. And when you’re hired, they also give you a $2,000 signing bonus as a thank you for using them. But if you use the JavaScript Jabber link, you’ll get a $4,000 bonus instead. Finally, if you’re not looking for a job and know someone who is, you can refer them to Hired and get a $1,337 bonus if they accept a job. Go sign up at Hired.com/JavaScriptJabber.]**[This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.] **CHUCK:  Hey everybody and welcome to episode 132 of the JavaScript Jabber Show. This week on our panel, we have Jamison Dance. JAMISON:  Hello friends. CHUCK:  Joe Eames. JOE:  Hey acquaintances. JAMISON:  So formal. [Chuckles] JAMISON:  It takes a while to be Joe’s friend. DAVE:  It was honest. [Chuckles] CHUCK:  Dave Smith. DAVE:  Hello world. CHUCK:  I’m Charles Max Wood from DevChat.TV. And this week we have a special guest and that’s Craig McKeachie. CRAIG:  Yes. CHUCK:  Did I totally slaughter your name? CRAIG:  You did not. You said it perfectly. CHUCK:  Yay. Do you want to introduce yourself, Craig? CRAIG:  Sure. You know, I’m a web developer like everybody else. I like to say for at least 15 years so that I don’t age myself too much. Mostly I’ve been on the Microsoft .NET stack. I dabbled a little bit in Ruby, in particular when the ASP.NET MVC came around and copied it for all intents and purposes. A lot of that time I was a consultant. I worked for startups and bigger enterprises and so forth. But I’ve always been interested in writing and teaching. So, about a year ago I wrote a blogpost on choosing an MVC framework. And basically it went viral on the internet. It got about a thousand shares, hundreds of comments. And I decided at that point that I wanted to write a book on that and went crazy and quit my job and thought, “Oh, I can have this done in three months.” And seven or eight months later, I finished it. So… [Chuckles] DAVE:  Hey, that’s still really good time. Congratulations. CRAIG:  [Laughs] CHUCK:  No kidding. JOE:  Yeah. JAMISON:  Where were you working before this? CRAIG:  My last place of employment was Quantum Health. It’s a company. I live in Columbus, Ohio. It’s a growing company there, a rapidly growing company there. I was a consultant for different consulting companies there in town. CHUCK:  So really quickly, before we get started. I have two announcements. The first one is that we’ve partnered with JavaScript Now which is a job board. So, if you need to find a job, go check them out at JavaScriptNow.com. Also, if you’re going to list a job, you can go to JavaScriptNow.com and enter the coupon code JavaScript Jabber. And what you get is you get $40 off your listing. And the basic listing is $40. So, you essentially get it for free with the coupon, or you can do the hot jobs posting option which is $80 and you get that for $40 because you get $40 off. So, go check that out. The other announcement I have is that I am organizing a conference. It’s an online conference. The idea is that a lot of people can’t go to conferences because they can’t afford to travel or they can’t afford to take the time off. And so, if you are interested in a conference where you have to do neither of those things, my tagline is sort of “You can attend in your pajamas,” it’s going to be JSRemote Conference. And you can find it at JSRemoteConf.com. It’s going to be in the evening, three nights a week for two weeks. We’re going to have two hours of talks each night. And I’m also offering a users’ group option. So, if you want to get your won ticket and then watch it at home, that’s fine. If you don’t think you can make it all three nights to whatever venue your Users Group is going to put it on, then you can pick one up. Or if you’re a users’ Group organizer, then you can get the Users Group rate. And then you can host it somewhere where people can come and gather and watch it as part of your Users Group. So, if you’re interested in any of that, go ahead and check it out at JSRemoteConf.com. JAMISON:  So, I don’t know how to ask this delicately. Were you independently wealthy when you quit your job? CRAIG:  [Laughs] JAMISON:  How did you support yourself by writing a book for seven months? CRAIG:  You always ask the first question and you always ask the best ones. So, I have to say I’ve noticed that listening to the episodes. JAMISON:  [Laughs] CRAIG:  I’m a big fan of the show. But I would say I’m far from independently wealthy. I’ve sort of dabbled in entrepreneurial stuff for a few years. So, I think it was just time to make the leap. And as far as the financial stuff goes, I’ll just say my wife has a good job. And so, the only thing holding me back for years was really just making the leap. [Unintelligible] CHUCK:  That’s awesome. JAMISON:  You had kind of a cushion, I guess. CRAIG:  Yes, exactly. JAMISON:  Cool. CRAIG:  So, my startup is funded by my wife, yes. [Chuckles] JAMISON:  She is your venture capitalist. CRAIG:  That’s correct. DAVE:  So, the second question I have is why do financially independent people always say that they’re not financially independent? [Laughter] JAMISON:  Anyone can be financially independent if you’re willing to live at a certain standard of living. Well, not anyone. Employed programmers, I would say. CHUCK:  That’s it. I’m buying a nice tent. JAMISON:  Yeah. CRAIG:  I totally agree with that statement, yes. CHUCK:  So, before we get too far into this, you mentioned that you have a discount code for your book. And I’d like you to be able to share that for anyone who is interested in buying it. Do you want to just give that out real quick? CRAIG:  Sure. So, I set up a special page for JavaScript Jabber listeners. My blog’s at FunnyAnt.com. And I could talk about why that is in a second, but that’s Funny A-N-T [dot] com [slash] Jabber. If you go there, for about a month or so, I’ll leave up a 20% discount off the book if after we talk about it a little bit more you’re interested in it. Just at a high level, I mean obviously it’s about choosing a JavaScript framework. It’s sort of addressed to be an unbiased journalistic perspective on the frameworks and builds the same apps 37signals Basecamp type clone app. I didn’t build the whole thing, in case anybody [chuckles] wants to ask that question. But I did build a decent amount of functionality more than your average to-do app out there, in the book, in all three frameworks. But that’s the gist of it, yeah. CHUCK:  Well, you know the steps to building Basecamp, right? Step one, start working on it. Step two, invent Rails. Step three… CRAIG:  [Laughs] CHUCK:  I’m just kidding. DAVE:  Profit. [Laughter] CHUCK:  That’s right. CRAIG:  Profit, indeed. No, it just gave me, I find for my corporate and consulting experience, you spend a lot of time working on gathering requirements and hem hawing about how the screen is going to look, or that screen. And it gave me this well-defined set of requirements to build something against. And so, after a while of fiddling around different ideas I said, “I’m just going to do this because all I have to do is go back and look at the app again. And I have my answer as far as my requirements go.” CHUCK:  Yeah. JAMISON:  That’s a great idea. I find that when I’m trying to play with something and trying to invent a real world project for it, I spend more time on the real world project than learning the technology. If my goal is just to learn the tech, then that’s a bad thing. CRAIG:  Right. And it also forced me into corners of the framework that maybe I wouldn’t have before. Like for example, when you get to, given a to-do or you need to sign it a due date, maybe you wouldn’t put the datepicker in or make the datepicker behave in just the same way that it does in 37signals. But it’s a pretty reasonably complex [unintelligible], so that kind of threw me a couple of challenges which I liked in the process. CHUCK:  Interesting. JAMISON:  So, you already mentioned a little bit of the audience, or did I invent that in my head? Did you talk about the audience for the book yet? CRAIG:  Yeah, that’s a good question. I think I really wrote it for myself. It’s sort of scratching your own itch. I’m this guy working at Quantum Health and you get to a certain point in your career. And things keep changing and things keep changing. And you just learned Rails and ASP.NET MVC and now there’s this JavaScript revolution coming at you. And not only is it coming at you, but there’s three or four different frameworks and a language that you’re possibly not very good at coming at you. So, I wrote it for the person who feels like they can’t really keep up or having a hard time keeping up with all the evolution happening in JavaScript so rapidly and wondering, “Hey is this framework going to be around in another year? What are the real pros and cons of this?” Because there’s a whole lot of people giving you one side of the story, but not a whole lot of unbiased, at least attempting to be unbiased looks at the frameworks and saying, “This one’s got an awesome router but this one doesn’t have data binding,” that sort of thing. CHUCK:  I have to point out. You said three or four frameworks. And so, this must be an old book. [Chuckles] CRAIG:  Right, right. Now, why do you say that, Chuck? CHUCK:  Well, I’m starting a new framework. No, I’m just kidding. Next week I was going to say. [Laughter] CRAIG:  Oh exactly, right. [Unintelligible] DAVE:  You didn’t cover Chuck.js? CHUCK:  Oh yeah. CRAIG:  This was a legitimate problem. JAMISON:  I thought it was Woodchuck.js. CRAIG:  I’m sorry to talk over there. But this was a legitimate problem when I was writing the book, was where to draw the line. The book is focused on Backbone, AngularJS and Ember. And when I started, it included Durandal and it included CanJS, and maybe a few more that were on my periphery there that I was talking about. I do touch on Knockout a bit in the book as well. But it definitely is a [chuckles] challenging aspect of writing this book. In fact, I think if I just would have written something on Angular, I could have gone a little bit deeper. But I’m wondering if I could have finished in that three or four months working on it fulltime. But given, I think it took me quite a bit longer to try to grok all of them. JAMISON:  So, you brought up an interesting point. I feel like in a lot of ways, technology is a popular culture in that things get popular because of tastemakers and for social reasons, in some ways more than for purely, I don’t know the right word. I don’t know, more than which thing is absolutely the best. It’s which thing has a culture of influential people around it. And the idea of looking at these things in a purely technical stance instead of just saying, “Who do I follow on Twitter? What’s the framework they like the most?” is really interesting. Do you feel like you can come up with an answer about which one’s the best for your problems? Or is it just a comparison and you leave it up to the reader? CRAIG:  You know, I try in the last chapter to really, it’s called recommendations in the last chapter, and I try to really give some opinions. But I don’t go as far as to say, “You know what? Sorry you read the book, because it is Angular just like you thought.” JAMISON:  [Laughs] Spoiler. [Laughter] CRAIG:  I try to look at it more like it depends on what situation you’re in, really. You know, to be honest, I really had a hard time warming up to Backbone. But the more I pushed myself to, “Come on. There are a lot of people who really like this framework. What is it? Put yourself in their shoes. What are they seeing in this framework?” And I think I finally got it. So, I could make some good recommendations. For example, one thing I say about Backbone is, I hear a lot of people are like, “Well, I don’t know if my company will approve this JavaScript framework or that one. I don’t know which the official one is.” But as light as Backbone is, if your jQuery code is getting to be a bit of a mess, as small as the framework is and unobtrusive as it is, I would just, no one has any problem like including jQuery in their project. They don’t ask for corporate permission on that anymore. And I feel like if you’re in one of those places where you feel like you need to ask permission and you don’t have enough time to run it up the ladder, I would say it may not be up, and you’re in a brownfield legacy application, it may be a really good choice to just stick in Backbone and start improving, refactoring your jQuery code and making it a little more manageable. DAVE:  Backbone, stealth MVC. [Laughter] JOE:  I really agree with that statement just because Backbone itself, like you just said, it’s small. But it’s minimal as well. You can stick it in and it could just exist in a couple of little places on a couple of little pages. And nobody will know if they don’t go in there and look at that one specific spot, that Backbone’s in there. Not that you may be hiding it. But it just doesn’t have to affect a lot of things when you add it in. CRAIG:  Right. And I think no one really says that. No one says, “Hey these are different things.” Another way to say that same thing is Backbone has always called itself a library. Angular and Ember call themselves frameworks. And there’s a reason. One is this small thing that’s trying to help you out. And the others are more overarching things that are trying to be a framework for building a full application. JOE:  Right. JAMISON:  I wanted to go back to what you said about this being written for the developer that’s maybe feeling like there are too many options out there to consider all of them carefully and they would like someone to give a higher level overview of them. I feel like it’s not cool in some ways to not pick one and be part of the community in Ember or Angular. You know, you want to call yourself an Angular developer because then you’re part of a tribe. A lot of people identify with you and you have this shared identity and culture, not just shared technology. But I think there’s this silent majority of people that are maybe lagging behind the cutting edge a little bit because they’re building things that haven’t needed to be client-side MVC frameworks yet. So, I feel like there’s definitely an audience for this that isn’t addressed by some of the other blogposts that are, or tutorials out there that are like, “Check out this hot, new thing. It’s so cool and amazing.” CRAIG:  [Chuckles] Right. JAMISON:  And going more for novelty and cutting edge. CRAIG:  No, I totally agree with what you’re saying. JAMISON:  Yeah, yeah. CRAIG:  Sort of a related and ironic story is that I get done with the book. And the first thing, I send it out and I’m like, “What questions do people have?” “Here’s the book, what questions do you have?” when I’m trying to launch the book a few months ago. And the most common thing I got asked was, “What about React.js?” right? [Chuckles] CRAIG:  Because people want to fit that in. JAMISON:  Did you just sigh? [Laughter] CRAIG:  I wrote a blogpost called “What is React.js” [chuckles]. But yes, I did sigh deeply and so forth. So, it’s kind of… I just feel like you almost have to be super human to keep up with all this stuff. JAMISON:  You do. DAVE:  Oh yeah. Oh, that’s so true. JAMISON:  I’ve felt bad because I couldn’t keep up before. And I’ve had people tell me things like, “Oh, you can’t understand this?” in a disbelieving way. No, I can’t understand. I looked at it for five minutes. It’s one of the hundred other things I’m trying to look at. DAVE:  Yeah. CRAIG:  You know, in all the time I’ve been doing software development, I have never seen such a breakneck pace in new framework adoption and the birth and death of frameworks. Oh, it is just crazy how fast it happens in this community. JOE:  Yeah. DAVE:  Right. CHUCK:  Yeah. CRAIG:  I was just listening to the Famo.us episode from you guys, which is a very similar thing to React. And you can see it being the next thing. So, it just keeps going. It’s great that the innovation’s happening. But it is overwhelming for the people in the trenches. DAVE:  Yeah, so true. So, can I ask a question also about the book? Obviously it goes into the technology of each framework and talks a little bit about, “Here’s how you do this in this framework and that in this framework.” But when you’re choosing a framework, you’re not just using technology that you’ll use as a developer. You’re actually picking some other stuff that I call framework meta, like a community. You’re picking a community. You’re picking a culture of people who you’re going to be interacting with and getting help from. You’re picking a Stack Overflow section where basically, are your questions going to be answered or not? Do you go into that in the book and talk about those kinds of meta around each framework? CRAIG:  Definitely. In fact, even my first blogpost that I put out there, if you just go to Funny Ant and look around for choosing an MVC framework. There’s quite a bit of information around that and I’ve expanded upon that chapter from that article from the book. But a couple of things that really seem to hit home with people when I mention then was this idea of understanding, usually an open source project has a couple of people who are the leaders, and understanding what their background is. And honestly, the JavaScript Jabber podcast was a big help in me doing the research on some of these things. For example, maybe you guys know episodes off your head, but the early AngularJS episode with Igor and Miško. JOE:  Miško, yeah. CRAIG:  Yeah, exactly. That early episode was just great. They literally said, “Here are some Google guys,” and they came out and said, “Silverlight and WPF were inspirations for this framework,” right? JOE:  Mmhmm. CHUCK:  Alright, I give up on it now. [Laughter] CRAIG:  And I think some of that stuff is just very, very insightful. And then just knowing that they’re at Google, they’re in this high, it’s a big job environment and that Java guys love their dependency injection, their IoC containers and so forth like Guice. And they mentioned Guice as being one of the big influencers on your show. Just stuff like that where it’s, “Hey where is this coming from?” The same thing goes for Ember, with the big influence from the Rails community, from Yehuda Katz and so forth. You guys had some great episodes where [chuckles] in particular you’ve mentioned it I think on your recap episode where, I’m sorry, Yehuda Katz and Jeremy Ashkenas were on the same episode going back and forth about the frameworks. I believe it’s the Backbone episode, actually. But really insightful into where they’re coming from, what they believe in, how opinionated or un-opinionated. Do they believe in convention over configuration? Are IoC containers important to them? Do they like declarative programming like WPF or Flex or Silverlight as Angular does? Things like that, quite insightful. I’m kind of running through it a little fast there, but there are definitely aspects of that in the book. We could talk a little bit more about that if you want. CHUCK:  The thing that I’m really curious about and I think the thing that people ask is what does differentiate it? As far as when I go in on my day to day stuff, what am I going to notice when I start using one framework over another? CRAIG:  I think it depends on what your background is. For example, if you’re a Rails guy, you’re probably going to really warm up to Ember. This is something that’s kind of obvious and out there, but the APIs look very familiar to Rails APIs. If you’re a WPF, Silverlight, or Flex person who’s been left behind by the fact, or even a Flash developer who’s been used to more declarative programming, you’re going to warm up to the Angulars of the world a little bit more, perhaps the Embers, stuff like that. CHUCK:  I mean, there are all kinds of different ways that they approach problems, too. Do you find that one framework is necessarily better than another at a particular problem? CRAIG:  So, yes. I think there are cases I’ve come up with. For example, let’s say you’ve got a heavy investment in jQuery UI plugins and you really like your jQuery UI and your whole app is themed in jQuery UI, I think you’re going to have an easier time interoperating with those plugins either in the Ember world or especially easy time using Backbone. It kind of depends on which pieces you’re focused on. If you know the jQuery UI, I’m trying to think of another example of where a framework will stand out. So, let’s say your UI is very complex and compositional. In other words, you have a lot of widgets on the page, sidebars, headers, and they need to intercommunicate with things. One thing that’s talked about a little bit but not a ton is that with AngularJS, basically the out of the box router is not in the box anymore. It was taken out as of 1.1.6 of the framework. Most people say 1.2 of the framework. And most people in the real world use the AngularUI router when they’re building their Angular apps because it allows them to, the story that Ember likes to tell because it’s a weakness of Angular is their router story and how good their URLs are. And something that goes with that is they give the example all the time of you have a list of blogposts. And when you click on one of them, you go to the detail but the list is still on the page. Maybe the list is on the left and the detail is on the right. I think this is their basic tutorial. And then you go to edit a blogpost. And you’re in yet another third state. In order for you to keep the code that builds the list reusable across three views, the initial one that just shows the list, the second one that shows the detail, and the third one that replaces the detail with the edit, you’d like to just keep that list code in one place. Well, with Angular out of the box, without the UI router, this is not possible, which is why, well I won’t say it’s not possible. You could use ng-includes. You know, I try to stay away from third party things that sort of un-level the playing field between the frameworks. So, what I found myself doing in something more complicated like the Basecamp example where there’s nested hierarchies within hierarchies and you really want to component-ize pieces, is keeping one view and having multiple controllers off that same view. But if I refactor that using the AngularUI router, the code would come out to look a lot more like the Ember code. And it would use this compositional, this ability to compose views. I don’t know if I went, I’ve thought a lot about that thing and I kind of went fast through that. Is everybody following what I’m saying there? DAVE:  Yeah, yeah, totally. CHUCK:  Mmhmm. CRAIG:  So, that’s another example. Let me try to think of a different one. So, the router’s a big deal right? But to be fair, this is being addressed in Angular, right? DAVE:  Yeah, very much so. CRAIG:  They’ve brought Rob, somebody help me out here, from the Durandal project over. CHUCK:  Eisenberg. CRAIG:  Heisenberg, yeah. CHUCK:  We talked to him on… CRAIG:  I just said Heisenberg instead of Eisenberg. Is that pretty funny, guys? [Laughter] JAMISON:  That’s probably a compliment. JOE:  Yeah. CHUCK:  Yeah, we talked to him on Adventures in Angular. So, you can go and hear about some of that there. CRAIG:  Cool. And yeah, when you hear him talk, he’s rewritten the router there. And so, they’re recognizing what their weaknesses are. I guess another common one, it’s an obvious one, but if you’re newer to the frameworks is the whole testability story. So, Tom Dale who’s with Yehuda is one of the big public figures for the Ember project. And people have asked him, “Hey, say something nice about Angular,” or whatever, “What do you admire about Angular?” It’s their testability story, and the dependency injection. And I think that’s why a lot of people warm up to the Angular world. It’s not quite as hard to approach as Ember as well. But it is interesting to me that Ember is a very strong framework, how it is. At least [unintelligible] challenged me in terms of just looking at raw popularity and community behind it, how it’s been struggling to keep up. DAVE:  As you were going through these frameworks, first of all I think it’s really cool that you did this, because I don’t know very many people who have built as close to a real world project as you have in three different frameworks, being able to do the same project. In fact, I don’t know if I know anyone who’s done that. So, I think it gives you a really cool perspective. And I wondered, as you’re going through this process, did you come up with a handful, maybe three or four different questions that we can ask as developers when trying to choose a framework? Or did it end up being more complicated than just saying, “Hey, if you answer these three questions you’ll choose the right thing”? CRAIG:  You know, that’s interesting. What I did come up with was a pro and con list. So, you could look at it saying, “Hey is this a deal breaker to me?” Also, in that last recommendations chapter, it’s been a while since I’ve looked at it to be honest. So, I should be able to do this off my head, but I’m trying to remember how I approached it. And I think it was one thing that’s helpful is this perspective of an evolution of these frameworks. And so, that’s one thing I like to go over, because I think it’s an eye-opener for people. And I actually, so I borrowed this from a guy, Brian Genisio who’s a consultant that I’ve met up with a few times nearby me in Michigan. So, long story short, the evolution in my mind kind of goes like this. So, first you had plain JavaScript. And then it became too hard to work with the DOM so everybody stopped, did very little JavaScript in their apps. Then DOM manipulation libraries came along, like MooTools, jQuery, script.aculo.us, all the competitors. And jQuery won that war. And people became less afraid about working with the DOM. And then the next evolution I feel like was people started doing more, since they were less afraid of working with the DOM, the apps became more and more complex. And as the apps became more and more complex, basically more and more complex from a JavaScript perspective. So, people started not just loading some data via AJAX one time on a page. They started interacting with the page on the client. And then all of a sudden, things started happening like the back button would break and things like that. And their code got to nested hierarchies of spaghetti with callbacks and so forth. So then, there was a point where Knockout came along. Angular at the same time. I’m unclear as to who was really the innovator, maybe one of you guys knows, in terms of data binding. So, people were writing a lot of boilerplate code. And this idea of an automatic binding between the view and the models so that you don’t spend all your time grabbing things by ids and setting properties on them and so forth, came along. And so, that was the next evolution, was this Knockout, early Angular phase. And then I feel like the next phase was the AngularJS and Ember where okay, so there are good libraries for data binding. There are good libraries for DOM manipulation. And there are good libraries, like there were good third-party libraries like History.js and Sammy.js for just handling routing. So, just to be clear, routing is basically the mapping of, it works just like a Rails router or an ASP.NET MVC router or whatever your MVC framework on the server corresponds to. It maps a URL or a route to some code, at its basic level. It can get as complicated as being a full state machine as it is with the AngularUI router and with Ember. But that was the first evolution. And so, people realized, “Hey, my back button’s breaking now that I’m doing more and more stuff with JavaScript. So, now I need some frameworks. I need more than just these independent libraries. I’d like something more of a cohesive story.” And that’s where AngularJS and Ember came along. And they give you, and the Backbones of the world, that give you a router and that give you data binding, with the exception of out of the box Backbone does not have data binding. And they give you routing, data binding, I’m trying to think through it here in my head, models, ability to bring your server-side model down to the client and have it be more like that domain or business model that you’re used to, or at least a view model. So, all that’s to say, I really like to look at things as an evolution. So, there was this first generation of frameworks. And I think Backbone’s in that. And that’s why it became so, so popular. And I think then we hit a second generation of frameworks with AngularJS and Ember. And so, it’s important to understand what you’re getting for these frameworks, because they did come about at different evolutions in the JavaScript world. And who knows what the next evolution is? Maybe it’s starting to be the Reacts and the Famo.us’s of the world. But I don’t know if that’s just a different animal, it’s a different kind of library that we need to build applications and we’ll need abstractions on top of those, like the Angulars of the world. CHUCK:  I think it’s interesting too, because that’s more or less the path that I’ve followed in my own career. I started writing HTML back when the web was pretty new. And just played with it and got to know it a little bit. And then moved on from there to jQuery and, “Oh my gosh. This is so nice,” right? Because it makes dealing with the DOM so much easier. And then I started to get into jQuery spaghetti land, where jQuery is super nice but I wind up doing contortions in order to get everything that I want in there. And I’ve got this big, long mess of things that happen on certain events and stuff like that. And then Backbone comes along. And gee, it’s real nice because I can organize all of my code in these very nice structures. And then now, I’m getting into AngularJS and seeing all of the cool stuff that it can do, and using pieces of it here and the entire framework there. And I think a lot of people have moved along that way. And so, yeah it’s very interesting to see that evolution in the world of JavaScript and have been able to ride along with it. CRAIG:  Right, and I think just understanding. So, if you’re on this, to answer the earlier question more directly now with that framework in mind, if you’re on this older legacy app that’s really quite brownfield or worse and you’ve got a lot of messy jQuery code in there, like I said at the top of the episode, it might be your path of least resistance to just get Backbone in there and start refactoring some stuff. If you’re on a new project, you really want to look hard at AngularJS or Ember. I don’t think you want to start a generation behind. I hate to say that. I’ll probably get some hate mail. But I think it is what it is, and just looking at general pros and cons. The other thing you really need to look at I think is your team. What kind of resources and background do you have? Do you have these JavaScript oh I shouldn’t say the word, ninjas? Or do you have these people who are really deep in JavaScript? Or do you have a bunch of Flex developers on your project that you need to utilize? Or do you have a bunch of Silverlight developers? Or do you have a bunch of Rails developers? In which case, you might be leaning towards the Ember way. So, looking at your resources or your team and how you might get them up to speed. And then you have to look at the backings of these projects and look at the communities and how strong they are, how easy it is to get an answer for a question. So, I kind of go into all this stuff. I think one bottom line thing that nobody’s really saying that much but needs to be said is I think I’ve heard Scott Hanselman perhaps hint at this at some point, is this question of, is there going to be a winner in this world? And is there going to be a winner like a jQuery winner where all other things, basically you end up rewriting with jQuery because it becomes so prominent? And I think that’s a real consideration for people when you’re looking at the future, is to think about whether it will be a world with Angular and Ember or whether Angular will entirely overshadow. And I don’t think so given the strength of the Rails community with Ember. But it’s a legitimate concern, because of the massive popularity of AngularJS. DAVE:  Yeah. I would go out on a limb to say that that is more of a concern in my opinion in this field than any other development area, specifically web development. Because if I’m using some framework for Windows desktop application development, there’s a good chance it will be supported for a long time. And I can work around problems in the future. But when a framework stops being updated because the developers have moved on to something, it’s only a matter of time before browsers leave it in the dust, right? It could start doing things that are no longer supported, especially in the very soon to arrive world of all evergreen browsers. CRAIG:  Right. And in that vein, you really have to look at Durandal or something, with Rob Eisenberg’s project. And he’s not really leaving that project behind. He’s managed to basically, for anybody who doesn’t know, he’s joined the Angular team as a consultant or contractor. And he’s able to spend some time keeping the Durandal framework sort of in sync. And I think it’s really there. You hear him talk. It’s really there to keep the Angular team honest. If all of a sudden they’re not taking his ideas which he thinks are important, into the Angular framework, and he puts them in Durandal and they become popular, it’s a nice litmus test of the community giving feedback that, “Hey, this was important to us or this wasn’t,” in that vein. But I’d be hard-pressed to start a new project with Durandal, I hate to say it, because of that. Because it feels like more knowing that he’s on the Angular team now, that it’s not, not going to be supported, but that it just doesn’t feel like as much of a first-class citizen. CHUCK:  Well, the other thing is that I think the tradeoffs in the different frameworks out there are more pronounced than maybe between jQuery and its competitors. And so, you wind up solving problems in much more varied ways. So, I honestly don’t see those frameworks going away just because nobody’s using them. I see them going away if they do because of what we’re talking about here, the project abandoned. CRAIG:  Right. I’m really hopeful that that’s the future, because I think it’s a healthier ecosystem with multiple competitors and there are people pushing each other. DAVE:  Yeah, totally agree. Look at the router for example. The Ember team said, “Oh, we got a better router.” And [chuckles] Angular basically said, “Okay, well we’ll throw ours out and make it pluggable.” And then poof, all these awesome routers started appearing, especially Mr. Eisenberg’s, you know? CRAIG:  Exactly, exactly. There are a lot of things to consider there. I could go through some general pros and cons, I think. I feel like I focused on the router, but there’s a lot of other stuff you could talk about. So, here’s at a high level, some of my pros and cons that I keep a mental list of for Angular and Ember. A lot of it’s redundant, but you get an idea, right? So, a pro of Angular as I’ve said is testing. I think another pro is productivity compared to something like Backbone, mostly because of the data binding. Their vision with Web Components, in other words directives, is pretty close to Web Components in their vision. So, they’re trying, at least making an effort, I don’t know how well it’s working, to foresee the future and work with the future of browsers. It’s a bit of an evolution from jQuery. So, you’re not writing any more jQuery code whereas in Backbone jQuery’s pretty in your face still. The one thing that I think a lot of people miss about Angular that makes it quite popular is how close to the metal it is. So, I have never felt, when I’m working with a framework, more like I’m just writing HTML, including Ember, than when I work with Angular. And I think that’s why a lot of people warm up to it, is that you just feel like you’re writing HTML. And I think that that’s an overlooked thing. JOE:  Interesting. AJ:  That’s my main reason that I like Angular, is to me it feels like an evolution of jQuery. To me, Angular doesn’t feel like a framework in the way that Ember does. To me, it seems like it’s just getting the DOM out of my way even better than before. CRAIG:  Definitely, definitely, I agree with that. CHUCK:  One thing that I’m a little curious about, and I don’t know how deeply you’ve delved into all of these, but I’ve talked to Angular developers and I’ve talked to Ember developers, in particular especially one friend of mine who was an Ember champion for a long time and then he’s recently been thinking about moving away from it. But it seems like as you get deeper and deeper and deeper into these frameworks, a lot of times what you wind up finding is the edges. So, you find the cases where the framework is now actively working against you because it’s not what it was intended to do or it was not how it was intended to work. And I don’t have specific examples of this, but I’m wondering. Have you talked to people who have run into this? And generally, which frameworks tend to hold you up first? CRAIG:  I see what you’re saying. You know for me, that’s a tough one. So, you’re saying, which ones do you hit those edges very, very quickly? Right? CHUCK:  Mmhmm. CRAIG:  I think it was a pretty even split between Angular and Ember for me on that. I don’t mean to just say that. But there were definitely edges in both of them where I felt like I was hitting the edges. I’ll give you some concrete examples. In Angular, I needed to set focus, so this is a very simple thing on its surface. But if the element on a page doesn’t exist when it’s first rendered or is hidden, it becomes a lot more challenging, and there’s a Stack Overflow post that’s quite popular about writing a service and a directive that communicate with each other to solve this problem and get focus set in this scenario. And I was definitely hitting the edge there where something that just felt like it should be so easy wasn’t. In Ember, it was different things. But I hit edges like that. If there was a framework I was more frustrated with, it was, I’ll be honest I started with Angular and I’m not sure that was such a good idea. I kind of wish I’d started with Backbone to give it more of a fair shake. Because like I said, it’s just more of an abstraction. So, you’re immediately more productive, which isn’t necessarily better. It’s just, it’s better in some use cases. But in others, you need that close to the metal feeling. So, I think it’s a lot easier to leak memory for example in Backbone than it is with these other frameworks. You can do it in any of them. But I felt like there was so little opinion, too. And I think I’m just a person who prefers an opinionated framework, so take this with a grain of salt. But it was difficult to go with the loosey-goosey-ness of Backbone because of that, I think. As far as hitting edges, the edge with Backbone, I think the worst one to me was that it looks at the whole world like it’s either a collection of items or individual items within that. But there’s no concept of hierarchy out of the box without using, there’s a relational, Backbone relational plugin. So, when working with something like 37signals, you have a project which has multiple lists inside of it which has multiple to-dos, it was challenging to make that work in this world that only sees things as lists and items, basically. Angular, I also ran into challenges with integrating jQuery control. So, this was a walk in the park in the Backbone world, integrating a calendar picker like I talked about before. Whereas in Angular, you have to basically at that point learn directives at a very low level to understand how to get that control to play well in the data binding framework of Angular, which is not a level 101 topic. [chuckles] DAVE:  Oh yeah. Yeah, that’s interesting. CRAIG:  It’s very complex. So, I guess I hit edges on all of them. It’s hard to say which one first. I gave Ember, by the time I was done I read the Ember documentation front the back for a day or two on top of what I had learned about it before. And then when I sat down to write the app it’s like I knew exactly where to go whenever I got into a problem. So, it probably went the smoothest of everything. But it was difficult at first to understand, if that makes sense. They have a lot of concepts. They literally say the controller, Yehuda Katz I’ve heard him say the controller is the presentation model, is the view model. So, here we have something named controller that is the presentation, the view model. And this is difficult for people who want to relate to something they’ve, frameworks they’ve worked with before on the server or whatever. This is difficult to relate back to, to get through your head that this thing called a controller really has these automatically copied or reference properties that make it into a presentation model for you. And then there’s this whole idea of a route and a router. And there’s this new concept of route. And I think it’s a more robust way of building apps. And I think it’s a more robust framework in this. But it’s very difficult to wrap your head around at first and get past that initial learning curve, at least I found. JAMISON:  So, you mentioned documentation briefly. Can you compare the quality and the availability of documentation among the frameworks? Because it’s a thing that doesn’t seem as important when you start out with it and it becomes more important the further you go. CRAIG:  Right. That’s a good question. And there is a section in the book that covers that. But at a high level, I’ll go over here, definitely. So, it’s funny because I had documentation as a con on the AngularJS list. Let’s start with that, because if you were digging around at Angular a year ago, you know that basically their documentation was a forum. It wasn’t very good. You would go to a page on a particular, particularly around the API, on a particular topic. And then you would have a ton of comments from people trying to reword the documentation to communicate what it was. Now, long story short, that’s gotten better. So, they’d totally redone the documentation. It’s a lot better now. I’d almost say it’s probably the best of the three frameworks, although Ember’s walkthroughs and tutorials and API documentation is really great. I think where they fall down is just since they were later to the game, and since they have a big community but smaller than Angular’s, if you go to try to find something on Stack Overflow, since they reworked some of their APIs, you basically run into old, outdated information quite frequently. And you don’t get, there’s just not as large a pool of people to quickly give you an answer is what I found in the Ember world. Even though that community’s big, that was my experience. So, it was like the documentation was awesome as far as what was there. But when you got to the edges and then you needed to look something up, it felt a little like a wasteland sometimes, like you couldn’t find it or you’d only find outdated information. That was challenging. At this point, this was three or four months ago. So, it’s always an evolving thing and hard to keep up on. But that’s it. DAVE:  So Craig, if you were going to write this book today, would you pick the same three frameworks? CRAIG:  That’s interesting. That’s a very good question. I think if I were going to write this book, I would not pick the same three frameworks, but I wouldn’t because I think they’re outdated. I would do it to future-proof, because I’d know that it would take me another six or eight months to write the book. So, by then I wouldn’t be trying to predict where the world would have gone. But as far as the pool of MVC frameworks that were there in the first place, I would pick the same ones. But I think there’s some interesting stuff going on. I’m still trying to entirely appreciate it with React and Famo.us and so forth, particularly realizing the world’s becoming a more and more mobile place. I think that I might consider at least having a section that addresses these not MVC type things, these lower level frameworks, because React doesn’t call itself an MVC framework. It says I am just the view, I believe it is, right? DAVE:  Yeah, that’s right. CRAIG:  We’re just the V in MVC. JAMISON:  Mmhmm. CRAIG:  So yeah, that’s interesting. I will say this. I’m doing a little bit of corporate training and definitely, there’s just like in every other spectrum, there’s a lot more AngularJS uptake in that space right now. But I think if I had to do it again, to answer the question a different way, I might consider just focusing on Angular just for my sanity, if that makes any sense. [Chuckles] CRAIG:  Or focusing on one framework, either Angular or Ember. You know, looking at them and saying, “I’m committed to this.” But I think that that would have been a little wiser in hindsight, let’s put it that way, because it’s hard to go deep into three different things. But I hope it’s valuable to the community as well, because I just don’t want to trust somebody’s blogpost about it. I really want to read opinions from both sides, the pros and cons, and decide for myself, for my particular project, what makes sense. JOE:  Right. DAVE:  Well, my final question is, will you please just tell me which one to use? [Laughter] CRAIG:  Tell me more about your project. [Chuckles] CHUCK:   Nice. CRAIG:  Is the answer, unfortunately. DAVE:  Yeah. JAMISON:  Oh, that’s not the fun answer though. DAVE:  It’s not. [Laughter] CHUCK:  Well, I’m a consultant. I’ll give you that answer. It depends. [Laughter] CHUCK:  Alright. Should we do some picks? Dave, what are your picks? DAVE:  Yes, I have some somewhat unorthodox picks today, because I spent the last week in Europe attending ng-europe, which was a great conference. And after that conference I went over to Amsterdam. And I would like to pick the entire city of Amsterdam. This is a wonderful city that I thoroughly enjoyed. I love to ride my bike to work. And in Amsterdam, I have never enjoyed riding my bike more than any other place in the world than in Amsterdam, the Netherlands. Totally pick the whole city. There are a million other reasons why I just absolutely loved it. And my second pick on the same vein is what the Dutch call, it’s a food, they call the stroopwafels, which I learned and maybe even pronounced right. It’s this crispy little waffle that’s like a sandwich. You’ll just have to google it. But it’s like these two little wafer waffles that are pressed together with the syrup between them. And they are so delicious that I would like to pick them. CRAIG:  Awesome. CHUCK:  Cool. Jamison, what are your picks? JAMISON:  It’s only one. I feel like it has to be the best pick ever because there’s been all this buildup to it. It’s not the best pick ever. It’s an okay pick. It’s called Heilmeier’s Catechism. And I don’t even, I have no earthly idea where I found this. Someone randomly linked me to it I think. But it’s basically a list of questions to ask yourself when you’re trying to do something hard, by this guy named George Heilmeier who is the CEO of some company that I’ve never heard of called Bellcore. I don’t know if that’s a big deal or not. Anyways, the questions are: What are you trying to do? Articulate your objectives using no jargon. How is it done today? What are the limits of the current practice? What’s new in your approach? Who cares if you’re successful? What difference will it make? What are the risks and the payoffs? How much will it cost? How long will it take? And how do you check for success halfway through and all the way through? And I like this idea of having a list of questions to check yourself against when you’re trying to do something difficult that you maybe haven’t done before and you’re not really sure how to do, or what the measures of success are. So, that’s my pick. CHUCK:  Nice. AJ, what are your picks? AJ:  So, I’ve got two of them. And they’re basically the same thing. So, there’s this guy. His name is Feross. And I met him while I was in San Francisco because my buddy I was there with, he knows him. But he has implemented BitTorrent in JavaScript. And so, it’s a little bit different because the way that the web RTC stuff has to work, he had to do some funny business. But he’s got this demo up. Unfortunately, it’s not super pretty or it doesn’t look really awesome right now. But it is really awesome. It’s instant.io. And you can just drag a file onto the site and then share a link with someone. And as many as you’re sharing a link with, it starts web torrenting. And it turns out that Popcorn Time, which now that Blu-rays have advanced and they have more anti-playable feature bug things with them… CHUCK:  DRM? AJ:  Yeah. CHUCK:  Encryptions? AJ:  Well, now they’ve started, on Blu-rays they’ve started putting fake playlists. CHUCK:  Ah. AJ:  So, there were ways to play a Blu-ray on a Mac before. And it would just read the playlist file and it would go through it. But the latest Blu-rays that I picked up from Redbox, I wasn’t able to play on my Mac because they have so many fake playlist files that to determine which one is the right one and put the command in so that it reads that one with the right seq-, I couldn’t figure it out. So, there’s this Popcorn Time which if you ever rent a movie from Redbox and discover that you can’t play it because it’s got so much crap on it, it’s actually built with Node-Webkit and WebTorrent which is what this guy at instant.io made. And it allows you to watch movies in a distributed fashion. And it’s as easy and as beautiful as Netflix. And much quicker download speeds and better quality movies in my experience. So, those are the two things that I think are awesome. CHUCK:  Awesome. Joe, what are your picks? JOE:  Alright. Hmm, I’ve got three picks. The first is a couple of talks that were given. The first one is by Pete Hunt where he gave a talk called ‘Be Predictable, Not Correct’ that he gave at Mountain West JS this last year. And he’s a big React guy. So, he talks a lot about React, but the topic of the talk itself is really more about some kind of fundamental computer science issues which I found to be very interesting. And he references another talk which I’ve watched before and I know has been picked on the show before. But I would like to pick it again because it’s one of those talks that I feel like everybody should watch. And it’s called ‘Simple Made Easy’. CHUCK:  Is that Rich Hickey? JOE:  Yeah, I believe so. DAVE:  Yeah, [unintelligible] JAMISON:  Yeah. JOE:  Yeah. Just a fantastic talk that really every developer should take time to watch. And my final pick is going to be an expansion for, it’s a card game called Mascarade, which I know I’ve picked the game here before. But the expansion just came out for it. I played it with some people a couple of days ago. Had a fantastic, awesome time. It’s a great expansion. In the Mascarade game, you basically have a card in front of you that identifies a personality or a persona. And each persona has different powers. Your whole goal is to try to get a certain amount of gold. And the person who gets to a certain amount of gold first wins. And you pass these masks around. The card represents a mask and you pass the masks around. And you don’t necessarily know who you are because your mask is turned face down. And so, it’s a combination of some luck, bluffing, and strategy. And it’s a great game, very easy to learn. It plays pretty quick usually. But lots of fun and this expansion has just been really cool because it adds another nine or twelve different masks, or personas you might call them. Great game, very fun, very cheap as well. Base game’s 20 bucks then the expansion’s 15. So, that’ll be my final pick. CHUCK:  Awesome. I’m going to just give one pick really quickly and that is a book I’ve been rereading. It’s called ‘Virtual Freedom’ by Chris Ducker. I think I’ve picked it on the show before. But it just talks about all of the different ways that you can outsource parts of your business so that you can focus on the core of things and do all of the things in life that you want to do like hang out with family and stuff like that. So, I’m going to pick that. I guess I should pick my awesome assistant as well. Mandy is super helpful, does a lot of stuff for the shows and a lot of stuff for me. And so, if you want to go hire, you can go to DevReps.com and check her out. DAVE:  Yay Mandy. CHUCK:  And those are my picks. Craig, what are your picks? CRAIG:  I’ve been waiting to do this one for a while. You guys had to pick them every week. See, I get to save up picks for a while. JAMISON:  [Laughs] CRAIG:  I just want to remind everybody first, if what we talked about was interesting to you, hits home to you, you feel like you want to find out more about the book, go to FunnyAnt.com/Jabber and I’ll have for a month or so, a 20% discount up there. If you’re not sure, there’s a sample chapter you can download. There’s a short mailing list where I send you about five or six emails that you can jump on that pops up in the bottom right corner, hopefully in an unobtrusive way. So, go check that out. As far as more fun picks here. So, I believe this has been picked on the show before. But ReadyPlayerOne.com by Ernest Cline, it’s a fiction book written. And the reason I had to pick this is because someone on the show, it might have been Derick Bailey, somebody like that had mentioned this before. It’s a great throwback to the 80s book. It has a lot of 80s pop culture references. But the funny thing I realized after Derick mentioned it to me and then someone at one of the JavaScript users’ groups informed me that I graduated in the same high school class as the author of this book, which is very popular among the tech crowd, the geek crowd, whatever. So, I had to pick that one. JAMISON:  So, by the transitive property of popularity, you are also very popular. CRAIG:  That makes me cool somehow, indirectly. DAVE:  Congratulations. CRAIG:  Yeah, [unintelligible]. No, but I really was enjoying the book. I’m about halfway through and I enjoy it. It’s a very good book. So, another pick was this kind of very funny site that I frequent. ProductHunt.com, which basically people up-vote everybody’s little app idea. And about a month ago I saw this PleaseHelpMeJaRule.com, which is a pretty hilarious site. You go to it and basically it asks you a couple, two questions. How thug are you feeling? And how emotional are you feeling? And then depending on how you answer those questions, it will play you a Ja Rule song from the 1990s. And it’s quite fun to mess around with. And I also wanted to pick NathanBarry.com/authority. So, the book I wrote is a self-published book. And basically I was inspired by Nathan Barry who’s a designer who self-published his own book online. And he wrote a book then eventually of course, a meta book about how to self-publish books after he wrote the web app designing handbook. JAMISON:  That’s the final stage of book writing. CRAIG:  That’s right. [Laughter] JAMISON:  The final horn. CHUCK:  I’ve actually read ‘Authority’. It is really good. CRAIG:  Yeah. And actually, to support him you should buy it on the site. But if you’re a paper book person, he does have it and released it recently on Amazon.com as well. So, you can get a physical copy if you’re interested. But it’s not too long of a book. But it definitely inspires you to think, I don’t know. I’ve known many people over the years who have written books for big publishers. And they say, “All I got out of it was famous,” or whatever. And I think that it would be great if the world changed so that that wasn’t the case for technical authors. And that’s it for my picks. CHUCK:  Alright. I have one other announcement. We are doing our JavaScript mobile roundup where you can come and talk to, or come and listen to some of the implementers of some of these mobile hybrid app frameworks talk about building hybrid apps. It’s going to be on Wednesday, which if you get this the day it comes out, is today. And it will be this afternoon. So, if you text ‘MobileJS’ to 38470 or if you go to JavaScriptPowerUp or JSPowerUp.com, I’ll have it up by then, then you can get all the details there. And that’s it. I don’t think we have any other announcements. So, we’ll wrap up the show. We’ll catch you all next week. And thanks for coming, Craig. CRAIG:  Yeah, it was great to be on. I’m a big fan of the show, so keep up the good work, guys.[This episode is sponsored by MadGlory. You’ve been building software for a long time and sometimes it’s get a little overwhelming. Work piles up, hiring sucks, and it’s hard to get projects out the door. Check out MadGlory. They’re a small shop with experience shipping big products. They’re smart, dedicated, will augment your team and work as hard as you do. Find them online at MadGlory.com or on Twitter at MadGlory.]**[Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.] **[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit CacheFly.com to learn more.]**[Do you wish you could be part of the discussion on JavaScript Jabber? Do you have a burning question for one of our guests? Now you can join the action at our membership forum. You can sign up at JavaScriptJabber.com/jabber and there you can join discussions with the regular panelists and our guests.]**

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.