065 JSJ Build Tools with Adam Hawkins

Download MP3



01:16 - Adam Hawkins Introduction


Next Week

Transitioning to JavaScript


[Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.]  [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.]  [This podcast is sponsored by JetBrains, makers of WebStorm. Whether you’re working with Node.js or building the front end of your web application, WebStorm is the tool for you. It has great code quality and code exploration tools and works with HTML5, Node, TypeScript, CoffeeScript, Harmony, LESS, Sass, Jade, JSLint, JSHint, and the Google Closure Compiler. Check it out at JetBrains.com/WebStorm.] CHUCK**Hey everybody, and welcome to Episode 65 of the JavaScript Jabber Show. This week on our panel, we have Jamison Dance. JAMISON:  Hello friends. CHUCK:  Joe Eames. JOE:  Hey there. CHUCK:  I’m Charles Max Wood from DevChat.TV. And this week, we have a special guest, Adam Hawkins. ADAM:  Hey, how you guys doing? CHUCK:  Terrific. So, you want to introduce your self since you’re new to the show? ADAM:  Yeah. My name is Adam Hawkins. I’m primarily a Ruby guy but have come to the JavaScript world through Ember and browser applications. I’ve been here now for about a year and a half and just learning as I go along, CHUCK:  Nice. So anyway, you recommended that we talk about build tools and then you wrote a blog post about it. We talked about build tools, I think on Episode 2 or 3 or something. In your mind, what are build tools? ADAM: **Well, I think a build tool is something that you need to create a JavaScript application. There is a distinction between, say maybe an application or something [inaudible] that needs CoffeeScript or something like that versus a full-blown application that runs on the browser which needs modules, asset pre-compilation, templates, all those sorts of stuff, and testing and things like that. So, on one end, you have build tools that simply do the compilation and the concatenation, and then you have other tools that aim to be like a whole development environment. So, there is a large spectrum and you just have to choose which you need, basically.CHUCK:  What kind of a build process do you guys have on the projects that you work on? ADAM:  Well, okay. My background is, we are building a CRM with Ember.js and we needed a lot of different things. Well, my team prefers to write in CoffeeScript and use Sass. So, we needed those two things right away. Then we needed module compilation and then also asset concatenation, minification, as well as environment support. We need to develop a certain code and then deploy a certain code and a few other things. So, it’s pretty complicated and we needed a tool to do that. Well, I wrote one after looking at what’s out there. JAMISON:  So, what made you write one instead of use Grunt or Yeoman or something else that’s already out there? ADAM:  Well, we started to do our work right around the beginning of 2012. I think that Grunt was around, but Yeoman definitely wasn’t. We had looked at Grunt, but at the scale of what we needed to do, it just didn’t seem to make sense for us. JAMISON:  What do you mean by ‘the scale of what you needed to do’? ADAM:  All the different things that we had to do, like the compilation of the different things and we had a whole build process. You know, with Grunt, you can declare your tasks like, “Okay, I need to compile these files to CoffeeScript and at these directories.” But our build process is ten or 15 steps long. Having to create all those different Grunt tasks and then customize them for different environments just didn’t seem to work out for us. CHUCK:  It sounds like there are a lot of steps here. You talked about minification and compiling CoffeeScript and all of these different things. So, when you’re talking about a build tool, are you talking about something that integrates other pieces that do those things? ADAM:  It depends, because some of the build tools like Yeoman will do it and Brunch will also do it. It actually depends on how integrated you want to be. With Grunt, you can just use it to compile your CoffeeScript files or something like that. But other tools also integrate testing and a lot of different things. Does that answer your question? CHUCK:  Kind of. Why don’t you go ahead and explain your build process? ADAM:  Okay. So, our build process is initially, we compile all of the CoffeeScript files to JavaScript files. And then from there, we wrap each JavaScript file in a certain directory into modules. We have an app directory that contains all of our models, views, controllers, and helpers and things like that and those things are all wrapped into a JavaScript module. Then we have other parts of the code which are initialized, things like that. CHUCK:  Hang on. I need to back up for a minute. When you say a module, I’m usually thinking something like RequireJS or something like that. Is that basically what you’re talking about there? ADAM:  We use minispade because the thing for us is at the end of the day, all the JavaScripts are always compiled down to one file, even in development. So, we don’t necessarily need something like RequireJS. CHUCK:  Okay. Anyway, sorry I interrupted you. JAMISON:  RequireJS, you still have your files separate in development. You keep them all together even in development? You run your build process every time you change a file? ADAM:  Yeah. But the nature of the build tool we’re using is that only the different parts of the tree are rebuilt when one file changes. So yes, we do run the whole thing, but it’s really not so bad. JAMISON:  Okay. JOE:  Interesting. Why not use RequireJS to manage file dependencies on each other? ADAM:  Because it just didn’t seem like we needed that. Are you familiar with minispade? JOE:  No, not at all. Does it basically do that same kind of thing? JAMISON:  It’s Ruby-like. So, you just type require and you put in the path of the file and it just pulls in the file, but it doesn’t return anything. It just evals the file, right? ADAM:  Well, yeah. Minispade is very basic. All you do is essentially map a string to a function call. Part of the build process is to look at the file name and then generate a minispade module based on the file name. We have a file that’s called app controllers application controller. So then, that translates into controllers application. Then also part of the build process is to look for require statements and then rewrite them as minispade.require, which then calls the function which then usually just evaluates some code in the global scope which is totally fine for us. JOE:  Cool. ADAM:  So, that’s one part of the build process. That’s where the application code is. And then, there are other codes like initializers. So for Ember, you can tie into the boot process and do things there. We have a set of files there that are treated a different way. And those files are wrapped in immediately invoked functional expressions. Then there is vendor code and things like that and depending on where the file is in the file system, it’s inserted into a different position inside the final compiled file. So for example, we have jQuery in our application. So, jQuery’s just inserted at the very top of the file with all the other files in the vendor folder and then comes the initializers and then the environment-specific files and then the application files, like the controllers and the models or whatever, and then comes the compiled templates. And that’s the build process for the JavaScript. CHUCK:  Nice. So, you talked about minification and things like that. Is that part of your build process as well? ADAM:  Yeah, depending on what environment we’re in, we minify. For example, we have our production configuration file and inside there, we say that we’re going to minify. So, when we deploy the application, we just compile it for the production environment, which includes things like minification and some other things to strip out Ember asserts, which are unused in the production builds, and also precompile Handlebars templates. And then, we also do image optimization and things like that. CHUCK:  So, what are you using to precompile your Handlebars templates? ADAM:  We are using the barber gem that me and Paul Chavard wrote, which is also what Ember uses to precompile its templates for its own build process. CHUCK:  Now when you’re saying gem, that’s Ruby, correct ADAM:  Yeah, that is Ruby. The Ember.js build process uses Ruby. And actually, we are in the process of moving it over to Grunt. So at the moment, it uses a Ruby gem to precompile Handlebars templates. JOE:  Hey Chuck, you know a little bit about Ruby, don’t you? CHUCK:  Just a little. ADAM: [Chuckles] Yes. So I think you and I, Chuck, I will consider myself primarily a Ruby and a Rails guy. I don’t know if you would have put yourself in that same category.**CHUCK:  Yeah, at this point, yes. I’m trying to broaden things out a little bit, but it’s hard. And this is kind of a tangent, but the thing for me is that I like being an expert in at least one area. And so, I’m not willing to ignore Ruby to go become more proficient in other areas. If I can work it in, then I will. And I find ways to do that. But yeah, I’m not going to ignore Ruby for too awful long to go dig into other technologies because that’s what people are paying me for, is to be an expert in Ruby. ADAM:  Well, do you guys have experience working with some build tools like Yeoman or any of these other things for building JavaScript applications? JAMISON:  We use Grunt and RequireJS. It seems like a very different workflow from yours. It accomplishes the same thing, but it just goes about it in a really different way. We have RequireJS so it gives you that nice list of dependencies in each of your files. You don’t have to count on things being added to the global scope in some other files. So, it lets you sandbox your modules a little bit more and then, just Grunt to build it. And that works well for us. I was going to say this, because you said you consider yourself a Rails developer that does JavaScript and this definitely seems like that kind of workflow. It seems like it’s geared towards someone who’s more comfortable in Ruby and kind of does JavaScript to make cool applications, but isn’t deep in the JavaScript world. Is that an accurate statement? ADAM:  Yes, generally. JAMISON:  No, I’m not saying that you’re not a good JavaScript developer. Just that you’re… ADAM:  No, no, no. JAMISON:  You’re a Ruby developer that does JavaScript is what it seems like. ADAM:  Yeah, that’s how I would classify myself. I’ve been doing Rails since 2006 and I’ve been doing frontend and Ember now for a year and a half, almost two years. So just by the math, most of my expertise is in server-side stuff and pretty much all of that is in Ruby. JAMISON:  This is kind of a tangent, but what led you to make a client-side app instead of use some of the more traditional Rails techniques like server-side rendering and the Russian doll caching that gets talked about a lot? ADAM:  Well, we hit a problem in that we had a very complicated UI and we were using server-side rendered JavaScript to update the page. Like when you submit a form, it’d go to the server and the server would return JavaScript that knew how to update the HTML and things like that. Then at a certain scale, that just completely fell apart. It was no longer feasible for us to continue developing our product. And then, we decided to switch and go client-side with Ember. CHUCK:  Yeah, there are definitely some upsides to going with the client-side. One is that if you can distribute more work out to the clients then you don’t need as heavy-duty a server, because most of the heavy lifting is being done in the browser. The tradeoffs are there and they’re totally worth it one way or the other, depending on how complicated your application is and what you’re doing with it. But at the same time, sometimes it does make sense to just move ahead with the server technologies because you might have a little bit more control and you may never run into some of those issues. ADAM:  Yeah. Well, I think this was something that I realized after spending a significant amount of time doing this is that for us, Chuck, going from a very mature development environment and platform like Ruby and Rails and going to JavaScript, it’s a big change. And a lot of things that we have on the server, we don’t have in the client at all. Build tools are used to kind of fill the gap. CHUCK:  Yeah. ADAM:  Especially when you have, I think that we can all agree that it makes sense to keep your classes in separate files and then use something to string it all together. You have to use another tool to get that with JavaScript. CHUCK:  Yeah, I have seen though where you keep all of the files separate like we’re talking about and then RequireJS will actually go and request the files when it needs them. And that’s a technique I’ve used in the past and it seems to work pretty well. In that case, you don’t necessarily need it all in one file to save yourself the HTTP requests in the browser. JAMISON:  That’s good for small apps. But if you’re writing anything larger, you’re going to have lots of separate files and that’s going to just kill your performance. In development, I think we have 300, 500, I don’t know, modules. And even on Mac Book Pros on Google Chrome, when we load up our app, it’s ten seconds to just resolve all the HTTP requests before the JavaScript gets loaded. ADAM:  Yeah. CHUCK:  But that’s pre-build? JAMISON:  Yeah. This is in development mode, just to avoid having to run a build tool every time you make a file change, or have a watcher or something. JOE:  Oh, it’s taking you guys ten seconds? Ouch! JAMISON: **Are you going to like pound your chest about how many more files you guys have? [Laughter]**JAMISON:  If only we could have a ten-second long time. JOE: **I don’t know what our numbers are for files. I think we have more than that, but I don’t think it’s taking us that long. But honestly, I don’t know. I feel silly that I don’t have those numbers at my fingertips so that I can pound my chest. [Laughter]**JOE:  I’m pretty sure your app’s significantly smaller than ours. We have 100,000 lines in our apps. JAMISON:  Yeah, we have like a third of that. JOE:  So, I think the number of files we’ve got is significantly larger. But it doesn’t seem like we have that long in dev to resolve the HTTP requests. JAMISON:  So, what do you do for your build process, Chuck? CHUCK:  Well, for my build process for most of my JavaScript, I have to say most of my clients, they’re requesting Ruby on Rails applications and most of the functionality involved in these apps, they're on the server. They’re running in Rails. So, I just use the built-in sprockets. JAMISON:  Usually you got that pipeline stuff? CHUCK:  Yeah, the sprockets asset pipeline stuff and just build it up that way. However, I have built a couple of apps where I split things out and actually used RequireJS to manage them. In those cases, I just serve up the raw files, because they were never big enough for me to actually worry about doing more than maybe consolidating some of them into a single file. JAMISON:  Sure. What about you guys, Joe? JOE:  We’re using Grunt really heavily. We have a huge, huge, huge build process with a lot of stuff. It's unfortunate Merrick’s not here because he’s the one who’s kind of the architect of it all. But it’s really served us very well. One of the big things that we found was just from running our test, switching from PhantomJS to Chrome went from a minute to six seconds to run all of our frontend tests, which we don’t have a problem. CHUCK:  Wow! JOE:  We’ve got less than a thousand frontend tests. But yeah, that was crazy, because Phantom is really fast for lots of stuff but just running those tests. These are just Mocha tests. This performance difference was -- we suspect that it has to do with caching, that Phantom is not an aggressive cacher and Chrome is. So, that’s what we suspect. But we’re not really sure why it’s so significantly faster. But also, Jamison, I just ran a quick test. We have 500 JavaScript files coming down and I think it takes us about three seconds to load the page. CHUCK:  Yeah, there are other issues there too, how much stuff is between you and the server that you’re pulling it from and stuff. So, if your dev server is in-house or on your local machine, that might make a difference too. JOE:  Yeah. ADAM:  Do you guys use source maps when you’re developing? Or does it even matter if you already have the code in separate files? JOE:  Yeah, since we’re in separate files, we don’t here. JAMISON:   We actually don’t use source maps either and we use CoffeeScript. The first week that anyone starts that hasn’t used CoffeeScript before, they’re grumpy. But then, they just kind of figure it out. I don’t know. There are tools you can put in your editor to compile stuff. JOE:  Jamison? JAMISON:  Or the compiled JavaScript isn’t that much different so you can just learn to read it and figure out where it came from. Yes, Joe? JOE:  Do you wish you were using source maps? JAMISON:  Do I wish I was? ADAM:  Do you think you’d like it if you were? Like you had it hooked up for free? Do you think you’d like it? JAMISON: **It’d be cool, yeah. It’d probably save me a few seconds every day. [Chuckles]JAMISON:  And it’d be cool because I’d have tech cred. JOE:  Yeah. JAMISON:  I wouldn’t have to feel bad about not using them. CHUCK:  I think source maps though, one of the things is that most of your browser JavaScript tools or even in Node.js, they don’t give you a way of linking back to your original code. JAMISON:  No, they do. CHUCK:  Oh, they do? JAMISON:  It’s what a source map is. Yeah, you can ship a minified, concatenated file but debug in the un-minified separate modules. CHUCK:  Oh, I didn’t realize that they actually would translate it for you and open up the right file for you. I was going to say, because that would make them super handy. JAMISON:  Well, they are. CHUCK:  [Laughs]ADAM:  Yeah, they are. JOE:  I’m kind of curious. You said that you guys are concatenating even in dev. Do you find that to be a problem? Because it kind of seems like to me, at least in dev, the trend is for people to try as much as possible to keep separate files in the build process as minimal as possible in dev and then have a longer bigger build process production. It seems to be a fairly common pattern where you guys seem to be, at least with the single file in dev, that’s a fairly unusual one. Do you find a lot of pain from that? ADAM:  No, actually, not at all. It’s actually worked out really nice for us. Where would you think the pain points would be? Are you thinking about speed or other issues or what? JOE:  Debugging, just debugging. ADAM:  Oh, so part of our build process is in development, we use -- this is kind of embarrassing because I don’t know the exact official term for it. I’m not sure if it’s source map. But it’s when you do like the comment at the end of the function that indicates the name of it. Do you know what I’m talking about? JOE:  Not if it’s not source maps, but continue on. ADAM: [Chuckles] If you annotate a part of JavaScript with some special comment that indicates that this is where it was originally from, in development, we compile all of the application files as string functions which then are evaluated with this annotation. So, when we’re developing and then we see an error, we’ll see, “Okay, line 5 of blah…blah…blah…controller,” because of the annotation.**JAMISON:  Do you run a watcher or do you rebuild every time you make a change? Because that’s the part that drives me crazy, you can hook up source maps. But if you have to turn your interpreted language into a compiled language, then that makes me grumpy. ADAM:  No, we don’t do that. We just reload the page when we’re done editing. We don’t run a watcher. JAMISON:  Sure. JOE: **It’s amazing how quickly our baselines get adjusted. I mean, I was doing compiled languages for 12 years and then I started doing JavaScript heavily. And now, if I actually had to go through a compile step, I’d pull my hair out. [Laughter]**JAMISON:  I’ve actually been doing lots of Go on the server and it’s made me appreciate JavaScript and also hate parts of JavaScript that I didn’t hate before. But definitely, I appreciate that it’s interpreted and I don’t have to wait for a compile step. And so, I hit a function where I misspell a variable and then I’m like, “Why can’t the compiler check this for me?” CHUCK:  Yeah, but then you usually get the back trace and can find it. JAMISON:  Yeah, yeah. CHUCK:  I haven’t found that terrible. I mean, the nice thing about the compile step is it will tell you all of the syntactic or otherwise problems that it’s designed to find all at once. JAMISON:  Indeed. CHUCK:  And that’s the tradeoff. But at the same time, I haven’t missed that, especially since in some cases when I was working with compiled languages like C or C++ or even Java, you get as many warnings as you get useful information. And so, you wind up digging through a whole bunch of stuff and wishing that you, in some cases, could suppress the warnings. There is a tradeoff there, too. But yeah, I tend to like the interpreted languages. You just run the program again and find the problem. ADAM:  Yeah. It’s much nicer. I agree. JAMISON: **Warnings are like your conscience, Chuck. [Laughter]JAMISON:  You ignore them at your peril. CHUCK:  I suppress my conscience, too. JAMISON: [Laughs] You just pass in a flag, turn it off.**CHUCK:  That’s right. JAMISON:  Do you want to talk a little bit more about iridium specifically? We’ve kind of been talking about build processes in general. But this is the specific tool that you guys use. Does it require that you use minispade or can you drop in another, like Browserify or RequireJS or something like that? ADAM:  You can drop in whatever you want to. Iridium is something that I wrote and it’s built on top of rake-pipeline, which was initially written by Yehuda Katz for Living Social to do essentially asset compilation of various things. With rakes, I want… JAMISON: **Wasn’t it his answer to the asset pipeline? He wasn’t a huge fan of it and this is kind of his interpretation of what that should look like to [inaudible] pipeline’s history. .**ADAM:  I think somewhat. And rake-pipeline is much more flexible than what you can do with the Rails asset pipeline. CHUCK:  My understanding is that he didn’t have a major beef with the asset pipeline in Rails. What it really came down to was there were a few other things that he wished that it could do, especially once he started getting into Ember and things like that. And so, he added these other niceties to it. ADAM:  Well, I think the other part of it is that -- I’ve run into this in my work, is we primarily are a team of Ruby guys but we have JavaScript and frontend people. And when all the tools are written in Ruby or some other language versus people who are familiar with it, it rubs people the wrong way. And if you just want to build an application with something like Ember or Angular or anything like that, if the only interface you have is a simple command that’s just like build. You don’t have to really learn anything, versus if you want to use the asset pipeline, you basically have to use all of Rails. It’s not worth it for you to configure it yourself outside of Rails. So, I think that also has a lot to do with it. CHUCK:  Yeah. JOE:  So, one of the things that I heard you talk about that I was curious about is, I’m just curious what made you go to Ember on the frontend versus picking any of the other, like Backbone or Knockout or Angular? Is it because of the parity of things with Rails? ADAM:  No. It was really because at the time we made the decision, it was really the only game in town. Mind you, this was, we decided to go full client-side back in November of 2011. That was a long time ago. There was SproutCore and I had no experience with Backbone. But Ember just seemed like a better fit for what we were doing. I have a lot of respect for Yehuda and the work he’s done and kind of trust him as a developer. So I said, “Okay, if Yehuda’s willing to stake part of his claim in this area, then I think that means something.” Yeah, that was pretty much why we chose Ember. JOE:   Gotcha. ADAM:   Jamison, do you have some other, you had a question about iridium or what were we talking about before we got sidetracked? JAMISON: Yeah, just about iridium in general, how it works. ADAM:  The iridium uses rake-pipeline which defines a build process that should work out of the box for most applications where it will do CoffeeScript compilation and Sass and things like that and give you module wrapping in a dev server and a test harness and then a way to compile your assets for deployment. That’s pretty much the gist of it. JOE:  Sweet. JAMISON:  So, is there a good getting started guide, if someone wants to take a look at iridium? ADAM:  Unfortunately, no. And this is kind of my fault because I was hesitant to write documentation for it because a lot of the things it depended on were just Git dependencies. I didn’t want to kind of release this software and have to make everybody go through Bundler to just install it. So, I’ve just been holding off on it. But unfortunately, no. I think I’m also hesitant to write the documentation onto it, because I’m not sure how much traction it will get, to be honest, because of the whole Ruby versus JavaScript thing. JAMISON:  Sure. There’s definitely a group of developers that are like you where it would appeal to them to have a tool written in Ruby. I’ve heard that a lot about Grunt, when I talk about it with people that, “I don’t want to use Node. Why would I use Node? I’m more comfortable with Ruby. It’s got better tools for string manipulation,” that kind of stuff. So, I think it’s an ‘If you build it, they will come’ thing. If you write docs, then you’re going to get more traction with those people. ADAM:  Yeah, we will see. My initial use case for iridium has always been Ember apps. So, there is an iridium Ember plug-in you can install which will then automatically install an Ember.js file and all the different files required for Ember inside the right files and give you generators so you can create controls and things like that, and does the proper Ember, Handlebars pre-compilation, all that kind of stuff. But I think that the community just wants JavaScript stuff, which is completely understandable. So, even the Ember team itself is moving the repos over to use Grunt. JAMISON:  That’s a little bit of a different case, right? If you’re shipping a client-side JavaScript library, it seems weird to force -- the people that are using that are going to be JavaScript developers. So, it seemed weird to force them to use a different language. At the least, you could ship a compiled version of it. I just had a little bit of nerd rage about this the other day. I was cloning a library and I had to use rake to build it. Why not just have a downloads folder that has your JavaScript library? I don’t know. A tiny rant. ADAM:  Well, I think it’s the same. The nature of client-side applications is they only can be built in JavaScript. The people who are building these applications are going to be JavaScript developers. So, I think that it makes sense to have the tooling all in the same language. And just when we started, there really wasn’t anything else out there. The only thing out there at the time was Brunch, according to research I just did because I was wondering how long these tools have been around for. I didn’t even know about it. The only thing that I saw was rake-pipeline, so I just built on top of that. CHUCK:  My question is, we’ve talked a lot about maybe Ember.js folks moving to Grunt or pure JavaScript implementations. Do you feel like there’s any kind of mismatch between building JavaScript build tools in Ruby versus JavaScript build tools in JavaScript? ADAM:  Yeah, somewhat, because the thing is that unfortunately, you always have to shell out the other language to do something. For example, if you’re building a tool in Ruby and you need to compile templates of Handlebars, then you have to shell out to Node or something. You have to use JavaScript for that. But if you’re, I’m not sure if this is still the case, but if you’re in JavaScript and you want to compile Sass, you have to go through Ruby. So, there is this weird intersection point between the two ecosystems. CHUCK:  Do you think eventually we’ll move to the point where the JavaScript stuff is done in JavaScript and just has a clean port to Ruby or vice versa with Sass or they have a Sass compiler written in JavaScript? ADAM:  Well, I know that Sass is moving towards the C implementation. Now I’m not sure, but can Node use the extensions? JAMISON:  Yeah, you can write C++ modules. So, some smart person will probably do that with the Sass, with libsass once it gets published. ADAM:  Yeah. So, I think that’s what we’ll see. Each ecosystem will have their own native versions of all the important things. It just so works out that CoffeeScript is JavaScript and Sass is Ruby and most people usually use one or the other. So, you always have this weird dependence. CHUCK:  So, if somebody wanted to build their own build platform for their application, what recommendations do you have for them to figure out which tools are the right ones or whether or not they need to build their own? ADAM:  Okay. I’ve done a lot of research on this after the fact. When you decide what kind of build process you want, you really kind of have to ask yourself, “Am I more of a JavaScript person or am I more of an other language type of person?” And see what solutions are available in those languages. One of our team members is a purely frontend guy. He doesn’t know any Ruby, only does JavaScript and Node. When I showed him our initial version that we built, it was totally foreign to him. But it’s totally easy for him to just wire up all these things in Grunt and make his stuff work. And it also has to do with whatever technology you’re using on the backend because that usually has something to do with it. For example, if you’re doing testing of your application, perhaps you want to integrate your backend at the same time you're building your frontend. It also depends on what language or what your backend is. If you are using Rails as a backend, perhaps you need to control the server more, so it has to be done in Ruby. Maybe then your test framework has to be, your test suite has to be in Ruby and you need to find a build tool that kind of caters to that. Or maybe your backend is in Node and you can use JavaScript. So you need a build tool that caters to that. So, there are really a lot of variables in the equation. And it has a lot to do with personal preference and other technological choices. I think that at this point, it doesn’t really make sense for anybody to spend a lot of time building their own build tool. I would like to see maybe a small set of really good libraries all competing against each other, versus a whole bunch of libraries that maybe are not so good. And I think that it’s nice to see Yeoman now getting a little traction and just bringing a lot of developers into this space so we, as a community can have great tools, which is something that I think we really need in JavaScript. CHUCK:  Alright. Well, I don’t know if I have any more questions for you. Do you guys have any more questions for Adam before we get to the picks? JAMISON:  I just wanted to ask a little bit about your testing setup. ADAM:  Okay. So, our testing setup is we use in-memory data in our Ember application and then we execute the test in a browser with QUnit. Then if we want to, we can run the test headless with PhantomJS. JOE:  So, are your tests more like integration-type tests where they’re hitting a lot of stuff? ADAM:  Well, for us, yes. I think that it made more sense for us to just focus on the integration points because that was where we got the most value out of the tests. And it’s very hard to unit test UI stuff, especially in Ember, I think. JOE:  Interesting. So, what about unit testing any of your business logic? You guys haven’t really focused on that? ADAM:  As far as business logic goes, we have some extra methods on our models and helpers and those things could easily be unit tested. But we haven’t seen the need to do it yet. I think also, we started doing our testing before a lot of the testing stuff in Ember actually kind of shook out. Now, there’s Ember testing, which changes a lot of things and actually makes it easier. When we started doing it, there was nothing like that. So, we just kind of forged our own way and kind of got stuff working and just went with the easiest thing that could get us the most value, instead of doing the thing that was the most correct engineering choice, I guess. JOE:  I gotcha. Obviously, I’m a really big tester guy. Anybody who’s listened to the show much would recognize that. I would definitely encourage you to relook at the value of unit tests. And anybody, really, who’s embarking on a new project, to look at the value of unit tests. Obviously, if you’ve got a setup going, things are going a certain way, you can put yourself into a place where what we’re already doing is working for us. So, the amount of effort it might take to change things around might just not be worth the value in the long run. But in definitely general, in the majority of cases, unit tests are going to be really valuable, have a lot of value, and a lot more value in the long run, even than integration tests, just because the high cost of integration tests. Not that I’m saying that they don’t have value, because I really do believe they do and they should be done. But unit tests, bang for the buck, are definitely the highest bang for the buck in general. Not any particular case, but in general, in the majority of cases. JAMISON: **You might have to go on an epic yak shave to get them up and running. [Laughter]**JAMISON:   But it’s worth it. Is that what you’re saying, Joe? JOE:  Yeah. That’s definitely true. Sometimes, you can be in a place where that’s true and it just doesn’t make sense at a late point in the game to make a change. But I would beat myself up if I ever didn’t say, “Hey, unit testing is awesome and people should be testing their JavaScript code.” My whole point in life right now is to get people to test their JavaScript code. ADAM:  I wouldn’t say that I’m saying that. I’m just saying that in our case, if most of your classes are just empty shells of framework classes, then what’s the point of unit testing when all you’d really be doing is testing the framework? JOE:  Sure. I definitely want to say that your mileage can vary based on a particular circumstance. But in the general case, unit tests are really by far the most bang for your buck. ADAM:  Oh yeah, I completely agree. I think that this was actually a hard point for us, was that in the beginning, it was just so difficult to get anything working and testable. Coming from the server-side where you can pretty much test anything and having to really work to just get something working where you could just write a unit test for a simple module you wrote and then write an integration test to simulate the user actually clicking the application. It was an awful lot of work. But once you have it, the rewards are unlimited. JOE:  I really hope that Ryan Florence and Yehuda Katz listen to this and make sure that Ember continues to address the documentation and friendliness of testability in Ember. I know that they’ve made leaps and bounds in improvements in recent times. Ryan Florence in our last show said something funny. He said, “Ember’s often attitude has been yeah you test your code,” but they haven’t really made it a focus. Personally, I hope they continue to make it more of a focus. ADAM:  Yeah. I hope so too. And I know that Ember testing makes it at least much easier for people. I think a lot of the culture around testing has to do with also the tools that you’re using. In JavaScript, there are really a lot of choices. It kind of depends if you want to do it, say in Node with Mocha or whatever, or if you want to execute the stuff in the server. The framework has to come out and actually make a decision on which one they want to do. That could be hard. I think that they have with QUnit. But I think that’s always the hard part about making these decisions for everybody. CHUCK:   Yup. JAMISON:  Yeah, it’s true. CHUCK:  Alright. Well, let’s go ahead and get into the picks. Jamison, do you want to start us off? JAMISON:  Yes. I have two picks. The first is this indie game that was made in a seven-day gaming jam called Sub Rosa. It’s kind of like a mob simulator game. So, it’s only fun if you play with a large group of people. But it’s free on the Internet and it’s like blocky polygons. Not very pretty to look at, but it’s super fun. So, the way it works is there are three teams. Each team has an objective. They either have to buy a disc from another team, or sell a disc to another team, or just get the disc. They’re all kind of working against each other. You can drive around in cars and shoot out windows and stuff and it leads to these funny moments where everyone’s meeting together. These three teams are meeting together to exchange these briefcases. You don’t know what’s in them, if they’re cheating you or not. Then one person pulls out their gun and then suddenly, everyone pulls out their gun and I don’t know. It devolves into violence. It was pretty fun. And my next pick is this thing called biggie which is a little wrapper around a library someone made to make slideshows out of markdowns. So, you just make your slideshow in markdown and then it posts it as a gist on GitHub and then, you can give these really lo-fi slideshows that give you lots of programmer cred for being super ugly. So yeah, those are my picks. CHUCK:  Awesome. Joe, what are your picks? JOE:  My first pick is an iPad game. It’s called Kingdom Rush and it’s the Frontiers version. It’s a standalone, but it’s basically just kind of a part two of the Kingdom Rush. It’s a tower defense game. It’s very cool. It plays differently than a lot of tower defense games I’ve played where you don’t lay out the path but instead along the existing path, you put up towers. You’ve got mage towers, archer towers, artillery towers, and then fighter towers. You have to put your fighters to slow down so that your other towers can do damage. It’s just a really fun game. Their second edition of it basically came out. This new part two came out, Kingdom Rush. It has been really fun. Just had a ball playing that. And then, Brandon Sanderson has a brand new book out, I don’t who he’s coming out with, called ‘The Rithmatist’ and that’s starting with an R, Rithmatist. And Brandon Sanderson’s just an awesome, awesome author. The author of the last few Wheel of Time novels and Mistborn series. ADAM:  Oh, yeah. JOE: **I picked up a copy of this book, really excited to read it. Haven’t read it at all yet, but I can safely say it’s going to be a good book knowing how good of an author Brandon Sanderson is. And then for my last pick, it’s kind of a little bit of a rant about the younger open source generation of developers. [Laughter]**ADAM:  Okay. JAMISON: **Before, they had to lock up [inaudible] place.**JOE: **Exactly. [Laughter]**JOE:  I went to Open Source Bridge and spoke there and I gave a talk about test-driven development and AngularJS. Right before that, I attended a talk by Ward Cunningham who is one of the luminaries of our industry. He helped invent Agile. He invented the Wiki. So, I attended his talk, which is really cool, about teaching your wiki to do new tricks with domain-specific languages. Then he, to my great pleasure, came and attended my talk that I gave. Then I spoke with him briefly afterwards. But as I was just so excited and texted a bunch of my friends and tweeted this out, a lot of my friends were like, “Who’s that?” And I just in my head was like, “You’ve got to be kidding me. This is one of the central figures of our industry.” Even my boss who’s older than me didn’t know. Definitely, it’s more likely that if you’re younger, you’re not going to know who these slightly older people are in our industry that have been around. But if you don’t know who people like Martin Fowler and Ward Cunningham are, Bob Martin, the guys who’ve changed our industry, and there are plenty of people beyond that, that the people who’ve really formed our industry. I think you’re really doing yourself a disservice and you ought to spend a little bit of time now and then looking at who are the people that have really created the shoulders that we’re standing upon today, are these guys, these giants who give us the tools and have brought about all these amazing changes in the industry. People nowadays, they know current names, Addy Osmani and Paul Irish but there are a lot of people that were around before those guys that have just done amazing things for our industry. So, as my pick, I’m picking Ward Cunningham just because he’s an awesome guy. He’s very friendly. We had a nice chat. I almost got the chance to pair with him and teach him Angular, but I ended up flying out the night that he was available. So, I really regret missing that fantastic opportunity. ADAM:  So, your pick is Greybeard. JOE: **Yes. [Laughter]**ADAM:  That’s a great pick though. CHUCK: **Awesome. Alright. Well, I’ve got a couple of picks. The first one is Speedtest.net, which is just a terrific way of figuring out how fast your Internet connection is. And you can actually pick the server you want. I typically pick a server that’s close to here. I hit the X-mission server in Salt Lake City. But it’s pretty handy for just finding that out. I just got a new Internet connection and they promised me a certain level of bandwidth and they’re coming out tonight to adjust it so that I get what they promised. Anyway, so I’m excited about that and I’ve been using this all day long testing my connection. [Chuckles] The other pick that I have is ThemeForest.net, which is they give you HTML layouts and stuff. They have a bunch of other web pages that you can get music or clip art or things like that off of them as well. But I really like some of the stuff that they give me. That way, I don’t have to go and find a design. I can find one that I like in there and I can pay anywhere from $20 to $30 and use that for the web page. Anyway, those are my picks. Adam, what are your picks?**ADAM:  I have a few picks. My first pick is a music pick. It’s Solo Piano Radio. So, if you like laid back solo piano music to do code or just hang out to, you can listen to it for free on iTunes. They also have a page stream without ads. I just listened to that today and it’s totally great. My second pick is ConvertKit which is by Nathan Barry and it’s a product for launching products and tracking conversion and things like that. So, I’m using it to watch my eBook and it’s worked out great. So, if any other freelancers or programmers are looking for something, I recommend that they check that out. My last pick is an application by my friend Joe Fiorini who was on the podcast a couple of times ago called Staticly. It is a Mac OS build tool for people who need that. It’s launching pretty soon and I think that people should check it out. And those are my picks. CHUCK:  Awesome. Alright. Well, I think we’re done. Thanks for coming, Adam. It was a good discussion. ADAM:  No problem. JAMISON:  Yeah, thanks. ADAM:  It was totally fun. I think we got a little sidetracked, but I think the nature of these issues is they really expand out into so many other areas as well. CHUCK:  Yeah. And I think it depends on what your background is and what the environment you’re coding in is. So, those tangents kind of inform the decisions that you’re making and why. ADAM:  Yeah. No doubt. CHUCK: ** Anyway, we’ll wrap up the show. We’ll catch you all next week.

Sign up for the Newsletter

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