Episode transcript

Edit transcript

Ryan Burgess: Welcome to the very first episode of Front End Happy Hour. The show where we, over drinks, talk about everything front end development. Since we are a happy hour show we will be enjoying drinks while we discuss today’s topic. Each week, we will also choose a keyword that we will all drink to each time it’s said. For audience participation, we encourage you to drink along each time the keyword is mentioned. What have we decided this week’s key word is, guys?

All: Tools

Ryan Burgess: Awesome. So every time we say tools, take a drink.

Derrick Showers: Just to be clear that’s Javascript tools.

Ryan Burgess: It could just be tools in general. We have an exciting episode today where we debate a Medium article published at the start of 2016. It talks about the state of web development. The article titled “The Sad State of Web Development” was written Drew Hamlett and provides his thoughts on things that are troubling to him about front end development. In this episode, we’d like to share our opinions and thoughts on this particular article, whether we agree or disagree, we’re going to debate whether it’s a good article. Before we get started, I’d like to take a moment to introduce Front End Happy Hour’s panelists. Let’s have each of us go around and give a brief introduction of who you are, what you do, and what you’re favorite happy hour beverage is. Derrick, you want to kick us off?

Derrick Showers: Sure, so, I’m Derrick showers. I’m a front end developer at LinkedIn. My favorite happy hour beverage is probably my favorite beverage, which I guess makes sense, is an old fashioned.

Ryan Anklam: My name is Ryan Anklam. I’m an engineer, a UI engineer, at Netflix. My favorite Front End Happy Hour beverage has got to be beer. I’m from Wisconsin. Our baseball team’s called the Brewer’s. So I’ll stick with that all the way.

Jem Young: Hi, my name is Jem Young. I am also a UI engineer at Netflix. My favorite happy hour drink is probably gin and tonic. You can’t go wrong with that nice, sweet, refreshing. Any time of the day.

Augustus Yuan: My name’s Augustus Yuan. I’m a front end engineer at Evernote. I think my happy hour drink, I’m pretty into the moscow mule.

All: Nice.

Ryan Burgess: Where’s your favorite place to get a Moscow mule?

Augustus Yuan: I like the Martins West in Redwood City.

Ryan Burgess: They make their own ginger beer, it’s delicious. I’m Ryan Burgess. Along with a few of the panelists here, I work at Netflix, as well. I’m a UI manager there. My favorite happy hour beverage, I’m going to have to go with Derrick’s, as well, is an old fashioned. I’ve always liked them and they’re delicious. Anything whisky is probably my favorite choice. Let’s jump into our discussion today. In the first sentence of this article, it reaDerrick Showers: “2015 is when web development went to shit.” Drew’s statement is basically highlighting a lot of things throughout the article, but a lot of it is focused on how it’s actually, front end development is a lot harder. You used to be to just open up a text editor, start writing some HTML, Javascript, CSS. things are now a lot more complicated and convoluted. What tools to set up and get started. How do you guys feel about this statement. Is true or do you agree?

Ryan Anklam: FIrst of all, clearly, he was not around in the early to mid 90s. Because, web development really, really was shit back then. IE6, IE5, little yellow icon to let us know something went wrong. Click on that and got help us, right. No, he wasn’t around long enough to know what real shit is.

Jem Young: I have to agree with Ryan. When I learned Javascript, it was way back when and the way to debug it would console log everything and alerts. No, sorry, it wasn’t console logs. It was just alerts, you would alert at everything. So it was, like, alert object, alert this. So, we’ve come a long way and it’s much better now, I’ll take that over the 90s, early 2000s every day.

Augustus Yuan: I was probably not even born for that. I’m pretty young, but, I guess I don’t know. But, I’ve also done, developed in the older browsers and you have to use alerts in those older IE browsers. I think it’s, like, just way easier to get jump started, right now with all these different starter kits. I do kind of like have some sympathy for what he’s saying in some respects, but I do think overall there is better.

Derrick Showers: I think the other things that’s obvious here, is the complexity of apps on the webs has grown tremendously since the 90s, right. I mean, yeah, you could get away with just using Javascript maybe ten years ago but it’s a very different world that we live in now and I think we’ll get to later, talking about single page apps and like is that the way to go. Obviously, I think everyone would agree there’s a least some use cases for single page apps and for that kind of stuff you need some sort of ***Fragemarking???*** tools to get started with that.

Ryan Burgess: Yeah, I guess you could write it from scratch. There’s a lot already taking care of, like why would you want to redo all that? As Drew in the article starts talking about node and mpm, he talks a lot about microservice and things that come along with node. He also references another article, engineers being basically magpie developers. Which, what he means by that, is that we’re distracted by the next shiny thing. How do you guys feel about that statement? Is that accurate or do we disagree?

Ryan Anklam: I’m definitely a magpie developer. There’s no doubt about it. That’s one of the things I love about my job, right? Where there’s always something new to learn. Nothing is stale and old and boring. There’s always the next challenge right around the road and I love that.

Ryan Burgess: Yeah, I have to agree. That’s what keeps us on our toes as front end engineers. We’re constantly having to see what’s the next things. How can we leverage it? Is it something useful to what we’re working on? Or just sometimes, it’s just worth just checking out and it’’s really cool to see what the industry’s doing and what’s changing.

Derrick Showers: I think it’s an advantage of being in an environment where there’s so much open source stuff going on. I mean, what’s the other option that we just all follow in line after one person builds something and then we just fall in line and all use that, I think that’s probably a worse alternative.

Ryan Burgess: We could still be stuck on jQuery. We could still be stuck on it. Not to hate on jQuery it got us to an amazing place. Which, I feel like, all the frameworks kind of do. They’re stepping stones. They get us to something better and greater and yeah, you could still be stuck on the old technology, but why? When there’s something else that makes your life easier or better, makes the user’s easier, better.

Ryan Anklam: I think that’s a great point because, we’re still learning how to do this shit and without a lot of tools. Front end engineering, as a profession, is really, really new and we’re still figuring out how to do this stuff so that’s why it’s evolving and that’s why there’s new tools and that’s why there’s something new and shiny every couple of months because we haven’t found the best way to do this yet. Maybe there isn’t a single best way, but we’re still learning and applying everything we’ve learned into these new tools.

Derrick Showers: Yeah, I think the alternative is, I recently go into doing some stuff with Swift and trying to build my own app and it is somewhat refreshing that you’re told how to do everything because you learn one thing and then that’s how it is. But, I could see how that could become kind of annoying after a while. It is just nice to have the ability to branch out and figure stuff out together as a community versus having Apple decide it all for you.

Ryan Burgess: When you say that, are you meaning javascript versus Swift? Javascript is pretty much like what we’re talking about at that point.

Augustus Yuan: Yeah, I think you guys brought up some good points in that it’s good if it’s like something that's like optimizes your process or anything. I think there is this distinction between chasing shiny new things. It’s good to explore them but it doesn’t make sense to move everything over to that unless it’s really helping you and I think that might be what he might be frustrated about. All these people are chasing these shiny new things and then they’re like, hey guys, let’s all just do this. But it might not actually make sense and I think it’s really important that they distinguish, like does this make sense for us and stuff like that.

Ryan Burgess: This would be a perfect example of, like, something using the tools, like *** Gulp and Grunt *** is that a team could have started with something like Grunt and then do you just automatically switch because everyone is switching to Gulp, does that make sense? Now the next new **??? 9:03** is probably not using either and then you’re using MPM. I do see his point that when it makes sense to change you’re not necessarily going to change every, every day you’re not going to change framework or way of building something, that makes a lot of sense.

Derrick Showers: Maybe what he’s getting at, and the real truth of it is, is sometimes we are very quick to adapt these shiny new things without actually putting the necessary thought behind it or actually thinking about how… LIke I think the MPM and Gulp/Grunt thing is a really good example. People are like, I need to write all these tests in Gulp because it’s the way everyone uses it or Broccoli now, at least in the Ember world is pretty popular.

Ryan Burgess: I was just going ask, is Broccoli that popular right now? I didn’t know that was a thing in the ember world.

Derrick Showers: I mean if you’re just watching SASS and you need to compile it to CSS you can easily do that with NPM. I think that’s what he’s getting at and I think he has somewhat of a point there. I think when you adapt things just because they’re new and cool.

Ryan Anklam: If a tool is new and shiny, it doesn’t make things better it’s not going to have the adaption rate of something like React had, right? React literally makes my life as a web developer way better and, you know, the community has spoken about it. Everyone is implementing it. He talks about it later on in the article and they’re implementing it because it’s a good idea. It makes our lives easier, it helps us produce production code and it features out faster and with less bugs. So, there is power to the community. What we tend to gravitate to usually is a step forward for web development.

Ryan Burgess: And it’s also tested, right? That’s the thing, too. Someone like Facebook created this framework because they were trying to solve a problem and as they’re building it they’re testing it on a fairly large website with a large amount of users actually using it. So, it’s tested, so they’re using it, other people are using it, it’s open source that they’re actually fixing these bugs and issues that come up and so I think that helps, too. It’s tried and true because people are actually using it. So, the more people use it the better.

Derrick Showers: Yeah, that actually reminds me of a talk that I saw at a conference once about jQuery and why you should use jQuery nowadays when you could do essentially everything. But one of the things they mentioned, that I thought was a really good point, is that it’s tested. So if you’re doing everything in Javascript you have to write more unit tests to make sure that you’re getting what’s going to work. Use jQuery, you get it for free.

Ryan Burgess: I think to me, as I kind of joked about still using jQuery, I think it was so powerful that jQuery actually made Javascript so great because you’re actually able to support legacy browsers. Like, I remember having to support IE6. There’s no way that you could have done all the latest and greatest browsers and still supported IE6 without something like jQuery to get us there.

Ryan Anklam: The output that we had when we switched to jQuery, my job so many years ago, was amazing. When you go from writing vanilla javascript and having to do all these shims, or whatever, for all these other browsers, from that to jQuery, I mean we shipped so much more code. It was better code, it wasn’t always the greatest idea. When we got jQuery, we decided to jQuery the hell out of everything we ever did.

Ryan Burgess: And did you write jQuery plugins for everything at that point?

Ryan Anklam: Oh, yeah, everything.

Ryan Burgess: That was the way to go.

Jem Young: I look at it like this, I’ve heard the vitriol against Javascript because it’s evolves and we don’t know what we’re doing and we’re constantly reinventing the wheel. But, you don’t have to do it, no one’s making you. Javascript at the end of the day, is still going to run the browser, if it runs in the browser, then that’s what’s current. Like no one’s making you use grunt, or gulp, or broccoli, or stuff like that. But, I hate to say it, but you can always switch languages. Like, if someone’s not comfortable on the front end then that’s just the nature of being a front end engineer these days, keeping current. You can switch languages, like C doesn’t evolve that fast, java. I’m not hating on this guy, or anyone in particular, but I’ve heard javascript is evolving too quickly and you guys don’t know what you’re doing. And, I’ve heard that a lot from a lot of different engineers. At this point, I think it’s getting old, because javascript’s the dominant language in the world. It used to be PHP but not every site runs PHP but every site runs Javascript. I say Javascript’s number one language in the world so it’s like, we need to just need to get over it and accept it, that’s just the nature of things.

Derrick Showers: It’s interesting, because the one thing he talks about in the article is, he says, every developer that goes through college should write an application in node, deploy production, and update their dependencies three months later and no one will want to do front end development. From what you just said, probably a lot of people feel like that’s not a common..

Ryan Anklam: The truth is, I’ve felt that way, too, I’ve had a dependency patch version break my code. Because, the developer, whoever wrote the module doesn’t really understand what a patch was, it’s not supposed to be breaking. I’ve felt that pain and we solve that pain and we start shrinking wrapping our dependencies that were pinned to a specific version and I haven’t had that problem again.

Ryan Burgess: Yeah, I think that actually brings up a good point. Shrink Wrapping is a perfect example of that is that you can actually mitigate that risk by leveraging other people’s packages. That’s a perfect example of why you would use shrinkwrap.

Ryan Anklam: And is that problem unique to javascript? What about ruby gems? No ruby gem dependency broken things when someone revved a module?

Ryan Anklam: True, but he does reference ruby in here. Saying that it’s like, basically, that we took everything that was great in Ruby and rewrote it for javascript. Is that a good statement to say? He calls it the official motto. I don’t agree. I know gems are very similar, but I actually disagree. I think there are differences. I guess I’m not a huge Ruby guy, so maybe I’m wrong to say that but I would love to hear your takes on it as well.

Derrick Showers: I’ve definitely heard that before from people that are well versed in Ruby, but, sure. Every language starts that way, right? But, all the frameworks we have around node and mpm and stuff like that. The people that were involved in that could have been [inaudible] I don’t think that it’s the official motto.

Jem Young: I think his point about MPM modules kind of spot on a bit. We do have probably too many MPM modules as someone who’s released a few myself, I probably don’t need to. I probably should roll those back. But, it’s fun. It’s absolutely fun.

Ryan Burgess: TO that point, basically we’re making smaller microservices, whatever we want to call them, but we’re basically making something that does something really well. So I kind of like what to challenge that as is that a bad thing to basically write a function that does one thing well and then you create a module for that that someone else can use. Yes, it only does that one thing but is that bad to do that? I feel like, it should only do that.

Augustus Yuan: I was actually contemplating this and I remember stumbling upon, do you guys know Sindre Sohrus? The guy who has tons of contributions on Github. He’s just incredible and he did this AMA and this guy asked like this exact question. What are your thoughts on one line modules and stuff. And I actually quoted him so I’m just going to say this: “By making small focused modules you can easily build large complex systems without having to know every single detail of how everything works. Our short term memory is finite. Other people can reuse these modules and when a module is improved or a bug is fixed, every consumer benefits.” I think that’s a really good point. He also goes on to say, this wouldn’t really be possible if it weren’t for how MPM works right now. We should be modularizing things so everyone can get the benefits.

Ryan Burgess: So we should be embracing MPM, basically.

Jem Young: If you listen to people on TC39 like what they actually say, modules are huge. My favorite ES6 feature is the module system. Because to me spread, rest, all that light **cons??** it’s awesome but the module’s the most powerful because that’s going to allow you to write javascript, just like Augustus was saying, like individual tiny modules. And that’s what the people on TC39 want, like they’re saying that’s the future of Javascript not monolithic apps and monolithic jQueries. It’s probably not going to exist anymore in the future, it’s going to be all tiny modules, call them what you want.

Derrick Showers: It’s like what jQuery plug-ins tried to be.

Ryan Burgess: I think that’s a good way to put it. It saves copying and pasting. Like because you can literally use this function or module or whatever we want to call it at that point, but you don’t have to copy and paste it and put it into another script. You just use, you can have unit tests specific to that actual specific function. That’s huge and I think that’s a lot better way to look at it.

Derrick Showers: I think when you’re working on big stuff, like the companies that we work for. I remember my first job as a developer, I was trying to just do a carousel or something and I was like, is it ok for me to use a jQuery plug-in for this? And everyone was like, I’m not really sure. Like, maybe. Maybe just copy and paste it. But, like, the cool thing about MPM modules is that everything comes with a licens, you know, like you just build it into your app as a module. You don’t have to feel bad about reusing something that somebody else had built. YOu don’t have to feel bad about not reinventing the wheel every time.

Ryan Burgess: I kind of like that, too. You’re also not copying and pasting someone’s code. So it’s not like you ripped it off. It’s like, no I, literally, linked to this person’s package, so yes that’s ok. There’s a license, there’s credit given, there’s a lot of that. I do like that, that’s actually a very good point. Just going on to stack on, copy and pasting someone’s snippet. It’s like you’re actually like no, no, no I’m technically giving credit to this person.

Derrick Showers: So, has any else gotten burned by MPM? Like he said, write a big app and try and update your ***redundancies?*** three months later.

Jem Young: I’ve been burned so hard. My last company, we were, it was like a small two man team, me and my friend Yuval Ziegler. We were on the bleeding edge, we were proud of it, we were like, React Beta, React Router Beta, everything beta. Then when things actually went main, we got burned so hard. We screwed ourselves so hard. You learn a lesson doing that, like probably don’t do betas for production code. We walked right into it. Joke was on us in the end.

Ryan Burgess: You were the magpie developer.

Jem Young: Oh, totally. It was worth it, though. For one glorious three months, we were on the edge. We were on the edge and it was live.

Ryan Burgess: Let’s jump onto another section of the article. Obviously, this is going to hit one of our keywords, but, he talked a lot about front end tools. In the article, he picks on these things like Babel, PostCSS, Gulp, Grunt. I agree with Drew that we do rely a lot on these extra pieces to build our application but I think there is some positvives and negatives to using them. These things we use, I’m going to use the word tools.

All: Cheers.

Ryan Burgess: They do help us automate a lot of the tedious task that we normally have to spend manual time doing and this actually helps us focus a lot on what we’re actually trying to do to make features better, make our user experience better. So, how do you guys feel about that? Is it something that we should avoid using tools or just embrace the fact that they’re there?

Ryan Anklam: Here’s my unofficial poll on why tools are great. Raise your hand if you would rather write CSS over Sass or ***Lex?? 22:05*** I would never go back to Sass. You need a tool for that.

Derrick Showers: Yeah, the same thing’s true of, since I’m writing do much ES6 at work, or ES2015, whatevr the magpie title is, I mean even for the simplest of projects I’m setting up some sort of like you know, transpiler or whatver to write.

Jem Young: I had a shower thought today and it was, I have good ideas in the shower. So I started off writing C-Sharp and C-sharp.net and I was using Microsoft, I forget the name of it right now. Visual Studio. So I started off using Visual Studio and it was like the most fantastic thing because it did this, code completion, builds for you, did all this fantastic stuff, and I came to realize that’s actyally what Javascript tooling is doing it’s just not built into an IDE ***??? 23:10*** So, if this were built into IDE we be like, oh yeah it just does that for you. But, there is no one IDE that does this so we have to build our own tools until the IDEs catch up and by the time they catch up, we’ve already moved on. But essentially, we just move that away from the big companies into the hands of smaller engineers. What do you guys think? That was my shower idea.

Ryan Burgess: I like the shower idea.

Augustus Yuan: One thing that I do what to talk about is, post CSS. I feel like it’s kind of misunderstood because I think he sees post CSS as a replacement for Sass. I disagree with that. He doesn’t even mention Sass that much in his article and he talks about how PostCSS has all these plugins and it takes so much time. I feel like the responsibilities are different. Sass, I feel, encourages way better code and it solves a lot of issues that ***fighting??** CSS you wouldn’t have and I feel PostCSS is more for cleaning it up. I think practical plugin for PostCSS is removing vendor prefixes so you’re supporting all these older browsers, you have all these vendor prefixes, and then later down the road when you don’t need it you can just remove them.

Ryan Burgess: I agree, I think that’s a perfect way to look at it. Is that it’s not, it’s not off by itself. You would still use ***Less??** or Sass but you’re still able to use this after the fact and clean up and support different browsers, versions that you’re dealing with. I think that’s a perfect example. I don’t agree with him saying, that, he just really wants to use Sass. Like, you can use Sass but also use PostCSS with it.

Augustus Yuan: Yeah, and he has this sentence where he says, “I just want to install something and use it not decide all the little plugins I want to use.” But for PostCSS it makes a lot of sense to separate that out into a bunch of small plugins because not everyone is going to optimize or clean up their CSS code in the same way. Maybe you want leave the vendor prefixes because you support older browsers and stuff like that.

Derrick Showers: And that exists everywhere. It’s not just in front end development. I actually agree with this statement and somethings. Recently tried to get on board with VIM because… I know there are people who love VIM, love Vim, but my big complaint against VIM is that I’d rather just install something and be able to use it. I don’t like having to look through a million different plugins to find out what actually is making things behave the way I want it to. So I do think he has a point with that. But, I agree with you, with PostCSS it’s a little bit different of a situation. You’re taking parts of, portions that you need in order to, everyone has a different circumstance. I agree with it, but not in this context.

Ryan Burgess: I think VIM’s a good example because I’m on the train of wanting ot be good at VIM but every single time I try and do it, I know I’m losing time and I just go back to whatever I was using in the past. That’s a hard one for me to over that hurdle, and I want to be there. I know Ryan, you are there. I’ve seen you on it. Like I watch him on there like, damn I wish I was that good.

Derrick Showers: I totally agree. I look at people in awe as they’re going through VIM screens super quickly and I’m like wow, this is just mesmerizing.

Ryan Anklam: There’s only one way to do it and that’s uninstall everything else. I took off **Atom** I took off Sublime. I took off anything that was easy to use and just suffered.

Ryan Burgess: You dove into the deep end. You’re like, I’m in. I”m on the VIM bandwagon and I’m not going back.

Ryan Anklam: I couldn’t go back. I’ve tried to use other things and I’m using VIM commands in SUblime.

Ryan Burgess: In part of the article, Drew actually talks a lot of smack about React and single page applications, so not just not React but ANgular, Ember, basically using frameworks and deciding whether or not people should actually be writing single page applications. He’s also pretty hard on some companies who actually do use React in their code, places like Netflix, Yahoo!, and AirBnB, and Vimeo. He kind of says that he’s seen React, I think Ryan you mentioned earlier, that he seen React in so many different place, like we said, not really sure that’s a bad thing. I’d like to get your take. Is it bad to write a single page application? Are we over-engineering something that could just be back to the HTML 1.0, old-school way of writing things. Are we adding more complexity for something that’s not necessary?

Ryan Anklam: It’s all about the user, right? I think a single page application in most contexts is a much better user experience. I mean, could you picture Gmail as a traditional application? Every time you clicked that email you refresh the page and wait for everything to parse and just reflow and everything again. Every time I get an email I have to refresh? That would be obnoxious. I think in not most cases, but there’s a good argument for single page applications being a much better user experience.

Jem Young: I think you make an excellent point and he makes a good point too, in that I don’t think you always need a single page application. For instance, the team we work on, acquisition, is not a single page application. We use React, but they’re all one pagers. So, I mean that’s a good instance where we don’t need a single page application. I look at it like, my mom wants a website, I’m not going on AWS and set her up with her own server and do all this fancy stuff because she doesn’t need it. Like, wordpress would be just fine for her and same with single page applications. You probably don’t need them a lot of times. I see a lot of sites, I guess I'm going to have to disagree a little bit, you see a lot of sites where it’s totally over, like Angular and all this, but it’s really like maybe a two page.

Ryan Burgess: I don’t know if you’re disagreeing. I think you’re actually just making valid points and Ryan was kind of saying the same thing. It’s finding the right use case. You can do it for no reason, like there are perfect examples where you use just a Wordpress site for your mom’s shop or whatever it may be, and that’s perfectly fine. You don’t need to build a whole single page application, over-engineer it. So, I think, yeah, I think both of you are kind of saying the same thing. It’s like there are reasons for something like Gmail being a single page app. But, there’s something liek a small website with a “contact us” and like “about us,” that doesn’t really need to be a single page application.

Derrick Showers: I think, too, he calls out AirBnB, essentially their details page. So, I think just looking at this there’s things give you immediate feedback. So you pick a check-in date and a check-out date and it tells you right away if those dates are available. Whereas, I feel like something like React, and i’m not a React person, just to clarify. But I feel like something like React is a smart move in this situation. Because, yeah, the whole thing doesn’t need to be a single page app, but there’s an element on the page that needs to give you that immediate feedback and that’s what’s great about React, as far as my understanding is concerned. There’s an element on the page that you can kind of manage separately from the rest of the page. I think this is a great example of using React and the other thing that I would add is, we’re in a world where people are so used to that immediate feedback. Especially, with mobile apps and that’s what we on the **Levs?? 31:06** have to compete with and that’s what you always hear as a huge advantage that mobile apps have is you have this, whether they come ***out site??*** or not that’s what they need, they need immediate feedback. You aren’t waiting for page refreshes. Like I don’t want to type in a check-in date and a check-out date and wait for the page to reload until it tells me it’s not available, so I think it’s a perfect example where it’s great to use something like React.

Ryan Anklam: Yeah, I think, [inaudible] the mobile applications is probably a good example because the only time you’re waiting is that initial startup but once your initial startup is done, you’re done, everything else is seamless. You’re just like, it loads it’s done, maybe have to do a little data fetching but not a lot. You’re not waiting a ton, you’re not doing a whole page refresh, a whole rerender, it’s like just a small component that’s actually rendering.

Derrick Showers: It’s the difference between an app versus a website, right? And that’s really all you think about. You know what I, so for a marketing website, would I create an app for that? I shouldn’t. That’s overused sometimes, too. There’s companies that are creating apps for marketing websites, which is… You don’t need to do that. Same thing is true with single page apps to websites. AirBnB is an app so I think it makes sense to do a single page app. You’re booking a vacation it warrants it.

Jem Young: Totally, I think HTML, CSS, and some Ajax would probably solve like 80% of use cases out there. But people are like, oh no, I’ve got to build an app because it’s hot. Which, I mean, it’s pretty cool. But, yeah, I agree with everybody here. Most of the time you don’t need an app. I mean, think about what an application is versus a website and I think the line’s gotten a little muddled and I think that’s why we’re at where we’re at today and why he’s on a small rant about single page apps.

Ryan Burgess: I want to challenge you, too, on the one point you said about doing a sign up flow or something like that, is that would it be bad if it was a single page app? Because it might be a little bit quicker, you know, I know some of the stuff you’ve been working on is not, it’s more that traditional page by page. But if it was a single page, would that be wrong?

Jem Young: It would definitely work for, without giving to much detail into what we actually do because that’s another podcast, but, yeah, it would totally work. Would it increase complexity? Probably. Right now, it’s easy to jump in as someone pretty new to Netflix. It’s easy to jump in because this page is this page, there’s no React router.

Ryan Anklam: What about from a user’s aspect. From something like that, right, you’re going to pay the tax, either you’re going to have to download a bigger Javascript payload, bigger CSS payload, for a single page application so you’re going to wait for that page. The time to interactive might be a little bit slower but if it’s an old click and refresh, you’re going to wait between those state changes in the application, so which one’s better for the user?

Ryan Burgess: That’s a good question that I’m not actually sure how to answer.

Ryan Anklam: Because people are so used to getting immediate feedback, are they going to get bored waiting for the page to load and leave right away or is it that transition between pages that’s going to lose your user. Where do you draw the line?

Ryan Burgess: Yeah, and I think it’s like someone coming to your page for the very, very first time. I feel like, maybe if you could balance it, too, that maybe the first homepage is kind of separated from the rest, like a signup flow or something like that. That that might make sense. You kind of break those two from, maybe your homepage is like not part of that single page app because then you’re not downloading all that extra, but maybe the next step is a signup flow or whatever it may be. Maybe that’s where it is. I’m not sure, because I do agree with you we’re so trained to be like, oh, too slow I’m out. Especially for the first time visiting something, you have no idea how long that’s going to load. So, if it takes extra just to load that first single page, that would be terrible.

Ryan Anklam: That’s why we’re doing all this isomorphic stuff, right? We’re paying a huge tax to render these applications isomorphically now, or universally, I’m sorry. Wrong word. So, yeah, now we’re paying this huge tax to render these apps universally because that fraction of a second we’re going to save up front is worth it to the user’s experience and while they have something to see right away, we can be loading up that Javascript and making the page interactive, while you actually see something. It’s not a blank screen.

Augustus Yuan: I feel like it does get kind of convoluted with like SPAs and stuff because you are trying to create this seamless experience, where you’re trying to make, especially with the login flows, make that experience as quick and clean as possible. There are definitely situations where SPAs don’t make sense, if you’re just making a random landing page for an email. Like, hey, people come to this and I’m selling registrations or something, unless that goes on to something if you want to make that seamless. I think it’s also interesting how he points out you shouldn’t build an SPA and he goes really strong with this: “When you think you need an SPA just stop thinking. The users just don’t fucking care.” I don’t know, I felt like that’s kind of an interesting thing he said because, if my users don’t care and it’s better if we feel it’s a better seamless experience for them, why not do it.

Ryan Burgess: Well that’s the funny thing. We’ve actually all made that point that it’s better for the user experience and so he is literally saying that it’s not. And I disagree with that. The users do care and if they’re waiting in between every single page, that’s just a painful experience.

Ryan Anklam: You have complete control when you’re doing that. If you feel that it’s a better user experience to make them wait a second or two because I’ve heard that that actually makes sense. Because when you’re saving something and it switches right away, switches your view immediately, that gives off the perception that the user doesn’t feel like it actually saved. But, you have complete control over a single page app. You can fake the two seconds, or the second, whereas if you’re dependent on a page refresh you have no idea how much time that’s going to be. We take it for granted, I think, at least I do, in San Francisco sitting on top of servers that are right here, it’s so quick. But, if you’re in other countries you realize this pain.

Ryan Burgess: Sure, yeah, I think to speak to that, we’re in a bubble. We definitely, Silicon Valley, we have faster speed internet connects. You’re right, so someone in India or some place where it might be a slower connection they’re going to experience those pain points even more than we would here. So, I think that’s a good point.

Jem Young: I think I’ve just been burned by too many single page apps. In that, if I log into something, ok Javascript’s downloading I’m in the app but if I click something and it’s got to load again, at that point what are we doing? You could have just built out a website because if you build it properly, like Ryan’s saying, yeah it should be seamless, all the data should be loaded like prefetch everything. But, a lot of times that doesn’t happen and then I end up in this terrible state where it’s just like, I see where he’s coming from. Like, why is this an app? We could build a website. At least that way I can refresh and I know I’ll be back to where I started.

Ryan Burgess: So, my biggest pet peeve adds to that. When you’re in a single page app and you do a couple of interactions, maybe you’re technically loading that fake page or different panels or whatever you want to call them, different states and then you hit the back button and it just takes you back to google because you googled their site and I’m like, no! I should be able to hit back and go back through those interactions even though it’s a single page application at that point. You should still be able to interact with it like it’s not. That is my biggest pet peeve. I know it’s extra work but it’s totally worth it and it makes the user experience that much better.

Derrick Showers: That makes it so easy to manage that, too.

Ryan Burgess: Yeah, I say it’s more work but it’s an extra step. I guess that’s maybe what I should say. It’s an extra step for single page apps.

Derrick Showers: Most of them, I don’t know so much about React, but Ember and even Angular I’m sure they manage it for you, so you don’t have think about it. So, that’s another example of, if you’re using just jQuery you have to think about that for sure.

Ryan Burgess: You have to write that yourself or find a jQuery plugin that does it. Alright, to end our episode we’re actually going to take something from Javascript jabber where they talk about various picks and things that they like whether they mention various frameworks, things they’re reading, or tools that they like to use.

All: Cheers!

Ryan Burgess: But, basically anything that would be useful. So we’d like to share with our audience anything that we find useful and would like to share back with the community. Derrick, do you want to kick it off with your picks this week?

Derrick Showers: Sure, so my first pick is Let’s Encrypt. It’s an open source, essentially a way to get an SSL certificate and it’s really easy. I looked at it a couple of months ago. I was like, oh, I’m not sure. It was still in beta, now it’s in public beta so it’s increased its exposure to everyone. Yeah, so all you do is if you’re running Apache you literally [inaudible] two lines and it sets up everything for you. What’s great about that is you can use web workers which is something I just added to my personal site which is awesome. If you want HTTPS, which everyone should be on, I think it’s become more and more popular, it’s definitely an easy way to do it and you don’t need to have Apache but that’s the easiest one to set up a script for that. My second one is, I thought everyone had heard of this until I talked to Ryan today and he was like, what’s this? Product Hunt, awesome if you’re really into, like me, finding out about new products. It is, producthunt.com, awesome. I recently found out I have the ability to add new products to it. It’s like invite only, but I guess the comments I made were…

Ryan Burgess: They were valuable comments!

Derrick Showers: Yeah, so they separate it out into tech, gaming, and podcasts. So if you’re looking, they do a new thing every day, so if you’re looking to purchase any products it’s worth checking out.

Jem Young: Are you going to add Front End Happy Hour to the podcasts?

Derrick Showers: I mean, of course.

Ryan Burgess: Ryan, your picks?

Ryan Anklam: My two picks. The first one is the website frinkiac.com and if you’re a Simpson’s, a crazy Simpson’s fan like I am, this is probably one of the greatest websites every created. It basically takes every episode of the Simpson’s, scrapes all of the audio from it, and you can search every episode for any quote that any character makes. You can export it into a PNG, download a graphic or an image. That’s changed my life. I’ve lost a lot of hours because of this website so far.

Ryan Burgess: I wasn’t really surprised that you put this one on here, either. We all know Ryan loves the Simpson’s.

Ryan Anklam: Probably wouldn’t be a surprise as my first pick. The second pick is the Red Rising Trilogy. If you’re into sci-fi, these three books are just absolutely amazing. I’ve spent many, many hours reading them, and reading them over and over again, listening to the audiobooks. Just an awesome story. Then my third pick, I know I don’t get three but I’m taking three anyway, is the word tools.

All: Cheers!

Jem Young: I actually bought the first book in Red Rising just because you said it. It looks interesting, I love sci-fi.

Ryan Anklam: You’ve got to get through the first hundred pages of the first one. It’s starts off really slow and then from about the hundred page mark of the first page all the way through the second books until, the last book tapers off a little bit, but, yeah, the last two-thirds of the first book and the entire second book is just awesome. I couldn’t put it down. I sat down and just read it. I was brushing my teeth, I had that book in my hand. When I was drinking coffee, I had that book. It was an amazing, amazing book.

Jem Young: Looking forward to it.

Ryan Burgess: Now we’re all going to be reading Red Rising. Jem, what are you picks for this week?

Jem Young: Yeah, I have three picks. The first one is Syntax Con, it’s in South Carolina May 5-6th. I’ll be speaking there about service workers and the future of Javascript. So, you know, if you guys want to come on out, I’ll buy you a coffee.

Ryan Burgess: Are you buying their tickets, too?

Jem Young: Yeah, send me a good haiku, it has to be about javascript, though. The second one is, Planet Money, the podcast. I listen to it on the shuttle on the way into work. I love Planet Money. It’s one of my most favorite things in the world. Third one is, macbookselfiestick.com. Just go there. You just have to see it. Definitely get one if you can because they’re amazing.

Ryan Burgess: I have to ask, are you going to get one?

Jem Young: Yes, I am! I’m going to get one and then hang off the shuttle and then take one going down Market or something, just so everyone can hate tech.

Ryan Burgess: Even more.

Jem Young: Yeah, even more.

Ryan Burgess: Awesome. Augustus, what do you have for us this episode?

Augustus Yuan: Yeah, I was just looking into this new thing that GitHub hosted called Scientist. It’s basically, this experiment framework where they made it easy to test, switch between legacy code and new experimental code and then run it and then they can get their analytics on how it behaves. I’m still kind of looking into it, but it’s definitely something that seems really interesting.

Ryan Anklam: Are you saying this is yet another tool?

Augustus Yuan: Yes, definitely. Yeah, it looks really interesting but I’m still looking into it.

Ryan Burgess: Great, so, my picks for this episode I’ve chose the Viking and Lumberjack series which is an accessibility web series, video on YouTube and it actually has two of my friends that star in it which is Bill Gregory and Karl Groves who actually are the viking and lumberjack. So they talk about everything accessibility. So definitely worth checking out, it’s pretty comical but also you learn, so it’s great. And then, my second pick would be the O’Reilly Fluent Conference which is happening in San Francisco next week from Netflix we actually have quite a few, I think there’s three speakers who will be speaking there. There’s a lot of great talks. It’s actually, probably, one of my favorite conferences, so definitely worth checking out. Hopefully, you can make it out to San Francisco. Really great conference. Anything else that anyone wants to add? How about everyone add their way that we can get in touch with you on twitter. Derrick, want to kick us off?

Derrick: Yeah, mine is pretty… @derrickshowers.

Ryan Burgess: Nice.

Ryan Anklam: I am @bittersweetryan.

Jem Young: I am @jemyoung.

Augustus Yuan: I’m at @augburto.

Ryan Burgess: I’m @burgessdryan.

Jem Young: Wait, do we have, does the podcast have a twitter?

Ryan Burgess: This podcast does have a twitter. It is @frontendhh.

Ryan Anklam: So throw all your shade at us. Tell us how much you disagree with everything we said.

Jem Young: Tell Ryan why The Simpson’s suck.

Ryan Burgess: Oh, do not tell Ryan that. That will be a long discussion. We do not need that.

Augustus Yuan: Tell us how many times you drank from the word tools.

Ryan Burgess: Did anyone keep track?

All: Cheers!

Ryan Burgess: That concludes our very first episode of Front End Happy Hour. The podcast where we discuss front end development over drinks. Make sure to follow us on Twitter @frontendhh and let us know all tools keywords that we missed in this episode. We may need to make up those drinks on the next one. Stay tuned for more episodes at frontendhappyhour.com. Thanks for listening!