Emily:
All right. Welcome back to PodRocket. I'm Emily, producer for PodRocket. And today, we're back with The Launchpad, our monthly panel episode where we cover a wide range of topics trending in the world of web dev, as well as going into some of our guests' hot takes at the end, about what they're fired up or really passionate about in the world of web dev right now. But before we get into our Recent News section, I'm going to introduce our panel.
First, we have Tru Narla, also known as Mewtru on her Twitch account. Tru is a software engineer at Discord and has built a big following on Twitch, where she streams herself coding. Welcome back to the podcast, Tru.

Tru Narla:
Thanks so much for having me.

Emily:
Of course, of course. Next we have Paige Niedringhaus. She's a software engineer at Blues Wireless, author of Modernizing React Apps course, and the co-host of the React Round Up podcast.
Welcome back as well, Paige.

Paige:
Thanks. I'm glad to be back.

Emily:
Great. And then, to round out our panel of guests, we have Chris Bautista also rejoining us. He is known as Trash Dev on Twitch, where he live codes, and is a senior software engineer at Netflix. Welcome back, Chris.

Chris:
Hello, hello, hello.

Emily:
And you might hear me going back and forth of saying Chris and Trash, but he does like to be called Trash.

Chris:
Yes, please call me Trash.

Emily:
And then finally, we have our very own Noel Minchow, joining us to round out the panel. Welcome back, Noel, as always.

Noel:
Yo. Thanks, Emily.

Emily:
Awesome. Well, I'm very excited to have everyone here, to start off the new year. We're kind of going to go over a little bit of 2022 stuff and talk about what we're expecting for 2023. So, I want to start off with our first topic.
There was a State of Frontend 2022 report from The Software House, which is a Polish custom software development company. And they released this report, where they took about 3,700 survey responses from 125 countries, and it was commented on by 19 Frontend experts all from like Netflix, CloudFlare, AWS. So, I want to go through a few of the points the report makes and just talk about the trends and see how they might develop in 2023.
The first thing I wanted to discuss is styling tools. The survey found that SCSS is the leading styling tool of the year. Chris Coyier commented that while SaaS has sustained its popularity over the years and is widely loved, developers are not solely using SCSS and utilizing other styling tools like Tailwind and CSS modules.
Have you used SCSS this year? Why do you think it scored so high? Do you rather use Tailwind or CSS modules? What are your thoughts?

Paige:
Well, I can kick us off. I have used SCSS this year. We use it for a lot of the projects that my company builds, but we also use it in conjunction with CSS modules and also design system libraries, like Ant Design and Material Design.
So, I think one of the biggest reasons that I still gravitate towards it and I really like it is just because I know how to use it well. I really like the nesting ability that it gives me for writing class names. The variables are great, some of the just nicer functions that it offers. And a lot of these, I know they're being brought into the CSS language, so we don't need it nearly as much as we used to. But it's just something that I've learned to work with well and I enjoy writing CSS with it.
So, I think it will be hard for us to lose a lot of its popularity in the coming years because it is so ubiquitous and a lot of people are familiar and happy with how it works. So, yes, I keep using it.

Tru Narla:
Discord uses CSS modules for their styling. I don't think we use SCSS actually. But a lot of what SCSS has that CSS doesn't makes it so much more useful, as you mentioned. Just the nesting itself is just something that I really wish that we had. But yeah, I use, on side projects, mostly Tailwind. I just really prefer writing styles right in where I'm writing for UI code. It makes it easier for me. I haven't used SCSS this year or last year, but I get why it's popular.

Chris:
Yeah, I can take a stab at this. So I'm going to say SaaS, because SCSS is just way too long for me to say. So in Netflix, we do use SaaS. Going off these results here, I would say Tailwind's probably not the top because it's pretty new, right? SaaS has been around for a while. In my opinion, there's a lot more legacy mature apps that exist today, that existed long before these extra things, like style components, CSS modules, Tailwind.
So given that, I feel like there's a lot more legacy apps than there are greenfield. Well, I would like to say maybe more pet projects that people do toy these things, but in my opinion, this is kind of like a hot takeover. This is kind of a blanket statement in my mind. The industry is going to be majority legacy, therefore using either stuff like CSS or stuff like SaaS that has existed for a while.
And then also, you just got to think about the teams, right? These choices of these tools, you have to get buy-in from everyone on your team. You can't just say, "Oh, we should use Tailwind tomorrow." That just doesn't work that way, right? You have to be pragmatic about these decisions. And SaaS has been around for so long, has been proven to get the job done. I think that's why people start to lean on that.
That doesn't mean that in 2023 we'll see a shift. We won't see a shift to use these more popular tools, because granted everyone can tell Tailwind is just taking off, right? So, I think Tailwind will eventually be higher, but I don't think it will ever actually ever fully take SaaS, at least the near term. So, yeah.

Noel:
Yeah. I think I largely agree. Yeah, we have a smattering of tools we use across different projects and stuff, but SaaS is so entrenched. I think that's where these members are coming from. It's easy, the tooling is there, it's easy to find if people know how it works, like linting and stuff, super easy.

Emily:
Awesome. Great. Let's go on to traditional hosting. The report said that, from the respondents, hosting on a personal server dropped eight points since 2020, while using cloud-hosted services like AWS and particularly Vercel, which jumped 20 points, increased by 64%.
How do we see hosting changing in 2023? Will personal servers continue to decrease? Do you see people moving more towards like AWS and Vercel?

Chris:
Yeah. For sure everything's changing. The reason why Vercel's taken off is for good reasons. People want to ship things and people don't necessarily care about infrastructure maintenance or wanting to know that. They just want to build things. They want people to see what they build. And if they can offload that extra cognitive load, they'll do it, right?
Obviously, cost comes into play. But I think, at least starting off, I think it's a no-brainer to kind of offload all this infrastructure maintenance to the "experts", quote, unquote, right? Or I don't know who exactly is doing it behind the scenes. It's probably AWS behind the scenes. But I know, personally, I don't really care.
I just want to code my app. I want people to see what I'm working on. And if scaling is an issue, I guess that's a good problem and I'll have someone like Vercel or someone else handle that for me. And then, if it ends up being too expensive, then maybe I'll think about maybe doing it myself. But until then, I think what developers want is just an easy barrier to entry to have your products seen by other people or just delivering things.

Paige:
Yeah, I completely agree with that. I have worked on applications where it is kind of a microservice architecture. So, you have 15 backing services that are all having to be run on separate servers or having to be run in the cloud somewhere. And it's a nightmare, honestly, to have to deal with that, to have to make sure the build pipelines are all working, everything's deploying correctly, just everything is talking to each other, and load balancing and all that stuff.
So, when companies are making that easier and I don't have to think about it, like you said. I just press a button, it deploys, it's out there for the world to see. That is my ideal build and deploy scenario. And like you were saying, Trash, I want to just build the application and build the cool thing that somebody gets to interact with. I don't really care how it runs, or what CDNs it's cached on or where it is, just as long as it's available.
So, if someone else can do that for me and they can do it with relatively low cost and ease on my end, I'll probably go for it.

Tru Narla:
Yeah. The first time I used Vercel to deploy something, it was magical. I don't know, it was just so nice. Because I remember, when I was younger, building stuff in high school, it was just so complicated for me to... I have code locally on my machine, how do I have it so that my friends can use this? And it just took me so long to figure that out. And now, it's just really simple and easy. And I think that's the move, too.
When people talk about serverless, is this what they kind of talk about? Vercel and that hosting or is that something completely different?

Noel:
In my head, serverless is more back-end code that you are deploying to cloud functions, and stuff like that, versus front-end hosting. I mean, the lines are always blurry, of course, right? The tooling's all changing, but I think that's kind of colloquially what people mean.
But I guess, more broadly though, I'm always just surprised, especially because this poll was focusing on front-end devs. I'm surprised that these kind of onto my own or my client's servers numbers are still as high as they are. Just the web front-end ecosystem is so mature now. There's so many options that's just kind of one-click, push, deploy.
Maybe it's just legacy systems, people can't get buy-in from customers and stuff like that. But back-ends are more complicated, I get it. But in the front-end space, I'm baffled these numbers are still as high as they are, because this is what, 37%? That just seems crazy to me.

Paige:
Well, I think you hit the nail on the head. It's definitely legacy systems. It's large, or even small companies, who want their private enterprise servers on-prem or on private clouds. I mean, it's definitely all of that stuff. And I'm sure a lot of it is just tied to inertia. It works this way, it's always worked this way. Why change it if it's still working for us?

Chris:
It's also probably either, you know, engineers like to know how things work before they go and have someone else do it for them. So, it could be a case of pride and ego that someone's like, "I know how to do it, so I don't need someone else to do it." And then they're like, "Okay, I'm tired of doing this. Let me go switch."
I always take the results from these surveys with a grain of salt, in general, anyway. I truly don't believe that number. It's true. If it says high, it's fine. But I don't know. I don't know why you wouldn't use something else other than like, I get it, I want to know how things work behind the scenes. But at some point, you want to work on something else other than maintaining infrastructure, right?

Tru Narla:
I mean, there's only 3,700 respondents, so there's so many more front-end engineers in the world. So, it's a small subset of people. So, yeah.

Emily:
All right. Onto the last point of this survey, Static Site Generators. Samuel Snopko, Head of DevRel at Storyblok, notes that larger companies are turning towards SSGs over JAMstack. And many companies in the industry like Next, Remix and SvelteKit are racing to become the main static site generating solution.
Do you see this rise in SSGs? How do you think that frameworks like Next, Remix, Gatsby, SvelteKit will continue to evolve? What do you want to see from them in regards to static site generators?

Tru Narla:
I'll do a little bit. So, I definitely see a lot of more SSG solutions. There's Astro that got really popular this year too, that I tried out on Stream. And I get the ease of use of it. The idea is just you write HTML and then that's what you display. It's very easy to use.
And so, similarly with SvelteKit, Svelte is a language that's super similar to writing HTMLs. React has all this other underlying stuff, so when you're writing React, you have to know a lot of JavaScript and all of that. But with a lot of these other tools, or frameworks, it's pretty easy. Being someone that mostly writes HTML, CSS, it's a lot easier to get into. So SSGs, I think it's super important.
When I was working at Square, we were trying to rewrite our whole front-end app from a Ruby on Rails application and move towards something with JavaScript. So, we were debating between using Svelte, React, what do we do? And so, SvelteKit would've made this a lot simpler, if it was out when we were doing those discussions.
But I don't know what I would want to see, but I definitely think it's a really cool move for the next... Any static site, this is such a better way to solve it versus using something like React.

Chris:
I can take a quick stab at this. So, I do see a rise on SSGs for sure. Most of the apps I work on are pretty dynamic. I can't truly SSG stuff. I need a server to either serve-render it or do something else. But there is a fair amount of content sites and marketing sites. I think, what I've seen in the past and my previous employers, we were using things like Next to server-side rendering, when we could've just SSG'd it and cached it on CDN and called it a day, right?
And I think, mainly it's just kind of ignorance at first. People didn't really know what SSG was. They knew what server-side rendering was and they knew that was good for SEO, right? Which is mostly the main reason why people use it. But now, the SSGs becoming a main player and people are becoming more aware of these performance gains that you can get.
I definitely see sites that are either marketing or content heavy are going to strive in that direction. Because I don't know if this is obvious, but with SEO you rank higher with your performance. So, if you have higher performance then you're going to become higher or rank higher than those results.
So, I know there's no reason in my mind why these marketing and content companies wouldn't be doing this, other than they just aren't aware of it yet. And then once they are, I think it will just be a steady rise.

Paige:
I think you both made some really good points. Tru, you were saying how a lot of these SSG generators are more easily accessible to people who might have less JavaScript, or just maybe software engineering backgrounds, in general. And I think that that's really true. I worked on a Hugo site and it was great because it was so very easy, because I knew HTML, I knew CSS. Our designers could even get in there and do some small changes on their own. So, that was great for that, in that regard.
And then also, like you were saying, Trash, the benefits that we get from SSGs, the SEO benefits, the speed, the findability online, all of that is huge and it's just making things a lot easier. Everybody at one point thought that they had to have these massive JavaScript-heavy websites. It had to be dynamic. And it was basically a food recipe blog or it was something that didn't need nearly any of that interactivity or that really heavy bundle of just extra stuff coming over the wire that people thought they needed. So, yeah, I can see why a lot of people are starting to go towards that.
The company that I work for, Blues Wireless, one of our sites is Next.js, and we do need the server-side rendering for it. But we have other ones where it's completely all SSG, because it is just content, it's documentation, it's examples, it's things like that.
So, I could see why a lot of people would want to go towards that and I hope that we'll see more of it. Because in the end, the best user experience is the one that's fast, the one that feels fluid and the one that the user can have the best experience with. And that's really what we're all building this stuff for, is our users.

Noel:
Yeah. Yeah, I feel like SSGs are the natural marriage of people wanted these somewhat reactive front-end frameworks. They're nice to work in for developers, right? That's a big thing about React View, that I think we don't talk about as much. They're cool, they enable us to do reactivity, but they're also just nicer to work in than a lot of other frameworks.
So, I feel SSGs are kind of bridging that gap if we can have really light, really performant bundled front-ends, that let us use these tools that we like using as dev. So, I feel like that's just coming to fruition in these kind of having upticks and popularity.

Chris:
One thing I like to add, so even talking about Static Site Generation, I don't know if listeners actually know what that is, right? Effectively, what SSG is, during your build step you just build HTML files and then serve those, right? But you can imagine, and if your site gets really big, this build step can get very, very long.
So, assuming you have hundreds of routes, you don't want to build all of those during your build step, right? Because that's just going to take forever. So, I know we hinted at ISG, or incremental site generation, that allows you to just regenerate specific pages as you want.
And I know Next came out with something. I don't know when they did it, but basically you can hit an API now that will, on-demand, just invalidate something and rebuild it. And I think that's super cool.
To be honest, I don't do SSG too much on my end because, like I said before, a lot of my sites are very app-heavy dynamic. But I have heard the pains of many people that are in the SSG ecosystem, where I don't want to build a hundred pages because I just changed a typo. I want to just change this one page. And that's kind of what ISG is solving there.

Paige:
Yeah, I think it came out, I remember playing with it at Christmas in 2021. So, it came out at least a little bit before that.

Noel:
Gatsby and Next have opened with really, really cool stuff there. We've been, on our end, for our blog, we've been pushing it this way. We've got thousands and thousands of blog posts. The build takes a long time from raw, but when we have one post that gets pushed, we just need to update this one page, so it's quick.
So, there's been big, big steps there that have made that a lot easier. Just kind of get up and spinning, like point it at [inaudible], tell the suite to do its thing and it kind of just works. So, yeah. It's been cool to see.

Emily:
Yeah. Shout out to the blog, do check it out. I love all my content buds.

Noel:
Yeah, yeah.

Emily:
You'll see all of that in action. But one of you mentioned SvelteKit, or maybe I mentioned SvelteKit. 1.0, was finally released in December and I don't know if you were watching Rich Harris tweet every day the countdown, but I was anxiously awaiting. I was in Puerto Rico when it released and I immediately emailed him. I was like, "Hey, let's talk about this."
But I want to get your thoughts on SvelteKit. It's been two years in development, released in December. There's been a lot of buzz around it. A lot of frameworks already publishing how to deploy SvelteKit to their own platforms. It's been generally well-received. Have you been excited about this release? Why or why not?

Paige:
Yeah. I mean, SvelteKit I think is an awesome turning point for Svelte. Because Svelte is just a really nice framework to work in if you're a developer. It's a nice way to build websites. The components are easy, the syntax is pretty easy to pick up. So, SvelteKit just added all the bells and whistles that you need if you want to be a framework that's taken seriously for large scale production style apps.
It adds in the routing, and data fetching, and caching and basically all the stuff that you need to consider if this is going to be a large application that a lot of people are going to be using, or a lot of developers are going to be working with. And so, I think they really kind of brought themselves into the conversation now, to be considered for those big apps that you are going to have, that will be either long-running or are just ready for prime time.
Yeah, I think it's really awesome. I haven't gotten too far into the details of it yet, but I'm really excited to.

Tru Narla:
Oh, yeah. A hundred percent. I love Svelte. I learned about Svelte just this last year, when I was streaming, and it's just such a fun way to write front-end. I don't know, it was so fun. And so, SvelteKit, I also haven't dug deep and used it yet, but I definitely love the direction that they're going in.
Like I mentioned earlier, when I worked at Square, I was on the team that handled squareup.com, which is a huge marketing site. Lots of blogs. I picked Svelte as the language to go with. And if SvelteKit was a thing back then, I would've been like, a hundred percent this is the way that we should start moving towards.
But, yeah. I'm super excited. They're also going to introduce incremental static regeneration, like Trash mentioned. So, that will be awesome. But, yeah, I definitely think it's going to be great. And then, Vercel. Rich Harris works at Vercel. Vercel is wonderful with documentation and it's just going to be, I don't know, they're just doing such a good job with launching and getting all these docs up to date, and all these tutorials. It's just really easy to pick up and learn.

Emily:
Do you see this release as SvelteKit ushering in anything new that we haven't seen before? I know you guys kind of touched on it, but how do you see SvelteKit changing maybe the framework environment in 2023? Or is it just another framework?

Paige:
I mean, it is another framework, but that's great. It's great to have options. One of the cool things that I've read about SvelteKit is that it can do the dynamic data and the pre-existing, pre-rendered data side by side in the same page. So, when you have something that you need to be dynamic, I think on their documentation itself, actually, they have a kind of Getting Started with Svelte tutorial. And they'll give you some sort of prompt and then they have this live [inaudible] next to it, where you can actually type in, see how the code changes in real time.
So, I think that's one of the examples that they're talking about, of that pre-rendered data plus live dynamic data. So, having that together in a nice way, where you don't have to think about this should be server-side generated, this should be client-side and then client-side hydrated or things like that, I think they've taken care of a lot of that for us. So, we don't have to specify it's a server component or it's client-side. And that's great.
I don't want to have to think about that if I don't have to. I will, if you tell me that I need to, with React or Next or things like that. But if they're smart enough that it can do that for me, then all the better.

Chris:
I'm sorry. So, one thing I like, I'm not a Svelte or a SvelteKit expert at all. But what I do know is it's pretty interesting to see these meta frameworks kind of lean heavy on web standards and be prescriptive on how things should be done. If you think about prescriptive frameworks, the person that comes to mind for me is Angular, right? Angular is like, we have our way of doing it, which is easy for people to onboard. You get that consistency amongst teams, which is the main draw for enterprise software and stuff like that.
So things like Remix, things like SvelteKit, that kind of have these kind of conventions, I think it makes it a lot easier for engineers to build products in a more consistent way. If anyone's been in the React code base in multiple companies or multiple teams, every React code base looks completely different and they use completely different tools, and it's mind-boggling sometimes. So, it's nice to see these kind of prescriptive frameworks.
I don't want to say, maybe not prescriptive, it's too strong a word. But I think it is, in my mind. But it's funny, because back then, there was a whole divide between Angular engineers and React developers because they thought Angular was holding their hand too hard, and React engineers want this freedom.
And now, we're going back to this thing where these opinions are being put on them and now they're happy about it. So, we kind of swung both ways because everyone's like, "I want my own opinions." But then, they don't even know what opinions they want. So then, they just ask the experts for their opinions. So it's like, well, just pick something, right? So, I just think it's just pretty funny, in that sense.

Emily:
All right. Next, I want to go into the golden age of JavaScript. So, this is actually an article that was published in January of 2022, but I thought it was kind of pertinent to how 2022 played out.
Everyone was very excited about TypeScript at the beginning of 2022. It obviously very much blew up this year. There was also an influx of meta frameworks, like Trash was just talking about. JavaScript increasingly was on the Edge, and whether it's wise to solely rely on one language when you're developing. So, considering how 2022 played out, I do want to touch on some of these points and how we might see JavaScript continue to evolve in 2023.
So like I said, TypeScript's kind of taking over the front-end space. Generally, how do you see it evolving in 2023? Do you see more people adopting it? Guillermo Rauch says that TypeScript can scale easier than JavaScript. Do you see this manifesting, as more developers adopt TypeScript, and how do you see that happening?

Tru Narla:
I, a hundred percent, think TypeScript is the future. I don't know any big company that hasn't started evolving, or moving to TypeScript, or has fully moved to TypeScript. It doesn't make sense for me to have such a big production app still be in JavaScript.
And then, TypeScript also, there's so many packages nowadays that are getting really popular because of type safety. And so, I definitely think that's the way of the future. So, yeah, TypeScript I think, and it also, Guillermo did say, yeah, TypeScript can scale easier than JavaScript.
I think a lot of people in their head think TypeScript is a whole separate thing than JavaScript. A lot of people think it's hard and complicated. I don't think it's that much. When you're using TypeScript, a lot of times you're using all these libraries that kind of handle all that fancy types for you. So, you're doing the fun parts of TypeScript, where it's like, "Oh, my thing matches up with this or it doesn't," and I can figure out what the error is.
I feel like people get too caught up in their head of having to have to switch to it and having it be a big problem. But I'll let Trash go. That'll be my first and then I'll jump back in later.

Chris:
I'll say, my first hot take is if you're not using TypeScript then you're probably just doing it wrong to begin with. I don't see a reason why you wouldn't use TypeScript from the beginning on any project going forward.
One, market demand for jobs is just blown up. If you want a job, learn TypeScript, right? If you don't know it, then I don't know what you're doing.
But also to Tru's point, there's huge influx of libraries about types out there. Literally, if I open Twitter right now, if I don't see a TypeScript post between every three tweets, then I don't know what I'm looking at, right? Everyone's on this TypeScript type train.
I mean, it's for good reason. It's not to say that TypeScript doesn't have any flaws, but it's way better than just writing JavaScript in my opinion. And if companies want it, then there's no reason why you shouldn't. Unless you don't like getting paid, you should learn TypeScript.

Paige:
Well, I agree with you both. I was late to the TypeScript train. I didn't get on it until summer of last year. And I joined a new company and we had TypeScript code bases already. So, that's kind of how I was thrown into it. And honestly, I'm really glad that I was.
It is maddening at times, when I'm having issues and compiler warnings and my types aren't matching up. But it has also saved me from so many undefined null errors, things that wouldn't have worked, typecast issues, all sorts of stuff. So it is not as bad, I would say, as something that is a strongly typed language, like if you've ever worked with Java or something like that. It's much more forgiving. For the most part, I think the errors are easier to understand or to figure out.
And yeah, it is a hugely popular and only gaining steam in all organizations of all sizes, from little tiny startups to big enterprise level stuff. So, I would definitely say, if you have not gotten into it, get started and just build some side projects, turn TypeScript on and see what happens.
And one of the huge things I think is that extra sense of security, you know? We started with writing unit tests, and writing end-to-end tests, and having things that gave us a better sense that our application was going to work, when it got into production and into user's hands. And I think that TypeScript just offers more of that, more security and sense that it will do what you expect it to do when people are interacting with it.
So, yeah. Go for it. Don't shy away from it. It's only going to continue to get more and more popular. So, TypeScript is here for a while at least.

Noel:
Yeah. I think to build on what Paige said a little bit, it's interesting that all these old type-safe languages of old were always, I don't know, talked about. So, I don't know, fearfully is the right term, but people were always scared of using them because they thought it slowed them down.
But somehow, TypeScript seems to have perfectly struck that balance, where devs seem to love using it but it doesn't get in their way. There's probably something to be said here academically, about language design here, that we should be learning lessons from this.
But regardless, I think we're kind of getting into this cool space where the tooling is really getting there. And now, one can go set up. You can use Prisma or really any ORM, and have it use tools to have type spit out for that. Then you have your API definitions, use those types too and have them bubble all the way down to the front-end. Then, if you change the type of a database feel here, you run your command on all your types regenerate and you know where the front-end's going to break.
And that's a super cool place to be. That was not really possible unless you were fully bought into the Oracle or the Microsoft Stack before, like a .Net app or something. But now, you can do that with all these open source tools and everything just works. I think it's a fun time to be using types.

Paige:
Well, one of the things that I just take it for granted now, because I'm so used to using it, is the IntelliSense that comes from it, when you're using VS Code to do your coding, and you're using TypeScript. And it just knows what methods are available, it knows what parameters a function takes. And it gives all of that to you.
So there's no guessing, there's no having to go look back at where the original thing was in the code base. It's so helpful in that regard, and I think that's awesome. That's probably one of the biggest benefits that we all just kind of take for granted, I think.

Chris:
Yeah. I think if there's any pushback towards TypeScript, so I think, TypeScript at its core, if you just open up a TS file, no third-party libraries, TypeScript's pretty straightforward, right? I think where the pushback comes is when people try to use TypeScript with other libraries, like using TypeScript with React, or TypeScript with whatever X tool. And you get these weird cryptic errors, or it's literally like a novel long and you just have to scroll to the bottom to see it.
But we're getting better at addressing this. One of my homies, Matt Pocock, he wrote a VS Code extension that basically takes these long cryptic type areas and translates them in a more human readable way. So, it's one way the community is kind of taking steps forward to ease that barrier to entry. But most times, where I see people complain about TypeScript, it's more of them just trying to integrate with some library. And potentially, the library itself just has bad types. So, they're just throwing any everywhere, without truly understanding anything.
So, yeah. I think that's where some of the friction comes on. And I get it. People want to be productive, right? If a tool's in your way, then don't use it. Because at the end of the day, you do need to ship things, right?
But I think, after that week of just banging your head against the wall, you'll see your productivity graph exponentially rise. So I would say, for anyone that is new, that doesn't do TypeScript now, or you gave it a shot and you hate it before, I would say, just stick through it, through that painful part. And then, I think you'll truly see the fruits of your labor.

Emily:
All right. So obviously, TypeScript, huge impact on the community right now. So, when we talk about JavaScript, this article also was talking about how they saw JavaScript becoming more full stack.
Do you think that it can go beyond the front-end and tackle back-end features that go beyond serverless functions? And how do you see that manifesting?

Paige:
I mean, I think that the best example of that so far is the Next.js framework. It is truly, and it's the only one that I've used that wants to be everything. It wants to be able to do your API calls, it wants to be able to do your front-end and all of that at once. And in my opinion, it's done it pretty damn well, actually. So, yeah. I think it absolutely can be full stack and I think it's a good example of it.
Up until now, there's been so much division between your node server, that's doing all your back-end secure things, your database interactions, what have you. And your front-end, which is just serving up views, and data, and things like that. So, I think that it can be, and I think that a lot of developers want it to be.
So, yeah. I think that's something that people are going to push more towards this year, because it's just simpler. And the easier that we make the development, the better. The faster we can get things out to users, the better the experiences can be overall. So, I think it's definitely something that people are going to continue to strive towards.

Chris:
I think you hit it on the head pretty well. I think Next.js or Vercel makes full stack development insanely easy, because you don't actually know that you're doing full stack development. I guess, I'm kind of confused with the question because I feel like JavaScripts has been pretty full stack for a while, right? Obviously, you have your node servers, et cetera. And at Netflix, we have good amount of apps that use node as well.
I guess, when you mean beyond service functions, I guess maybe you're hinting towards the Edge maybe? And that's kind of what Vercel's pushing now. I don't want to go too deep on that, but we all know or not we all know, but service functions do have inherent issues, cold starts and stuff like that. And then Edge goes up to seek that issue. And if you're not familiar what Edge functions are, it's effectively just running JavaScript closer to your browser.
Right now, currently, the traditional way of getting performance is using something like a CDN and cashing your static assets. So then, you don't have to go to your original server, you can just hit a CDN and get those static assets back. Whereas the Edge, you can execute your JavaScript closer to you, versus going to some region that could be farther away, right? So maybe I'm in Japan, I have to go to US east. That wouldn't make sense, right? So, you can have that JavaScript execute closer to you.
And I think that's where we're pushing the boundaries there. I don't think the Edge is mature enough yet, nor do I think that engineers truly understand the Edge and it's power yet. I think it's a cool innovation. I think it's mature. Yeah, I think a lot of people hear the Edge and they're like, "Cool."
But I don't really know what problem it solves for me yet. Because, one, the Edge just sounds intimidating when you say it. And then, two, most engineers are tackling the performance issues already and maybe they don't know what they don't know. They don't know if they actually need the Edge or not. So, it's an educational thing. But I think, after serverless functions, Edge is next for sure.

Tru Narla:
When I was reading the Edge in the notes, I was like, "What is this?" I tried to Google it and all that came up was Microsoft Edge or something. I was like, "What? I think, I don't know what this is." And I had to ask someone what the Edge is.
No. But I think, like Trash said, I think it's super cool. I think the idea of running something, doing computation on a CDN is crazy. That's so cool to me. And I don't know if it's there yet or not, because I haven't really looked into it. But super interesting tech that we're going towards. Sorry. Go ahead, Emily.

Emily:
No. No problem. I will say that, the article that we're discussing was also saying that Sunil Pai suggested, at the JAMstack conference last year, that everyone start putting at least part of their website on the Edge because it is, to Trash's point, becoming more available and workable for devs. So, great. Thank you. Thank you all for going through this Recent News journey with me.
Before we go on to our hot takes predictions, I just want to say that, if you are enjoying the podcast, please follow us on Apple. That really helps us know what you guys like, tailor our content to fit what you want to hear and keep bringing you new experiments like this panel that we're on today.
All right. So, we're going to go into our hot takes. Each guest is going to have one minute to either talk about something they're passionate about, angry about, excited about, looking forward to in 2023.
We're actually going to start with Noel and I'm going to give you one minute. Let me get my timer out. All right. You ready, Noel? And start.

Noel:
All right. I'm going to build on the thing we were just talking about. I feel like we spent a lot of time talking about Edge computing and how it's going to change everyone's day-to-day developer lives potentially in the future. And I don't think that most devs are going to actually need to think about it actively when doing 95% of development in the long term. I think these frameworks and tools, things like Vercel, are going to figure out things that can be done at Edge and make that just automatically happen in 99% of cases, long-term.
So, I don't feel like this Edge stuff that we've spent a lot of time thinking about this year. I think, right now, there is work that can be moved there that can help optimize and make web apps super snappy. But I don't think long-term devs are going to need to care about it.

Emily:
Paige, do you mind if you go next? I'll give you one minute on the clock.

Paige:
Yeah.

Emily:
All right.

Paige:
So, my hot take is going to be about AI, because that has been extremely big this year with GitHub Copilot, with ChatGPT, with Amazon coming out with their own code, Whisper or I can't remember the exact name of it. But basically, a lot of people are talking about, is it going to take our jobs as developers?
And the long and short answer of it is no, I don't think it's going to. I think what it's actually going to do is enhance our jobs. It's just going to make it easier for us to write code. It's going to make it easier for us to get the stuff done that is not necessarily the most fun part of our jobs.
But the part that I really enjoy about my job is the novel solving of problems. And that is something that AI, I don't think is really quite able to do yet. It's just one of those things that it's great when you have a very specific problem, but not so much when you have a lot of ways that you could get to the right answer. So, I think it'll just make it better. I don't think it will go to take our jobs anytime soon.

Emily:
Tru. Do you want to go next?

Tru Narla:
So, I posted on Twitter asking people for their hot takes. I just want to read one, because I think it's funny. Someone said staging is basically telling your team you don't trust them. And I thought that was hilarious. But it's not. I don't think it's a good take. I just think it's funny.
But my hot take, I have a couple. The big one is, I post a lot about Tailwind because I really like Tailwind and I use it. And a lot of the reasons that people don't like Tailwind is they say it's just long class names. And to that, I think that's just the poor reason to not use Tailwind. There's ways to mitigate that and make it easier for you to use. So, I just think that's a bad excuse for not trying a different thing out. Just think of something better. I don't think that's a great way.
The other thing too is a lot of people are hyper-focused on productivity when they're programming. So, they try to make their text input as fast as possible and try to do all these things to make it faster to code. I was reading something, if you just add 15 minutes to your day, I don't think it really adds much in your productivity output. And I think people hyper-focus on it and they don't need to. That's it. That's my takes.

Chris:
As a VIM user, I'm offended.

Tru Narla:
Yeah. That's targeted at you, baby. That's targeted-

Emily:
Awesome. Also, Tru was just on in January talking about Tailwinds. So, if you want to check out that episode, we'll put it in the show notes. Trash.

Chris:
I don't know if this is a hot take. This is more of something I'm passionate about and I just like spreading the word. So, I was on the podcast in December about tRPC. So of course, I'm going to talk about tRPC again.
A big goal of mine for 2023 is upping my tRPC contributions. I'm just really passionate about the project and just TypeScript in general. So, I just love shilling it whenever I can. So, this is a great opportunity. If you haven't heard tRPC, tRPC.io, check it out. There's a podcast somewhere. Scroll down on your Spotify. This is a big ad. I'm so sorry.
But if you like type safety and you like to work productively in your code base, check it out and add. Boom.

Emily:
Love it. Love it. Yes. We'll put that in the show notes.
Also, Paige has also been on the podcast. It's been a while, but we'll also put her podcast episode on the show notes, so you're all equally represented.
Thank you, everyone. This has been absolutely so much fun. Thank you for joining us today. It was a great panel. Thank you for listening today. We really appreciate everyone's support, especially on episodes like this, so we can do more fun things like this. Thanks for listening and we'll see you soon.