Well imperative programming would be a for loop and inside of that loop you would mutate some data, that's exactly what we don't want. We want data to be immutable. We want const and not let keywords. So it has everything to do with immutability. We will loop over maybe one hundred values, why should I write ten lines of imperative and mutable code when I can just do it with a filter method which is more readable. Premature optimization is the root of all evil. When your app gets slow or when you have to iterate over ten thousand elements then you can think about expanding the implementation and making it faster.

It's more about using the right tools for the job rather than blindly using the most performant method. Performance is a whole other topic in Web.

So good engineers use prop drilling, reinvent the wheel for each problem, use no types, don't have a good file structure and conventions? These are not preferences.

The issue of function instance creation can be addressed using the useCallback hook. However, with the upcoming React compiler, this problem will be resolved automatically. Additionally, the problem can be solved with a form library, which I mentioned later in the video. The real mistake here is in overusing useState hooks and failing to group related data effectively which creates problems in the long run and unmaintainable code.

@@tenacity_dev even react docs mentioned splitting state into multiple useState hooks, check older documentation hooks FAQ, title "Should I use one or many state variables?" (KZbin blocks links, so I can't send it directly)

Ah true, I named it the other way around. Nice catch

There's a reason why companies, solo engineers and startups use Typescript. It's not because the logo is a different color. The benefits that Typescript provides are immense. JS can be used for small projects but for anything other than that it will give you headaches.

@@tenacity_dev Then why did you say "If you use JavaScript in 2025 you should stop."? Talk about saying one thing and meaning another. (And what a silly thing to say)

​@@jesse9996 Yes, you should switch to Typescript. If you haven't tried Typescript, go and try it, I'm sure you will love it and wouldn't want to go back and use plain JS anymore.

@tenacity_dev Your comment is laughable.

I agree, but for most use cases in modern apps it will not be needed to use for loops for the performance boost. What you just said comes from knowing the language and I fully agree that we should know the performance differences but readability and maintainability of the code is often times more important for modern apps than performance when looping over approximately one hundred objects max. If you are going to do a for loop, you can also do loop unrolling to save clock cycles but that just goes way out of scope for most web development. 🚀

I'll put that on my list for future videos

I see what you mean. But imagine that if that component grew and we needed to add more things. The example above would become unmaintainable because there would be no structure, lots of functions that are not reused and no typings.

It also might introduce unnecessary re-renders as when the object changes, all the components that rely on only one of the fields will re-render, even if the field content is the same. Then you have to use useReducer and make it even more complicated.

@@tenacity_dev I can only see it being useful for very short and strict typings. In your example an "address" is being mentioned. Would we use an internal "Address" type or create a new one? The address would be plain text or a structured object? In case of being a structured object, how many depth levels are we expecting to handle? And how complex would be the updating the state of a nested object of that depth? Collapsing data into a single state is not maintainable "by definition", aggregating them by its use can improve readability and maintainability in many cases

@@turculaurentiu91 There will always be a balance between performance and how easy it is to write the code. When building something maintainability and the ability to easily change the code will often times be more important than maximising the performance. Real performance issues slow down the app and block the main thread, this won't affect it unless we really put everything inside on useState, which no one recommends.

@@rodrigonovais9624 I mentioned that we should split the state into logical parts, the same goes with components. Now if you ask me if the user has an address and that address is not a primitive type and it has lots of other properties then that is just an out of the scope problem which has it's nuances.

Will do! I'm glad you found it useful.

@tenacity_dev very

To use FrankenPHP you should pull the FrankenPHP image instead of the php-fpm image that is used in the video and then just move the Laravel code to the FrankenPHP image. FrankenPHP comes with Caddy so you don't need any web server to act as a reverse proxy. If you want a video about it tell me and I'll put it in my backlog.

@@tenacity_dev yes, sorry to bother you. Your video will help me a lot.

​@@kinanditav4111 No problem, I'll try to make a quick video about FrankenPHP

@@tenacity_dev thanks a lot

Thank you! There is a separate API endpoint for refreshing the token, check dj rest auth documentation for more details.

Coming soon!

haha, thanks, I haven't posted it on Github, the entire code is all that's shown in the video.

You can use for example Vite with React or Remix, it's still React and you won't need to learn a new framework. Imagine this example, if you build something and 70% of the features of Next.js become obsolete. You will be using a framework with an overhead that is not needed. It's like using a car to somewhere that's one minute away. One factor that is also import is what you feel comfortable with, so if you feel comfortable with Next.js then use it, but it does not mean it's always the right choice.

Thank you!

Yes, they need dynamic data to load in for different sites, that's why that approach is better. I made this to show how simple it is to actually do these sort of things with URL swapping and cookie manipulation.

Love to hear that!

Very true

Thank you, it makes sense. Hmm, I'll think about what could be a good thumbnail for this video 🤔

It's working ig lol

Changed it!

@@tenacity_dev just curious what was the thumbnail before?

Will do!

Glad to hear that!

Thank you!!!

So it's a project management application, maybe something like Jira but with some AI integrations? I don't see a use case for SSR or really fast page loads or the need for the site to be indexed well. I presume that the clients will want their projects private and not seen by other people so I would not use Next.js there.

@@tenacity_dev yeah client wants a simple project management module, but they have other stuffs they want. In general, I don't think any dashboard which are behind login/authentication should go for NextJs. In fact, if its decoupled it will be lot easier to scale up/down based on load. I spent quite some time recently on NextJs and thats what I figured. But there are places where SSR can be really helpful. I really wish something like Remix are still around.

Hey, this video was made a while back, I'll probably create a new one talking about when to use which authentication method.

No it does not, Brave uses profiles which has similar functionality. You can have as many profiles as you want just like workspaces in Arc.

😊

Definitely interested

App router is the path that Vercel is taking and it has all the latest React features. Using the pages router is fine but migrating to App Router is recommended to use React's latest features.

A huge complaint about Vercel and Next.js is that the Vercel team is working with the React team. It leads to issues where the React team will align to Vercel's goals and it's a sure way to be accused of being uncompetitive or accused of doing shady stuff.

I agree, look on the bright side of it, you learned a great lesson for your next projects.

Yes I will, what tutorial would you like to see?

@tenacity_dev for example tanstack router or router v7 as framework approach as an alternative to NextJS

@tenacity_dev like router v7 framework approach.

​@@tenacity_dev Beginner guide for getting started on MERN stack or maybe regarding React

I agree

Hahahaha, well then split the app and set a reverse proxy to route the SSR needed pages to Next.js and the other ones to Vite app