Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and in today's episode we are going to continue the interview with Simon St. Laurent. Simon is a senior editor at O'Reilly Media. He has been doing web development for far longer than I have. We talked with him last time about some of the early days of web development and the state of the web and where we are today and where we're headed and we're going to continue that conversation in today's episode. Thank you to today's sponsor Digital Ocean if you're looking for a cloud hosting provider. I recommend you check out Digital Ocean. We will talk about a special offer that Digital Ocean has for you as listeners of Developer Tea. But first I want to jump straight into the discussion with Simon Lawrence. If you missed the first part of the interview make sure you go back and listen to that at speck.fm. Of course you should also subscribe to Developer Tea. If you don't want to miss out on future episodes and that way you can make sure you catch every part of these interviews as they come out. You can do that in any podcasting app that you use. Of course iTunes allows that as does Stitcher and everywhere else that we are. So go and check out all of the episodes at speck.fm and make sure you subscribe to Developer Teaso that you don't miss out on future episodes. Well great. So we've talked about the state of the web. We've talked about advice for people who are feeling overwhelmed by that, the idea of keeping up. But I'd like to talk to you about something that you wrote about recently which is the concept of a web app versus a website. Can you kind of unpack your thoughts on that? Sure. Well I used to think of the big divides in the web world as between designer, focus people and programming focus people kind of the logic versus the art. But over the last year or two I don't think that's the kind of conversations I'm seeing. It's not that designers and programmers are all the same people now if they aren't. But I'm seeing a more fundamental difference in the way that people are planning and building applications as opposed to the way that they're planning and building sites. And by applications I pretty much mean either all of these things are built with with web tools. It's JavaScript HTML CSS underneath. But like five years ago I wrote an iPhone application that was HTML CSS and JavaScript wrapped up in phone gap with a tiny bit of objective C that may be insane. These days a lot more of it tends to be single page apps that are running on the web. Or a lot of Android and iPhone development is built that way. With sites it's more the classic model of I want to reach the whole world. This won't be like sitting on one device. It will be typically divided up across potentially a vast number of pages. Like the O'Reilly website is not even that big but I know that I've probably seen like five to 10% of its pages. Or something like CNN which basically every news story got a unique URL and stayed up forever and they just accumulated. That's not an application model. That's definitely a site model. But things like single page apps really had people doing things like starting from a blank HTML page that loaded JavaScript and then the JavaScript created everything. You can use the document object model that way. You've been able to use it that way from the beginning. It just didn't really make sense until JavaScript got a lot faster. People came up with use cases where they wanted that kind of custom control of what people were seeing all of the time. The other thing that I think changed is that as Flash died a lot of programmers came from that world to the web world. If you think about all those little boxes of Flash they're all effectively individual applications. I think a lot of those practices came really quickly and directly into the web world. We haven't really digested them. Flash folks had an advantage and that action script was basically JavaScript and they were familiar with a lot of the things if not necessarily the details of the web yet. They caught on quick. They brought those practices. Then you have things like Rails which started on the server side taught a lot of people about model view controller patterns. Then people started saying, well that works really well on the server. What would a model view controller look like in the browser? Out of that, I think in some ways backbone was the backbone for this. Angular is probably the best known NVC framework right now. React tries to do less by really only providing the view piece of it. There are a million variations on model view controller. If you want to talk about acronym overload, it's a great place to go. The model view controller stuff is great for Lufke at your code programming perspective. It's not the way that the web was originally built. It doesn't map that neatly to the technologies that we used to build the web. I almost feel like it's a case where the languages are dividing. It's not that what we're coding isn't compatible. It's that the way that we're going about writing things has changed fairly dramatically. We have one group of people writing scrolls. We have another group of people writing books. We have another group of people who are doing billboards. They're all using the same basic technolog text and graphics mixture, but they're doing it for very different purposes. They're really deciding how to do things very differently. It is very interesting because we don't really have many other places where programming is used simply to create a window to look at content. There are very few other places where that is the case. There are some applications like iPhone applications where that's true, but by and large, the web is alone in that particular type of programming. It's easy to think that everything on the web is a website and not think about it from the perspective of application development. That's as wide sweeping as saying that every application on your MacBook Pro, all of the applications that you have in your applications folder, we're made in the same amount of time where they take the same amount of energy and they have the same structure. That's just not true. Let's say you have a calculator and then you have a word processor and then you have an image editor. These are three entirely different things, totally different inputs, totally different outputs, different reasons for using them, and the web can be exactly the same way. There are so many different types of things that we build for the web. It's easy to think that we're building a website, but very often what is being labeled a site or perhaps what's being labeled an app is the opposite of that. You can pretty easily turn a site into an app if you have the mind to do it. It's frequently harder to go the other way, but it's certainly possible. I'm thinking like the computer that I'm using to talk to you now is a general-purpose computer that can do all kinds of different things. The web has sort of become the general-purpose network equivalent of the computer and it has as much variety if actually maybe more because of its connectedness, then what we've become accustomed to on our computer systems. The place that I see this actually causing problems is partly that it adds to the overwhelm of there being so many things because it's easy to do a search for something and find yourself in a context that doesn't make sense to your particular background. It's also creating a lot of issues in the, you know, we were talking earlier about priorities, and which ones do you want to set highest and how is that going to work? The two things that I keep finding are like indicators of programming gone wrong, are performance and accessibility. And there are lots of ways to screw these up. I'm not necessarily saying that programming logic is the particular issue, but typically if you create stuff that is too difficult for a screen reader or another accessibility, like the accessibility tools in iOS or Android to deal with, that's kind of a sign that there might be something deeper wrong in your application. And performance, yes, people are sending way too many images, a very large images. I liked the classic. I think it was an 87 megabyte Oakley site. Oh wow. It's not like 10 or 14 or something. It's much, much better. I still occasionally find people who have, you know, just uploaded the original photos to their sites. You'll have a 5 megabyte photo for somebody's biography. Oh man. Happens over time. Yes, there are lots and lots of ways to screw this up. But if your application is showing someone basically a beach ball, maybe a prettier beach ball, well, it's busy creating all of these data structures internally so that you can actually show them something. That's also usually not a good sign. So kind of my long term hope is that people's and patients, customers and patients, users and patients will keep both the app and the site developers on paths that A still connect with each other and B are better for the rest of us. Well, you can also look at this from an economic perspective. Those seconds, those microseconds or even full seconds, all of that matters. That time matters. And it changes the way that people view the thing that they're that they're working with. You know, you aren't creating a website to get somebody to slow down and take a moment in their life. Right? Like that's something they can do, you know, I don't know on their own if they if they practice meditation or yoga or something. They're probably are mindful of this website's trying to do exactly that. Exactly. Like a minority case. Yeah. But certainly they aren't doing that by loading slowly. Hopefully not. No, what you want to do, and there are some things, I guess we should back up and address this. There are some things that are universally good. Right? So for example, if you can make a photo, look just as good with fewer bites or fewer kilobytes, hopefully fewer megabytes, then do it. Right? Like there's no good reason not to do that. And even if you are running a site where you want to allow people to download the full quality thing, put that as a secondary image that they can just click to download. Yeah. You'll find that like one percent of people actually want it. Yeah. Exactly. You're not you're not going to see a lot of people who are just begging for that five megabyte version if you're just running a marketing site. So there are some kind of universal principles that should be respected. Human factors is another good example of this. If you are building an animation, for example, there aren't really many good reasons to make that animation perform poorly. If that animation is janky, if it has like 16 frames per second, it's very likely that that your priorities would include making that animation a bit better than that. Yeah. It just it's giving us a sense of discipline. You don't want to lock yourself up completely. You know, if we're not designing sites for 14 for modems very often anymore, even with mobile bandwidth, but finding that that comfort zone of things that make your users happy, things that are easy to maintain, things that you can communicate to other people. Like these these tend to be the boundaries that put limits on complexity and hopefully keep us all a lot safer. Well, I'm glad you mentioned the image thing because that's one of the easiest big wins that you can get. I mean, you can download any number of free image minification tools and do this across your entire image folder in a few minutes. It's just something any beginner can do. Yeah, it's totally free. You don't have to go and study, you know, the algorithms or anything. They're already available to you for free. So that's the kind of stuff that I think everyone should be keeping in mind for sure. The other things that are not necessarily universal is how far down the road do you go for progressive enhancement? Like on one end of the spectrum, are you supporting Opera Mini? Right? Are you supporting screen readers and are you supporting, you know, the old Nokia phones? Are you supporting the razor from the early 2000s? And then on the far end of the other spectrum, have you implemented something for VR? Right? There's so many different points along that spectrum and it's likely that you're going to find a minimum and a maximum that is not at the far ends of that spectrum. We hope so. I mean, I definitely want the VR people to be experimenting with crazy intensive VR stuff. That's also part of that graphics Renaissance I mentioned earlier. There have been days when like I was working on a terminal trying to fix my server and trying to visit like help websites and links when I really wish people would have simplified a lot more. Links being a text only web browser that has been around forever and is still occasionally useful. It's actually all things considered that the web has wound up as simple as it is after all these years is pretty amazing. It is pretty amazing. So it's kind of the least common denominator in some ways, right? Yes. And it's still the gateway where a lot of people come in. It's a lot of people who well, I guess actually Minecraft is kind of the other gateway right now. But a lot of people who want to get started with computers start by building their own website. And from there they decide whether or not they want to do programming or whether they want to become a designer. The web really creates that kind of foundation that welcoming zone. Yeah, absolutely. The good news is I think despite the many things we've talked about here, that welcoming zone is still pretty welcoming. So hopefully that will continue to bring people in. Yeah, definitely. And speaking of bringing people in, I want to talk a little bit more about Fluent before we round this out, this discussion. So can you tell me kind of who Fluent is for? Maybe mention a few of the people that are going to be there and what we're going to be talking about at Fluent. Sure. So Fluent is probably best for people who either have encountered the kinds of complications we're talking about or know they're coming up to them. So you probably already know your way around HTML, CSS and JavaScript. Probably your job involves creating apps or creating sites depending on or or both. There are people who do both. I think mostly it's for people who are fairly close to the to the code. There definitely is conversation there for like a managerial perspective. We've added a lot of design content this year. But I think mostly it's for people who don't mind looking at the text behind all of these magical programs that we're building. We're trying to cover a pretty broad range of stuff. The show started out as a front end show. Really the things you can do with the browser plus we had sort of bonus content on noted media or because those were still JavaScript and running on the server. We're a little broader than that now. We go into the Ruby and PHP and we've had some hack and hvm stuff in the past kind of conversations. We also have some content that is focused on I guess best practices, testing, community, how GitHub fits into the picture. We're all sharing code now and having to work on stuff at the same time. So it's a pretty broad mix. One of the things that I'm looking forward to I was talking about the split between apps and sites. Alex Russell from Google is going to be talking about progressive web apps which is sort of his vision of combining the web app world with service workers and with a lot of sort of more I won't say the website's specific approaches, but progressive enhancement is definitely something that comes from years of site paid and maintenance. I'm really curious to see what he'll be saying about how we can actually bring these things together. And then the other one that I'm looking forward to is Doug Crawford who I mentioned earlier is kind of legitimizing JavaScript with the JavaScript, the good parts. But these days he's doing something very different. He's been concerned since he first encountered the web about security issues in the way that we use documents to trade stuff the way that technologies we've used to secure like our passing documents around the classics are like SSL and HTTPS aren't necessarily what we should be using to lock down transactions. Identity has always been this like gigantic hassle on the web. How do you know that this person is really them? I think we're reaching the point. Passwords are still around. They probably will still be around for a while, but they're becoming dusty and dangerous. Sure. And they're also being supplemented by things like two-factor authentication and that kind of thing. Right. We're trying to find cryptography that is beyond the reach of the NSA and its friends. So Doug has really taken a different turn. He's still working with JavaScript. He's still centered on JavaScript. But his safe project in a lot of ways is looking at the things that the web is not the best place for. Then kind of finding a way to build things alongside the web that can handle those. So that's something I'm really curious about. That's something very different. And then alongside that, of course, we have a lot of stuff on React. We have things on Angular. A lot of things this year on kind of advanced JavaScript programming techniques. How do you take these functional approaches that we've been talking about for years and really make them shine? It's a broader mix that we've had in the past and I'm hoping we'll be able to not only like bridge some of the gaps in the web community but get people looking at their own projects in the light of a much more diverse set of questions about what we really should be doing. It's very exciting and I'm really thankful to O'Reilly for extending the invitation. Both to have you on the show Simon and to also allow me to come to fluent. Today's episode is sponsored by Digital Ocean. Digital Ocean is the fastest growing cloud infrastructure provider because they are laser focused on their mission to create simple and elegant solutions for developers and development teams. It's easy to deploy a droplet on Digital Ocean that you can deploy them with open source platforms like Node.js, Magento, or Docker ready to go. It's built to scale. You can scale your applications with the Digital Ocean API. And of course they have floating IPs and as you grow you can manage your apps with team accounts. Digital Ocean is reliable and highly available. You can select from data center regions around the world based on latency or you can deploy across regions for redundancy. They have a straightforward pricing model. You only pay for the resources that you actually use by the hour. There's no setup fee. There's no minimum spend. So if you use the promo code Developer Teathat's all one more Developer Teawhen you check out you can get a full month for free on one of Digital Ocean's one gigabyte droplets. That's a gigabyte of RAM on a super fast SSD server. Of course you can deploy these droplets in less than a minute. It's incredibly easy to use. Go and check it out digital ocean.com. Make sure you use the code Developer Teaat checkout for that gigabyte droplet for free for a full month. And of course that will be in the show notes. The link as well as that special code. Go and check it out digital ocean.com. Thank you again to Digital Ocean for sponsoring Developer Tea. If you are listening to this and you are wanting to go to fluent check the show notes at spec.fm. There will be a link directly to to attend fluent this year. And of course we have the spec slack community which you can get free access to by going to spec.fm slash slack. And we'll be talking about fluent. We will probably be doing something special for the people in the slack community. So make sure you go and join that slack community and ask about fluent when you jump in to the Developer Teachannel. So I'm going to have a few questions for you today and the kind of the last part of the interview here that I'd like to ask all of the the developers who come on the show. And if you're ready we can go ahead and jump into those. Sure thing. The first question I'd like to ask Simon is if you had 30 seconds to give every developer advice what would you tell them? Start for the most minimal foundation you can manage and then build out slowly from there. And things gently and cautiously. It's great advice. I think the progressive enhancement mindset not just for the web but in any endeavor that you set out to accomplish. The progressive enhancement kind of philosophy is applicable in so many scenarios. The second question I'd like to ask is if you could have people talk to you about one subject more often what do you wish people would talk to you more about? This is a developer subject or any subject at all. So I'm spending a lot of time exploring woodworking these days which is on the surface really different from programming but I keep finding it has the same challenges of design meets implementation and how do those things work. I think what I'd like to hear more and more about is sort of the complex pathways from concept to actual creation. That is really interesting to me because just last night I interviewed David Hemphill. David is another developer and we were discussing the different hobbies that Developer Tend to gravitate towards. One of the hobbies was for him was fighting Jiu-Jitsu. I know a lot of developers are interested in music as well as piloting flying airplanes. There's a couple of things that tie all of these together and I think woodworking actually fits in that same group of things. That is having some kind of preset systems and structures in place. You have some variables that you can manipulate to your advantage to an end goal and then you have certain techniques that you can practice over and over and you accomplish things using those techniques, taking advantage of the system that has these kind of manipulable parameters. Then on the other side of that you get something out of it. If you're flying you're taking advantage of years of engineering and research and trial and air and you're flying in mid-air. It's amazing. If you're fighting, you're taking in the actions of another fighter and you're responding within milliseconds. You're exercising your brains as much as you are your body. It's an incredible process. Same thing with playing an instrument and I'm interested if you see those same connections in woodworking. Yeah, I think you definitely do. I think there's something else that's encoded with all of those things which woodworking also has, which is kind of the stepping away from the computer and so you're applying all of these techniques and engineering and the things we've learned to a more physical environment. In the case of the airplane you're not going to be staying in mid-air all the time. You do have to land. With music, unless you record it, it kind of goes away. But there is especially for the martial arts, especially for the woodworking. There's definitely a physical component to that. Even the people I know who spend their time on electronic music tend to get really obsessive about the physical like the speaker setup and the way that all of these different things have to come together. I think as humans, we can do all of these great things with our brains, but we also need to connect them to the rest of us periodically. That's a really great point. There's some level of mastery of a space or of some kind of material that you don't quite get when you're only material that you interact with physically is a laptop or a keyboard and a mouse. I think that's some of the excitement around things like 3D printing and some of the routing stuff that I see people doing, the engineering, plywood and laser cut stuff. People are saying, oh, I've got all these programming skills. Now I can do something cool with them in the physical world. Yeah, totally. Same thing with the RPI and robots and all of those really cool gadgets that you can actually make walk around your living room or whatever. Given the opportunity to apply these things beyond the screen, we just jump on it. Yeah, I totally agree with that. That's really interesting insight and hopefully you can find more people to talk to you about woodworking. On a more specific level, I actually have no experience with woodworking. Well, I've taken some classes. I'm working on writing about it. There's a lot of stuff going on there, but it's kind of funny because I'm actually stepping back from the power tools. I have enough electrons that work, I guess. But there are a lot of the people that I met first who were deep into hand tool woodworking, alternative to programmers. Wow. And that was kind of strange. At least in my generation, the older folks not so much, but there are a lot of programmers who are finding joy and tuning handplanes and making saws, behave just right. It's sort of similar to what we do, but it's just different. What we do for work, but it's just different. Well, Simon, this has been a great discussion and I really appreciate your time. If people want to find out more about you or find you online, where should they go? The easiest place to find me is probably Twitter. I'm at S-I-M-O-N-S-T-L. I have a website that is kind of ancient and cluttered that's SimonSaintL.com as well. Most of the time, if you see that collection of letters, it's me somewhere on whatever service. Perfect. And we will include links in the show notes for those endpoints. Thank you so much again, Simon, for coming on the show. Thank you very much for having me. Thanks so much for listening to today's episode of Developer Tea. And thank you again to O'Reilly for having SimonSaint Lauren come on the show and for allowing me to come out to San Francisco for a fluent. If you would like to go to fluent, jump into the Spek Slack community, which you can find at spek.fm slash Slack. And ask that question in the Developer Teachat room. I'll be happy to talk to you about it and we might just be giving away a ticket or two to fluent in that Slack community. So go and check it out. Obviously, there's a ton of other awesome stuff that's happening in that Slack community. People asking programming questions, career questions, and just talking about life in general in there. We have well over 2,000 members in our Slack community and of course, it's always free to you as the listeners of Spek shows. By the way, you should check out the other shows and content on the Spek network. You can find it all at spek.fm. That's where the show notes are for Developer Tea and every episode of Developer Tea is there as well. So you're already going to spek.fm, most likely if you're a listener of this show, go and check out the other shows. There's tons of content and I am certain that you will find plenty of it to be applicable to your job and to your everyday life. Thank you so much again to Digital Ocean for sponsoring today's episode. If you are looking for a cloud hosting solution, you can get started today with Digital Ocean and you could have a gigabyte droplet spun up for free in just a few minutes. Of course, the code for that is developer tgoedadigitalocean.com. Thank you so much for listening to today's episode and until next time, enjoy your tea.