Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and in today's episode I speak with senior editor at O'Reilly Media Simon St. Laurent. Today's episode is sponsored by Hired. If you are a designer or a developer and you're looking for a job and you don't know where to start, I recommend you try out Hired.com. We will talk more about what Hired has to offer to Developer Tealisteners especially. Here on in today's episode, but first I'm excited to get into this discussion with Simon. Simon has been doing web development for far longer than I have and in fact has been doing it basically since before web development was even a thing. He's been writing HTML since before HTML was in a browser so I'm really excited to talk to somebody who has that much experience and I hope you will enjoy this episode as well. If you do want to hear the second part and you don't want to forget it, go ahead and subscribe to the show in whatever podcasting app that you use. Now let's get straight into the interview with Simon St. Laurent. Welcome to the show Simon. Great to be here. I'm excited to talk to you because you have been doing web development or something development oriented for how long now? Since 1994 really I had kind of an awkward transition from HyperCard. Can you talk a little bit about what you do now but also that experience? Yeah, sure. I worked for a Riley Media. We've been best known as a publishing company. Historically we did books. Now we're doing a lot of conferences, online training, videos, things like that. I like to joke that I started in publishing at Kinkos Copies. That was a while ago. There were still many good memories of single-sided and double-sided. But basically at the time I was starting out of college I was lucky because the web was just getting started. I would work at Kinkos by day and then I would go home and I was doing hypertext stuff. I had HyperCard at that point and then I started converting things over to the web as it became clear that this was for real and this was going to change everything. I spent a lot of time on the XML side of the world. I wrote some books on XML. I spent a lot of time thinking about what Markup means is something separate from programming. But pretty much since 2006 or 2007, my focus at Riley and my focus technologically generally has been on how to make better things on the web. Great. So can you kind of explain for those of us who weren't working in the web at that point, can you tell us what hypercard actually is? Oh yeah, sorry. So hypercard was basically a way of creating stuff that today would be web pages but it was a stack of cards instead and then you wrote a lot of code to connect the cards. Unlike physical cards. They looked like physical index cards but they were on your screen. Okay. So you had a stack of cards and you could either go backwards and forwards through the stack or you could write code that navigated through the stack and the stuff that got me excited was writing code that navigated through the stack. So I could create apps where I would write a whole bunch of different cards with different titles and then the text would magically link on the titles. Oh wow. Yeah, at the time it was like new and revolutionary. And now it's like, why would you do hypertext that way? Isn't that like an encyclopedia? But you know, that's useful. That's fantastic. So coming from hypercard, the internet is such a big jump from that, isn't it? Well, it's moving from one computer to the whole network of computers. Whenever I was doing hypercard, I was building stuff in my own little space. It's kind of like I was building sites that only had that site and could not imagine anything else. Wow. Yeah. It's such a interesting history because a lot of people who work on the web now, we couldn't imagine it without all the amazing tools that we have. Even going from a world where C-assets didn't exist to this brand new amazing thing that allows you to style stuff across multiple pages, that must have been a surreal experience. Well, I'd spent a lot of years explaining to graphic designers what they couldn't do in HTML. So having C-assets was a pretty major relief that way. But even when people are getting started on the web these days, it's easy just to jump into a tool and do whatever. I still tend to encourage people to spend some time in HTML first, build a few things, and yes, they won't look quite like you expect them to. But they will actually magically open on mobile phones incredibly quickly as I discovered by accident the other day. So there is still value in that kind of early experience. But it's a different kind of thing. It's just now it's like kind of punk rock minimalist. And back then it was, this is awesome and new and huge. So that's great. So I want to talk to you about kind of the current state of the web now. You mentioned that you work at O'Reilly and the listeners of the show, you should know that Simon has been kind enough and O'Reilly has been kind enough to exchange a ticket for me to attend Fluent, which is next month. Fluent is about the current state of the web and perhaps a better way of saying it is, Fluent is about learning the tools that allow you to participate with the current state of the web. Simon, can you talk a little bit so on this podcast I aim to apply the discussion to the broader software development community. But it is my experience that most, if not all modern developers working on distributed software systems, likely are working with some level of hypertext technology, if not working with all of the browser technologies. So would you agree that the web is in many ways kind of the common linking ground for most modern developers? Yeah, but I think the web is both where people get started and where people build for a large audience. We had, we definitely had a burst of native applications, Android iOS, that did a lot of the same kind of networked connections that the web has done. I don't think those are going away any time soon, but the web certainly persists, continues and grows. The Fluent we're trying to show not just the set of tools, the JavaScript, the HTML, the CSS, the various deployments and the millions of choices of frameworks react in Angular are probably the biggest ones this year. But how they all fit together, it's not that hard to get started with something in isolation, but knowing how to choose among them, figuring out what the vocabulary is for asking questions about them. And then, you know, just a, there's always a heavy dose of the how to really do things that helps you get started. The web, you know, I was just talking about kind of punk rock HTML. I was lucky though, because it was so much simpler. I talk a lot about how we've had a Cambrian explosion in the JavaScript world pretty much over the last five or six years. If JavaScript got legitimized as a programming language in a lot of ways, with Doug Crockford really pushing JavaScript to good parts and functional programmers realizing this could be awesome. And since then, it's been pretty much constant churned and keeping up with that, keeping up with the ever evolving opinions about what's the best way to use the languages, what's the best way to build an app, it's vast. Yeah. Well, I mean, it seems like just two or three years ago, well, I guess it probably was two or three years ago. If you were kind of an expert in backbone, then you were good to go, right? That was the forefront leading technology and everybody was looking for people with 10 years of experience in backbone. But now, I mean, like you said, churn, it's constantly something new coming out or at least a revised version of that old tool, right? So if you knew how to write React code even a year ago, I guess React is over a year old, isn't it? Yeah. Yeah. If you knew how to write React code a year ago, first of all, React has changed a lot in even in one year. But secondly, now you need to also know how to write it with ES6 syntax, right? Like with Lets instead of Vars, for example. Yeah, ES6 is a bigger change than the JavaScript world has seen in a very long time. I was really curious to see how quickly people would pick it up. But I've been, it's gone way faster than I expected. I mean, clearly not everybody is, but it's a lot easier for people who want to be on the cutting edge to use ES6 today. You know, tools like Babel really make it easier. That's really different from kind of my past web experience where you would see things emerge and then we'd all be waiting for a while for it to actually surface in the tool set. Yeah, I can agree with that. I think a lot of the stuff that ES6 brings is stuff that you, if you have worked with JavaScript sufficiently, you kind of wish it was there before anyway. And you don't necessarily know the particulars of the syntax that you wish for, but you wish that you could do a lot of the things that ES6 provides for you to be able to do. Yeah, and it seems like ES7 is going to continue that or whatever. They're calling it by the years now. It's all kind of complicated. Yeah, ES 2016. Right. But it's going to be much smaller. So I think we've had kind of the big burst and that's that part of settling for a while. Something else that I keep having to remind myself of though is that as much as we see like constant churn on backbone to angular and react and ES6. Most of the web is still when you look at what people are actually using like 70% of what's out there is still jQuery. And there are a fair number of sites that aren't using any frameworks at all. There are a fair number of people who advocate not using any frameworks at all. Though admittedly backbone seems to be the one that sneaks in even among the minimalists. There are still people using backbone just not a lot of them. It is a choice. You can look at your projects and decide do I want the all in one package that angular offers? Do I want the view centric approach that react offers and then I have to write some other code to supplement that? There are projects where just sticking with jQuery actually makes sense. There are other projects where you need the latest greatest most insane performance and UI maximization you can possibly squeeze out of a device. The thing that's amazing about the web is that it can have all of these different people working on different priorities and still basically working the same tool set and mostly be able to work with each other. Yeah, it is an amazing landscape of products because we shouldn't look at it like there is one way to build websites right there. There isn't just one way. There are many ways, many different tool sets, many different priorities, right? All of these things are competing and I recommend that if you ever hear anybody say this is how you build a website that you take a step back and you think a little bit deeper about the problem that you're solving because if somebody tells you well, you absolutely need to be worried about x, y and z. If that doesn't match the problem that you're solving, I would at least investigate a little bit further about why there are different priorities for every project and it's easy for somebody who has been doing this for a while and they're teaching how to do it. It's easy for them to kind of label their way as the way. I'm guilty of this. Pretty much anybody with a blog that talks about creating websites is guilty of this, right? This is the best way to do it. The reality is that there are thousands of good ways to do it. Well, maybe hundreds of good ways to do it. Let's hope it's hundreds because if it's thousands, that's what we're going to deal with. Sure. Sure. There are great micro frameworks that work perfectly fine for exactly a specific project, right? Then there's big, massive frameworks that work great for other projects and it would be a misnomer to say that you should be using the small framework on something that the big framework does better. Right. But there may be times when you have specific performance issues or you're dealing with devices that can't actually do as much or have a smaller screen. It's always a question of what the specific situation needs and more than that, how many situations you need to cover. Sure. Perhaps always been flexible, but frequently we put in design models that break it. All of those lovely fixed CSS layouts that looked great on a desktop computer were tiny and terrible on mobile phones. Yeah. So we had to tear everything down and start over. The punk rockers who were using just PlayDust.html didn't have these problems. It all worked fine. But most people aren't like that. There's a set of priorities that you need to establish at the beginning of a project or both change over the course of the project. But how much is performance going to matter to you? How much is a particular design going to matter? The classic is the designer creating stuff in Photoshop and sending it over to the designers and saying, make this pixel perfect across every browser. Why would you do that? Perhaps the biggest cost is in development time. Yes. Yes. You can take something that would have been really simple and make it incredibly difficult. It's kind of funny because a lot of the people I've spoken to who really bounced off the web, it is like those graphic designers I was talking to in the early days frequently. They have visions of something precise that they want to create. You can create great things, but you have to adapt to the medium. It isn't always easy for people. I have experienced this on many occasions. It's actually easier for people to not adapt to that new space. If you encounter a designer who came from a print background, for example, they're going to have an easier time designing something that looks like print on the web. That's because they're naturally experienced with designing for the web. They don't have the fluid browser size in mind, for example. A lot of the time, they aren't going to be thinking about the concerns that the developer starts at the very beginning of the project thinking about. It's important, especially as developers, to be aware of that number one and number two, to be able to communicate what those differences are when you are collaborating with that designer. I think it would help Developer Too to work with multiple environments and multiple media. On the design side, some of the most fun conversations I've had were with designers who had done, sure they had done print, but they'd also designed, say, for textiles or they had designed stage. Interesting. In all of those circumstances, you have different constraints and changing constraints. Even in print, you can do one designer. It has to work across a variety of different print contexts. That can be a recipe for madness. A lot of developers have a preferred toolset. I think, actually, at this point, most developers I talk with on the web have more than one toolset programming languages or programming contexts. It is now possible for the first time since the early server side JS went away for people to really only program in JavaScript and not think about other programming languages. Even as they cross the client, the server, Raspberry Pi devices running underwater hardware. That's possible. But even if it's possible, I tend to find people who've worked in multiple contexts have a real advantage in sizing up problems, figuring out how best to handle them. Sure. I want to take a moment and pause and say, for those of you who are listening to this, and you hear us talking about frameworks and you hear us talking about libraries and tools and we're using a bunch of acronyms. If this seems daunting to you, you're not alone. There are plenty of people who are also listening to this. You aren't the only one who is listening to this that is confused or feeling a little bit like your underwater. That is very much so kind of a picture of what this industry feels like for most of us. There is something new every single day to learn. You're never going to catch up and if you want to be a part of the industry, you're going to feel like you're never catching up. You have to learn to be at peace with not ever being fully caught up. Would you agree with that Simon? Yeah. I think part of the joy actually is that for beginners, the pathways are maybe a little bit clearer. Even if the strange, what is HTML and CSS in JavaScript? Does that play about coffee? I don't know. There is that initial language barrier. The place where it gets especially crazy is if you're trying to keep up with the latest and greatest, which changes daily, weekly on a quiet week. I talk with a number of people who are, I guess I'll just call them hot shot programmers and they're always chasing after the next thing. They'll build a project or two and then they'll try something different and then they'll build a project or two. Then I talk with people, well, okay. One of them was still maintaining cobalt applications. There are people dealing with really old stuff, but there are a lot of people also, though, who are looking for something more stable. The classic story of Enterprise is that we really want it to work and efficiently and do all of these things. It's really got to be stable or we're not going to touch it. These work in 10 years from now. And so finding those kinds of trade-offs, I think the industry is trying to provide lots of things for everybody. But most of everybody is looking to find the thing that will work for them for a long time. Some people have the luxury of always a new Greenfield project. Some agency and developers who are always building new things for clients can try out the latest and greatest. And then someone else gets to maintain it. Isn't that awesome? But for those who get to maintain things, it's usually a little more cautious. And they have, maybe even, they might know the acronyms, but the churn can be daunting too. And that's probably important, an important distinction for those of you who are just now coming into this field. There are many different types of businesses where you could work as a web developer. You just mentioned agencies, Simon. There's agencies and then there's well-established companies and then there's startups. In an agency environment, you do very often get a chance to work in something kind of Greenfield. The trade-off there that I've experienced at least working in that kind of environment is that very often you don't really get to go super deep into any one thing, right? You're building something from the ground up and then you stop and then you start back over again. In an environment like a startup or well-established company, you may be working on one very small narrow problem for a significant amount of time in developing and redeveloping and refining your knowledge about that specific problem over and over and over. So that's kind of the benefits and trade-offs of both sides of that coin. There are some people who get to know everything because they're a one person shop and that's extra funding. Oh yeah. And that's the freelance model, isn't it? Pretty much. There's still a fair number of one person web development places, even on a small scale. Some are consulting and have made it. But there are a lot of people who's sort of initial programming businesses more or less web work. So lots of possibilities. Sure. Today's episode of Developer Tea is sponsored by hired.com. Unhired software engineers and designers can get five or more interview requests in a given week. Each of the offers has salary and equity at front and they have full time and contract opportunities. You as a user, you can view the interview requests and accept or reject them before you ever even talk to the companies so there's no awkward experiences with people trying to turn them down after they've already given you an offer. They work with over 3,000 companies from startups to large public companies and they have employers from 13 major tech hubs in North America and Europe. The best part for you is that it's totally free for users. If you are looking for a job, you can use hired totally free. Normally, a hire gives a $1,000 thank you bonus if you get a job through their system. But if you use our special link, which you can find in the show notes at spec.fm, they'll double that bonus to $2,000 when you accept the job. To go and check it out, it's hired.com slash Developer Tea and of course that link will be in the show notes as spec.fm. Thanks again to hired for sponsoring Developer Tea. So I want to talk about one more thing about the state of the web. Specifically, what things are you really excited about in the near future and the current state? What things are really exciting to you? Well, I feel like we've finally gotten to a especially interesting place on graphics. I mentioned Photoshop earlier in kind of the curse of the pixel perfect. But when you step back from using Photoshop for layout and start looking at what you can do with graphics, programmers now have Canvas and WebGL. The Sdesiders are doing a lot with SVG. Sometimes it's creating things that Adobe Illustrator and exporting them. SVG is getting a lot of use as an animation space as a way to enhance what we could always do with HTML. And it doesn't require the same level of programming knowledge. There's a lot of the other ways to do this. Canvas is straight JavaScript. WebGL, you can kind of wrap in a library, but it's still really build this, then draw that, then move this. SVG is like graphics done in HTML where you kind of say this thing goes here. If you want to do really fancy curves, it can start looking like a programming language, though. So it has its own complexity. But graphics, like overall, seem to me like they're achieving what we've been talking about and wanting for a long time. On a similar note, animation in all different kinds of forms, some of it has to do with graphics, some of it just has to do with like the little touches that a user interface that tell you you've actually clicked on that thing and everything's going to be all right. There's a lot you can do now that was sort of pioneered in JavaScript. It has moved to CSS where it can take advantage of hardware acceleration, so it tends to be a lot faster. Those things feel to me like they're really coming around. There are a lot of bigger questions where I feel like we're still experimenting, which aren't really things like the relationship between what happens in the browser or what happens on the server. The model that I worked with for years was that like all the program logic was on the server and the browser was basically the window to look into things. As HX came in, as frameworks have gotten more and more sophisticated, as developers have realized just how much you can do with a really basic server setup, a lot of logic has moved to the client. So all that programming code that used to live on the server now gets sent to the browser to be used, which is great because it saves you like server processing cycles and you can borrow other people's computers and things. I just mean that you're using the user's computer, not that you're really borrowing somebody who didn't expect it. You're not creating a server farm in your basement. Hopefully not. Maybe you're mining Bitcoin or something. No, that's not to do that. At the same time, I feel like we're just figuring out a lot of the questions around building APIs interfaces from the clients to the servers. We have now these models. They're called isomorphic or universal or a fronty backy or I can't remember. There are at least two more names for it. But basically, since you're writing code in the browser anyway and it's JavaScript and we now have node and you can run JavaScript really easily on the server, you can decide your server can basically decide whether or not to do the JavaScript processing at the server or on the client, which can make a big difference if you're sending pages to a not very smart phone that can display stuff but doesn't have a lot of power to do much with it or if you've got constrained bandwidth issues or if there are some cases I've heard where it's a security thing. If somebody is in your own corporate network, you don't mind sending all the logic to them if they're outside, you want to send them as little as you possibly can. There are all of these new architectures appearing really over the last, we started with web services around 2000 but really unlike the last five years, it's gotten a lot more intricate. I'm very fond of what are commonly called REST APIs. It doesn't mean that you or your program get to go to sleep. It's more about having a constrained set of actions you can take on a wide variety of data types. Rails really made a very simple version of the REST story popular but we're really getting into the many ways you can use it. That stuff is growing, experimenting, exploding, tying a lot of the web stuff to the cloud in new ways. It's perpetual ferment. The thing that's kind of nice about that stuff is if you're doing a small project, you don't really have to think about it very much. If you're doing a large project, it can get really deep but as long as you're willing to constrain your experiments so that they sort of operate only in places where you're comfortable trying new things, you don't always have to be on the cutting edge with everything. Yeah, I agree with that. I think learning one piece at a time, you may feel like you need to learn a whole new stack all at once. I felt that pressure before myself but learning one tool to integrate into your existing stack and replacing one thing at a time with a new interesting or more powerful version of the thing that you had before. That is a way of going about adopting new tools. You see this, actually, if you follow a single project, you'll see this in practice. There are really simple things that you expect them to do with that project. I'm thinking of a couple of open source projects right now in my mind. You expected them to have done that well in advance but even with something like a CSS framework, it takes a lot of testing and a lot of deliberation on how do we name things, for example. What naming structure should we use for our classes? Should we have an extra, extra large breakpoint or not? Should we provide support for Flexbox or not? A lot of this stuff depends on many different variables. Don't feel like you have to adopt an entire new stack all at once. You're going to run into a lot of problems that you've never encountered before and you're not going to know which tool that problem is coming from most likely. We're getting better at combining things into stacks. I think NPM in particular has got a lot of people excited about. I can download all of these components and I can mix and match and they'll all talk to each other and everything will be great until one of them has a security issue but we'll hope that doesn't happen. Part of the joy is that it has become a lot easier to switch things in and out over time. Part of the complication is that we've got really excited about this. I now see people creating 27 stage workflows. I'm sure there's bigger than that. That was the last large number that I heard where they're bringing in all of these different pieces. They're writing an ES6 so that has to be compiled to ES5. They're processing their sass into CSS. You can really go to town with workflow these days and custom craft something that fits exactly what you want. Then switch things in and out of it whenever seems convenient to you. Part of the joy of this is that a lot of us are not just working by ourselves. We need to be able to share these things with other people. That tends to be where the things break down. Technically we can make them work but explaining them to other people gets harder. It's a time when we're really trying out all of these new possibilities, a lot of which honestly node created for us. We haven't settled yet on what really is the best idea here. The best set of ideas for that matter. Yes. I think you're right. I think node, at least some of the concepts that node has introduced at the very least, but also the power of JavaScript period, has brought along with it a lot of new ways of thinking about the same problems. Yes. Node really fascinates me. I keep running into places where JavaScript is driving things and I just didn't expect it. A lot of desktop application development like on Windows and Mac these days is done with tools like NWJS which lets you basically use JavaScript and web technologies to code or decromy in Windows. There is a lot of stuff going on. I mentioned Raspberry Pi earlier but there are also things like Tessle that are boards that are really built with JavaScript development in mind. The whole node bot's movement is pretty astonishing too. Node really changed the rules. When I first saw it, I thought of it as a, hey, this is a server side framework in JavaScript. That's a cool idea. But then node really... It's a little more than that, isn't it? It's a little more than that. It's getting everywhere and into everything and mostly that's good. I think one of the biggest things that node brings... Well, in my opinion, one of the most important things that it brings along with it is the package manager. We've had similar package managers in the past. Probably the most comparable would be gym files and Ruby Gems. But node brings this package manager concept to the front end and the back end all in the same thing. That's unprecedented in some ways. Yeah, I had friends who kept using Pearl for years because C-Pan had such an amazing list of modules. They weren't really fond of Pearl but they had a better library in a lot of ways. JavaScript had a very tightly shared library in the browser but it really wasn't until node hit that we started having not just, here's a framework or maybe I'll mix these two libraries. I'll be really daring. But you really can assemble. It's really like the unique small pieces loosely joined. I don't know if people will know like unique shell scripting and pipe stuff but the output of one process goes to the next one and you can really wire together all kinds of logic to solve your particular problem very precisely. Node has NPM, Node, various other package managers. They've really brought this to the JavaScript world and given the web, well not everyone's using JavaScript. Obviously, lots of people are still using PHP and Rails and Java and other things. NPM has definitely given the JavaScript side of the web a common packaging system. Sure. These package managers are kind of maturing. All of the other ones are also maturing with NPM. Thanks to I think some of the influence that NPM has had on development environments. Composer and also, Ruby Gems has become better over time as well. There are a lot of interesting and powerful things that the web is getting. There are package managers for virtually every language but this is like a package manager not for a language but for the whole stack and that's the difference. That's the main difference. It goes beyond JavaScript in particular so it's big. Super powerful stuff. Do you still use Bower by chance? No, actually I never used Bower. I stopped programming and then restarted programming and I missed Bower. I mostly missed Cronk too. Cronk was really interesting but when I came back it seemed like Gulp was the way. We've adopted Gulp at Whiteboard where I work and I love Gulp but there was a time, a very short period of time where Twitter bootstrapped and a few other front end tools were actually being built by a make file. Yes. I'm honestly surprised that there wasn't a step in the middle where somebody used Rake for that stuff but maybe somebody did. I don't know. Well, making a lot of ways is the grandparent of all of this stuff. I don't think make was the first at what it did but it was certainly the best distributed stuff. I hope we can all learn from makes ups and downs and make things smoother. Sure. Again, if you're listening to this and you're like, what is Rake? What are these things? These are all just single tools that you can very easily Google. Of course, we'll have links to them in the show notes as well but they all have their own purposes and they all have a history and actually make is still used every single day. You've probably used it if you've installed anything on your command line unless you are part of the generation now that specifically only uses brew which is another powerful package management tool for OS X. Yes. Somewhere or another in your systems there is a package manager lurking. At least one. Yes. Probably multiple versions if you are unlucky. Yes. Great. Simon, you said you're excited about rest. You're excited about MPM and all of these tools kind of maturing to the point where now we can start refining them further and doing more powerful integrated things. Does that sum it up pretty well? I'm hoping we can take the last five to ten years of rapid innovation and figure out what the best parts of it were. I see best practices really starting to emerge. There are different practices for different practices. People are creating different kinds of things. But I'm not going to say we're achieving stability. I think we have achieved a bit of fatigue and maybe that will lead to stability. But on the package manager front, I think we're evolving a common way of doing things even when we're not using the same tools. On the language front, I think the big burst of ES6 changes behind us. On the frameworks front, I think we've probably still got a lot of years to go before we really decide what we want. But that's okay. Yeah, I agree. I agree. I'm told to the idea that we will eventually, in my opinion, we're going to reject the notion of purely isomorphic. I have my reasons why. But I think that we will recognize that different languages are designed for different things. But I don't know. That's all guessing. I corrupted myself a few years ago. I was editing some books that involved Erlang and I wanted to play with it. I wasn't up writing a book on it, not in Elixir. So I went into the deep functional programming end of the pool. Coming back has been really difficult. As much as I love the vision of JavaScript on both the client and the server, and node is amazing, the next time I have to really write some server code, I think I'm going to have to take Elixir for a real spin. It does different things. It makes me think different ways. I don't think it's going to be just the simple one environment for everything. I'm totally excited about some of the things Iomorphic lets you do. I think there are cases where that's more important than the scalability and stability that you get from some of the other language models. But it's eventually you'll have to make a trade-off. Yeah, absolutely. That's really what it comes down to. There's always going to be trade-offs in different directions. You could use a general purpose programming language for everything. That's what I think is going to be the downfall of a lot of the approaches to using JavaScript. I think people are going to start treating it like a way of setting variables and reading those variables and then creating functions and that's it. I don't think that adequately taps into what JavaScript is best at. And also ignores what some other languages are better at than JavaScript is. Yeah, I would love JavaScript to have lightweight disposable processes, but I don't see that coming in my lifetime. Sure. We'll see how it goes. Yeah. Thank you for listening to the first part of my interview with Simon St. Laurent. Of course, if you don't want to miss out on the second part of the interview, make sure you subscribe in whatever podcasting app that you use. By the way, if you have an Apple TV, Apple just now released the podcast app on the Apple TV update. So make sure you update your Apple TV and subscribe to Developer Teathere. So you can listen to me in your living room. Thank you again for listening to this show. Make you too hired for sponsoring Developer Tea. If you're a designer or a developer and you're looking for a job, then you have nothing to lose. Go and check out hire.com. It's totally free for you. And if you end up getting a job through hired, you get a $2,000 bonus right off the bat. So go and check it out hire.com slash Developer Tea. Thank you again for listening to today's episode. And the special thanks to O'Reilly and Simon St. Laurent for being on the show today. They of course have provided me with a ticket to attend fluent, which I'm incredibly excited about. I'll be talking about fluent on the show. And if you join the spec Slack community, we have some potential giveaways, maybe even a ticket to go to fluent. So go and check that out as well. Spec.fm slash Slack. Of course, all of today's show notes can be found at spec.fm. Thanks again for listening to today's episode of Developer Tea. And until next time, enjoy your tea.