Course Q&A

[00:00:00]
>> Speaker 1: With Next's new emphasis on React server components, is there a new suggestion for full stack JS frameworks that can work with an already built API? Or would the suggestion be using lots of use client and not really taking advantage of RSCs throughout the app?
>> Brian Holt: Yep, it's a good question.

[00:00:23]
So if you have a very client-heavy app and RSCs are not really solving a problem for you, then what do you do? Well, a couple suggestions. You can use Next in a way that doesn't have RSCs as much, but you're gonna run into exactly what you're saying. My suggestion is look either at Remix/React Router 7 or TanStack Start.

[00:00:51]
Remix already being stable and TanStack Start. I mean, I don't know when he's gonna GA, but it's soon, I think. I know 1.0 is coming very, very soon. Maybe by the time that this is viewable on the stream, that TanStack Start will be stable. My very biased, very personal opinion here is, I like TanStack Start.

[00:01:11]
I like Tanner's approach to building all these things. SolidStart is already out there for SolidJS, and those are kind of converging technologies, and I like SolidStart. I like the choices they made there. I like the client-first approach with a light sprinkling of server, as opposed to server-first and then a light sprinkling of client.

[00:01:31]
So all that to say, your two best bets are gonna be either Remix or TanStack Start. And that's really just gonna be your opinion of which one you like better. They're both extremely valid opinions to hold.
>> Speaker 1: Any tips for self-hosting Next.js? Is it available or is it just better to stay with Vercel?

[00:01:53]
>> Brian Holt: It's totally available. Any tips, you just run it like a Node service, to be really honest with you. You lose some of that. They build Next intentionally so that it works better on their infrastructure. Again, it's part them just saying, what can we do even better? And it's part just product thinking of, how do we keep a captive audience?

[00:02:17]
All that to say, it's not any harder to host than any other Node service. Do I have any special, no, just whatever you would do with the normal Node service, you'll do with Next.js. Plenty of people do it, by the way.
>> Speaker 1: Any suggestions on how to write tests for use deferred value and use transition with something like React Testing Library?

[00:02:45]
>> Brian Holt: That's a good question, I haven't tested the core function at those functions. This would be one of the things, you'd be really tempted to test the framework, right? Where you're saying, if I do this it, is it deferred? And don't do that. React has its own suite of tests.

[00:03:06]
The test does use deferred value do what it does. The way I would approach this would be much more from a user-centric perspective of, what am I expecting the user to experience, right? So if a user does this action, is the immediate action correct, and does it reconcile eventually to the correct state?

[00:03:26]
If you approach it that way, then you're actually going to be serving your users, as opposed to just testing what React already tests itself to do. I don't know if I have more specific advice to that.
>> Speaker 1: Do you have any suggestions on building a career in React?

[00:03:41]
Should we focus on Next.js, or Remix, or any other framework?
>> Brian Holt: That's a good question.
>> Brian Holt: So having done a decent amount of hiring over the years, particularly of junior developers, the thing that impressed me most were people that had some project that they were really passionate about.

[00:04:08]
They went super deep on it, and they learned a bunch of stuff, and I'll give you an example. When I hired someone at Reddit, I probably had 600 resumes that came in for one person. We probably narrowed it down to 30 interview people, and the person that I hired didn't have the most experience, didn't have the widest breadth of technologies.

[00:04:33]
And actually, probably most interesting to you all is that his experience didn't match the stack that I was hiring for. But he was, first of all, smart, and then his experiences, GitHub showed that he had built this an entire, I think it was Rails. I really don't remember, but mismatched to the Python Django at the time, so React stack at that point.

[00:04:58]
And I was really impressed by the depth and the passion that he had come at with those things. And he had gone really deep on these technologies. And so throwing him at Python and Django and React was easy because he applied that same tenacity and that interest to learning the stack that we needed him to learn.

[00:05:21]
And ended up being a phenomenal hire, one of the best hires I've probably ever made. So really, my answer is, I don't think I really care as a hiring manager, did you pick Next or did you pick Remix? If you're picking for just the most generally applicable, it's gonna be Next, cuz Next is just getting shipped a lot more than the other ones.

[00:05:43]
But if I'm your hiring manager, I don't care, right? I would much rather see a phenomenal Remix app than a crappy Next one. So my general advice to just junior developers in general is follow what just gets you excited about code and just go real deep. Just do as much as you can and ship something.

[00:06:04]
Don't take me to 75% the fun part and then don't ship the last 25%. Actually ship things. You learn so much in the hard parts of shipping things. And that's where I get really impressed. If I can go onto your GitHub, see that you have this one Repo, and I don't care how many stars it has, it just means that's marketing.

[00:06:24]
But if I can download it, if I can npm install, and if I can see this app running, and I'm impressed by it, that's gonna count for a ton more points. So I know that's kind of a sidestepping answer as well, but just go deep, be interested, be passionate, follow what makes you interested in something.

[00:06:43]
And I think you'll end up with something more important than you did Remix versus you did Next.
>> Speaker 1: Any suggestions how to approach full text search on statically generated sites?
>> Brian Holt: Full text search, that's gonna depend on your application. If you really need to do it in a browser, that's gonna carry its own set of interesting problems.

[00:07:15]
There's plenty of libraries out there of people that have thought through this that you could use as well. But I mean, you're asking the Postgres guy, do you have a Postgres-shaped problem? And my answer is always going to be yes because Postgres does everything, right? So yes, by all means, Elasticsearch or any one of those will work just fine, or Pinecone or something like that.

[00:07:40]
But my opinion, I just use Postgres for everything these days. So I would probably just rely on Postgres, and then if you're doing vector search or something like that, then PGVector or PG RAG or something like that. Otherwise, you can get some other off-the-shelf service that sits on top, like Solr or Elasticsearch or something like that.

[00:08:09]
>> Speaker 1: When managing server-side versus client-side components, any recommend patterns for large scale projects? Like how to build things so that changing a component from the server side to client side and vice versa doesn't have a domino effect?
>> Brian Holt: In reality, I don't find myself really changing my components that frequently.

[00:08:31]
Generally, if I write an RSC, it doesn't later become a client-side component. And I kind of alluded this early to when we were speaking about it earlier in the course. But you find yourself pushing client state further and further down the tree so that you don't have to make the client components.

[00:09:01]
So I guess my advice there is, one, it doesn't seem to happen to me very much, just by virtue of the way I structure my next steps. Secondly, the thing that you do is you just push your client code as far down as you can. And then thirdly, don't fear client-side code.

[00:09:19]
It's not like it's a big, huge, ugly beast. When it does happen, I guess when it does happen, you're just gonna have to refactor your code to handle that. But I don't know, it's not something that I find myself running into, so it's not something I really fear, or it's not something I really prepare my code for very frequently.

[00:09:45]
>> Brian Holt: Usually, there's a clear divide, this definitely should be a React server component cuz it reads from the database. And this is accepting user input, so it definitely should be a client one. And the amount of middle ground of this could be either is usually quite small.