>> Scott Moss: Any other questions?
>> Speaker 2: Are you able to use client in a layout,
or are there any reasons you'd want to use that in a layout?
>> Scott Moss: Yes, you can totally use client in a layout, and yes,
there are reasons you want to use client in a layout.
And the biggest reason I can think of is providers.
If you have to add providers to your app, which most React apps do,
a lot of those providers have to be client-based cuz they pass down states and
context, then you typically do a use client for that.
So yeah, you can do a use client in a layout, and you will probably do it a lot.
You can also push that down and have the providers be its own component,
that's a use client, and then import that into the server component layout so
that way the layout itself is still a server component.
And again, I think the Vercel team calls that the donut architecture,
where it's a server component on the outside and
then the donut hole is just stuff with client components.
>> Speaker 2: Do you have any favorite third-party libraries that you use with
your Next.js apps?
>> Scott Moss: It's a great question, like I said yesterday,
I don't really use any component libraries at all.
Actually, I don't know how to describe this, but
I use a lot of this stuff, so Magic UI is a really good one.
I use a lot of this, this is really cool stuff.
Aceternity UI is also another one just like it, this is for
design engineering stuff.
It's really cool, and then what is the other one?
Yeah, UIverse is also really cool, you can go on here and
get inspired and see different components that people have made.
I like to go look at the challenges.
This is a good one.
So they have to take this design and make it with just CSS and
JavaScript, these buttons.
This one's really cool, this one won first place, that's pretty good.
Yeah, and you can look at the code, so it's really fun.
So I'll look at a lot of this stuff, but yeah,
those two projects, Aceternity, Magic UI.
And then 21st.dev, which is a collection of all of them, is also really good.
You can go on here and get some really cool stuff.
The reason I like this one is because I was telling somebody earlier, 80% of
the stuff that I make, I don't write code for anymore, I just have AI do it.
And this right here makes it easy to have AI do it for you, cuz for instance,
let's say I want this, I can click on this.
I can click on Copy prompt, and it'll give me a prompt to give Cursor,
and then Cursor will just make it.
Yeah, we're in the new generation, [LAUGH].
We got a lot of different ways to make stuff.
Or you can just copy the code yourself if you want,
you can even customize the prompts.
If you're using V0 or one of these things,
you can send the prompt there, so it's pretty cool.
I really like this project, 21st.dev, and
you can pretty much use all this stuff for your site.
So that's about it, everything else I just use Tailwind.
I use V0 a lot, but not for anything in production, V0 is like Figma to me now.
So I'll go on Dribbble or I'll go on Mobbin, and
I'll get inspired by some screens, and
I'll take these screens and I'll go upload them to V0.
I'm like, here's a screenshot of a thing that I like,
here's what I need you to change, here's a screenshot of my app, make the changes.
And after talking with that for 30 minutes,
it'll finally make the thing that I want.
I can use that code, probably won't, but I'll take the screenshot of it.
And then I'll take that to Cursor and
then I'll work with Cursor to make a PRD describing the thing that I want.
Then I'll take that instruction with the screenshot and
then I'll feed it back to Cursor and I'll say, make that.
And then it'll usually get there 90% of the time, so super simple.
But that's it, that's pretty much my stack, I think with AI now,
I feel like I don't need a component library.
It's almost slower to do it, so yeah, this is pretty much how I work now.
What else do I use?
I use a lot of AI tools, so that's nothing to do with Next.js, but
I do use tons of AI tools to get stuff done.
But yeah, these are my favorite things that I use all the time.
I like Upstash, Upstash is really cool.
Upstash, gotta give a shout-out to them, they're really great.
They do a lot of things, but the thing I use them the most for was workflows,
which is something that works very well with serverless.
They have workflows which are really good, but honestly,
we've been using Trigger.dev, which is a really great company as well.
I love these guys to do our workflows for us, our background jobs,
which is something that we absolutely have to do.
There's another one that we use that's pretty good, it's called Ingest,
they're also pretty good, we use these folks before too.
I mean, they're all really good, they have different trade-offs and stuff.
Trigger is the one we chose, but any one of these is really great for
doing serverless.
And you need to do something in the background like processing this,
something on interval, something on schedule, AI, retrying, handling webhooks.
Anything like that, you wanna use one of these tools.
So yeah, been doing a lot of that, and yeah, I think that's it.
I can't think of anything else that I use, other than Neon, I love Neon.
Yeah, that's it.
>> Speaker 2: I feel like I can't find it anymore, maybe the docks changed,
but I feel like not too long in the past,
I saw something in the next docks about SPA mode.
>> Scott Moss: Yeah, so that's called static exports,
this would be the SPA mode.
>> Speaker 3: Okay.
>> Scott Moss: So if you do a static export, excuse me,
you could do output export, it's just gonna give you single-page app
you would have gotten from Create React App essentially.
If you just wanna make a pure SPA,
I can upload this to a CDN, no server-side, anything.
Yeah, you could just export it like this, and
it'll give you that as a single-page application.
So it says right here it can be deployed and
hosted on any web server that can serve these files.
So if that's what you want, you could do that.
>> Speaker 3: Yeah, I was just gonna ask, do you ever see a use case for
that type of thing or any benefits using this over a Vite?
>> Scott Moss: That's a great question.
I mean, yes, I still see the benefit,
because even if you use something like Vite, at the end of the day,
you're still at the mercy of which router framework are you gonna use,
and then writing that code for the router and things like that.
So you still have to come up with some opinions.
You rather adopt somebody's opinions at some point,
whether it's the new TanStack router or React Router or whatever router you want.
You still gotta adopt those opinions, you still gotta adopt the opinions on styling,
how are you gonna do styling?
Is it gonna be CSS and JS, things like that,
Vite has plugins to handle styles differently.
So there's still a little bit of configuration there, whereas with Next.js,
it's done, you just make the file, you don't have to do anything.
So it's just a trade-off, it's like do you wanna configure that stuff
yourself if you want more control or do you just want to say export?
>> Speaker 3: And then you might know more about this, but
I assume that using this would break the site up more,
chunk it better as far as what asset's going
to the client, the JS, HTML, and CSS,
whereas maybe Vite might just bundle it all into one.
>> Speaker 2: Yeah, I mean, I think it does more out of the box for you cuz each
of your routes gets its own index.html and then things get split that way.
We have it set up with our app at work, we do a lot of code splitting just via
suspense and lazy loading with React, but it would be easier to just let Next do it.
>> Scott Moss: Yeah, it's definitely easy to have the bundles split on the route
done for you automatically without having to do it dynamically.
So that's probably another big thing as well.
I mean, you could do it with Vite, but you probably have to set it up or
rely on someone to make a plugin for you or something.
>> Speaker 2: Yeah.
Yeah. We were doing it at work,
I was doing React Router stuff, and at a certain point, I'm building this and
Next did it way better than me, so why?
>> Scott Moss: Exactly. [LAUGH] Why [INAUDIBLE].
Exactly, yeah.
And that's kinda the point I am in my career,
is just I wanna limit the amount of time that I spend on nonbusiness logic code.
If I'm not working on business logic, I feel like I'm wasting time.
So that's like build tools, performance, I don't wanna do any of that.
I just want something to do that for me so
I can focus on the thing that actually makes my app, which is the business logic.
The actual features, the value, the UI, the things that people are here to use.
No one's gonna use my app and like,
I use his app because he uses Turbopack, and I'm a big fan.
Nobody's using my app because I use Turbopack.
I don't care, I just want it to work very well and fast so
I can focus on the thing that makes my app unique.
So I will always lean towards tools that do that for me and
hope that there are a bunch of people smarter than me whose job
is to make sure that this is good, are doing their job.
And I'll just do my job, which is building a really cool app, so.
>> Speaker 4: So if you use, for example, this type of export and
you have a server actions in your application with Next output.
The client file static, and then you will get
the server files in a separate output directory.
>> Scott Moss: So you'll get what?
So even if you didn't do this, the way it works when your app gets bundled,
it's two module bundles.
Well, there's more than one bundle, but just think of two different types of
bundles, there's a client modules and then a server modules.
If you import a function into a server component,
a function that's running on the server, that doesn't get bundled anyway.
Even before this export, it never gets bundled into the client.
So they're not really changing anything on that part, you just won't see
a server module bundle, you just won't get that because where are you gonna put it?
You can only deploy the static site.
So essentially, it's gonna turn those server components that you had that were
fetching data into dynamic, I'm sorry, into static components, and
they would have tried to have pre-rendered them.
So while it was building and doing this export, it's gonna execute your
server component, try to get the data, and render it statically, right?
And then that's what you're gonna get for the client-side stuff.
I don't know what they call it, but it's when the server hydrates the client,
they're gonna put that in an object that they attach to the window.
So when your client loads up, you'll just have that data there,
which is a very common pattern.
So yeah, it will completely ignore server stuff.