If an HR is rejecting Dev's based on if they are using built in mapping methods (which are not zero cost in JS btw.), said company needs a new HR. But, I do agree with the "you should make code readable" point.
map and filter on large data sets introduce noticeable slowdowns. While you may be an advocate for functional programming vs the imperative approach the correct answer is to know why you are using the tool not just to switch to it. While I love functional programming I refuse to use a method that is going to be slower than a boomer loop. While in your todo example it makes sense it will stop making sense if you ever work with a real dataset The rest of the video has a lot of good points. I would argue the "need" for typescript I prefer JSDoc to get types when I want them.
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. 🚀
3:30 By the end we have more than double lines than the initial "problematic" multiple useStates, cause not only we still have multiple state lines, to maintain the object readable, we also have the types and the utility function that was not needed in the first example
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.
"second mistake" doesn't look like one. After joining all field into one object, you introduce unnecessary object creation on every key press, and you create new instance of updateUserInfo function for every component rerender And then you use destructing to get data back from the state object, copying values once again
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?" (RUclips blocks links, so I can't send it directly)
What does imperative programming have to do with immutability, they aren't mutually exclusive concepts. Filter is fundamentally the exact same thing, but likely with extra steps and more memory overhead. classic web dev abstract away everything and wonder why we have no RAM left.
How someone with your skill level is allowed to review code is beyond my understanding. And you even attempt to teach others? Half of your examples are based on opinion. How can you expect anyone to know what your preferences are? This is just unacceptable.
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.
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.
This is the most react developer video ive ever seen
If an HR is rejecting Dev's based on if they are using built in mapping methods (which are not zero cost in JS btw.), said company needs a new HR.
But, I do agree with the "you should make code readable" point.
map and filter on large data sets introduce noticeable slowdowns. While you may be an advocate for functional programming vs the imperative approach the correct answer is to know why you are using the tool not just to switch to it. While I love functional programming I refuse to use a method that is going to be slower than a boomer loop. While in your todo example it makes sense it will stop making sense if you ever work with a real dataset
The rest of the video has a lot of good points. I would argue the "need" for typescript I prefer JSDoc to get types when I want them.
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. 🚀
You are filtering out the completeTodos but naming the output array as incompleteTodos.
Ah true, I named it the other way around. Nice catch
3:30 By the end we have more than double lines than the initial "problematic" multiple useStates, cause not only we still have multiple state lines, to maintain the object readable, we also have the types and the utility function that was not needed in the first example
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.
"second mistake" doesn't look like one. After joining all field into one object, you introduce unnecessary object creation on every key press, and you create new instance of updateUserInfo function for every component rerender
And then you use destructing to get data back from the state object, copying values once again
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?" (RUclips blocks links, so I can't send it directly)
More of this please
Will do! I'm glad you found it useful.
@tenacity_dev very
can you please cover react router as a framework approach.
I'll put that on my list for future videos
thank you !
Good video. Disagree with the typescript thing tho. Shouldnt judge people just for that if they build great stuff that works in js
i use javascript with jsdoc getting the best of tow worlds 😂😂
What does imperative programming have to do with immutability, they aren't mutually exclusive concepts. Filter is fundamentally the exact same thing, but likely with extra steps and more memory overhead. classic web dev abstract away everything and wonder why we have no RAM left.
How someone with your skill level is allowed to review code is beyond my understanding. And you even attempt to teach others? Half of your examples are based on opinion. How can you expect anyone to know what your preferences are? This is just unacceptable.
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.
duckaj karu pavijane
dont do the mistakes this video does - job winning tips for 2025
"If you use JavaScript in 2025 you should stop."
You should certainly stop giving that silly "advice". Good developers use both JS and TS.
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.
en.wikipedia.org/wiki/Higher-order_function