Our Predictions for 2023

Welcome to Syndax, the podcast with the tastiest web development treats out there. Today, we have our rid. Predictions for 2023, we are going to say look into the crystal ball and and predict what will happen in web development in the next rid Year.

My name is Wes Bos. I'm from Canada. With me as always mister Scott Talinski. Happy New Year, Scott. Happy

New Year. Yeah. Rid. We gotta do some, like I don't know. We wanna call these resolution type of deals, but we rid Do something in the new year here to really talk about what we'd like to accomplish as professionals and as developers over the course. Things that we would like to learn and spend more time on. Obviously, this is in the episode because we're we're talking about predictions, you know, stuff that we think is gonna happen. But, you You know, I wouldn't mind spending some time talking about the things that I would like to get into more over the course of the year as a technology focused person.

Yeah. I'm rid. I'm feeling sick.

So I'm not exactly

feeling like kinda sick. No. Like, you're feeling sick.

Ready. Like rah rah rah today as much as I would love to. But, yeah, I'll do my best to remain excited about all of these predictions.

Ready. Alright. Let's get on into it. These are our predictions for 2023.

The first one we have here is server side rid. JavaScript sites become more than norm. This was one of our predictions last year, and I feel like we are just starting to see the the tide turn rid. In terms of, both, like, component like React and Svelte and Vue and all these things being just rendered on the server, rid in by by default, but also things like people are going back to just regular templating and adding in Alpine JS or any of these Sprinkle

frameworks on top. And this is actually, there was another one, h t m x, that came on to our radar as well.

Rid. That is feels like just, like, straight up HTML where you you sprinkle in little things, and it just Does the type of stuff progressively enhanced to make your website just work a little bit? I don't know. Little bit more JavaScript y on top of just a rid Straight up HTML site. But, you know, with SvelteKit and Remix and all of these frameworks really leaning hard read. Into the HTML of things.

We are I think we're going to can see that continue to see that trend even a little bit more where we're dealing with less of JavaScript straight up and down and more getting to utilize the browser core browser features, core HTML features rid While not losing any of the things that we've come to to love from JavaScript frameworks, like, you know, the the Page transitions are just loading up straight data instead of having to load up a new page doing that that the rid. Client side loading of routes rather than doing a a full on pull, full page refresh, losing your state, losing your data, keeping that rid. That cached data from the JavaScript client side of things while getting to mix in straight up server rendered HTML from rid. JavaScript templates. Yeah. This is a trend I think they'll just continue to to grow. I I wouldn't I wouldn't be surprised if React rid Doesn't get in a little bit more into this game too, but who knows with React? I I'm gonna I'm gonna say that. I'm gonna say my prediction is that React

We'll get into the form space.

Like, doing forms in React is such a pain in the butt. Okay. Maybe it's a wish a wish that they would do that.

But if you look at the stuff that HD max has, they have an entire crud Example without a line of JavaScript. It's just declarative. You just describe your HTML.

You use almost all Regular HTML inputs with a couple, attributes, and it will just update it on the server side for you, which is really cool. And we're seeing it with Remix rid as well using just a lot of form attributes. And, like, if you follow the spec closely enough, it will just work without Any JavaScript if JavaScript is disabled, which is unreal.

Not to say that that should happen, but, it's amazing that it does work.

So Some pretty cool stuff coming down the line. So I think that both the SSR as well as sticking to web primitives Is going to be or web APIs is going to become much more popular.

Yeah. I I totally totally totally agree with that. And I I think The reason why React has such a hard time with that is React's pure avoidance of the DOM.

Like, rack React does so much rid. To avoid the DOM, obviously, they have the the virtual DOM to to do that with. And not to say that you need the DOM here, but when when you abandon the DOM entirely, You are abandoning a lot of what makes HTML function as it does and how the browser functions as it does. Rid. And you step in there, and you kinda have to end up doing things the the React way instead of the browser way. So this is, I think, is a is a, I think long term, that's a problem for React if other frameworks like, Svelte, so to say, are are getting to utilize or even remix. Right? They're getting to utilize the DOM in a way that you haven't, or not necessarily the DOM for Remix, but you're getting to use these browser primitives and browser APIs in a way that we've just of avoiding for so long. So next one here is TypeScript inferred becomes hot.

And you know what? I think it's Already starting to become hot, but I don't know if that's necessarily reached the the mainstream yet. So to say, I use Type inferred with our Zod schema, where basically you define your schema and then you say, hey, TypeScript, infer the types from this thing. And guess what? It just spits out the types, meaning that we don't have to double define things where that happens so many times. And if you're using GraphQL, you're often having to triple define things, especially in your types. So inferred is going to become one of those things that people start to wake up to as being like, oh, wait. Rid. We can actually get our types pseudo I don't wanna say generated, but pseudo generated for us using this inferred functionality from TypeScript And just have it just work with little effort, and then our whole code base becomes smarter.

Yeah. Exactly. I think that we are at a point now where the lot lot.

Rid So many library authors put so much sweat and work into the extremely hard parts of TypeScript, which is, very, Very obtuse generics and all these edge cases and whatnot. And then using those libraries is a freaking dream because I I wrote, like, rid. Forty lines of TypeScript the other day, and I didn't write a single line of TypeScript. I didn't type anything because it was A 100% inferred. And I was like, well, ain't that nice? You know? Like, this thing is a 100% type safe, and I didn't have to actually write anything.

Rid I was already kicking over that. Well, ain't that nice. That was great. It ain't that nice. Yeah. Yeah. It was very good.

So I think, like, between that, between types rid being generated for you based on some sort of schema or database or something like that, as well as, rid. The likes. I think it was Brad Frost posted like, should I write my style? What was it? Rid Not a style guide. What is it called where you have a design design system? Should I write my design system in TypeScript? And I was like, absolutely. Yes. Because, rid Like, it might be a little bit a little work for you who's writing the design system, but everybody else who uses that thing just gets to rid. Almost entirely gets the benefit from it without and the the argument of, oh, not everybody knows TypeScript.

Not everyone needs to know TypeScript. It's A lot of the stuff is just inferred directly from

using your the library. Yeah. Great. I'll take it.

Anything that makes my my experience better in that regard, I will take it.

Next up is Deno gets hotter. And I have a little subnote here that Scott rewrites his platform on Deno, which obviously is just a tongue in cheek. It's a joke. But, rid. Deno itself as we have seen, we interviewed Ryan on this show earlier this year. Deno has continued to evolve, but it also has become more usable, I think, for normal people to do normal work inside of Deno.

So it's becoming less of a hobbyist tinkerer type of situation In more of a situation where now, hey. We have access to the entire Node NPM ecosystem.

We have, Just a lot of really great tools. The Deno hosting stuff is really excellent.

I I just think Deno gonna continue to get More and more usable throughout the year, and I I think you'll start to see more and more people using it for little tasks picking it up. Oh, I need I just quickly need rid. To have TypeScript preworking for me out of the box without any setup, and I just need to hack away on some stuff, I can Get it up and running hosted somewhere. I'm going to pick Deno because it's easiest to do that with. You know? What are the steps you have to take to have a a A node project up and running with TypeScript out of the box.

It's just when you compare the 2, It's a very different experience with Deno, and I think people will start to gravitate towards that. Yeah. There was a

a thread Between some of the Deno folks and some of the folks who work on Node.

And, rid. Basically, the reason why Node hasn't decided on that is because apparently, Deno makes some decisions in terms of what the TypeScript rid Config and versions and stuff like that. And Mhmm. TypeScript says you shouldn't do that. So Node is kind of just being like, well, the user should decide that. But, like, rid. Every other user is like, no. No. No. Like, just just make it work for us. Like, I I I'll give up a little bit of flexibility. Right. Yes. Rid Right. In term and I don't even know what I'm really giving up by using Dino.

But I was like, I want that in rid Node as well. Like, right now, I've switched to using I've I've talked about many of these libraries over the times, and I've settled on using TSX, rid Which is not anything to do with React.

It's just a t s x index dot j s, and that will run your node read. TypeScript code as it'll compile it and rerun it and all that good stuff. And it's a pretty smooth experience.

But we want that in rid We want that in Node just directly. And they said that they are going to be building in some sort of loader or some way to basically just rid. Strip types and run typescript in node.

And I said, oh, cool. Like, what's the is there a link for that? And I looked for it, and they didn't reply, and I couldn't find anything. But rid My then my prediction, by the end of this year,

Node will be able to run TypeScript without a plug in. Hey. I think that's a great prediction. And, honestly, it won for them. I'm hopeful for if you've ever looked at the GitHub, like, community, rid Node community or node meetings of these things where node folks are kind of arguing about these use cases.

Rid. Man, it can be a little bit frustrating to read those sometimes because I think some people are just totally discounting how much people actually want to use this and how how many people are, You know, turned off by the fact that there is no easy way to do so many of these things. So, yeah, I think that's a prediction that I would love to see if we're rating these on, like, things that I would really like to see, that's certainly something I would I would really like to see, Especially because there's so many times where I just wanna get up and running with a quick little project, and I can't, you know, without having to jump through 800 hoops Getting into compilers.

Should I use t s node? Should I use this or that? Should I just have a es build compile it or whatever? It just makes everything a giant pain in the butt. And granted, you know, TypeScript is a a third party here. I guess, you know, something else that could rid. Happen and evolve in the space is the not to say that the types in JavaScript will ship rid in 2023.

But you'd have to imagine that we're going to really, at the end of the year, have a much better idea of what types in JavaScript actually look like whether or not that's that proposal advancing or if it's improving or if it's being solidified, whatever.

I do think types in JavaScript will become something that we can actually have a bit of, so concrete understanding of, I suppose.

Next one, JavaScript run times are going to mature.

Rid. So we this year, like, we we looked at our last one here. There's not a word of bun last year. And this year, it's rid. There's nothing but bun it buns in your face, you know? You just it's all over the place. So I think what are we gonna see in terms of JavaScript run times? Rid. We are going to see, well, Dino is is that a spot an hour? I think you could maybe probably use it in production. I probably would wait maybe another 6 months because I I did hit a bug with the npm integration with you running an express server.

They fixed it, rid. But, like, there's I'm sure there's more of those that that are somewhere in there.

I do think we will see no TypeScript by the end of the year. I just said that.

Bun rid Says by the end of the year, they are hoping that BUN will be the recommended target for a lot of libraries. So, like, imagine, rid what? Yeah.

Imagine, Next JS or Remix or SvelteKit saying, we recommend that you run this in bun because it's the fastest, rid You know, we recommend that you run this in Node because, ideally, we're going to have Node, BUN, Dino, maybe something else. Who knows what will come down the road? And we will be, oh, like, I can run these in literally any framework.

So what will we see there? So I bet.

I don't know if we're gonna we're gonna see Bun shipping a remix project, but, I definitely think That we will see by the end of the year, people deciding where they want to deploy their application to. Yeah.

And I would love that world where it feels okay to do that. That seems like a a lofty target, but, rid. I I'm about lofty targets. So let's let's see. You know what? The the ideal situation would rid be that I can change one line in my code base to say SvelteKit adapter bun. I hit save, and then my site just performs faster without me having to do anything. Rid Yeah. That's the only way. If you're out there and you're saying Scott's definitely gonna do this, that's the only way I'm going to do this. That's the the only way.

Okay. Next, you have, we will see a new TS bundler written in Rust, and you link to STC here. No. I have not been keeping up with STC, but I also don't deny this this prediction.

I didn't realize this.

Do you know what STC stands for? No. Speedy TypeScript type checker.

I like that. Shouldn't that be ST Speedy TypeScript?

Yeah. But they have Speedy TypeScript type checker. It's because it's it's written by the same guy who made SWC, which is rid. Speedy. What does SWCC stand for? SWCC also speedy.

Speedy speedy web compiler.

Rid. Speed. An STC is speedy TypeScript checker. Okay. So the big the big thing if you're not you know, if this seems weird to you that there'd be a something a TypeScript read. Checker written in Rust. The big thing is that right now, any type of tool that you have that gets your TypeScript to JavaScript that is, Quote, unquote, super fast or written in Rust or written in Go or whatever, e s builds any of these things.

These tools are not doing the type checking. And if you want to do type checking, you're still using TSC, which is the TypeScript type checker. So there is only 1 type checker that is like I I don't wanna say that it's in existence, but there's only 1 type checker that people are using, and it's TSC.

So this prediction, a new t s, re new TS bundler written in Rust, but this this maybe is a checker. Yeah. Type checker is is probably the the thing to say here because this is This is a project and it exists. And why? Maybe because it's faster is that the TSC isn't Inherently that slow, and I'm not enough of a, a genius to know if if just simply rewriting it in Rust will make it that much faster.

But it's interesting, and I think it's one of those spaces that if you could have it instantaneous or any of those things or have it as fast as possible, rid. It's it would be a nice little win there, and I'll take a faster TSC. I'll take it. I yeah. I don't think I have a big enough TypeScript code base to realize

When it gets slow, but imagine, like, imagine Versus code, how big of a TypeScript code base that is. You know? Or imagine, rid. Stripe. Stripe is a TypeScript codebase, you know, like they probably, like, I don't know how long it takes, but having real time information about rid Problems in your code base, it would be extremely helpful. You change something and, like, what if it takes a second or 2 to actually give you output? That's That's a big lag.

So the it's been being worked on. I don't know if this prediction is something that's already happening, rid. But it's we we talked to, I think, both Jared from Bun and Ryan from Dino about this is that, like, it's It's a very hard thing to do it. So my prediction is that this STC is gonna come out, and it's going to have a, like, a subset of it. And I believe Alongside this, we're gonna start to see ESLint rules or something that says, these are features that this rid Type checker doesn't cover, like, enums. Enums is a popular one.

A lot of people don't like enums. They never use them.

TypeScript rid Themselves has said if we were to do TypeScript again, we would not include enums. Because enums are a weird one that it's like it is the only part of TypeScript that ready. It compiles to JavaScript. Everything else is stripped out.

So I don't know if there's there's maybe parts of TypeScript that are really hard to implement. And if you can, like, maybe write a ESLint rule that just says, like, don't do that, and then we can use it hurts it hurts when I do this. Rid. Well, don't do that.

Don't do that. What are you doing? Don't do that.

What are you thinking? Hey. You know, it's funny rid because I do use enums, and and there are times where I'm like, yeah. I probably shouldn't just because of these things. But, yeah, I I do I am interested in that rid as well. And that said, like, what about like, you have it here as the next one. This could be related new JavaScript APIs.

Like, what about just, like, getting straight up enums in JavaScript? Because I like enums, and I I would like to feel okay about using them. Yeah.

So I you know what? I I they're one of those ones those those APIs that are potentially coming to TypeScript that have just been kind of sitting around. You know, things take some time, and I understand that. So yeah. Well, what what are the type what are the JavaScript APIs that you actually think will rid Maybe either move forward in 2023 or ship. Let's go ahead and and pull up some of these JS proposals.

Like, here, decorators, Wes. Rid Do you think they're going to ship in 2023?

Oh, I don't know, man. So the weird thing about that is TypeScript, rid I think TypeScript is going to there's been decorators in TypeScript for a long time. They've always been experimental, but they're not The decorators that are proposed in JavaScript and, like, there's a difference there, and I it it just seems like a bit of a mess.

So who knows? Ready. They're in level or level 3. They're in stage 3. So we're seeing, this is stage 3. I bet guarantee, we will see these next year. 2 reversed and 2 sorted. Those are just the same as reverse and sort, but they don't modify the original array. They're non mutating.

And then we have dot to spliced, which is really nice. It's rid How to remove an item from an array and return the new subset of that array without modifying the original one, that's super handy. And width, This one is amazing is if you want to replace an item in an array, right now, what you have to do is You make a copy of that array, and then you update the item that you want or you splice everything before it, put your new item in, and splice everything after it. That's annoying as well. So rid. This new dot with method is going to just allow you to say, like, replace the 3rd item with this item. That's why it's dot with. So four a brand new array methods coming coming at you hot. Okay.

I think I think temporal will make its way rid Yeah. Into the browser in the 2023. I don't know if it's going to happen, but, you know, that's my optimistic pick of the week. Re I think record in 2 pool will get into stage 3. I think the pipeline operator will finally get its, rid. Issues figured out, and I think it will move into stage 3. They've been, like, back and forth on the style in which the pipeline operator, rid. Should exist, but I I think at some point, they're gonna have to move forward with 1. They can't just kinda go back and forth forever. So,

what else we have? This one is nuts. So

atomic's dot wait a sync. Yeah. What the heck is that? Yeah. There's, You know what? If if you are out there and you're, like, very curious about potential things that come to JavaScript, we talk about this from time to time on the show. But if, you know, you don't catch every episode, you might not miss it. There there is the, the working groups JavaScript proposals repo that show Exactly where they are, and you can click into any of them and read the GitHub issues and see where all these proposals are. And there's some, like, always some interesting ones that pop up. Like, we just saw 1 atomics dot wait async, and both of us were looking at that, like, rid The heck does that even mean? Yeah. Oh, this Atomics, that way to sync is kinda cool. You basically wait for something. Rid. And I wonder if it has something to do with,

like, that next tech event loop where it puts out the end of the event loop when you await something with a promise. Yeah. Rid Curious.

We'll we'll do a show on a bunch of these proposals because I think there is some explaining that needs to happen, some research on our end. But rid. There's some exciting stuff coming down the pipe. Yeah. I just, like, breezed over the fact that I thought temporal would make it. But temporal is that, like, basically, a new way to do dates in JavaScript. Ripped. We have a whole episode on it. You can go listen to that. It's really neat. I really like it. It feels very nice to use. There's polyfills out there. You can give it a try today. Rid. But it's in stage 3, and it's one of those APIs, I think, that will will change a lot of how people write JavaScript in really positive ways. You know, you know, I also of the pipeline operators will change it quite a bit as well in terms of how people write code, but, you know, that one is still stage 2. Still waiting on that one.

There's some interesting stuff in here that that could show up. I I would love to see I I would love a crystal ball to see what moves forward and what doesn't. But, rid. Yeah. Let's, next one here is riding towards the winter CG spec.

So the winter CG Is a basically, a working group to determine essentially a spec for rid JavaScript to follow on, to work within specific environments, workers specifically. Right? And this is a working group that has a lot of really interesting companies in it.

And, basically, what you have here is rid. Basically, the the winter CG spec will be more of a popular target because this thing will become more relevant. Is that your understanding?

Yeah. Yeah. So, like, well, part of our predictions here is that BUN do you know become much more popular? And there's also Cloudflare Workers, which is their own rid bit of it. And, there's a couple other JavaScript environments.

And just like we have with the browser. Now we're going to have multiple back end or server jobs environments, and rid. They are all getting together to work around this thing called the Winter Community Group, which is they are making sure that the web rid Back is implemented in all of them so that when you're writing a serverless function that works on Vercel, it also works on rid. Netlify, and it also works on Deno running on begin.com.

You know, like, ideally, you should be able to just have a standard request and response.

And you could bring that everywhere with you, as well as all of the other stuff that is involved in the web spec. So rid.

That's cool because a lot of the stuff used to be sort of, like, node specific.

And if you can right. Your thing to not be node specific, but to be kind of like web platform. Not all the APIs are there yet. So, like, stuff like writing a file is rid. You have to pick a target. Maybe we'll see adapters then. But, you I I've been I'm even thinking about this right now is anytime I write any new JavaScript, Should I try to start thinking about keeping this that so it will run-in an edge function? Because rid. That's really the environment right now is if you want your code to run on the edge as close to your user as possible, you have to run-in an environment that is not Node. Js. Rid. It's a different pared down JavaScript environment. You don't have full blown Node. Js APIs there. So can you do whatever the equivalent is in the, rid.

The winter CG spec or the the web spec. Yeah. And in that same regard, you know, I think we'll hear the words edge rendering in general or just edge a lot more.

We I think we've heard it quite a bit as this year's gone on, but, like, who's actually using it? Right? Re I think the big players are using it, but

are the the little players using it? I don't know. Yeah. I that's the thing is it has to become rid. Easy. You have to be able to NPM install a library, and it just works in in that setting. We see this with everything performance related is the the heavy hitters do use it, rid because they can employ 1 person to make sure that it works. But, the person that's making 1 website for their client or a scrappy start up,

they want those performance benefits as well. And when the tooling and the libraries catch up to that, then we all get the benefits. Yeah. Totally. Rid. I have a funny note in here. It says a new JS framework, and I have this in here because it's like, you know, if you wanna if we're talking to, like, making bets, Like, we're putting money down on this.

Just feels like that's a easy easy easy win there. Easy bingo chip. There's a new JS framework. It's either gonna be one that already exists It's going to become more popular or one that does not exist yet.

Nobody knows about this thing, and it's certainly going to do things ever so slightly, just a little bit differently. And that's going to be some sort of paradigm shift according to the author of said framework. Yeah.

I think that, Of course, we'll see new ones, but I think we are starting to and we will see the uprise of the alternative framework.

Rid I'm I'm hearing I'm hearing so much about Solid JS. Quick, we got the author of Quick coming on. Yes. Rid There is Which is very exciting. Yeah.

I have earlier, people are starting to sour on React. Rid. And I think as a result of that, we are starting to see other people realize, oh, these other frameworks maybe do have it better or have Have solved a lot of my pain points here.

And there it's a better way to to approach that type of thing. So pretty excited about the rise of new rid Frameworks and I'm hoping web components, alongside

those things. Yeah. Right? Web components along with any of these frameworks be really super neat and yeah. Rid. I I don't know. I I'm really excited about a lot of them. And, you know, what I'm really excited about is that the the ones that take a a different approach to things like quick, You know, with its resume ability Mhmm. I think that those are the types of of frameworks that I appreciate the most because That's taking a totally different approach where everybody else is doing hydration right now. And not to say Quik's the only one doing resumability, The quick's probably the most popular one doing resume ability right now. So, you know, the the people who are are taking a different approach that other people can learn and grow from, You know, we saw this. Remix pushed out some of their features, and then SvelteKit was able to adapt some of those. And, you know, SvelteKit and re React Router and Remix had nested layouts, and Next. Js was able to take advantage of some of those. I think anybody who comes up with something big, rid You know, I I don't know how easy it or I I you know, this is a total dumb guy way of looking at it, but, you know, the lessons learned from resume ability could theoretically Improve everybody else's use case. Not to say that all other frameworks could become resumable or something. But, you know, I I think there's lessons to be learned in different approaches, and seeing people take such different approaches is is such great great things for us.

Rid. Next up is the page transitions API, which is one of those ones that I simply cannot wait for.

I'm I'm sitting at the edge of my seat waiting for the page Transitions API, which, you know, who knows when this thing will actually ship. But knowing Chromium and how they work and how rid. Bullish they are on it. I don't even know if bullish is the right word. I'm just using that. How, interested the Chrome team is In page 2 transitions, they're calling it the view transitions API.

I would have to think this thing rid. We'll get pushed further and further. It's currently behind a flag in Chrome, and that's, like, the only place that exists.

But If we want websites to start feeling more like native apps, which is always one of the big conversations that people have, you know, rid. PWAs, at the end of the day, will never feel like a native app. We have to start taking some of these things out of The developer's hands who are making the websites and having to do all of their animations and page transitions by hand because they simply will not be as good As if the browser is just taking it over for you.

So I I think the view transitions API will become Somewhat usable. I'm not going to say that Safari and Firefox will ship this thing, but I think we'll be able to do, re quite a bit with it in Chrome to really understand where it is and where it's going. And I predict that I personally We'll use it for something in the new year whether or not that is working in all browsers or not. I'm very excited about this one. Yeah.

I'm I'm very curious if rid. So this is a CSS spec, which is you tell, how things will transition in and out as they re change from page to page. But those elements exist basically because we have JavaScript push date where you can change the URL ready. And then you can update things on the page.

Now CSS is kind of coming in and say, okay. Well, when you do that, maybe we can rid Transition items on the page up and down or flip them or slide them or do whatever we want. And I'm curious if can you is this a polyfillable thing? Rid. You know, like, can can is there gonna be, like, a intermediate step where you can get, like, an adapter for SvelteKit or Next. Js? I know. That that would be sick until we can, like

Yeah. That would be sick because you know what? Anybody who's worked in native dev at all knows just how simple it is to pop something up and have it do rid. Whatever it is, the device's native transition for that. So to be able to get some transitions that we just don't have to write ourselves. Like, I like writing animations, and it's still, like, not the easiest thing to do to do page transitions a you know, all across the board. You really kinda have to get into the the nitty gritty about it. But yeah.

Next one we have here, I just put Scott was right rid. Or Scott is gonna be right. So this is the, I hear it. Annual part of the show. No. We we should we need to have that show, but rid I think Scott was right about this. Maybe about 8 months ago, Scott, pleaded the case for using tabs instead of spaces because rid. Tabs are 1 character. They are adjustable in your editor, which is therefore more accessible, to whoever's watching it. It's not actually four rid Our 2 spaces is 1 tab character and how that tab character is rendered to you. The user is up to you, rid. Which is a very good argument for using tabs. And I didn't come up with that, by the way. Rich Harris has largely said that I I've ripped that off from Rich. Oh, awesome. Well, Rich Harris was I think Rich Harris is right. I think this is the year we're going to start to see more people switched over to tabs, rid Which is funny that we we dig up this dead horse again, but I believe that we'll see at least 3 or 4 people be like, you know what? We switched the tabs and Life is good. Yeah. You know what? To me, that's not controversial at all. I think that's normal.

I think. GitHub's default ready. For tabs is 8 spaces, which is really now? You can change it. You go into your GitHub settings and say tab. I changed it to 2, rid. But, like, 8. Come on, GitHub. That's way too big. Yeah. 8 is too big.

Alright. Next one here is Rust becomes more popular, which you know what? I think this one is as good as Gold here in terms. I I think this is locked in. I Rust is going to continue to have its Surge of popularity.

Now granted, I don't think most JavaScript developers will be writing Rust by the end of the year or something, but I think more rid. We'll be writing Rust then wrote in 2022.

Yeah. I think as people find a spot in their application that is ready. Slow, for for whatever reason. Like, one one kind of cool thing I went down the other day was, like, how do you take, ready. How do you take frame stills out of a video? And there's there's a couple of ways. You can just pause the video and take a frame still. There is a new proposal ready. For, audio and video chunking, which will allow you to do it right inside the browser, which is really exciting. Rid Like, you can you can literally process video in the browser, much like a video editing software we do. And you can edit video and you can rid export it right in the browser, but or you can use, like, a WASM library, which does it over a WASM bridge.

Rid. And I bet people will will hit issues like that where, like, oh, this is kind of slow.

Let's move it to Rust. Rid. And, as more people learn it, it will become a little bit more, accessible, especially as, like, I don't know if I'm gonna write a library to parse video on Rust, but But somebody smarter than me will, and I'll know how to use that. You know? Yeah. Yeah. Yeah. Yeah. And maybe you'll use it in the browser with Wasm. Who knows? Yeah. Exactly. That well, that's what I mean is that, like, you just rid. All this WASM function, and it it does it in Rust really quickly.

And then you, the JavaScript user, just gets an array of data that you have to deal with. Yeah. Rid. Totally.

The next prediction here is that the React beta docs launch after a 5 year dev cycle. And, honestly, rid. I feel like the dev cycle for that might have been more than 5 years. I was being a little generous with that 5 year dev cycle on the docs. Man, the React beta docs have been in development, I think, longer than I've had children.

Like and it's like it is rid. Wild how long those docs have taken to the point where, like, I get it. You want docs to be and and they granted, the beta docs are good. They're way better than the normal docs. So that's not like the problem. But at some point, folks, you just gotta say, Alright. They're good enough for now. Let's get these things out the door. Because what you have when you have the beta docs existing for so long as the beta docs is that there becomes like an inherent lack of rest in the fact that these things are accurate or real or whatever. Yeah. And they're the beta docs. Why why can't they keep you can't get these out by now? I you know? No. I'm not I I get there's real people working on these things that have very real problems Yeah. That are not docs, but, like, re It's React. It's the biggest project out there, and the documentation has been in beta for Ever since before suspense was announced, since before any of the stuff was announced that we've already been saying Hux. Yeah. Rid. Been way overboard and way, like, delayed.

So, like, how how are those stocks not out yet? It's

it's wild for me. Well, As as somebody who makes a living off of training material, I, further promote crappy dogs Yeah. Right? For these libraries.

Yeah.

Rid Yeah. Just joking. But yeah. That's well, oh, yeah. We'll see it. React docs will launch this year. Totally.

Next one here. We will start to see CSS container re in production.

I think we are almost at a spot now where CSS container queries are. Let's just take a look at them.

In all of the browsers. Firefox shipped it, in 109, which is not even rid. What's the main Firefox right now? How do you how do you tell?

Yeah. I don't know because that's why I was just saying, you know, 109. I every Every time I've been opening Firefox lately, I've just been annoyed with it. Like, please get out of here because I I'm, you know, firmly into the arc world. So let me

rid See what my Oh, 108. One08 is the current release one. So the next major release I run Firefox dev, so I have it already.

But the next major version, we will see container queries in Firefox.

Dude.

What? What? No. I'm just like, what a moment. Oh, yeah. I I thought you're like, but it's not in Safari. I was like, no. It is. No. It it's been in Safari. Takes forever.

I'm just saying what a moment. You know? Yeah.

As far as this podcast is goes, but, like, my career, I've been just saying. Yeah. And I would love CSS container queries from ever and ever and ever and ever. And the fact that we're on the precipice of this kind of change to me is,

Oh, it's making me feel great. It's gonna be good. It's gonna be good. So it's gonna be a good year for container queries in production, and and CSS has, rid. Which is the ability to select something based on its or no. Based select something based on what is inside of it, re but not select. I I had, like, a little TikTok tip about CSS has, and, like, half the comments were, how is this different than parent child selector? And I was like, oh, well, rid. I I guess I missed this topic. It's not a child selector. It's the parent selector. Based on what child it's like, give me rid. All dads who have a daughter, don't give me their daughters. Give me the dads, but only if they have a daughter.

And maybe I should have used that rid. In there, but people were not like but for me, I'm like, I freaking I've wanted this forever, you know? And a lot of other people, when they hear about it, they're like, oh, yeah. Maybe. I don't I don't think I use that.

Rid Does it is it the 1st CSS property that's changed the direction that CSS selectors go? Because every other CSS selectors always starting at The parent going down to the child, and then you're ending on the child. And has feels like it's the first one that goes backwards, but I don't know if it is the first one. But I think the first one that that it's like the biggest one. You know, there's always been if you if you've worked in CSS for more than, you You know, 6 years or so just to, you know, random number there. But if you've worked for CSS for many amount of time, there's been a time where you've said, Man, I'd really love to style the parent based on the contents of its children. There there are times when it comes up. And the fact that we we can now actually use this, what? It it happened out of nowhere. It happened so quickly and almost a little bit quietly for how much of a major feature it is. Yeah. And, honestly, I haven't used it yet.

Rid. I I I feel like a chump for not using it yet, but it is one that I'm extremely excited about. And I can't wait for, real examples and more examples to pop up And user land to take this one to to show exactly, like, all the cool stuff that can be done now.

SvelteKit glow up. I think Svelte and SvelteKit will rid. See major adoption, this year. Let's take a look at, NPM trends.

What's SvelteKit at right now? SvelteKit started at 28 rid Thousand. It is that a 132,000. So, like, not a ton.

And I I bet that number will be 5 x.

Rid Is that it's it's not it I I'm only saying 5 x because it's it's a 130,000 to go to rid 700,000.

You know? Like, that's not it's not like 1,000,000 to 2,000,000. Like, that's a lot.

So I bet I bet we'll see 5 x increase in SvelteKit also just Because one point o just launched. It's it's only it's been stable for, what, 3 days now, Scott? Like, it launched last Wednesday at the time of recording this episode. I mean, we're coming to you in the future here. But, yeah, it has just launched.

And you know what? We'll see. You know, I would love it For my my sake as a content creator who created a wonderful course on SvelteKit, if you're out there and you'd like to learn, check out level up that video. But, rid. Yeah. I would love to see it it grow that much for a sheer fact of you know, we had a a conversation on our course drop about SvelteKit,