Emily: Hello and welcome back to PodRocket. My name is Emily, Producer for PodRocket. Today, we're recording our yearly wrap-up episode, Rocket Surgery, to discuss not only the good, the bad, and the ugly of the past year, but also talk about what we think 2023 holds for the world of software development. With me to discuss these topics are our PodRocket hosts, Kaelan and Noel. Kaelan, do you want to introduce yourself, tell us a little bit what you do? Kaelan: Yeah, sure. I'm Kaelan, senior engineer at LogRocket. Been here for quite a while, help out with the content team, and I mainly do architecture stuff for the front end at LogRocket. Emily: Awesome. Noel, you want to refresh our listeners? Noel: Yeah, yeah, yeah. I am all our Head of Growth with Engineering, so I'm the liaison between our engineering and marketing teams. Before this, I was doing just full stack feature work for the platform, but yeah, we do a lot of stuff with the blog and website and all that fun stuff. So, that's where I spend my time. Emily: Yeah, we love both of you helping the content team out. It helps us make really good content for everyone. Well, so excited to get into it. It's been a very busy year. We have a lot to talk about. So, let's just start. To go over what we thought 2022 was going to be, I have some of our predictions down, so let's just review them. First, let's start off, web development ecosystem is decoupling from JavaScript. Did we see that happen in 2022? Kaelan: I think we definitely did, especially in the tooling space. I know for a good solid eight years since Webpack, Babel became like the de facto solution. It has been frustration, and now with Rust, getting super big and also go to a lesser extent. Now, there's finally tools that are ready enough that they can actually fully replace Babel and Webpack. In particular, I think Turborepo and ES Build. ES Build in the case is a foundational component. A lot of people might be using it without even know knowing it. I think Vite uses it. Noel: Yeah, I totally agree. I think it's proved true in the tooling space in particular. I feel like it's been the year of Vite this year, which we'll get into more of later. I'm not sure if it has been as represented as much in what devs are actually writing as code, but I feel like the tools that people are using, even if they're not doing much work in them, those have been shifting to faster technologies by necessity. Kaelan: Yeah, when you talk about what's vogue right now, I guess to specify, I mean of the new things coming out, what percent are like non-job script? I would say then yes, definitely. Of course, it will take years probably for all these tools to be even half of the community using them every day. Emily: We're going to get into TypeScript and Node and WebAssembly later, but any beginning thoughts of any of those before we get into the nitty gritty of how you thought they were going to change this year? Did they meet your expectations? Did they exceed it? Was there anything different? Kaelan: I will say that WebAssembly perhaps didn't make as much waves as I hope. Of course, it's been like five years of me being disappointed at the state of WebAssembly. Things are still moving slowly. I mean the Rust community is growing very big and always compile your things over to WebAssembly through that. Because of that, Rust has actually taken off as a legitimate option for front-end frameworks and stuff. That's in exist and it became more mature over the last year, but it's still a very niche thing. It's definitely an area to look into in the next year though I think. Noel: Yeah, I feel like the Rust ecosystem has been where it has been happening. I feel like other than that, the tooling just isn't quite there so it's stayed niche still. Not that it is particularly hard to get into. I think it's just not something devs tend to be reaching for when they're going to kick off new projects or starting to build something as much as I keep expecting. Yeah, we'll see what happens. Emily: It's crazy how things change within the year. We also talked about React having serious competition coming in from 2021 to 2022, which I think was totally spot on. We're going to get into all the different frameworks and everything. There's been a lot of talk about React not fading because it's still very popular but it has a lot of competition. So, how did you see that manifest this year? Kaelan: React is weird in that... Well, frameworks I guess are weird in that if you spend all your time in one framework, then you don't really pay attention to the other ones unless you have a reason to. So, from my perspective, it seems like React is still super popular. Vue, I guess, I would definitely say as number two, but others perhaps were called in previous years legitimate competitors I think probably have started to fade a little bit. I guess maybe that just might be my conception of the community, not backed by any hard data. I've also noticed over the last year more Vue frameworks building on top of web components and we'll talk about this later, but I think it's probably a safe bet to say that over time, we will eventually move in that direction, because developers like less complexity. What could be less complex than using what's already in the browser? But that's a hard thing to predict. Emily: Yeah, absolutely. I mean everything's changing all the time. As we've already discussed, we've been wrong and right about certain predictions we had from last year. If we have no more other things to go over about last year, let's dive into this year and what we're expecting for 2023. Since we're talking about React, let's start off with React. React 18 was finally released I believe this spring. What did you like about it? What did you wish there was more of? The biggest question of all, where do we see React going in the future? Kaelan: React 18 was a big upgrade. React 17 if you don't remember was the easy upgrade that didn't really change much but React 18 is when they started to actually change things. It's mostly a lot of backend changes that paved the way for other things that they want to do in the future rent and server side components. It's a C change. I guess to my previous point, it does further depart React from just being a Vue framework. I think I've seen some contention without respects. Some people thinking that React is getting doing too many things. I saw this year and especially since LogRocket pays attention to this a lot that they are like for instance mocking fetch. It's just like mocking fetch in a Vue framework. I did not expect React to have to do that. LogRocket, we have to pay attention when libraries are mocking things that we are also mocking, because that sometimes can cause issues. So, that's how I found out about that and I'm like, "Why are they doing this?" That's a little compelling. Another point of contention I've seen is Next.js. Especially with service side components, they're working very, very closely and it seems like increasingly those two communities are merging. I think that might be a point of contention. So, people perhaps are not too comfortable with how close they are, but if that's the direction in communities going, then I guess that's a good thing. At LogRocket, we haven't quite gotten as far as operating new React 18 yet. We have a huge code base and it's a lot of things to change, but I have used it for other apps and I do like the new features and I'm excited for server components. But have you used any of the new features, Noel? Noel: I haven't spun up a React project in a while. I'm a Vue guy still so I haven't. Outside of work stuff, I'm not having it much. But yeah, I think Kaelan's point on the relationship with Next or how that is playing out and how that is influencing the framework is the interesting bit to pay attention to here, how the community reacts to it. I think on one hand, it makes sense as React itself becomes more all-encompassing and trying to do more than just be a front-end library and become more of a whole framework. It makes sense that they're having to work more closely with Next, which is the prominent framework to get a lot of the benefits they're trying to derive I think from the direction that they're going. But yeah, it does I think lead to this fear that people have of, "Is React eventually going to be more of a product that we are buying that happens to have this open source core but you're really buying into Next if you're using React?" We don't know yet but I think that that's where a lot of that tension is coming from. Emily: Yeah, I think the biggest moment this year that I remember was just watching Next.js Conf and Andrew Clark who's on the React team saying that Next 13 is essentially the real release of React 18. We've already talked about this but at risk of repeating, what do you see Next doing within this next year that may either take away from React or again just having this weird melding that everyone's like, "I don't know"? Kaelan: I hope they don't forget that not everyone can switch to Next. LogRocket for instance, we are a gigantic React app and we're a very specialist Snowflake, so we need those decoupled tools. Close relationships with Next is as good as long as anyone can pick up the documentation and make their own Next.js competitor to do for whatever reasons. We'll get you this later, but there are promising alternatives that are not Next.js I think. Close collaboration is okay but not too much I guess. Noel: To that statement specifically about the next release actually being the real React, Next 13 being React 18, I feel like that was a little bit more pitchfork than everybody needed to get probably, the heat on that. He probably was alluding to this is where React 18 is going to get the most traction, the most quickly is people on Next 13 spinning up new apps. This is where it'll hit production the fastest, people getting out new React 18 apps, which is fair enough. That's your Azure developer that you're proving around so that's what you're thinking about. Yeah, I think it is giving devs a bit of pause. This may be a point that leads devs to switching to something else like the Solids, the Vues. I don't know, just people that know they're not going to want to buy into the Next ecosystem for whatever reason, I think that if they're of that mindset, they might not go with React as quickly as they would've in the past. Kaelan: Well, Vue definitely seems to be going the same direction towards large tools that do everything you need. I just find it funny and then I've brought this up in previous Rocket Surgery episodes, where the community goes in waves of monolithic frameworks that do everything that you possibly need to do but are very inflexible and then everyone's like, "Oh, we should have very flexible anatomic things that only do one thing and then you get a setup that takes an entire month to install and then you have to install literally 3,000 NPM packages," stuff like that. In five years, React will be one giant framework, React Next or whatever, and then someone will come along making something small and atomic again and then we'll just be back wherever we were five years ago, five years previous. Emily: I think that goes into my next question. Do you see us in the era of monolithic tools and frameworks and everything or do you think that we might realize in 2023 maybe we should take a couple steps back? Kaelan: Yeah, because the previous generation of tooling was just needlessly complex. I'm looking at you, Webpack. Also, some of it was the browser changes like Webpack and Babel came out at a time when you needed to bundle everything. So, the tooling was by necessity more complex, because script module were not supporting the browser and that will to use any modern features you needed to use Babel but we're not there anymore. So, the only reason to use tooling is to get complicated things like server side rendering, which is something I would never want to implement myself, let's be honest here. If you're not doing service side rendering, then you might need other things but they're not the same things. Emily: We touched on Vue a little bit so I think that's the best time to start talking about it, because I know, Noel, you specifically love Vue. We have you on all our Vue podcasts too. Vue 3's default version was finally released earlier this year. What were the pros? What were the cons? I think the composition API was also released this year. What are your thoughts on how Vue did this year? Noel: Yeah, Vue.js Core is View 3 now, so it's good. I don't know. The Composition API think for all intents and purposes is pretty synonymous with View 3. So, that's been good. People have been able to use it. It's nice. If you're not familiar with the Vue ecosystem, it's the same abstractions that Hooks gives you with some nuance. People that are really in the weeds will say no, it's different because of X, Y, Z, but that's how it feels day to day, I think. Yeah, I think for the most part, the community's been into it. That's how new projects were spinning up. I think a lot of the difficulty was in the transition, because a lot of the conventions that previous Vue, like Vue 2, there was discussion around what was going to be changed, how much backwards compatibility there was going to truly be. So, it was a lot of heat at the time. Maybe this was probably technically the tail end of the last year when a lot of this discussion was happening, but as the cutover did happen in February I think this year, it came to fruition. Yeah, I haven't heard too much post it becoming the standard too much griping from anybody. I haven't really been looking for it. I guess another tricky thing is some of the tooling took a little bit longer. A lot of the big component libraries and stuff were a little bit slower to migrate than the timelines. I think that's what gave a lot of Vue its success initially was there really strong component libraries in Vue that you could just go pull off the shelf and start writing in and that helped to gain a lot of that popularity. Some of those took longer to migrate than anticipated. So, I think that that slowed adoption but we're getting there now. Kaelan: It sounds like the Vue community's in a similar situation when React Hooks has announced that it caused a massive amount of rewriting and dead libraries and crumbles and people using things incorrectly. Would you say that Vue has learned from React's mistakes? How does it compare to Hooks in day-to-day usage do you think? Noel: I think so. I think Vue does have the advantage of usually being a little bit behind React in that migration for better or worse. We'll talk about this more when we get into state libraries, global state management and stuff. Vue can see what's working and what isn't working and make minor course corrections there. It's hard to get into specifics about getting super in the weeds on object observation and stuff, but yeah I think so. It feels pretty clean to pick up and get going. I think there's probably another, like you said, the same problem React had where it's like now, we're in this state where you go look up Vue tutorials or Stack Overflow questions and you end up with this big combination of Vue 2 versus Vue 3 ways of doing things. So, that might be confusing for new devs and I think React has that same problem, but I don't know how you totally avoid that if you are trying to switch paradigms like was done with the Composition API and the Hooks API here. So, I think the short answer is yes but with some nuance. Kaelan: It does seem like they put more thought into it I think than React. I guess they have a benefit of being slightly higher level. Noel: Again later, they can observe the React community, see what's going on. We could talk about state management a little bit there too like UX and Pinia, which I haven't used, which is their Redux equivalence. I don't know what's been going on in the React space too much there, because again, I haven't been spinning up React apps much recently but it's interesting to you because I feel like there's a group that's still spending a lot of time and energy on global stores state management but then also with the Composition API and with Hooks, I feel like the need is greatly lessened. Do you think that that transition is happening, Kaelan? Are we moving away from needing these tools at all? Kaelan: Yeah, I don't even know what to talk about in that space anymore to be honest. React community went through the same thing. We moved from the Mantra. I've put everything in Redux to just do what works. I know a lot of people now for instance use data fetching libraries, particular ones with GraphQL like Apollo for instance. They prefer to actually put all their state there, even things that aren't GraphQL or things that aren't even touching the network and some people that do both or they have things in context and components essentially. LogRocket of course was designed to record all of your Redux store state. So, that transition has made that particular feature of LogRocket less useful unfortunately. Now, that the state is autonomized across the entire app, it started to attract throughout tradeoffs. But I do think it was a little weird, the whole mantra of everything must be global state, but I never quite saw the point. Noel: It seemed to almost counter to what we were trying to do with separation of concerns with components and stuff. Why make this giant polluted object that you always have to need or always care about observing in all these places and you end up with all these weird race-esque conditions for things because everything's up in this global state? So it was hard. I think similar with Hooks but in Vue, we have the provide inject API more or less where it's very easy to pass state down to arbitrary lineage of components. It can be from this parent 27 children regardless of how far down. They can just wire in and say, "I care about this global value or the value from any of my ancestors and pick it out." Yeah, that does feel like it solves most of the need that I ever had for global state. Just put it at the root if it really needs to be global. If not, put it at the furthest down node you can and then it's controlled as much as possible. Kaelan: Just curious, does that use proxies? Noel: I'm not sure. I don't know how it actually works under the hood. I've only used it a couple times. Kaelan: That's been a trend over the last couple years. Mostly board developers finding a use case for proxies which explains the five new state management libraries that come out every week. That seems like magic where you can just edit an object and then another component will just automatically render the changes and everything. Proxies are great and it's a good example of the community finally using modern standards, because we don't have to worry about browser compatibility anymore since IE died. Emily: Are there any of those libraries that come out every other week that you thought was really game changing comparatively to Redux? Kaelan: No, which is why it's notable, because I literally read one a week and then it's in one ear out the other. There's the Atomic State Management Libraries I think one by Facebook. I forgot the name of it. I've been meaning to try that one. That one looks good. So, if you're interested in new transfer state management, I think I would look up Atomic State Management with Adams. Recoil? Noel: Yes. Recoil. Emily: You want to talk about JavaScript run times? Because this has been contentious as well this year. Kaelan: Big one. So, you might have heard of Deno and you might have heard of Bun. So, Node has done a pretty good job over the last couple years of getting onto standards. You can now use script modules. Here at LogRocket, we're preparing to switch over to that, which has been something we've been looking forward to for a very long time. Get rid of our awful build system for server code, but recently, there's been more competitors. Deno came out first, found some use for cloud functions I think for writing stuff like that, but one of the things they tried very hard to do was focus on security and ergonomics and stuff, developer friendliness. But it seems like performance was an issue. I think if I remember correctly, one of the things that the problem there is that they're using TypeScript, which is written in Nodes. You're dependent on the Node runtime in a way. There are some people trying to rewrite TypeScript and Rust for instance and stuff. I don't think that's anywhere near ready. So, Bun comes out and is incredibly fast. The internet loses their mind, and just like Deno, it's like a drop in replacement almost. Well, that's another change I should say that Deno did. I think this year, they also really support for MPM, which was notable, because they tried very hard to say MPM is bad actually and we should all use URLs. That did not take off, I don't think. I was always confused by that. Curiously though, I've never actually seen anyone or heard of anyone actually using either of these. Noel: Bingo. That's the thing that it's weird to me about this as well. It feels like there's all this fervor when they come out but then it just doesn't come to fruition in the way I expect. Maybe it's just because most devs aren't using these much. Kaelan: It was supposed to be the next big thing and then it never became anything seemingly. Noel: Maybe it hearkens back to what we were saying before of the end of JS tooling, that being the tooling language and these run times may end up being the same thing where it's just the people that actually care about what runtime is being used is probably smaller than one would expect most of the time. Most devs aren't going to go into their tool chain and try to switch out which runtime is being used. It's like if the tooling starts changing it by default, then maybe that's when this starts mattering more day to day. Kaelan: All these people making new projects don't spend enough time considering the migration path. I think that's one of the reasons why things don't take off. I mean it's great and all but people don't often start new projects. Like you say, it's a drop and replacement, but I don't believe you essentially. Emily: We'll talk about this later, but a few of our listeners are actually sending in questions about legacy projects and having to work with these one said ancient frameworks and tooling and everything. To your point that migration is very hard, it's not always a drop and replace, do you think there will ever be a need for a drop and replace runtime? Do you think it's ever possible? Am I just totally speaking out of ignorance? Kaelan: It depends. I know that there are some Webpack alternatives that could be a drop and replacement, because that's a component that you can replace because you're not running in your code. It's just transforming it. If it does the transforms correctly, any other transform could also work, but we're talking about the runtime. There must be a million edge cases and bugs. There are other trends in the community that might make this easier like micro front ends. Like I said earlier, maybe you use Bun or something for rendering your service side components but not for your API or stuff. Maybe that could be your migration path. You don't have to migrate your entire ecosystem over to Bun or Deno. With monorepos and stuff, that's easier to do. So, that's probably the path forward for those tools in the short run. Noel: Yeah, I feel like the server side rendering is a good example too, because you can do things, run an instance of both, make sure they're the same for a lot. You can do that pattern, but yeah, I feel like it shouldn't be that hard. It was a true drop and replacement for people to be experimenting with this and I'm sure they're out there, people are doing them and making it work. It works with my side, project X, Y, Z. I'd expect it to be popping up in the Blogosphere, Hacker News posts and stuff more still. There's not much community engagement. Emily: So I wanted to talk a little bit about TypeScript because it's obviously grown in popularity. There was a survey that I'll actually link in the comments that 84% of the survey respondent said they used TypeScript this past year. A lot of people are saying that this is heralding in a new era for web development and that there's no reason to use solely just JavaScript anymore. How do you guys feel about Typescripts? How do you think that's going to change in the years to come? I don't think JavaScript's ever really going to go away, but it definitely is changing a landscape from my point of view. Kaelan: Yeah. Going back to JavaScript just feels like losing your sense of smell or something. I don't know how to just try that. Something's wrong. Noel: Yeah, I agree. I think even if you're just trying to set up something quick as a proof of experiment, it's still so easy to do it in TypeScript and you can just always escape the rails that TypeScript has given you to be any. I don't care about the semantics at this given point, whatever. It's pretty unobtrusive. You can get it out of the way, even in a TypeScript project when you want it to. There's not a lot of reason. Kaelan: Yeah, I mean even if you don't even have a build system, there's still ways of doing it. You can just run the command. You don't need to install Webpack and Babel and everything. People underestimate just how seamless it is or they think, "Oh, I'm just writing a small script." Well, small scripts have a tendency to turn into giant scripts, and then suddenly, they're key parts of your company's infrastructure five years later. So, do everyone a favor and use TypeScript. This year also, I always like reading the blog, the TypeScript updates. They continuously come out with the most minute seemingly changes that makes it feel like they're really thinking of everything and of every edge case and being as strict as possible. This year, they come out with the satisfies operator. I think that's probably the biggest feature and that NDS code, which is always tightly integrated I think when you talk about TypeScript. Noel: It's so fast in VS code. It's wild. I think that adds a lot to its ease of adoption. Yeah, the refactoring is easy. The higher order functions to where you can go into a type and extract. I want the type that is the return value of this function or I want the type that is the first argument of this function. I've been messing with those a lot more and they've been making some of my code a bit more concise because I like having fewer type definitions that way. It's all just bubbles out naturally and it's just like I'm doing these things. I'm like, "Man, this is sure easier than a lot of strongly typed languages I've used in the past and I don't need to declare all these classes that don't really need to exist for any reason other than passing data around." I feel like TypeScript's abstractions are very, very nice. Kaelan: I've had to use C# in side projects for game development and I find myself missing TypeScript so much almost every day. Why can't I just do this? Why can't it just work? Noel: Yeah, no, I'm happy. Yeah. It's good. Yeah. Emily: While we're on languages, let's talk about Rust. We got a bunch of listener comments and questions about how much they love Rust and everyone's using it. Last year, we talked about whether or not Rust would become a more dominant player in the non-JavaScript front end space. Did you see that happen? Kaelan: More dominant, yes. Vue, for instance, one of those component frameworks that I've been looking at supports all the things that I would consider the bare necessities and one coming out this year, like server side rendering. I have seen the usages of those go up. Like I said previously, Rust is being used long ago in tooling. So, even if you don't use Rust, never learned it, don't care to learn it, it's still changing things. So, I would say yes, it has not taken over the community, but it's consistently ranking high on developer surveys of most loved language and the languages that everyone wants to learn. So, best bet you can possibly make I think. Noel: Why do you think that is, Kaelan? Why do you think Rust has gotten into the Geist so much this year? Kaelan: I don't know. That's a good question. Everyone who learns Rust seems to love it. I think probably because of the developer experience, if I had to say, removing an entire class of common errors and holding your hand when it does report an error and stuff like that. I've briefly tried to use it for game development and stuff. Definitely not ready for that. It does seem ready to use for web stuff though. Emily: How do you see that manifesting in web? Kaelan: That everyone wants to ditch Node and rewrite their projects in Rust. That I think is a good sign. Emily: Yeah, I noticed specifically on our LogRocket blog, our Rust post always do pretty well and everyone's always surprised. We're like, "It's becoming more normalized, it seemed." You talked about Vue. Did you look into how Seed fared? We talked about that a little bit last year. Do you see either of them growing more or their frameworks? Kaelan: Yeah, there's like a lot of them, actually. There's like a popular webpage, Are we web yet?, made by the Rust community, which is a good general table of contents almost of the different Rust versions of things that you need for web development. Yeah, I think it's a good option. I mean with WebAssembly, now you can even find someone in C# too if you didn't know front end Vue frameworks, but Rust is a good option I think. Emily: So moving on, we touched on Webpack a little bit and it was Vercel that introduced Turbopack this year and everyone seemed really excited about it. How do you see that shaping how developers might continue to stray away from Webpack? Because I think you guys mentioned it's not as popular as you thought it would be. Kaelan: I think that's probably just inertia. The reasons why you use tooling, like I said earlier, is very different from five years ago. Turbopack focuses on almost their entire features that did not exist in Webpack V1 almost. But Turbopack is definitely one that I was looking into or actually pushing LogRocket to using it, also Turborepo. Like I said, the general trend, everything's converging. The monorepo tooling and your bundling tooling, they're always tightly integrated so it makes sense for those two to be even more tightly integrated. Noel: Yeah, I think we don't know yet. I think we're still pretty early, right? This is all a pretty recent, a few months ago thing. So, I think we'll see. I think the interesting juxtaposition here is Turbopack, assuming that everything's going to move away and Webpack incremental updates are going to be inadequate for devs for the use cases people need it for. I think it's going to be interesting to see where we end up, because Turbopack by virtue of where it's slated in so tightly coupled to Vercel to Next, maybe it ends up becoming the norm a little bit more. But on the other end of that, I feel like a lot of the open source tools and stuff are leaning more on Vite, because it is what it is. So, I think that's what I'm keeping an eye on right now. Kaelan: It doesn't actually seem too tightly coupled from what I can tell. Noel: I know I don't if it is. I think it's just the- Kaelan: Feeling. Noel: ... perception. Yeah, people feel like it is that way. Kaelan: But I think in general though, if you can tell someone that you can turn your one minute builds time to 10 microseconds, that's very, very competitive, particularly when we're talking about legacy systems. If you want to tell your PM, "Hey, we can ship code so much faster if we didn't have to wait half an hour to ship to staging," you might actually get some buy-in. So, I think compared to other tools, the bundling and monorepo tools both can actually change pretty fast. I think actually Lerna is dying. It was replaced with NX or it was taken over by the NX team. Yeah, NX is another monorepo tooling in the same category I guess as Lerna and Turbopack or Turborepo rather. Personally, if I were to start a greenfield project, I would probably pick Turbopack at least by the speed comparisons, which I think are the most important. Emily: Before we get into some of our listener questions and predictions for the end of the year going into 2023, I do want to touch on styling and browsers a little bit. One of the biggest things I remember happening this year was CSS introduced the has pseudo class and it's officially supported by Chrome. Why was this such a big deal this year? Kaelan: It's one of those CSS features that people have been asking for forever. You can look into our excellent blog posts about it, but the big picture is that, I guess from what I'm wondering what will happen in the next year is how this plays in into the eternal argument about CSS and JS. If we can now style using [inaudible 00:37:13] and CSS, I can't even think of really anything now that isn't supported by CSS that you needed to rely upon JavaScripts to style things differently based on their children. Also, the other selectors that have been added recently that frankly a lot of the community probably haven't even heard about because people have been using CSS and JS. I would like to CSS move off of it. I think in general is if we can use what's supporting the browser as much as possible, that is a good thing. Noel: Yeah, move off of CSS and JS. Kaelan: Yeah, it's slow. If it's not slow, it's complicated or both. Noel: Oh, for sure. You have to run JavaScript, right? Versus just sending a file. Yeah. Kaelan: Size and performance. You work more on actual websites than I do. I guess it's more important like lighthouse scores and stuff on normal websites. Noel: I mean nothing we do is that complicated. We don't have a ton of custom styles on most of our stuff as it stands right now. I haven't done much out of sandboxes with it. Oh, cool, I understand why one would use this, the has pseudo class specifically, but I don't know. I feel like CSS is in a healthy place. I feel like it's catching up with a lot of the features that people wanted and they were leading on JavaScript for before. We'll see I guess if web devs care. A lot of CSS and JS is easy to do in certain situations. CSS and JS is easier to implement sometimes when you can just link it right to your logical code right there, but I think once you've gone through it a couple times and can separate those concerns that there are performance wins and stuff. Yeah, again, you don't have to rely on tooling and a tool chain to figure that stuff out for you and you can just do it natively. So, that's always nice as well, simplify that. Kaelan: The CSS working group actually for our listeners, if you want to see about things coming up, they published their notes and stuff like far in advance. This was in the works for at least three years. I think you can definitely tell that they're working out on a lot of things. So, like I said, I think it's probably a safe bet in the future, we'll be using more of the actual features. Speaking about styling, I guess we have to talk about Tailwind, otherwise we'll have lots of angry comments. I wonder if this means that Tailwind could stop being such a giant monstrosity on your bundle. Maybe. I don't know. Have you used Tailwind? Noel: I mean, no, I haven't. To answer your question, I maybe. Again, I think that's what I was dancing around before as well. I think it's not free right to switch to a lot of these new CSS paradigms. It's a refactor. You got to rethink how all your code is working, so we'll see how much that comes to fruition, I think. I don't have super strong feelings on Tailend. Kaelan: I have not used it. It seems like an awful idea. It's funny. The styling was popular 10 years ago too and have died and then came back. Emily: I do just want to throw in the State of CSS came out literally yesterday and Tailwind is still the top library for CSS and then Pure CSS is after that, but it's still at 80% just to throw that in there. Still popular. All right, browsers. So, last year, Safari is the Internet Explorer of the modern age. Did it gain any respect this year whatsoever? Noel: Yeah, I feel like that was a meme. We were joking. I think it's becoming less of a meme and now it's just like a literalism. Yeah, it just feels that way. Kaelan: I guess the big news in browsers this year was Manifest V3 controversy that Chrome announced it's set to go in effect I think in January, sometime soon, which will be killing ad blockers. It upset a lot of people in the community. I guess the one thing to look out for is whether or not developers start to switch en masse to Firefox. I wish I was one of them, but the inertia is strong. Emily: Is just Chrome too big that Firefox probably can't attract more developers? It's just so integral into web development at this point. Noel: Yeah, no, I don't think so at all. I don't think there's any major quantifiable factors that are causing this, I guess particularly in the dev space. The old argument was so many of my users are using Chrome. I want to make sure that I'm testing and running with that, which sure, I guess that's reasonable, but I don't know. I feel like at this point, you're not going to have something that works on Firefox and doesn't work on Chrome for the most part. I'm sure there are cases, but it's not a case I've run into in a long, long time. Kaelan: At LogRocket, the only browser differences that we've run into recently have always been Safari related. A lot of those come up a lot, because LogRocket, we record and then we also play back. So, browser for our sessions. So, the browser differences can come up in two very different areas. So, we're very cognizant of how awful that is. But for developers, you should be using Firefox. The Firefox developer tools are pretty great now. I need to follow my own advice. Emily: Were there any Chrome dev tools that came out that you liked this year or Firefox dev tools? Kaelan: Nothing in performance. I think the lighthouse score was two years ago or something. Maybe more, but almost for saturation point I guess. Noel: Yeah, I mean I've been a Firefox user for a long time, at least last I checked. I haven't done it in the browser in a while, but there is still no Firefox dev tools, native lighthouse checker. They got installed something for it, which is a pain in the ass. Yeah, no, I mean minor improvements have been made to the Firefox dev tools UX more than anything. Nothing majors come out that I've been like, "This changes my day to day drastically," but it's adequate. I feel like very seldom anymore like I sure wish I had this in my dev tools. It's there. They're fine. Kaelan: A while back, the only thing keeping me on Chrome was the fact that Firefox did not support shared array buffers and I had side projects that were using those heavily. Firefox had lots of embarrassing open issues about them and very bad performance problems for a very long time with Canvas. So, if you're doing what I was doing in development in a browser, Firefox was an awful solution, but things have probably changed there. Noel: I have a side part that's like all canvas and it totally works in Firefox. It was a little bit more performing in Chrome, but it was like once I was doing Canvas things, I was buggy terrible coding. Once I was Doing canvas correctly, it works very well in both. It's fine. Yeah. Emily: Awesome. Well, I think we've covered quite a brave ground for this past year. I want to get into our listener questions. Some of them had problems this year that we can probably address and predictions for the next year. So, we touched on this a few times now, but we had two listeners submit questions about legacy technology and their problems have been arising when their business doesn't want to forego their legacy systems. So, we have two questions. The first, if a business isn't willing to move to newer technologies, how can engineering managers try to integrate these newer technologies into an older stack without a full rewrite? Noel: It's very situational. Depends on the situation. Kaelan: It's tough. That's hard. I guess my answer is sometimes you need a folder here. Sometimes you need to rip out your entire build system and replace it. Sometimes not doing that actually will make it four times more work. I've had that argument so many times. Oftentimes, it comes from people who are not familiar and they just think that, oh, surely doing the half step will save us time. Things are not that simple. To me, the question is how do you justify it. I think what has always worked for me is build times and performance. You can either find one or the other. If you can tell your CTO, "Hey, we can have our developers stop waiting on the builds and then ship faster." Another thing I think a listener brought up is about a storybook that's a relatively new addition to the tooling set where you have a separate build for just your components and then oftentimes your designers want to see the changes for that. So, you can get complicated build systems for that, but that creates a lot of value that you can immediately put a dollar sign on. Your designers make less tickets for about nits and stuff. That has a verifiable impact on your business. So, use money as your excuse I guess. Things get more nebulous on websites where you work on, Noel, performance is the other side of this, I guess. Noel: Yeah, I guess, I can talk about performance too, but I think on your prior of tying it to money, I think you can help put together a story when you have major bugs or things that are user facing like outages and stuff and it's easy to tie them to a legacy technology like quantifying that, capturing that, making lists of those things and be like, "This is how much this is costing us." If we weren't on these legacy systems, we wouldn't be having these problems. So, we would've probably have other problems too that it would be smaller. I can't see into the future, but some of these problems are unique to this old system architecture, whatever it is. If you can add those attributes to your asks as well, I think that generally helps. I think it's actually getting a little bit better. I'm getting into trends and predictions, but I feel like this year, there's been a big shift towards performance again. As we get to pre-compilation, server side rendering, doing stuff on the edge, people are caring more about that performance and stuff. So, I think you'll start to see even more of a delta between website's systems in general that are not using that or unable to use that due to old technology versus stuff that can or can partially use it. So, we did a website cut over. The old one was a more traditional setup. The new one is all pre-compiled on Gatsby and it's faster. You just hit some of the pages on the new site. It's like a couple millisecond or a measurable probably maybe 100 to 200 milliseconds, but it's faster. You feel it, you click it, it loads quicker. So, again, it's hard to quantify that, but I think we're getting there. Lighthouse scores ranking, impacting Google search rankings, and stuff that will also matter. I think as that pushes into mobile more and more, that's going to start mattering. So, those are easy numbers to pull a lot of the time as well that can help one make that argument. Kaelan: On the app side, arguing for performance is often a lot harder, because when your app runs a very complicated query that already takes five seconds to load, who cares if your site takes a complete second to load? When your users don't expect performance, oftentimes it's only the developer arguing for it feels like sometimes. But I guess the followup question was not just about tooling, but what if your company has a ton of old Jaguar code? I will start by saying, I'm so sorry that you're in that situation. I guess you could still tie that into money too. Even recruiting too. I would not work for a company that was using Jaguar alone, nothing else. It's just unacceptable. You're running a business like this? I don't know, 15 years obsolete. Noel: Yeah, chasing your time. I mean it's hard. Not everyone's in a position to move and change roles and stuff, so it is tough. But I think if you find yourself in that position and you're finding it hard to recruit people and stuff, again, start quantifying it and be like, "We're losing potential hires because of our technology, our current stack." I feel like that can help you make your case too. Kaelan: Great question. This space occupies a lot of my time at LogRocket, because I am like the liaison between design and engineering almost. So, like I mentioned earlier, Storybook came out a couple years ago. It had a great year, a big release. Maybe it feels like they've had 10 pieces. They're very framework agnostic. There are competitors, but I don't see why you would use any of them considering how feature packed Storybook is now. It's almost like a parallel set of tools now for just the space. To make a good design system now, I think it's important to be very integrated with whatever tools your designers use. Figma is big until Adobe bought them this year. Who knows what will happen next year? Sorry for all your Adobe employees listening. One big thing that I found, you want your developers and your designers to be on the same page. So, linking those together, that happens in Storybook. Another big thing is like visual regression testing. It's super easy to do with Storybook because you're already running the tests and they fulfill three different functions. They can unit tests, they can be documentation for developers and designers, and also your visual regression testing. That's just awesome and it's something that we at LogRocket have started to explore. Well, I guess similar to design system's component libraries, I've noticed also this last year, style agnostic component libraries, at least five of them. I really like that because no one likes to override 100 different styles. It means that you can pull in a style agnostic component library and then to supply your design system that already exists, which is just great. Saves a ton of engineering time. Emily: Yeah, totally. I want to move on one more listener question, design systems. They were asking, who are the current design system industry leaders and what technologies do they use to maintain and deliver design systems as living documents? I also just want to ask, how do you see the design system space changing in 2023? Noel: As far as a lot of big players in space, I don't know, Google it, check it out. Material was king for so long and we have Polaris, right? That's Shopify's. Kaelan: I've always personally hated Material UI whenever I use it. I have to override at least a thousand things. Noel: I like Material for little side products where I don't want to have to think about things. I feel like the defaults are fine a lot of the time. It looks snappy, good enough for a proof of concept. I can grab a component library and it works, but I get the knee jerk that a lot of people have had a long time. I'm glad there's other systems that are getting up to parity with Material in terms of implementation ease. Kaelan: Another thing I would like to call out, here at LogRocket, we use style system and theme UI and stuff, which are a good foundation for building your own design system. I think in the last five years, that's matured a lot too. We've fully went towards component-based design, not just on the developer side but now also on the designer side. Emily: Great. I think I want to move on to probably one or two listener questions. One of the ones I wanted to talk about was ChatGPT, which everyone as time of recording has been obsessing over this week, but it ties into AI tools in general. We had one listener say, "I predict next year we're going to be using more AI tools in development and everything." But this one listener that had a question said that they feel like this is a black swan event and that we just created fire. We've seen a lot of AI tools over the past year or so that is mind blowing, but they fizzle away. But their question is, what do you guys think the impact of AI will be on the industry? How will it affect our jobs and what new ways of doing things do you think we should be preparing for and if you have any thoughts on AI tools in general? Kaelan: Anyone saying that this is going to replace our job, stop reading the news. I think everyone's been complaining recently about how awful Google has gotten. This is going to replace search engines. This is going to replace a million little tools, but it's not going to replace your job. Have you seen the code output? It even gets arithmetic wrong sometimes. Sure, that might improve in the future, but I don't know. Writing code was never your job really. It's thinking about the architecture, thinking about the right way to do things. That's your job. Noel: Yeah. The interaction with the world still is where devs come into it. So, I think I agree, but I think there it will impact us day-to-day at the end of the day. Not in a way that's special to developers. I don't think change developers day-to-day lives in the same way that it changes any office workers' typical day-to-day workload just in our tooling is going to get better. Chat, email, all that stuff will be easier or search engines, like Kaelan said. It'll just be easier to answer questions quick. I think it'll be easier to ideate quickly. As an example, yesterday, we were kicking around the idea of performance reviews and stuff. You put in the bullet points for your coworker, manager, boss, whatever. It makes a nice sounding performance review thing out of it. Sure. I think we'll see a lot of those tools come to fruition quickly and beyond that the long term impact of AI on society is out of the scope of what I can talk about here. So, I don't know. Kaelan: I played around with GitHub Copilot and I wasn't super impressed. It could generate small snippets of code, but as soon as I gave it any bigger task, it just fell apart. Emily: Yeah, it's more just hopefully making productivity better for devs Noel: I think so. Kaelan: Maybe, small scale. Emily: Oh, another question was actually from a data scientist and backend engineer, and this played into another prediction of devs becoming more full stack rather than front end and backend. But this person specifically, which Kaelan does not like, but this person specifically said that something they still don't feel fully comfortable with is front-end testing. So, what are some of the mental frameworks you'd recommend using for testing? Are there any best practices? How can a backend engineer be better at front-end testing? Kaelan: My evolution on testing, I hate writing Cypress tests. My least favorite thing to do is writing Cypress tests. So, I tend to favor unit testing and regression testing, visual regression testing, storybook, stuff like that for the front end. Noel: Yeah, nothing to add. I feel like tests more specific beyond that just becomes so fragile that they're almost useless. It's just like if you got to tweak it every time, you're not really testing anything. Emily: Great. Short and sweet, but I do want to go back to the visceral reaction Kaelan just had on video about everyone becoming full stack. Is this something that's going to happen? Kaelan: I don't know where they got that. I mean, the field of engineering in general has been a continuous evolution into smaller and smaller specialties. We're not called computer engineers anymore. We're software engineers. We make software. Then that split and then that split. I mean, 15 years ago, they were calling us webmasters. Then we have ops people and then we have database people and then we have full stack people and then now we have front end engineers and backend engineers. Isn't that a more natural evolution? I don't know. Then there's a whole meme about people calling themselves full stack. They know almost no front end. It always amuses me as a front end engineer. Noel: Yeah, I think so as well. I think it's one of those things, it's good when you can slot into a more specialized role, especially if you're new into the industry. I think that's so hard if there's increased number of job postings for full stack or something and you're trying to get in for the first time. So, it's nice when one can specialize. So, that's a positive, but yeah, I'm with Kaelan. I haven't really seen a trend either way. I haven't been paying super close attention though, so I don't know. Kaelan: I have to wonder how much of that is coming from people who are trying to hire engineers and they would prefer to just put one type of job posting instead of two. Emily: Totally valid. Before we get into your predictions, one other prediction was someone said that they see things continuing to move server side only, especially with Next.js becoming more popular. What are your thoughts on that? Kaelan: Single page apps were a mistake. Emily: That's on point. Noel: I think that's probably going to be my main prediction of this year. Yeah, it feels like, I alluded to before, performance, the time to first load, what's delivered. I feel like we're in this renaissance of that right now. The frameworks care about it. The infrastructure cares about it. The search engines care about it and users obviously care about it whether they consciously realize it or not. I mean, yeah, I think it's happening. Kaelan: Even as a front end developer, I'm fully on board. I guess this makes this whole specialization argument just made it more difficult, because now the lines- Noel: What is the front end, Kaelan? Kaelan: Yeah, I guess the terms are blurring, but there is still a specialization happening there. as a front end engineer, I make front ends. It doesn't matter where they're on, I guess, is what I say. Personally, I like these trends because less loading states and stuff. I hate spinners everywhere. Emily: So let's get into your predictions. I'm very excited to hear. Who wants to go first? Noel: I think that I was just explaining it. I think we'll see more of this performance at runtime. It seems to be a thing that people care about. I think we've hit maturity maybe on a lot of these edge computing tools like Cloudflare's key value stored and stuff like that in a way that I think we might start seeing more of that stuff hit production workloads this year. I'm hoping, but it's all part of that larger narrative of just fast page loads. You load a webpage for the first time on mobile when you have slow connection. It's not like I can't get checked into my hotel or whatever because I only have one bar. Things just work with a fraction of the data that they needed before. At least I hope we keep going that down that route, because I feel we have been. So, that's the big one that I'm excited for. Yeah, again, I think Turbopack, the build tooling, continuing to go forward, get faster are my big ones. Kaelan: Yeah, agreed. I would also add to that just a continuous focus on standards. We see that in the Node community getting rid of their awful module system. I think that more developers will be waking up to that fact. I think that hey, we don't have to transpire this anymore. I think a large part of that was the [inaudible 01:02:59] and a large part of the corporate world finally begrudgingly entering this decade. After that, there is no reason to do a lot of things anymore. No really good reason to do a lot of things like CSS related, like I said earlier, CSS and JS. If there is, then maybe ultimately those should be just compiling down to these modern day technologies instead of the CSS that your grandmother made essentially. That's about it, I think, for me. Emily: All right. Those were some great predictions. I'm very excited to see what 2023 looks like for this space. Thank you again, Noel and Kaelan, for joining us or joining me, I guess. Noel: No, of course, of course. Yeah, it's always fun chatting. Kaelan: See you next year. Emily: I know. So, thank you everyone for listening today. If you like the podcast, please follow us on Apple Podcast. That really helps us see what content you really like. Help us make more content like this and follow us on Twitter @PodRocketPod. We'd love to hear from you. Tell us what you want to hear, give us comments, whatever you want. But Happy New Year everyone, and we will see you. This is our last episode of the year, I believe. So, we will see you in 2023. Thanks for listening.