Ep. #138, What’s New with Next.js Featuring Nick Taylor of OpenSauced

Brian Douglas: Welcome to another installment of Jamstack Radio. On the line we've got Nicky T Online, which I know you by Nicky T Online, but Nick Taylor. Hello, how are you doing?

Nick Taylor: Not too bad. How are you doing, BDougie?

Brian: I am doing fantastic. I feel like I finally have a part of my calendar tomorrow where it's no meetings, so it's unfiltered work which will probably be setting up meetings next week. That's basically my job now, it's how can I do a meeting with somebody and get them to see a demo of Open Sauce. But less about me and more about you.

Wanted to bring you on because you've got some interesting background within Next.js so I wanted to actually spend this conversation talking about your experience in Next but also looking forward to Next.js as well. But before we jump into that part, can you just tell the listening audience if they don't know who you are, who are you?

Nick: Yeah. I'm Nick Taylor, I'm currently a senior software engineer at a company called OpenSauced that you might know, BDougie.

Brian: I do.

Nick: I've been in the web dev space professionally since like 2002. A lot of work in .Net initially, but I pivoted towards open source and full stack JavaScript stuff like 2016. Got in early on some things, so I've been using TypeScript since 2015, React since about that time as well, and since 2020 I've been working professionally in open source which has been awesome because I love working with the community, love working out in the open and to be able to get paid for that is super awesome.

It started off at Dev.two which some folks probably know. More recently I was at Netlify, I was working on the frameworks team over there, and we can definitely talk about that. Now I'm over at OpenSauced, working in open source again and just loving the ride.

Brian: I originally was aware of you when you were at Dev.2/now Form. Yeah, I'm curious, what was the world like when you were working as an employee for an open source company? I guess an open source first company? How did you manage contributions and did you take a lot of contributions from folks outside?

Nick: Yeah. We did. Fun fact, as the first contributor outside of the core team to the project, and my contributions there are pretty much what got me hired there. But in the early days, I think there was less of a product roadmap and so people would be like, "Hey, can we add this?" And then we'd be like, "Sure, just pop it in," and if you don't have a clear plan of what you want to put in your product, it can come back to bite you.

So we kind of pivoted a bit there, we did get a product roadmap and stuff. But having said that, we still got quite a few external contributors. We used to stream quite a bit, me and my old coworker Christina Gordon and we'd do live coding sessions with people just interested in the project. There was a lot of buzz around it and people really enjoyed contributing to it. I think a lot of that, aside from it being a popular open source project, was we were a small team at the time, in the early days, and there was a lot of really great energy.

Kind of same energy I feel right now at OpenSauced where it's exciting, we're a tiny team and we're just shipping stuff. It's just like a really fun time right now. I think it's just a combination of all that that got people in the community really excited about the project, and I see the same thing in Open Sauce as well. It's the same thing. I know you were at GitHub before, but you were always...

I used to catch your streams and you'd be working out in the open, just building out parts of OpenSauced and you could always see people were excited about that too. I think that energy has kept with the project, which is really nice to see.

Brian: Yeah. It definitely has been interesting because Open Sauce, as an idea, has been around since 2017. At least the URL has been around since 2017, OpenSauce.pizza that is. The one thing that we did decide last summer when we wanted to figure out, okay, and I say we because I hired a team, we took in some investment, and I wanted to make sure we started the project in a way that had good foundation but also would attract interest and talent and contributions.

So we made the decision to use Tailwind and Next.js, and the thing that I noticed was at that time last summer, or even years prior during the pandemic, it's like Next.js and Tailwind, I can always find someone who could speak that type of language or that framework, interact. But also we didn't have to go back and forth on structure and whether we're using SaaS or SCSS or Post-CSS. All those decisions I didn't want to have in the open with a team that was not going to...

The challenge to open source, folks don't come back, they're not guaranteed to come back for a second contribution. So if you make one contribution, can you make impact and then leave without basically killing the project or making it deprecated? So this current app, OpenSauced , was my first, I guess, big, production grade Next.js project. The decisions I made were Next.js and I also chose Netlify because I had a connection to Netlify, and I knew Netlify was working on this next runtime and build tooling.

I know you worked on that at Netlify, so I was curious, can you explain a bit of that situation, how Next interacts with Netlify? Because you assume Vercel because Vercel is maintaining Next.js.

Nick: Yeah. So you can deploy Next.js to other providers. I know they have a Dockerized version that you can use for deployment. They also have a build output that you can consume. But I can't say for certain, but most of the other frameworks, the other frameworks, have adapters and that's how you're able to deploy, for example, Remix to Netlify, to Vercel, et cetera. Same thing with other frameworks.

We ended up going for Next.js, there was an adapter that we created as well. We call it, well, I say we, I don't work there anymore... But it's basically called the Next Runtime @Netlify, and it's to provide a great experience for Next.js on Netlify, and things an adapter of sorts. They're called build plugins, but I think they've gone away from the term build plugins, it's more like integrations and stuff.

But at the core of it, you're deploying it to a serverless environment and you just have to make sure that everything... The problems that you run into aren't necessarily with the frontend of the application because the frontend should just work, because that's what's going on in the browser. It's really making sure that, because typically people are deploying to AWS and that's where it goes under the hood for Netlify, so it's making sure all the proper Lambdas get created, the static content and all that stuff goes on the CDN properly.

It's just, I would say, a bit of a complicated project. It's hard to go into very granular details here, but there definitely has been mention that... I'm not saying this just because I worked there, but it's people on the internet say this too. They found it hard to deploy Next.js to other providers. I think Netlify is giving a pretty good experience, and it's getting better and better. I think things are looking pretty good for it to be to other providers.

I can't speak to other ones like Render or... I don't know if anybody uses Heroku still, but other environments like that. I think for Dockerized environments, it works kind of well, I think. I've never done it myself so I can't speak to that.

Brian: Yeah. So the concept of bundling your Next app alongside of Docker... I know Heroku well, and I've shipped a bunch of React apps for Heroku, and those build packs that Heroku had... Basically there's some after or post-processing or build tooling to make sure the server connects to your node server, or to whatever, or your server side rendering experience. So it sounds like Netlify has this abstracted, you said they're not build packs, it's not a runtime, it's integrations.

Nick: Yeah, yeah. They've gone with integrations, I think in general, at Netlify now. But to give some examples, for example, you have the Next image component and under the hood that does image transformations and all that. On the Vercel platform, for example, not positive, but I think they use Imagix and so that's what's provided there. Currently at Netlify if you're using the Next image, it uses a project called IPX, this came out of the View community, I believe.

So that's what handles the transformations and it uses a library called Sharp that other projects have used too, like Gatsby. So there's stuff like that, for example, when you have a Next image that's being transformed, it's a specific URL, and then when that URL gets hit on Netlify, it will transform it using IPX by making sure it goes to the proper service to do that. It's just making sure that things fit where they should at a high level, I guess.

Brian: Cool. Then you joined Netlify specifically to work on this problem?

Nick: Yeah. Well, to be honest, I loved what Netlify was doing. I had been a big fan of them since 2017, which I think is... I don't know if you were still there at that point.

Brian: Yeah. I was out in 2018.

Nick: Okay, yeah. I just liked what they were doing and, honestly, I think for myself whilst I was there it was time to go from Dev.two. I had a great experience there, but I was looking for other opportunities and I just came across it and I saw this role and I was like, "Oh, it's Node.JS and TypeScript." I had previously, before working at Netlify, I had worked in a lot of frontend stuff and I was familiar with the frameworks, but I had never worked on the underpinnings of frameworks so I thought it sounded like an interesting challenge.

I was not a frameworks author before or contributing to frameworks in that regard. Yeah. I just took it as an interesting challenge, at a company that I was a big fan of because I had a chance to interview some people when I was on the Dev.Two streams so I got to hang out with Jason Langsdorf, Cassidy Williams, Ben Hong and they all seemed like awesome people. That just really resonated with me, in terms of wanting to go work there.

So it was really more like new opportunity and challenges, and working also in the serverless space because I wasn't doing that at Dev.Two because I was focused mainly on the frontend there and it's a Rails monolith in the backend so there wasn't really much opportunity to, at least in my day to day work, work on anything serverless. It's kind of a combo of all that.

Brian: Cool, cool. Excellent. So I did want to spend some time talking about what's next with Next, and we just came out of NextConf, so Next 14 was announced, the biggest thing was performance. Not a ton of different features. But I know Next 13 had a ton of different features that were kind of half baked and still going through the process, so what's your thoughts on this new release and the performance updates? But also what's your thought of the fact that Next still has a foothold in the React ecosystem and community?

Nick: Yeah. All great questions. When Next 13 came out, some things weren't stable right away. Like the App Router came out and they were still working on some things, but people were excited about it and it was a change from what they had previously, which still exists and you can still use. We actually use it at OpenSauced right now. We're using what's called the Pages Router, but the App Router was the big thing that came out with Next 13 and that provided you things like nested layouts, and then you had this concept of React server components that the React team has been working on.

Then it's kind of all a blur where features came in, because I was supporting these things every day. But there's the React server components now, RSCs as they're called. There's server actions that exist now, which I don't think are experimental anymore, and this is if you... For folks who caught any of the Next.js Conf, there was Sam Selikoff who had a demo and then there's a SQL statement in a component where people just kind of lost their minds, like, "What are you doing?" It was a trivial example and, just for context, it was using a template function that makes sure there's no SQL injection. But the whole point, I think, was just to show a simple example of what you could do. It wasn't to say everybody scream at me, SQL injection.

Brian: Yeah. Which was what happened.

Nick: Yeah, exactly. But the internet is going to be the internet. But the release for NextConf 14, it did seem a little underwhelming but I don't mean that in a negative way. What you were saying, for example, there's a lot of performance improvements like the Dev Server, people were saying it was really slow so that got a lot of improvements. They've been working on Turbo Pack which is a product they acquired. Well, no, they acquired Turbo Repo from Jared Palmer, and then I think Turbo Pack came out of Vercel, I don't think that came into Vercel.

Brian: Well, they also hired Tobias from WebPack as well. So the Turbo Repo and Web Pack combo, it started to make a little more sense for those further away from those acquisitions and hiring.

Nick: Yeah. So that's not necessarily Next.js specific, but that was announced last year at NextConf when Next 13 came out. For folks who don't really dig into how your framework builds and stuff, Next.js is still using Web Pack under the hood. This is something that a lot of frameworks were using, like Gatsby uses this still. I think they're trying to move away from it, a lot of people have moved towards Vite now.

Brian: Yeah. Remixed has announced they're Vite migration, as well as Redwood is now also at Vite as well.

Nick: Yeah, exactly.

So it seems like all the frameworks are going towards Vite, except for Next.js because they've been focusing on Turbo Pack.

Like you said, Tobias who created Web Pack, is there as well so this is a Rust based version of a bundler and all kind of tooling like Web Pack that promises to be faster. But that's still being worked on, as far as I know. You can use it today. I think, for example, if you run the Dev Server, if you run npm run dev -- turbo it'll use Turbo Pack, I believe.

I don't know if you have to download Turbo Pack or if that's something built into Next.js for the Dev Server. But the one big thing that does look really exciting out of the Next 14 release is it's still an experimental, preview-ish, but it's called partial pre-rendering. There's some videos I'll give you after the podcast that we can put in the show notes, but from my understanding prior to partial pre-rendering you could have static content generated at build time.

So this particular page, it's static so it'll just generate whatever the markup it's going to have and then that's what'll get loaded and you can still have interactions and stuff. But it's essentially a static page, and with the partial pre-rendering you can still have static content so when you go to the page it loads up super fast, but you'll end up with these sections where if you're using a React Suspense...

From what I understood, the fall back will be what gets generated in the static content, so your skeleton loaders and stuff, so that will be instantaneous. Then the dynamic data gets streamed in after, so it provides a better experience. That's my understanding of that feature. Feel free to correct me on that, internet, once you listen to this.

Brian: Yeah. It's funny, because I definitely have some corrections in my picks. People DM me after the fact and be like, "Hey, actually you're using it wrong." But no, as far as this partial pre-rendering, I'm intrigued. I know the ISR was a thing that was before, Incremental Static Site Generation. The thing I was confused on with Next.js in the last year's launch is the App Router was meant to centralize how you're basically using rendering and stuff, server side rendering versus static rendering, client rendering. But I still feel like it's kind of confusing to this day. Has that cleared up at all?

Nick: Yeah. Well, I think to be clear, I haven't worked with React Server Components a lot yet, aside from a few Hello World things. But I think there's just confusion around React Server Components, and some people still aren't sold on them. I want to do a real deep dive into them myself to just give a really good opinion about it, but the main thing is with the App Router is you have React Server Components by default and those will get rendered on the server side.

But you can also fetch data in those components, and then that data can be passed along in the component tree from what I've understood. But if you want to go with something interactive, like on the client side, you have to specifically opt in to a component being used for the client side, so you have this directive which is a string that you put at the top of the file. That's the component, you'll see 'use Client'in quotes, and that gives you that interactivity there.

So I think there's still confusion around those things, and I know there's been a lot of... I'll drop it in the show notes after, but Ben Holmes did a really great deep dive on React Server Components. He had Dan Abrama on his stream a few months ago, and they built a small implementation of a React Server Components server, I believe, or a framework. It was just interesting to go into the details because one of the things that people have criticized is that the only implementation of React Server Components has been Next.js.

But that's not true anymore, as we were talking briefly about Redwood.js, Redwood.js has implemented React Server Components. It's not the in the production release yet, I don't think. I was speaking to Amy Dutton on the core team there, and I think they're still behind a flag or it's an alpha version. But I remember hearing Tom Preston-Warner talk about if this is what React's going with, this is what we want to go with, so they're definitely going that route too.

Remix is moving towards React Server Components as well, but there's some controversy about the React version being used in Next.js. It's a canary version, and there's some confusion around that, but for Remix they said it'll probably show up in Remix version 3.0 because they want to use it with a stable version of React. That's what I understood over there. Then the canary version of React, it's Next.js pulls.

I think they even pull in a specific version into the build of Next.js, they're not npm installing React when they build it, I believe. So they work closely with the React team, obviously, and I've listened to a bunch of podcasts about this and it's not like it was a conspiracy or anything. I say this as somebody who's worked at somewhere else, it's really been these things have been in the works for the React project for a while.

They've just been working closely with Next.js, from what I understood, just because they were interested in looking at implementing it potentially. But I can't speak to conversations with other frameworks and all that, because I don't have those conversations.

Brian: I mean, as an outsider, it looks as if the React core team is in bed with Vercel. But in reality, Vercel has put a lot of investment inside the React ecosystem, for better for worse. It's in their best interest to see things advance. I implemented Suspense in Open Sauce in 2019, when it was still experimental. We only just got Suspense last year out of experimental, I don't know when it actually launched because I was using it for so long.

But when you have a framework that's being used by folks, other than just the Facebook platform, React originally started as, "Okay. This is a cool thing that Facebook ended up using, now Meta, it's leveraging in projects." But now everyone else wants access around that and conversation and thought, and I think those who raised our hand and requested access and privilege in secret meetings, whether the secret was public or open source...

Anyway, it's something I'm willing to bat for Vercel, which I am. The one thing, I talked to the V team, I talked to the React team, I talked to a bunch of folks, when you request feedback for releases, request feedback for RFCs, a lot of time you just get a lot of noise. You don't get a lot of feedback, and I think if a company is going to provide feedback and salaries for folks that continue to work on this stuff, then I'd say so be it.

I guess my follow up question to that rant is where do you see React and Next moving forward? Because I think I saw a number, it was actually Laurie Voss in the Jamstack Survey last year. I forgot the number, but it was like 80% of all React apps in production are Next apps, and this was last year's numbers. I don't know what this year is.

But then React is making up a good amount, it's approaching where WordPress is like 30 to 40% of the web, a lot of that's also React so React is closer to 15 to 20% of the web is React apps. So do you see React being the next WordPress even though WordPress is a CMS? It's not apples to apples.

Nick: Yeah.

I don't see React disappearing any time soon. There's been talks about can we put JSX in the browser and stuff, and I don't know about that. But if we talk about the JavaScript ecosystem, I definitely think that React is still king and I don't mean that to knock other things, like View is amazing, Svelte is amazing.

But it does seem like a lot of the ecosystem is React still, and Next.js, I don't have numbers handy or anything.

But it definitely seems to be the most widely used meta-framework if people are using a meta-framework because there are, depending on how old your app is, you might actually still be using Create React App. You might be on a bespoke thing, like some people run it with Express and just bundling the frontend and stuff. But if you're in meta-framework land, I think Next.js is the one there right now.

The nice thing too about having the other frameworks, and even other things like Solid.js which isn't necessarily a React framework, all these different approaches and things that people are doing in their frameworks are helping push everyone forward which I think is a good thing. It's just nice to see in the ecosystem at least.

Brian: Yeah. I feel like this sort of decision fatigue that you get with choosing the next framework, pun not intended, but the decision fatigue of choosing JavaScript frameworks... I don't know. Maybe it's because I've got enough years, I started doing React around the same time you did, so my default is React.

I don't think I need to learn another framework, because I'm now at the point as an engineer where now I'm leading a company, I'm just tinkering with bugs and I'm not actually building features. So I'm indifferent on the future of what framework is chosen, but also I appreciate the current state of React and Next, that it's mature enough that we can just know it's going to still be there.

But I did see one tweet recently of the features that everyone is excited about coming out of this React ecosystem are basically features that were just missing in React for years. We're getting excited about stuff that was table stakes in other frameworks, things like React Server Components. I guess we were promised a bill of goods with client rendering and as things were evolving.

I don't think we'll be able to please everyone, because if you think about 2015, we're barely coming into adoption of AWS and all these other places to host and all these other tooling. It's hard to look in the past and think of what we didn't have as far as ecosystem and infrastructure, and then take that lens today and be like, "Oh. Well, React is only just now figuring this out." But I don't know, it seems like patience could be the thing, but maybe the web moves too fast.

Nick: Yeah. Well, the other thing too, it's nice having meta-frameworks these days because I always used to be the person at a company that was configuring Web Pack for a React boilerplate project or something. These are things you don't even have to think about now. You can still, for example in Next.js, you can still tap into Web Pack if you need to, but generally there's no reason to unless you have some probably bespoke thing that you need to tweak or something.

But it's just nice having meta-frameworks. Like you said, the decision fatigue. I'm not a Rails dev but a lot of people like Rails because it is opinionated but it's consistent. I know we're not specifically talking about Redwood, but Redwood likes that idea as well so let's have a generator to, say, create a new component with all these things.

I think another thing that's interesting about the frameworks in general, including Next.js, is you're talking about, yeah, I just want to learn React now.

But the thing too is people have become more product engineers in some cases, people might say that's full stack or whatever, but I don't know if Lee Robertson coined it but I've heard him mention it before. I like that idea of a product engineer, and yes, you might be building stuff with React but you also have to be aware of how the web works now. You can still focus on literally just frontend, but a lot of times, for example at Open Sauce, I'm leading a lot of frontend stuff but I'm doing backend stuff as well, working on GitHub.

It's not just like, "Let's make nice things." It's a bunch of things and I think it's important going forward that people understand stuff. I think you were mentioning caching and all that stuff, these are things you have to be aware of now. Some of these things were magic before in some cases, for example, Next.js has this revalidate which I guess still looks a little bit like magic, but you can also tap into the actual caching mechanisms now and stuff.

Brian: Yeah. You just shipped a PR that magically removed two seconds of our initial page load, which literally we had a wait that was two seconds. But things like that, understanding the actual end user, the user of the product and their experience, and if you're building a feature it's not just about getting a component, adding Tailwind. It isn't about how do you get the data rendered in a timely fashion, but also make sure it's actually up to date and valid data, and we're now looking at stuff that could be, again, revalidated.

There's a fuller picture, and I think the challenge I've had, even in hiring or just working with folks at Open Sauce and contributing, is everyone wants to be a frontend engineer because that's what they went to the bootcamp for. But I'm always trying to push folks to think beyond just React components because it's one thing about working in the sandbox or in a design system and getting stuff to look pretty.

Sometimes you got to think through how it's going to work at the end of the day. I did want to wind down to picks, but I wanted to ask you the question of if you start a new project today, a product that's going to have users, what's the framework you choose?

Nick: This is kind of hard just because I've been working with all of them previously, but if I was in the React ecosystem I would definitely reach for Remix or Next.js probably right now. They're both really good options. It's kind of hard to say, it's kind of like, "Hey, Nick. Who's your favorite kid?" Just because I've been close to a lot of these projects. But there's really a lot of great options right now, but I think those are the two I'd probably go with right now. They're both very capable and, again, I'm talking specifically React ecosystem. Next.js is amazing if you're in the View ecosystem, for example. But, yeah, that's where I would probably head to. You can't go wrong with either, I don't think.

Brian: Cool. Excellent. Thanks for chatting about Next.js with me, Nick. I do want to transition us to picks, so these are things that we're jamming on, things that keep us going and that we're excited about. If you don't mind, I'll go first, and actually the first pick I'll have is actually Open Sauce API. API to OpenSauce.pizza. I love for folks to build stuff on top of it and validate that it's possible.

I know Becca has been working a lot on specifically the documentation of Open Sauce in general, but if folks want to help with actually building stuff in Open Sauce and helping in the docs there, definitely reach out. My DMs are open, and Hello@OpenSauce.pizza is our email. Second pick is going to be Reason for emails, Resend is basically a React email. React email came out of an engineer from Work OS, Xeno.

He is working on now a company to help send emails, and I remember working at Netlify years ago and leveraging things like Send Grid and Postmark. Send Grid, it's great when you're working in Jango or a Rails app, there's a lot of cool SDKs and Ruby Gems to help you get unblocked quickly. But when working in React applications or full stack Node apps, not as well thought through. Maybe it is today, but not when I was trying this eight years ago.

Then Postmark was the answer, to drop in some interaction to be able to have your email templates within an app, and then set up some weird build pack stuff inside of Heroku to make sure that these things get sent. Basically, what I'm getting at is there's a lot of options out there, Resend is the cleanest and it's been the nicest. I think it now has the opportunity of coming in so much later from all these other solutions and getting to say, "Okay, today at the time of 10:22, let's build a thing that looks great for modern web developers."

So they do have that advantage of being the last mover. But at Open Sauce we've been using Resend, we just sent out an email to a bunch of people. Apologize if it looked like spam, we're working on that. So yeah, we've been working on Resend for, at this point, the past year and it's been great.

Nick: Oh, that's awesome. I've got a couple picks, they're not necessarily all tech related. I work out in mornings, Monday, Wednesday, Friday, and everybody is sleeping still when I start working out so I have headphones when I'm working out and I'm doing it over Zoom with some people. I got a pair of Airpods and Beats Pro, they're all amazing, they sound amazing, I got a pair and I don't know what's up with my ears but I went for a walk, they were perfect.

I did one workout and they kept falling out and so I think my ears just need ear hooks. I found a pair, they're from Soundcore, they're Sport X10. They're a little older, but admittedly the sounds isn't as good as Beats or Airpods but it's still pretty decent and they never fall off my ears so a big fan. The other thing I want to shout out is I use it pretty much all the time, you probably see my PRs, I'm dropping images all the time or GIFs or short videos and Clean Shots are my go to for that. I'm a big fan of it.

Brian: Nice. Yeah, I definitely have been recommending Clean Shots. I've used it quite a bit for some examples, but I always go back into Max Screenshots and polish them up in some sort of quick editor. Also, I'll mention I use Power Beats because I can't use regular Airpods when working out or running or anything active.

Even just eating a sandwich, sometimes the Airpods just fall out because my jaw and ear moves, so I'm with you with the ear hooks. Definitely got to wear ear hooks. I will also mention, I've got one last pick which I'm just going to slide this in. I've been listening to a lot of Vince Staples recently. Vince Staples is a local Oakland rapper. I don't know if he's still out here in the Bay Area or if he's out in the suburbs or whatnot, but he had the North song that went big a couple years ago.

I did not realize how funny this guy is. He's been showing up in podcasts in interviews and he's just a hilarious guy. Someone was asking him if he does DoorDash and he's like, "No, I don't do DoorDash." And they asked him why, and he's like, "I don't want people to know where I live." Even DoorDash? But no, he's just hilarious and every situation is comedy for him, and it comes through in his music so Vince Staples. A more up and coming younger rapper out of Oakland.

I bring this up because someone had mentioned when I was actually at the, weird flex, the Warriors game last night when Treyvon was choking out Rudy Gobere, and all the music was basically all Oakland hiphop from the 90s and 2000s. Someone remarked, "Does Oakland not have any new music?" And I mentioned Vince Staples is from Oakland, so yes, but not a lot of folks knew that.

Nick: Cool, cool. Yeah, I'm going to pop it on my playlist on Spotify, give it a go.

Brian: All right, check it out. And thanks again for the chat.

Nick: Yeah. Thanks, everybody.

Brian: And folks, keep spreading the jam.