NOEL: Hello and welcome to the Tech Done Right Podcast, Table XI's podcast about building better software, careers, companies and communities. I'm Noel Rappin. This is actually the first episode we've recorded since the podcast went live so thanks to anybody out there that's listening and I'm really happy to say that you can get the Tech Done Right Podcast at TechDoneRight.io and also at iTunes, Google Play, Overcast or wherever you listen to podcasts. If you like what we're doing and you want to encourage us to continue, two great ways to help us out are to either follow us on Twitter at @tech_done_right or leave us a review on iTunes. Both of those really help us gauge interest and help new people find the podcast. Thanks! Today at Tech Done Right, we're talking about JavaScript both with or without frameworks. We have two panelists who worked professionally in both the client and server side, first we have Dave Copeland. DAVE: Hello, I'm Dave Copeland, also known as David Brian Copeland, who's written a few books. One of which is Rails, Angular, Postgres, and Bootstrap, which is about doing full stack development with Rails and the second edition is coming out soon. I'm also @davetron5000 on Twitter. NOEL: That is an admirably straightforward title. DAVE: Yeah, it took a long time to get there. NOEL: We also have Zach Briggs. Zach, you want to introduce yourself? ZACH: Well certainly. My name is Zach Briggs, @TheOtherZach on Twitter, which is where I'm posting most of my musings these days. I'm the JavaScript Practice Lead at Table XI. Recently, I've been most interested in finding out efficient ways to embed interactivity into websites that might not have a very large budget and that's what I've been up to lately. Thanks, Noel. NOEL: You're welcome. I wanted to have you guys on together because Dave has written this entire book, he's actually written it twice now, about using Angular with a Rails backend and using Angular to do what eventually becomes a single-page site on the frontend and I know Zach, you also have a lot of opinions about how to interact client-side and server-side logic. I thought that the two of you might have interesting things to say to each other. There are two camps about how to combine server-side app and a client-side app. One is the way basecamp and DHH has talked about "sprinkles of JavaScript". In that case, the server side basically serves HTML to the client and the client manipulates the DOM, either on its own or with a lightweight framework. Then in the other case, the server is sending JSON data, usually JSON to the client and the client is manipulating the data and is responsible for creating its own DOM elements and that can be either a single-page app in the server and client or can be separate apps entirely. In what circumstances is one of those approaches recommended and what circumstances would you try more complicated client-side. How do you think about those trade-offs? DAVE: I came into the single-page app world by necessity due to terrible internet in our warehouses where I work. We operate our own warehouses and we write software for them to pick orders, basically. The internet was terrible and the way the application worked that they used for picking was very much like classic Rails like submit a bunch of stuff, re-render an entire page, every time the user does anything and it was just awful. I rewrote it in Angular and basically, the bandwidth needed for the application to work properly was way lower and it works way better for the user. It was actually born out of necessity for me and it works great. ZACH: I find there's often good sound technical reasons for a single-page app. I worked at Splice, a music startup, for a while. We had a music player that was persistent when somebody was browsing the site -- great reason for a single-page app right there. But the way I look at single-page apps in general is it's incumbent upon the single-page app to prove itself. DAVE: Yeah ZACH: I think a strong piece of evidence for that is if you look back at the history of the web and think back to, say 1995 and we have a very stark inflection point, where cookies are introduced. Once cookies are introduced in both browsers by 1995 and they enable virtual shopping carts, overnight the web changes. Amazon.com gets its start in '95 and it literally could not have started any earlier. When I think back to the first single-page app, Gmail introduced in 2004, I don't see that same kind of inflection point. I see apps here and there, usually for a good specific reason but I don't see the same kind of sea change. NOEL: I mean yes and no like Gmail was very surprising when it first came out. It was impressive. People didn't realize this was the kind of thing that could be done: Gmail and also Google Maps, Gmaps originally. ZACH: Absolutely and the ability to optionally build an application on the web is incredibly powerful but it didn't become the default way in the last 13 years that we build websites. DAVE: If you remember, Gmail was written with GWT so you could write Java and then it would produce JavaScript and then every Java developer was like, "Thank God. I don't have to write JavaScript. I can keep writing Java and have these amazing web apps." NOEL: Did you ever look at the JavaScript code that a GWT app put out? DAVE: I think I remember it being pretty terrible. NOEL: It was pretty terrible. That technology for sure, the technology of things that spit out JavaScript has definitely come a long way. DAVE: Yeah. NOEL: I think that's interesting though because there's certainly have been various pushes of people trying to say, single-page apps are the way things are going and there are certainly are some very successful things that are written in single-page apps. Does it turn out that's more narrow use case than people thought or is it that the tooling is still too hard? DAVE: I find it introduces a lot of problems that are often go unsolved by the developers. I don't know if you all use Heroku but they did a rewrite of their dashboard in Ember maybe about a year or so ago and the old dashboard was fine, works great. The new one works fine most of the time but it gets these weird things where clearly the front-end browser state is messed up and it starts giving a really weird errors because some esoteric network timeout wasn't handled properly and you have to reload the whole page and I'm like, "Why did this need to be a single-page app? This is like showing me stuff and has buttons." They may have other reasons like maybe it's easier to deal with, maybe it's easier to manage that code if you're going to have JavaScripts. It's easier to manage that way. I'm not really... NOEL: Some of the arguments I've seen, they may have their own bandwidth problem too. I certainly seen the argument that if you're going to support a native mobile and web and you already have something serving data then it makes sense to treat the browser as another client. DAVE: Yes, very true, because for all I know, the backend of the dashboard could be using the same API that the CLI is using and I could see total advantages in that. For them. NOEL: Yeah. I guess that does argue, though that the browser technology may still have a way to go as a platform for applications, which is certainly not what browsers were originally designed for. DAVE: Yeah. ZACH: I think we left what browsers were originally designed for the moment the image tag went in in '93, right? But you bring up another great point which I think, another sound reason to consider single-page apps is team size because you have that stark architectural divide between the client and server. If you can afford the tooling cost, the pre-render cost, if you're interested in SEO, potentially the code splitting costs, if your app grows because with a single-page app you add a new section and suddenly the payload for your entire site increases. Whereas in traditional Rails app if you add a new section, you have that initial page loads isn't going to change. If you can afford the tooling and the overhead, then you've got, once again like I said, a great architectural seam. It's perhaps a good place to throw a little bit of Conway's Law in there. DAVE: If you're at the point where you need specialists like where I work, we don't tend to have a front-end developer and a backend. Everyone's sort of full stack. I've certainly been in places where you really do need a fronte-nd developer to do some of the stuff that has to happen and allowing them to not have to deal with the Rails backend in order to get their work done. That does have advantages too. If they can just start up the front-end app only, they could be more effective by not having to deal with all of the backend stuff. ZACH: I think for seven months out of my total career, I've had somebody building API endpoints for me and the whole time it felt like I was at a spa. [Laughter] NOEL: The spa where they give you API endpoints ZACH: Right, right. I just asked for data to build the front end, okay. NOEL: It was when they asked you to type with cucumbers on your eyes that it got weird. ZACH: Yeah. NOEL: It occurs to me that there's a kind of a weird perspective here that we talk about how complicated single-page apps are and I think that the issue here is not actually that single-page apps are complicated relative to native apps or other kinds of GUIs. It's that web apps are easy like web HTML mark up. ZACH: Yes, absolutely because you've got your entry point, you've got your sense of place with that URL and you've got a sense of who's browsing with a cookie and whatever's coming in from the persistence engine. DAVE: And there's not a lot of interaction the user can do either. They can click on things and that's going to be it. NOEL: But at even more basic level and I remember this very clearly when I first started working on HTML, when I was simultaneously, on one half doing HTML, on the other half working in Java Swing or something like that. The way that a web application defines its entire interface in text, basically in code is tremendously powerful if you are a developer and it's much harder to kind of do that in a native GUI or even a single-page JavaScript GUI. In that case, then the framework or whatever is defining your interface in a way that in HTML you just kind of put it out as text. ZACH: Right. That makes a lot of sense. Yes, especially around the web crawlers. I'm sure the Google team is really sad when they realized that they needed to start executing JavaScript when they are crawling pages too. NOEL: A lot of these kind of incidental features that come out of single-page apps because we expect them to both be kind of GUI apps and to live as native web citizens so they need to have SEO complications and they need to observe the back button and things like that, that sort of gives them the sort of this double mandate. Dave, having done this book twice, how has the tooling changed and how do you think the tooling for the single-page apps is going to change over the next couple of years? DAVE: It seems like there is this sort of battle between give me lots and lots of single purpose tools and I'll figure out how to put them together versus give me a thing that has everything I need and just works. NOEL: What's an example of each there? DAVE: React is a good example of the first. It's like a view layer and if you want to do anything else like you're on your own and there's 20 different ways to do it and they're all probably pretty good but you've got to make those decisions, then on the other end is Ember, which is you will do it this way and if you do do it this way, everything will work out and you've got everything you need. Then you don't have to make those decisions but then you know you're constrained by what you, in theory, can do. In Angular, it's like halfway in between so it just makes like this landscape of tooling really hard to know what are the good choices and what are the bad choices? I don't know... I just found it really difficult to figure out like, "What am I 'supposed' to be using?" If I'm a 'good front-end developer', what am I supposed to look at and what do I not pay attention to? I found it really hard to navigate when things started breaking in Rails to try to do this stuff. NOEL: I feel like the Ember team has almost carved out their own parallel universe where they have their own set of every tool and if you happen to have a problem that fits into their sweet spot, then you're golden. ZACH: The only thing the Ember team requires of you is the entire HTML document and as long as you give them control over that, then you're fine. NOEL: The only thing they require of you is unflinching loyalty. ZACH: Right. But I love that framework. NOEL: But it's a great trade off, if you give them unflinching loyalty. I think that they've been very smart about how they handle the community and carving out what they want to do and doing it well. DAVE: Right like they've got a point of view and if you're going to buy into Ember then you've got a clear path and they'll tell you like, "This is what you need to do," and that's nice, right? Like if I have a team of developers, I don't want them making a bunch of decisions about which Redux implementation or whatever to use. I'd rather have them just get the work done. NOEL: Right, and that's the Rails heritage in the Ember Team like, "We're going to make a bunch of decisions for you up front so that you don't have to even think about it." I don't see any of the other major frameworks really, really pick that up. DAVE: Yeah. Angular has weird opinions about how to build an application but the whole dependency injection thing but they don't have opinions about how to architect a web application. I guess, if that difference makes sense. NOEL: One of the things that I'm kind of sensitive to, I was reading over the second version of your book... I'm going to get it wrong. It's Rails, Angular, Postgres, and Bootstrap. Does it have an acronym? Is there someone mnemonic I could come up with? DAVE: I wish there were but they're all pretty terrible so we have to spell it out: RAPB, BARP so Rails, Angular, Postgres, and Bootstrap. NOEL: One of the things that I look for, sometimes in the technical books, even my own is what the author is kind of apologetic for in the text like in Rails 4 Test Prescriptions, I'm a little apologetic about how much time the first couple tests seem to take when you describe them because that's a big hurdle for people. In your book, it seems like set up -- DAVE: Oh, God, the set-up, yeah. ZACH: Did that change on the second edition perhaps, for some reason? DAVE: Yes. In the first edition I was able to use Bower to bring everything in so you can do Bower and then that's a pipeline with like one-line of configuration and it figures it out. Then Angular 2, they were not even publishing it on Bower. I spent a couple of hours with webpack, Browserify and... There's another one, Broccoli or something like that? Anyway, webpack was the only one I could get to even function after spending two hours trying to get it to do something so I went with that. Basically, in the second edition, we just abandoned the asset pipeline entirely because it just doesn't work with webpack and all the stuff. I think the thing in Rails 5.1 is interesting in what they're going to do. NOEL: Rails 5.1 will have Yarn, which is Bundler for JavaScript and webpack, which I don't even know how to describe, as default tools. DAVE: It's still going to use the asset pipeline for CSS and 'JavaScript Sprinkles', which is interesting because they're going to sit nicely with Rails and the asset pipeline, we use dump CSS and it just works and you don't have to set anything up for a really simple case. I guess, they're trying to maintain that use case but then if you want to do crazier JavaScript stuff, you can use webpack to get all those modern tools. I'm interested to see how that works in practice. NOEL: It feels to me it's a transition of some kind that they're picking up. It seems to me like a relatively rare case of the Rails core team picking something up because the audience is using it more than the Basecamp core team is using it. DAVE: Yes NOEL: Would it have been easier or harder to set the book up as one standalone Rails app and one standalone JavaScript app? DAVE: Yeah, I thought about that and I think the thing that having them on the same app really enables is doing a full end to end test because you can basically say, "I'm going to set up all this data using active record. I can write my test in Ruby," which is way better than JavaScript in my opinion. But then I can actually execute the frontend app like a user would, end to end and see how this whole thing works. We can debate the level of end to end testing that one should have but it does seem easier than if I wanted to do an end to end test, I'd have set up two apps and figure out how that works. That just seems like slightly more complex. ZACH: That was definitely something we were running into at Splice does end to end task and I was sure missing some of those Rails niceties. With Rails, you can use a database cleaner, you configure it, you reconfigure it after it messes up first time and then suddenly you've got feature specs. NOEL: The one time that I've done a split project where we had a Rails app, which was just an API and it was actually Ember, it was more painful than we were expecting, which was not Ember's fault exactly. We picked a project that was not necessarily an Ember sweet spot, which didn't help and then we didn't quite know how to go about... I think that if we were to do it again, like if we had another project like that, it would go smoother. But the first time you do something like that, where you separate out the server side and client side in a different apps, you do have all kinds of weird little subtleties that you don't think about like authentication and stuff that is surprising. ZACH: Once again, at Table XI, we often are operating under tight budgets so this might be less of a concern at a product shop with a longer product life cycle but for us we have to stay lean for our clients. NOEL: There's an inflection point, where the tooling gets hard whether or not it's a single-page app or not, how much can you do before the tooling gets hard? How much can you do with either lightweight framework, framework-less? Does that save you a lot of set up? DAVE: I was really surprised at the amount of set up just to get Angular 2 to do 'Hello world' versus Angular 1. With Angular 1, you could sort of include this library and throw a tag onto a dom element and you could do stuff. Then in Angular 2 it's like, "No. You need to set up all the stuff," and I can see that being really off-putting for users and I can totally see why React, which does not seem to have that problem, being more appealing to people just starting out. NOEL: Zach, I've definitely heard you express opinions about Angular 2. ZACH: I argue that React would have the same problem just because of JSX compilation. DAVE: Yeah, that's true. ZACH: I taught myself Angular in October 2013. I remember that was my first month in Chicago and it was this Wizard of Oz, everything in color moment because I was coming from Backbone. Suddenly, I didn't need to reinvent the world every time I needed to render a collection or reorder it or remove it. NOEL: Suddenly, you didn't just have a backbone. You had a whole nervous system. ZACH: Right and it was amazing. That first moment. There was a script tag, I throw an NG-app attribute in HTML element to scope where I want Angular to look at. At the time, it was Angular 1.2 so it was 36k Gzipped versus jQuery at the time, which was 33k Gzipped. It was small enough, I didn't even have to ask permission to put it into a project so I never did. Angular 1 is actually what got me on to the idea of islands of interactivity, where when you've got a mostly server-rendered page, you scope a rectangle that's interactive and you build that out with a powerful framework that can scale all the way up to a single-page app, if need be but is also small enough to work in an otherwise, server-rendered page in a small rectangle. DAVE: Yes, that's exactly what we use Angular 1 for as well, like that islands of interactivity. That's a good way of describing it. ZACH: I was heartbroken by Angular 2 for so many reasons: the tooling requirement, the library size. To me, it felt like they were missing the magic of Angular 1. Maybe I just wrote Angular 1 in a weird way and that's what eventually pushed me out of the Angular community and I ended up using different libraries to achieve the same result. Currently, it's Vue but it could be anything with similar characteristics to Angular 1. NOEL: So that's vue.js, which is the one that Zach often uses for islands of interactivity. ZACH: Uhm-mm. NOEL: I think people make complaints about React getting more and more complicated and people complain about Angular getting more and more complicated. Is this a larger problem that the frameworks start trying to solve the world and they become unwieldy? DAVE: It could be. To follow in your Angular 2 thing, I cannot understand why they did any of that. I don't know what was wrong with Angular 1 that they needed to do a complete rewrite and it makes all this extra stuff available and it's all this extra complexity that you have to now, make a bunch of decisions about the mindset. I don't quite get it. I'm not sure. It seems like this complexity is why there's so many different tools and frameworks and new ones coming in because each time it's like, "I'll fix the problem with this by rewriting it from scratch or making a new one," and there's no coalescence on some standard way to do things. ZACH: In 2012, jQuery hit a 50% share of the web and however you feel about jQuery, the idea of a JavaScript library being so popular that they would measure its share of the web much less half of it is amazing. I personally don't think they would have gotten there if they required a build step, right? Eighty percent (80%) of the web is still PHP. A lot of those are old PHP content management systems and I'm going to out on a limb and say that maybe, they don't all have webpack running. [Laughter] ZACH: When we present a tool, a library specifically with a hard tooling requirement, we're cutting out a large portion of the people that are building websites. NOEL: I don't use these JavaScript frameworks in day to day. I'm not building single-page apps day to day at the moment. I have in the past. I probably will in the future and the level of churn and ongoing complexity and meta-complexity in those tool chains is really off-putting to me. I don't see a way to keep my skill set going because six months later, even by the accelerated scale of web stuff, it seems like the stuff is still changing and getting complicated. At the same time, I was recently at the CodeMash Conference, which has changed tremendously since the time I was there three years ago when JavaScript was an afterthought among all of these more enterprise-y C# and Java programmers. Now three years later, there's a much more sense of JavaScript being the commonality that no matter what your server side tool of choice is, you have to deal with JavaScript in some way. That's always been true. It just seems like a lot of people are more realizing it in a more serious way now. I don't know how that stuff kind of plays together but it does feel like there's tremendous opportunity for somebody to try and bring stability to this. I don't know how you would even and do that. DAVE: I wonder if that contributes to the instability. If you think about the mindset of a PHP developer, Rails developer, Java developer, the way they would set up just a build pipeline would be totally different, right? The Rails developers wants this to just work. The Java developer wants something like super complex and then meanwhile, the C developers are like, "We had Make 30 years ago." For me, it's like watching things be recreated in a form that's like, "I don't want to type it in this form. I want to type it in this. I want to make it in JSON so I'm going to rebuild this concept." Really, I struggle with that. I don't want to be the old graybeard who is like "just use Make" but, yeah I don't know. NOEL: To be clear, don't use Make. It's tremendously powerful and ridiculously complicated tool. ZACH: My current philosophy is to try to avoid writing enough JavaScript where I need tooling. That's my current philosophy. NOEL: Okay, so how do you do that? ZACH: So I tried to use libraries that are compatible with a script tag basically, which by definition means that they're compatible with just about any build system that I'm using. Right now, that happens to be the asset pipeline because if I have a problem with the asset pipeline, I can fix it by going to stack overflow and everybody else using Rails here can do the same thing. Once again, I'm trying to use very well-structured JavaScript in minimal quantities for the most important parts of the app that require interactivity and where that link-and-navigate traditional web UI just won't suffice. It's painful because I love writing JavaScript. NOEL: I feel like one of the problems with the asset pipeline is that development basically stopped on it for like six months to a year. I feel like it's still catching up. There's a new version -- the 4.0 version -- has been in beta for a really long time. I don't think it has become final, which addresses some of the longstanding problems but not all of them. DAVE: I wonder how much of it is based on this amazingly designed thing for the world of JavaScript where you just concatenate everything together in global namespace. If you don't want to work that way, it seems that's where it really struggles. NOEL: I agree with that and I don't know where it goes. We have talked about abandoning it for our projects here and haven't really pulled the trigger on it for any serious project yet but we also haven't done something that has required the kind of JavaScript tooling that would push us towards webpack or something like that. In our case, it's kind of... I don't know, chicken and egg? Which comes last? What's the opposite of a chicken and egg argument? DAVE: Kick the can down the road? NOEL: Yeah, that's it. That's what we're doing. That's exactly what we're doing. DAVE: That just means you get the latest and greatest thing whenever you decide and you're not stuck on webpack like the rest of us. NOEL: Yeah, but it's only the latest and greatest thing for a week and a half. Then it's like, "That is so April." ZACH: I think it's common for people to underestimate how much time it takes to setup tooling so if I pick up a webpack really quickly and get it all set up in three days or less, in a way that works in both test and prod as well, then that's three days I spent not building a feature for a client. NOEL: Yeah, at least in the consulting world, the client is never coming to you and going, "What we really want is an efficient JavaScript build process." ZACH: Yeah the user doesn't care what build process I'm using, as long as the web app is performing in a reasonable manner. That's why I personally have a hard time investing in tooling for a given project is opportunity cost. NOEL: Dave, do you still reach for Angular for that kind of single-page? DAVE: Yeah. We're actually having this discussion at work right now. For the longest time, on my team it was like, "If you are making a UI and it is not like --" Because a lot of our tools are like for people in a warehouse so they are a little interactive but they're also very simple so we would just go for Angular because we had the knowledge share and a lot of code and that was all fine. But now, going for Angular 1 seems like a bad idea at this point. Because Angular 2 is completely different, now the entire team is like, "Should we use React? Should we use Ember? Should we use Vue?" We're having this discussion now and trying to figure out what is the right answer there because we've got a little bit of React and the developers are like, "It's not the greatest but it got these pros and these cons." We've got one Angular 2 app and it's the same deal so there's no obvious solution because we don't have any momentum behind any one thing so I don't know what we're going to end up with. NOEL: I built a little app with Vue and I found out that all the things that I thought were really cool about it were deprecated in the next version. Clearly, either I'm not the target audience or there is this persistent JavaScript framework community management problem that they find stuff that people like about the frameworks and strip it away. DAVE: I do wonder how many of them like you can see the logic in the way DHH created Rails, which is I got a thing working for real use case and then I turned that into something generic based on my actual experience. I don't know if that's true for a lot of these frameworks. Angular definitely seems like something that someone sat down and was like, "This is how you should write a framework and then we'll worry about how it actually works to build an app once we've got this perfect thing created." I don't know if any of these frameworks are done the DHH way and have more longevity and have better designs because of it or not. I'm curious about that. ZACH: I think Angular 1 was born out of quick prototyping, if I remember correctly and then kind of grew the way that you described but I believe the very first version was just people are just trying to get something on the page very quickly. NOEL: The interesting thing about that is while I have had several people including both of you say, "I fell in love with Angular 1 because I could do a thing really fast." Again maybe I'm just not talking the right people, I've heard a lot of people say like, "Angular 2 is very different." I have yet to hear an actual line developer come up to me and go, "Yep, I really love what they did with Angular 2." I'm sure it's really good for what they're trying to do. I'm criticizing them from a community management perspective more than anything else -- DAVE: The component-based way of designing, I think, makes a lot of sense so I understand that they want to go there and that's what React is doing as well -- NOEL: Are they targeting bigger projects? DAVE: I guess so. I'm sure you've worked on a horrible Java project with Spring NOEL: I have. DAVE: And like the dependency injection thing for all of its foibles, I do see the logic in there and it's like working on a giant code base that uses that everywhere like it does simplify something so I can see why they might think that. I could see if I had like just oodles of JavaScript, then that might make it more manageable. But it doesn't feel like that islands of interactivity thing it doesn't feel like it's well suited for that anymore. NOEL: Islands of interactivity versus oodles of JavaScript versus sprinkles of JavaScript. I mean, like the Rails community management has its issues but I've come to respect it a little bit more over the last few years seeing other projects kind of stumble with the stuff that Rails actually manages pretty well. DAVE: Yeah. NOEL: That's an odd feeling for me, actually. There's this long history between Rails and JavaScript of Rails programmers trying to avoid writing JavaScript with various and sundry mechanisms and tooling and it's going to be interesting to see how Rails and webpack work together. DAVE: Well, the testing thing too is interesting because Rails was always like, "We're going to give you this super complicated DSL that does all this stuff but there's a way to test it really easily too so don't freak out." You don't get any of that with JavaScript or the asset pipeline. It's like, "If you want to test it, I guess you're spinning up a browser and clicking because there's no way to do it." I'm curious, Zach, about how you unit test if you're trying to keep tools minimal? How does that work for you for testing? ZACH: I use the Jasmine-Rails Gem, mainly because Justin Searls hates maintaining it so I point as many people towards this as possible, just to troll him. He's been my boss, great guy. I love him. Then, essentially just test it as if I were testing Angular components. I find that my front-end unit tests in general, regardless of tooling, are fairly low value just because they're so close to the edge of everything and I love isolated unit tests. I love being able to test drive my code if I'm in that kind of situation and the moment that I realize that whenever I feel the need to extract and test drive a plain old JavaScript class or object, then it's time to push that logic back to the server so that way, the logic has a URL. It's a little heartbreaking. So, minimally but it's quite possible. It's just a matter of managing which files are loaded and which circumstance. DAVE: Yeah, that was always tricky and still tricky. NOEL: If the logic of your system is not in the client, then it's hard to come up with a really high value JavaScript unit test. But if you are using a framework and you have more of the logic on the client side, then you get tied up into how hard to write tests against the framework which not all of the frameworks have really dedicated themselves to making testing easy. DAVE: You know, Angular 1 had a really good story there and Angular 2 like I could not figure out how to get it to test certain things and I ended up using Test Double, Justin Searls' JavaScript thing and because it was super easy and because of Angular it's like, all in on DI, I could do it and I got it working but there's definitely parts where I'm like Angular really should have made this easier for me to test but I just could not figure out, if they hadn't done it yet, if they just hadn't documented it, if it was in a way that made no sense to me, that was a little challenging. NOEL: There was one other thing that I wanted to talk about before we wrapped up which is Angular 2 also prioritizes TypeScript. It's written in TypeScript and it kind of prefers Angular apps to be written in TypeScript. TypeScript is a superset of JavaScript that allows for static typing and optional type inference and a couple of things like that. In the book, you explicitly don't do TypeScript for reasons I think are perfectly reasonable within the context of the book. How do you feel about different versions of JavaScript ES6 versus ES5 or TypeScript or? DAVE: It kind of comes back to that whole tooling and how much barrier you're going to put in front of a user. I can't even imagine how much longer the set up section would have to be if I had to get TypeScript set up because I'm assuming, it would have been a huge pain to maintain. I don't know, I feel like Angular 2 being a rewrite and you have to learn this new thing and set up this other tool, yecch, that's a lot to take on. In writing the stuff in just plain old ES5, I didn't feel like it was that much more verbose than the TypeScript version. I guess that the static typing might be nice when you get really complex. But I was also all in on CoffeeScript for a while and now, it's nice writing in ES5 and I just kind of works in the browser and I don't have to worry about it. ZACH: I like to call it JavaScript because it is the one that runs in the browser, right? DAVE: Right. NOEL: I was also all in CoffeeScript and there has a couple of syntax features that I still miss in other languages. If I was doing it on my own, I would use probably ES6. Have either of you guys tried Elm? DAVE: I did a little bit enough to know that it was very weird and I needed more time to dig into it. NOEL: Elm is a very functional front-end language. Its own language really that compiles down to JavaScript but it's very Haskell-like, functional, no side effects language. Zach have you tried it? ZACH: I'm afraid to even look at it. I'm afraid that I'm going to want it too badly. NOEL: I poked at it in a little bit. It's certainly interesting and I know a couple people who are in a situation where they are primarily not JavaScript developers and they're more comfortable in functional programming and they kind of fell in love with it. It's sort of weird that it's this huge community of JavaScript developers that at the same time is everybody's common language and yet, so fractured by different framework, and TypeScript and ES6, and ES7, in a lot of stuff. DAVE: I'm tired of typing function to be honest but if I have to type function and makes my build and life easier, then I'll keep typing function. NOEL: Yeah, you need macros for that -- [Laughter] ZACH: I'd say probably the one feature from- By the way, can we give up on ES2015 given ES2017. It's 2017 now. NOEL: Does anybody still call it that? ZACH: The only people that call it that are JavaScript people. If you ask the standard developer, what ES6 they'll know and they've never heard of ES2015. Give it up. NOEL: When they do 2009 more versions, they can call it ES 2017-- ZACH: Yeah, and I'm fine with the ES2017 or whatever going forward. Let's just rename it, regardless. I miss default parameters or probably, the thing that I missed the most -- NOEL: Zach is against time -- Oh, sorry that's you missed when you're in ES5? ZACH: When I'm in JavaScript, yes. NOEL: As opposed to Babel, which is actually what I -- yeah? DAVE: I think this whole thing is sort of the crux of it like there's several different names for the same thing and the community can't even agree. Is it ECMAScript? Is it JavaScript? Is it 2015? ES7? That's -- I don't know... NOEL: It is crazy. I guess you're not really marketing your book to JavaScript developers because you're sort of teaching the JavaScript but do you have a problem trying to find JavaScript developers in marketable clumps? DAVE: I don't know. We've been kind of punting on full stack developers who can just do JavaScript and not complain about it. But we are starting to look for frontend developers and I don't know how that's going to go because that could be a problem. NOEL: We kind of like to wrap this up with one resource or tip or something that somebody can takeaway today and use to their benefit. Dave, you got something? DAVE: I mentioned Test Double before and I'll mention it again -- Test Double JS. It is a great mocking library for JavaScript. It makes total sense. It's very easy. It's incredibly well-documented. I would check it out if you're doing some JavaScript testing and like isolation. NOEL: Justin is definitely obsessive about making it well documented. DAVE: Yes. NOEL: That's Test Double JS, which you can find on GitHub. DAVE: Yep. NOEL: Zach, do you have something? ZACH: Yeah, as a developer, don't feel forced into choosing between a single-page app and a non-single-page app on the first day of your development. There are infinite points in between when it comes to interactivity. Whenever possible, try to make decisions that don't paint yourself into a corner in the future and pick whatever level of JavaScript suits your needs today and don't worry about the need, six months down the road quite as much. DAVE: That's good advice. NOEL: I wanted to mention one kind of bittersweet thing, which is several years ago, I self-published a book called Master Space and Time in JavaScript, which talks a little bit about frameworkless JavaScript and then talks about frameworks that are now terribly out of date. But the part of it that talks about frameworkless JavaScript, which is the first couple parts of it, actually a lot of it, I think is still good advice. I have recently made those available for free at NoelRappin.com and it talks about testing using Jasmine to test and it talks about, mostly jQuery but frameworkless and little sprinkles of JavaScript so if you're interested in that and you can get over the fact that the code is a few years out of date. And Webpack wasn't even a glimmer in a glimmer of somebody's eye at that point, if you can deal with that, I still think there's some good advice there. That's it, NoelRappin.com and you can find it from there. Thanks to Zach and Dave. Tech Done Right, you can find us, this podcast at TechDoneRight.io or you can download it via iTunes or wherever you get your podcasts. Again, if you'd love to leave us a review at iTunes, that would be great. You can send us feedback or ideas on Twitter at @Tech_Done_Right. The Tech Done Right Podcast is brought to you by Table XI, a UX design and software development company in Chicago. Table XI has 35 meticulous and curious minds with a 15-year history of building websites, mobile applications and custom visual experiences. Our partners trust us to create innovative solutions that drive their businesses forward. Find us at TableXI.com where you can learn more about working with us or working for us. We'll be back in a couple of weeks with the next episode of the Tech Done Right Podcast. Thank you Dave and thank you Zach. DAVE & ZACH: Thanks for having us.