
Join the Conversation!
Subscribing gives you access to the comments so you can share your ideas, ask questions, and connect with others.
All the libraries we discussed earlier are popular and widely used, but then Next.js entered the scene—especially with Next.js.
By now, we know what Next.js does, what it’s about, and how it differs from previous versions or React.js in general.
If you guessed it, you’re right. Using those libraries or methods we discussed earlier in Next.js would turn your page or component into a client-side component. This goes against the core of Next.js and its server-side capabilities.
Transitioning everything to the client side in Next.js would essentially equate to using plain React.js.
Since Redux, Context API, Zustand, and others are all hook-based patterns, we can't use them on the server side, at least not for now. So, that's the issue.
💡 Why can’t we use Hooks on the server side?
React hooks rely on the component lifecycle, which is specific to the client-side rendering environment.
Hooks like useState, useEffect, or any other aren't available on the server because they interact with the DOM, which doesn't exist on the server.
However, you can simulate some hook behavior on the server using libraries like react-dom/server, but it's not the same as client-side hooks.
So what’s the solution to this problem? Is there even one? Or should we just stick to using these libraries whenever we want, without considering anything else? What should we do?
Yes, yes, we have answers to each one of them. It's not new; in fact, it's an old-school approach that most big companies have used, but it hasn't received the attention it deserves. It's pretty underrated.
What’s it?
"Please login to view comments"
Subscribing gives you access to the comments so you can share your ideas, ask questions, and connect with others.
How did you manage to remove the blur property and reach here?
Upgrading gives you access to quizzes so you can test your knowledge, track progress, and improve your skills.
By logging in, you'll unlock full access to this and other free tutorials on JSM Pro.
Why? Logging in lets us personalize your learning experience, track your progress, and keep you in the loop with new workshops, coding tips, and platform updates.
You'll also be the first to know about upcoming launches, events, and exclusive discounts.
No spam—just helpful content to level up your skills.
If that sounds fair, go ahead and log in to continue →
Enter your name and email to get instant access
##Looks like we found a thief monkey By the way, I liked the trick how you reached till here. You have a good sense of humor. You will improve a lot if you join our course with this passion.
var
(function-scoped, outdated)let
(block-scoped, modern and recommended)const
(block-scoped, cannot be reassigned)_
, or $
let let = 5;
is invalid)myVar
and myvar
are different)string
, number
, boolean
, null
, undefined
, bigint
, symbol
Objects
, Arrays
, Functions
Subscribing gives you access to a brief, insightful summary of each lecture to stay on track.
00:00:02 Now, we discussed many of the libraries in the last lesson, but which one will we actually use in our Next.js applications?
00:00:09 By now, you know that Next.js and specifically Next.js 15 is a bit different, and it allows us to approach state management in a completely new way.
00:00:19 So here's the thing, using those libraries or methods we discussed in the previous lesson in Next.js would turn your page or anything into a client-side component.
00:00:30 And that goes against what Next.js is all about and its server-side features.
00:00:35 Transitioning everything to the client-side in Next.js would essentially equate to using plain old React.
00:00:42 Since Redux, Context API, Zestand, and others are all hook-based patterns.
00:00:48 We can't use them on the server side.
00:00:51 At least not for now, so that's the issue.
00:00:53 And why can't we use the hooks on the server side?
00:00:56 Because they rely on component life cycles, which is specific to the client-side rendering environment.
00:01:02 you know that you cannot use useState, useEffect, or others.
00:01:06 In the same way, you cannot use useContext.
00:01:09 So, what's the solution to this problem?
00:01:11 Does it even exist?
00:01:13 Or should we just stick to using these libraries whenever we want, without considering that we'll be turning everything into a client-side mess?
00:01:20 What should we do?
00:01:21 Well, you'll be pleased to know that the answer to that question is not new.
00:01:26 It's an old-school approach that most big companies have used, but it hasn't received the attention it deserves.
00:01:33 It's pretty underrated, even though it's the fastest and the simplest.
00:01:39 Do you have any idea what is it?