Brian Neville-O'Neill: PodRocket is sponsored by LogRocket, a front end monitoring and product analytics solution, which is to say it's not really sponsored by anyone. It's sponsored by us, LogRocket, and we're giving it away for free. The podcast is free. The product is not free. There's a free trial. We could split hairs about whether or not that's free to you, but anyway, that's it. There are no more ads. If you're interested and you want us to know that you came from the podcast, please go to logrocket.com/podrocket. If you don't care, logrocket.com works just fine. Thanks. Brian Neville-O'Neill: Hello. Welcome to PodRocket. I'm Brian Neville-O'Neill, Director of Content. With me is Kaelan Cooter, frontend developer extraordinaire. This is the second episode of ... we're calling it a Rocket Surgery with Kaelan. The first time Kaelan and I talked was the very first episode of PodRocket, where we kind of broke down Webpack 5. We didn't call it Rocket Surgery yet, but we are now. It's going to be me and Kaelan, and we're going to talk about stuff. It's going to be a freeform chat. It'll be in depth or maybe more technical than the interviews that we usually do, and the idea is to give you a little bit more information on either stuff that you're maybe not super familiar with or stuff that you aren't familiar with at all. So hi, Kaelan. Kaelan: Hello. How are you? Brian Neville-O'Neill: I'm good. How are you? Kaelan: Been better, but great. Brian Neville-O'Neill: Okay, cool. So in this episode, because it's the perfect time of year to basically do this kind of thing, we're going to kind of talk about what's coming in 2021, things that are interesting, things that we think will have gained significant traction, have some real impact. While we probably won't spend too much time reflecting on 2020, we will mention a few things that we think were the most important for last year. Brian Neville-O'Neill: So there are a few things that we can start with right off the bat. I saw, and I think we all did, React Server yesterday. So we're recording this on the 22nd of December, so we saw it yesterday. Kaelan: Yeah. It's probably one of the biggest Reacts news, I would think, since 2018, when they announced hooks. I know there's lots of cynical comments in Hacker News like, "Oh, this is so-and-so from 20 years ago." Brian Neville-O'Neill: I can't believe that. There were cynical comments on Hacker News? Kaelan: I know. So uncharacteristic of them. Brian Neville-O'Neill: Weird. Kaelan: But regardless, if you read the RFC, which, by the way, is only one of many RFCs on the React RFC repo, they're a great read if you ever want to see what React will be like in the future and rejected ones. This one's interesting. It's something that has been talked about a lot, a lot of comparisons to the Next.js, but basically I would say the most important difference from what other tools have done in the past, more clean separation between the server and the client. Some server-side rendered technologies, the server code has an impact on the bundle. Probably too much to talk about in just this one talk, but I would recommend you read it. The bottom line is you can probably expect it to be easier to make progressive, incremental-style apps that render data from the server. Even if it's not using React Server, I would suspect if it's anything like React has done in the past, it will probably inspire similar tools. Brian Neville-O'Neill: When I was basically googling it to get caught up to speed, I thought it was funny that Addy Osmani's post outranks the official React docs for React Server components. So that's a big win for him, or at least, to be fair, I didn't search in an incognito window. So maybe it doesn't outrank it. Maybe just for me. But kind of towards the bottom of Addy's post is kind of like, "Will server components replace Next.js SSR?" That's the heading, and there is a decent explanation where Dan Abramov explains the differences between Next.js SSR and server components, but really there's three bullets that I will call to your attention, your meaning the audience. I assume Kaelan already knows this, but if you don't, we can just pretend. Three bullets. Here they are. Code for server components is never delivered to the client. The second one is server components enable access to the backend from anywhere in the tree, and the last one is server components may be refetched while maintaining client side state inside of the tree. Does any of that strike you as revolutionary? Kaelan: I'd definitely say the last one. They really seem to have thought about everything. I have to commend them, perhaps getting ahead of the Hacker News crowd. The detail strikes me as important. Every server side React ops is going to import React, anyway. So I guess it's not too much of a migration path. That does seem like that's a big open question, I guess. Is this going to be only a thing that new apps do, or are people going to move over towards it? Is there a reason enough to do that? To be honest, I'm not really sure, because some of the aspects of server components doesn't seem quite popular, like specifically the naming convention. That's kind of against the grain of what the React community has done in the past, where you have one component that runs on the server and the client. The distinction was erased, and now suddenly it's super hard again. Brian Neville-O'Neill: Keep going. I want to hear more about why the naming convention could be improved. Kaelan: Well, I see the reason why they would do it, of course, because the bundling needs to know what is a server and a client. I guess as soon as you enforce a naming convention, there's always going to be a group of people who don't like it, and they're going to be very loud about it. Brian Neville-O'Neill: Yeah. One thing I was wondering is I know it's really early days, so I won't blame you if you haven't given it a lot of thought, but how do you think people will start to evaluate which they should use, like for which projects? If you're deciding between one or the other, like, "Should I try this one?," what's the checklist there? Kaelan: That's an important question. A lot of people say you shouldn't be an early adopter of any technology, but even if the design of server components is superior to what others, like Next, are doing, just the amount of support that Next gets you, specifically how friendly, and we'll get to this later, the developer experience is with Next, it just seems like a huge hurdle. If you can't even convince your engineers to switch over to this system, how can you convince anyone? Brian Neville-O'Neill: Yeah. Kaelan: Especially considering that I suspect that these approaches will probably be adopted by other tools, other projects, similar to how hooks has inspired some features of Vue, for instance. Brian Neville-O'Neill: Inspired? Kaelan: Friendly competition. Brian Neville-O'Neill: I understand. So is there anything else before we move on? I just want to make sure we cover everything. It's hard. I mean, it's funny. When I was googling it, the whole front page is filled with, "Hey, here's what's going on with server components," but they have a limited amount of information to go off of, unless they watch the full hour video, which I didn't. Kaelan: Well, nothing specific to server components. I would be interested how this impacts the next version of React. This year, React 17 was released, and it's basically a maintenance release. It does seem like they're doing a better job of focusing on what the upgrade path will be. Suspense and concurrent mode have been a long time coming, and I guess we can expect that in React 18, potentially, that there's to say unexperimental support for it. React 17 did have some minor changes, like changes to the event system, internal things. It seems like a ton of things that impacted performance. I'm not exactly sure if we will see React 18 in the next year, but I would say it's a fair bet, I guess. Brian Neville-O'Neill: You didn't mention suspense and concurrent mode. Kaelan: It's available today, and some people have started to use it. There's already several really nice libraries that use suspense, but all of it is super experimental. It's not exactly been fully adopted as much as hooks has, for instance. Brian Neville-O'Neill: Okay. So moving on from React, we should talk about Webpack 5, even though we kind of already did in the first episode. I don't expect that everyone's listening to this episode to have listened to that 45-minute discussion. So what are the big things from Webpack 5? Kaelan: Particularly I'm interested in developer experience. There's not that many features that Webpack does not support that everyone is clamoring for, but one thing that everyone can agree on and one reason why everyone would want to upgrade is build performance. The biggest mover in this space, I guess, would be the persistent caching, which basically means that the Webpack cache now persists across various runs. Also, the caching algorithms have been improved. There has been several problems, and I'm sure I don't speak alone, but with module IDs and the hashing algorithms. Basically, bundles can be non-deterministic, which makes caching very difficult. It doesn't help that the way that Webpack is made, it's very decentralized in a way. The Babel loader has its own cash. TypeScript has its own cash, which can't really be mitigated, but you can improve the rest of what Webpack does, and that's basically what the Webpack team has been focusing on. Kaelan: Besides that, tree shaking and bundle size, that's another thing that everyone cares about. There's been lots of little gotchas with tree shaking that not many people were aware of, I guess, that basically prevented it from working at all. Like nested tree shaking, I can guarantee your code uses this sort of thing. Most projects that are big enough to, when you would want to start caring about tree shaking probably experienced these problems, and they're really hard to debug. So it's nice that Webpack actually supports them now, and it's not like you have to change your code or anything to get Webpack to work better. It just works, TM. Brian Neville-O'Neill: That was actually going to be my question, is when we first started talking about it, it was just released. So I was wondering how it performed after being kind of released into the wild and what the little were. Kaelan: Yeah. At LogRocket, we use Webpack, the new version, and it was a great improvement, tree shaking especially. One of the things we care about deeply is bundle size, because for various reasons that probably don't make a full sense, our SDK runs through Webpack as well. It's nice when all you have to do is upgrade an NPM package and then things work and you don't have to do anything. Nothing can improve the happiness of the developer than not having to do anything. Brian Neville-O'Neill: I thought you were going to say nothing can improve the happiness of a developer, and I was going to be like, "I agree." That seems to be the case. Kaelan: That's probably more accurate. Another thing to note about Webpack, tons of internal changes, which is always a great indication for a team gearing up for big things in the future. So I'm excited for v6. Brian Neville-O'Neill: v6? They just gave you v5. What more do you want? Kaelan: More. We need more. Faster. Brian Neville-O'Neill: Okay. Let's see. What else for 2020? Oh, there's Babel. Kaelan: Not many things to talk about here. You can always expect Babel to be very up-to-date with supporting the new ECMAScript standards. I guess the two ones that everyone's talking about would be the nullish coalescing operator and optional chaining. There are two features of ECMAScript 2020 that are already supported in Chrome, Firefox, I think everyone but IE, of course, a few stragglers. Consult with the tables, of course, but supported in TypeScript, Babel. There's no reason not to use them, which is nice, because they are great at saving time. Kaelan: The nullish coalescing operator, if you don't know, it's a new logical operator that returns to the right hand side when the left hand side upper end is null, which everyone does in 1,000 places in their code base. Optional chaining is very nice. It basically avoids the need to do very long chained if statements. It's a feature that, actually, CoffeeScript had ten years ago. But everyone forgot how awesome it was because everyone stopped using CoffeeScript, and now it's back. Another thing with Babel that I'm excited for this year, at least at LogRocket and from what I've noticed, the bundle size, I love what they're doing, preset enf, which was released in years past, but of course they've been making improvements to it, but this year has been great for bundle size, I'm going to say. Brian Neville-O'Neill: That seems to be a theme everywhere. I'm hearing it way more in the last six months than the previous three years. I don't know. That could just be ... Kaelan: Definitely. Brian Neville-O'Neill: There's a name for that, but I can't remember what it is when you keep hearing the same things over and over again. Kaelan: You'll hear about it, and then you'll hear about it everywhere. Brian Neville-O'Neill: Yeah. What's the name for that? Do you know? Kaelan: Nope. Brian Neville-O'Neill: All right. We'll both google it together later, or we'll get lots of tweets about it, because I'm sure somebody knows what we're talking about. I guess the last thing about Babel is isn't their V8 coming next year? Kaelan: Oh, yes. They tried to get it released before the end of the year, but it seems to be pushed back. Nothing of note I can see. Probably you can expect more of the same. Brian Neville-O'Neill: Okay. Oh, TypeScript. I'm sure you have lots to say about TypeScript. Kaelan: A lot. Similar to Babel, they've been very great at keeping up date with the standards. I remember when it took years to get the standards from Babel to the browser, and now it seems the browser sometimes beats Babel and TypeScript. Incredible, actually, how far we've come. Besides the standards, lots of really cool stuff. LogRocket does not use TypeScript, but I really wish we did. But I'm most excited for some of the features that you would want as a really huge project, which we definitely are. Incremental type checking, I've heard a lot from people who work on big projects, how slow it can be. So anything that can improve the lives of those developers I think is very valuable. I guess to our other theme, developer happiness, the big projects, I guess one way they get ahead is making developers happy, and definitely faster things, we like that. Brian Neville-O'Neill: Well, I mean, that's what, ease of use, performance. Kaelan: Right. Brian Neville-O'Neill: Speed. Kaelan: Oh, and another thing I would note, tupal types, named tupal types. So useful. I didn't think I would use them everywhere, but I ended up using them everywhere. Side projects, that is. LogRocket doesn't use TypeScript, but I wish we did. All my side projects do. Brian Neville-O'Neill: See, I know that we don't use TypeScript, and I know that you wish that we did, because you've said it to me hundreds of times. You've said it here at least twice just on this episode. But because I like my job, I'm not going to ask you to go into the reasons why we don't use it. Kaelan: Well, it can be hard for large projects to switch to TypeScript, basically. The larger it is, the more work it is. One thing that does seem to have improved in the last year, from what I've seen, code mods, which are tools that people use to migrate to TypeScript and to other things. It's just basically a program that changes your code, which some people find unnerving. It does seem like every year, it gets easier to switch. Another reason to wait, I guess. Brian Neville-O'Neill: Okay. So after TypeScript comes Node, the new versions, really, 14 and 15. Kaelan: Yeah. Not much change here. I guess the one thing of note I would say is the ECMAScript modules, which have been a long time coming to Node, are unflagged. It's still experimental. I've started to see larger projects use it. Probably the most difficult migration, I would say, probably in living memory, I would think, considering the nature of Node and just the sheer amount of code that everyone has. Moving to ECMAScript modules is probably not going to be too high on everyone's priority, but it's good to see that it's making some progress. Besides that, lots of good performance gains. I know when LogRocket upgraded, we saw quite significant improvements to the processing and stuff. Brian Neville-O'Neill: Nice. Speed, ease of use, developer happiness. Kaelan: Indeed. Brian Neville-O'Neill: Do you want to go from Node into Deno and then come back to Vue, or do you just want to go to Vue? Kaelan: We should definitely talk about Deno. If you don't know, Deno is a very interesting competitor to Node from the original creator, I believe, of Node. It bills itself as a secure runtime for JavaScript and TypeScript, and it does that by a very interesting security promise system, where if your program uses ... like file system, you have to explicitly give the program permission to use the file system, unlike Node processes, which you can just run it and it can do anything, expose you to the web, harvest all your data, delete everything, who knows? So that's nice. Brian Neville-O'Neill: That's great. Yeah. Kaelan: I like also that it's written in Rust, which is trendy, and I really like the standard library. That's another thing I would say. It's kind of a point of contention for JavaScript and Node. Node has a somewhat static and bare bones standard library, and JavaScript has an even more static and bare bones one. It's a nice change of pace to see such a well thought-out set of APIs. I guess the biggest note in Deno this year, they've reached v1 in May. They claim it's production ready. It already seems like some cloud providers are starting to offer support for it in their serverless platforms. AWS Lambda does. Also heard of several companies starting to use it. Brian Neville-O'Neill: Do you think there's a ... I don't really want to say a competition, because they're just tools, and you just use the right one for the job. But Deno will certainly grow in popularity. Do you think at some point it could overtake Node? Kaelan: Yeah. I think you will start to see it for new projects. I think that's significantly harder, it seems. I haven't used Deno in a bigger project. I've never done a migration path, but from an outside observer, that seems like it would be the biggest problem. If I had to guess about its long-term popularity, that would be the number one factor. If they can improve that pathway, maybe in the next versions, then maybe we might see a large-scale shift over to Deno. But then again, for some things, it might not make sense to switch to Deno. It seems Node might be better or at least not as bad for other things. Brian Neville-O'Neill: Yeah. No, I get it. It's a tough question for anything, really, except for, I guess, frameworks, popular frameworks. Kaelan: Right. Brian Neville-O'Neill: Or some frameworks that refuse to be called frameworks that are instead libraries. Kaelan: Right. Brian Neville-O'Neill: But the next one is ... Yeah, right. Vue. Let's talk about Vue. What happened in 2020 with Vue that you thought was interesting? Kaelan: I mentioned earlier it seems like React hooks have somewhat influenced the direction that the Vue team is going. I would say I really like the Composition API. It's their answer to kind of solving the same natural problem that React hooks did. That's finding a better way to reuse logic in multiple components. Basically, this is an element of reactive programming that seems more heavily influenced by that paradigm than React hooks. I guess you could say React hooks are a little bit more low-level. Kaelan: One thing that strikes me from the Vue Composition API, it seems like it would generate far less confusion. I guess the number one point of confusion for React hooks, the dependency, right, in the various hooks, I think. The fact that Vue approached that from a different way seems like it would greatly benefit them and sticks to their mantra of being very simple and straight to the point. Yeah, I must say, in 2020, my opinion of Vue has changed from completely ambivalent to excited. Brian Neville-O'Neill: Knowing you, that's a pretty big jump. I will say we, LogRocket content, we started covering Vue ... I don't know that we were ahead of whomever, but we started covering it early, and it was a bet that it would be popular and that people would be interested. It paid off considerably. I mean, obviously, I'd like to say that it's because we were very smart at LogRocket content and we could have seen it coming, but I don't know. Maybe we're very smart, but really, it was the engineers who write for us were like, "We like Vue. We use Vue. We want to write about Vue. You should cover it," and I said, "I believe you." Kaelan: Yeah. The Vue community seems to be very good at generating talk. Brian Neville-O'Neill: Well, I'll say that- Kaelan: That came out wrong. Brian Neville-O'Neill: I'll say that they're passionate, for sure. Kaelan: Yeah. Brian Neville-O'Neill: There's nothing wrong with that. Kaelan: Anyway, besides the Composition API, which, by the way, is in the v3 version, which is currently in preview, it might be released by the end of the year. Not really sure. You also have other things that were clearly inspired by React, which is quite interesting, the Teleport API, which is like React portals fragments, just like React. Yeah, it definitely seems like they're trying to catch up with React, in a way, but somehow doing better at it than React, maybe. Brian Neville-O'Neill: What? Better than React? Kaelan: Oh, gasp. Brian Neville-O'Neill: I know. Kaelan: I don't think it's better enough to switch your app to, definitely. Brian Neville-O'Neill: Yeah. Kaelan: That's ridiculous. But if I was starting from scratch, maybe it would be a difficult choice, I would say. Brian Neville-O'Neill: Again, it seems kind of like either where you're comfortable with or a billion other variables. Or maybe not. Maybe it's just pick one. Kaelan: Yeah. I'm a big fan of reactive programming, and I really like the focus on that. So anything that uses that wins me over. Brian Neville-O'Neill: That feels like a better justification than just pick one. Kaelan: Perhaps. Brian Neville-O'Neill: But I suppose that makes sense, considering your vocation. Okay. So that's basically Vue in 2020. The other one, and I guess I'll say the last one before I get into browser updates and standards and maybe even a little CSS, is Next.js. Next.js is and was and will be everywhere. I don't even know where to start, honestly. Kaelan: Yeah, there are so many features they added. Their team has been cranking it out considerably, not just v10, which was just recently released, but also the other releases earlier in this year, and their downloads are quite up on npm this year. I guess that's probably the safest trend for next year, that you can assume that next year, this would be even better, although I struggle to think of what features they're missing. We used it in one project. It's probably way out of date, but it's always a joy to use. Kaelan: If I wanted to summarize one important feature, I would definitely put fast refresh. It's like library loading, but better, I guess you could say, which I know has been difficult to do for tools similar to Next. No one wants to implement this from scratch. You can replicate a lot of features from Next yourself, but quite difficult to do a library loading or even use another plugin. Coming from Webpack, I know it breaks. You don't know why. You just live with it. Live reloading without roots and components state, which is a headline feature, assuming it works like advertised, that's game-changing, I would say. The amount of productivity boosts that could be is considerable. Brian Neville-O'Neill: What do you make, if anything, out of their recent fundraising? Vercel, the company that makes Next.js, raised 40 million. That's a lot of money. Kaelan: It seems to be a trend that I noticed Cypress recently had a big funding round, another developer tool. I don't know if that's something in the VC environment that has made them focus more on developer tools. Great for LogRocket, though, I guess. Brian Neville-O'Neill: Yes. Kaelan: I'm excited for them getting more funding, I guess specifically because any competitor to AWS, I have to root for the small guys. Brian Neville-O'Neill: I'm not touching that. I will say I hear you and acknowledge the validity of your right to express yourself. How about that? Kaelan: I'm rolling my eyes. Brian Neville-O'Neill: Okay, cool. Do you want to go into all the browser stuff and the standards before we talk a little bit about what to expect in 2021 and then wrap up? Kaelan: Yeah, not much. I would say specifically it's different for each browser, of course. From a developer standpoint, Chrome has been focusing a lot on developer tools this year. They've been super up-to-date on the CSS standardization. Firefox has been super up-to-date with WebAssembly standards. It seems like both of them have their own focuses. As usual, Safari is 30 steps behind, the usual. Brian Neville-O'Neill: That one, I will agree with you that yes, that's pretty obvious. When we're writing stuff for the blog, no one's ever like, "Hey, can you do more Safari content?" No, we're good. Then I guess that just leaves us with predictions, magical predictions for next year. Kaelan: Oh, don't forget standards. Brian Neville-O'Neill: Hit me with standards. I couldn't be more ready. Kaelan: So there's, of course, ECMAScript standards, which I talked about before, the knowledge coalescing operator and the optional chaining, dynamic imports finally being finalized. There's a lot of things in the docket, so to speak, like realms, more changes to classes. Some changes to classes have landed in ECMAScript 2020, but, to be honest, I'm not aware of anyone using them, because everyone uses legacy Babel stuff or TypeScript. I'm sure that will be impactful in a couple of years, but it isn't today. BigInt, I'm a fan of, because high-performance JavaScript, all that. Kaelan: But what I'm most excited about is CSS. There has been a lot of recent standardization for exciting new features in CSS. It's all underneath the umbrella of CSS Houdini, and, actually, most of the exciting stuff has already been shipped in all major browsers. Custom properties, which are like variables in CSS, have seen lots of improvements. They're now actually usable. The object model, which allows you to manipulate CSS in JavaScript, now you don't have to sacrifice your firstborn in order to do it. The layout API, level three layout API, big changes there. Too much to cover here, but you're probably going to see it early next year. Kaelan: Another thing I would say, the variable fonts are super great. I can imagine how much bandwidth that will save if everyone only has to send one font file and then just change it with custom properties. Yeah, exciting things in CSS. Besides that, WebAssembly, which I'm a big fan of, it seems like they finally agreed upon lots of important standards, like reference types, essential things to actually use WebAssembly outside of just a small novelty, essentially. Brian Neville-O'Neill: It was pretty popular for a small novelty. Kaelan: It promises a lot. Brian Neville-O'Neill: Yeah. Kaelan: Having the web to be as fast as native, the dream of every web developer. Brian Neville-O'Neill: What I hope for WebAssembly, outside of the dream of every web developer, is that more people become proficient in it, because for us, finding authors who know what they're doing or who know what they're talking about was really hard for the first 18 months. It's still not easy. So yeah, I'd like to see ... If it's going to remain popular, it would be nice if more people than just kind of perhaps a select few at Mozilla. Kaelan: Yeah. I'm especially happy that some of these standards have been finalized and the browser support is better, because I'm a big fan of the AssemblyScript project, which it's like TypeScript syntax, but it targets WebAssembly. It's fantastic, because if you wanted to write WebAssembly, your options are either learn Rust, force yourself to use C++, or use AssemblyScript. But it's quite limited today, which is probably why it's not much of an impact right now. But with the standards that I see and this browser support it will look like it'll have, WebAssembly, that is, by mid-next year, I feel like that might be breakout success with 2021. Brian Neville-O'Neill: Oh. I mean, look, you've said some kind of when to expect things in early 2021, but I believe that was your first- Kaelan: Prediction. Brian Neville-O'Neill: ... prediction. Yeah. Kaelan: Yeah. I mean, if you want to do anything that isn't a super limited, tiny, tiny problem, almost academic, you're quite limited, because without reference types, without garbage collection and all sorts of things that everyone expects in a modern language are just not there. So of course they're not supported in AssemblyScript. So of course you can't use it, although much of it doesn't matter if you use Rust, which is why Rust is the WebAssembly language of choice. Brian Neville-O'Neill: Yeah. Kaelan: But if the entire JavaScript community can run WebAssembly without having to learn another language with a quick migration path from their old code to the new code, that could be quite a substantial change. Brian Neville-O'Neill: Yeah. I would imagine. Then we could stop talking about Rust. Kaelan: Never. Brian Neville-O'Neill: I know. Never. Also, I know that Rust, too, has a very enthusiastic user base. Kaelan: Yeah. I'm especially happy to see web-focused libraries emerge on the Rust side, and some of them seem to be actually picking up steam. Brian Neville-O'Neill: Sick. We'll talk about that next time. Kaelan: Yeah, definitely. It's on topic. Brian Neville-O'Neill: All right. So we've talked a little bit about trends for WebAssembly and then full-on predictions. For those people that stayed to the end of the episode, they get the predictions, and you do rock. I mean, our hope, again, for Rocket Surgery is that you just listen. You're lulled into really deep technical stuff. Maybe you space out for a little bit, but come back, and you're like, "Oh, yeah, that's what I was looking for," like me when I'm reading the outline. I shouldn't that when I'm hosting the podcast, but you understand. That was such a humor... you're like, "Yes, Brian, good for you." I appreciate you humoring me. Okay. Next, what do you want to go with? Kaelan: We didn't talk about this before, but another thing that seems to be making waves is Rome, all-in-one toolkit, essentially, and tool chain, as they call it. It bills itself to be a linter, a compiler, a bundler. It makes coffee for you. It'll do laundry. Brian Neville-O'Neill: Does that make you nervous when it says it can do everything? Kaelan: Oh, definitely. Brian Neville-O'Neill: Yeah. Kaelan: It seems like they're focusing mostly on linting right now. It kind of reminds me a lot about Next, and it reminds me of create-react-app. It reminds me of all these other sorts of tools that ... really, too many to count. I know we have, I think, several blog posts now about tools in this space. Definitely my happiest trend, developer productivity. Nobody wants to wrestle with the Webpack config, the babel config, everything, which we've been doing for years now, since this era of web development, I guess you could say. Kaelan: The amount of trust that people are putting into these tools, I guess, was greater than it was years before. Maybe it's just that these tools are now backed by large organizations that have tons of developers assigned to them in a more professional manner than I guess the tools in the past have. Webpack has funding now. That would have been surprising to me years ago. Kaelan: So yes, I would definitely say we can expect to see more of that in the future, because it's quite popular. Besides that, not just the developer side, everyone is concerned with progressive web apps becoming a thing and AMP pages becoming a thing. People care a lot about bundle size, performance. They use Lighthouse to check their webpages, if they're cool. That can be very difficult to get your page score down. I know it, especially when you don't know why. If all you need to do is upgrade, that's monumental. It feels like it's finally becoming a focus and not just empty gestures. Brian Neville-O'Neill: Who's making these decisions, and do you get to vote? Kaelan: Illuminati. Brian Neville-O'Neill: That's why I ask. It does seem kind of like ... All right. I've always wondered. It never occurred to me to ask you directly. Kaelan: The Hacker News comments section, where all the decisions in the world are made. Brian Neville-O'Neill: I thought it was r/programming made all the decisions as well. Is it a combination of the two? Kaelan: They're the upper chamber, and Hacker News is the lower chamber. Brian Neville-O'Neill: I like it. Kaelan: Dan Abramov is the president or dictator for life. Brian Neville-O'Neill: I don't think that he wants that. From the little I've read about what it is he does and doesn't want, I don't think he wants to be dictator for life. You would happily take that job, however. Kaelan: Benevolent dictator for life. Brian Neville-O'Neill: Oh, sure. That's how they all start. Okay. All I really see here left in our little notes are Next.js products and then centralization. Kaelan: Yeah. There's also from a larger programming domain, not just web development, and not just this year, either. I know a bunch about game development as well, and the trends between web development and game development are not as different as you might expect, somewhat delayed for some reason. It seems like the trends from web development have leaked into game development. A big thing over there is now components. Sound familiar? Brian Neville-O'Neill: Yes. Kaelan: Yeah. Composition in general is a macro trend, to use a buzzword that I don't really know. Another one, reactive programming, data-oriented programming. Considering how popular they are and how they're revolutionizing multiple fields, I don't think they're going away anytime soon. But yeah. Brian Neville-O'Neill: I like macro trends. Kaelan: Yeah, we need more buzzwords. Brian Neville-O'Neill: Does that mean across different fields of programming? Kaelan: Yes, I think. Brian Neville-O'Neill: If a micro trend ... isn't that not a trend because it's too small? Kaelan: You raise an important point. Brian Neville-O'Neill: Thank you. I almost wish that we could take phone calls, but I don't think that would work. You can just tweet at us, or you could follow and subscribe or leave comments. Kaelan: Yes. Brian Neville-O'Neill: We don't have a Patreon or anything like that. That would be weird for a podcast. Kaelan: You can send me money anyway. Brian Neville-O'Neill: Don't send Kaelan money. He's fine. I think we'd get in trouble, honestly. Kaelan: I accept only Monopoly money. That's the only legal tender I value. Brian Neville-O'Neill: Nice. Good save, or weird crypto. Kaelan: Dogecoin. Brian Neville-O'Neill: Yeah. But that's real money. You could do something with that. I don't know what. Kaelan: Not according to the government. It is not real money. You never thought I would say that. Brian Neville-O'Neill: I was going to say, that's not really your motto, but okay. This feels like a natural ending to Rocket Surgery, episode number two. Is there anything that we either didn't say, left out, you feel like you want to cover before we wrap this up? Kaelan: Nothing in particular. I guess a lot more can be said about browsers and specifically the tooling space, VS Code. But we could talk a lot longer about that. If I had to put the numbers up, which I do not right now, but I'm pretty sure I'm correct, don't quote me, anecdotally, it seems VS Code has massively increased in popularity, at least from what I've seen, every developer, comments on every blog. Every single time TypeScript releases a new editor feature that is amazing, everyone's like, "Oh, wow." So more macro trends in that space. It seems like if you were to tally all the updates, Firefox, Chrome, even Edge, for God's sakes, really nice developer features, it seems. Brian Neville-O'Neill: Safari and Edge taking a beating today on episode two. Kaelan: Do not use Safari. Brian Neville-O'Neill: Yeah. Well, we used to ask you to write a blog post to kind of sum everything up, but this feels easier, now you can just talk about it. Kaelan: Less writing. Brian Neville-O'Neill: Less writing, more listening to me, which is probably a bad thing, but you're used to it at this point. Cool. We're done. Thank you for listening to, again, the second episode of Rocket Surgery with me and Kaelan. We're going to just keep doing this. This does represent a little bit of kind of a departure from our regularly scheduled programming, where we interview folks. But I think it's a nice way to break things up, and it's a little bit more casual. So if you have any feedback, either on this episode or anything else, again, you can just either tweet @LogRocket. You can even just email me, brian@logrocket. Kaelan, do you want to give out your email address, or would you like to keep it protected forever? Kaelan: No. Brian Neville-O'Neill: Yeah. Kaelan's good. So you tell me, and I'll tell him. How about that? Anyway, that's it for us. Thanks again. We'll see you next time. Brian Neville-O'Neill: Hey, it's Brian again. So it turns out that running a podcast is maybe harder than we thought. So I kind of want to hear from you. I'm genuinely interested in your feedback. We have to think about new topics, new guests. We have to find them, and don't get me wrong. We can do it, but it's a lot easier if everyone else who's listening helps. So if you'd like to suggest a topic or volunteer to be on PodRocket, we'd like to hear from you. So you can do that by going to podrocket.logrocket.com/contact-us. The hyphen is next to the delete key, if you're curious. If all of that is too long, you can just email me directly, brian@logrocket.com. That'd be great. Also, if you're feeling magnanimous, be sure to like and subscribe to PodRocket. Thank you.