Cooncidentally this is actually a pretty good article for people to get started with React haha.
I'm not sure if I would appreciate being asked these questions in an interview though... Answering these kind of higher level concepts is really difficult in a person-to-person conversation, if there's doubt about the candidates capabilities as a React developer it's better to give them a small assignment to see how they deal with prop drilling or a broken example that they need to fix/optimize by memoizing a value etc...
On the other hand these are also things that can be taught pretty quickly through code reviews, so if a company starts asking these kind of questions it's an indication that they're concerned about the wrong things.
That's only shows you know how to to use jsx not why react has implemented the features which it has this results in in dev's not knowing how things work means that when the next major update comes out the Dev in questions performance shall drop
What exactly are you talking about? Knowing how what things work? Knowing how the virtual dom works does not help you to write better performing code. The virtual dom is encapsulated in the React framework black box which is a black box for a reason. Unless you want to start working at React, there's no reason to increase your knowledge of what the virtual dom is and how it works, thats why you use React, to abstract that complexity for you, so you can focus on implementing business logic in the best way possible.
My examples would be that Understanding how the virtual react stores and updates state has a marked importance for performance accessibility and seo. That is what my main focus is and programming people to spit out JSX has also a recognised issue when it comes to just using libraries on top of dependencies or not considering the issues with purely client side rendering.
I completely agree that it is easy to teach JSX but understanding where and why it has emerged and the practicality of a framework built for Facebook is important and often overlooked. If you are down to using the is odd lib/ dependency and using bootstrap without purging or treeshaking why not just use a cms with plugins. It is often not right package for the job even though it works. You need to understand it quite deeply to make your own reactivity optimal abstraction aside.
For many use cases React has a great community but is very average while WordPress is excellent.
I hope this clarifies my position. A programmer should be able to look at patterns, recognise what they need and have a work flow that removes what they don't another reason I used WordPress as an example.
If the global [you] don't understand why your framework is widely used but just know how than can [you] really claim to be full stack. Coincidentally this has been discussed and dissected here although a quote about javascript in 2008 is quoting a different language the future was predicted unsurprisingly well.
The virtual DOM does not store and update state, React does. those state updates are reflected in the virtual DOM by React and then it decides which parts of the actual DOM need to be rerendered. The exact logic behind this is not relevant for any business logic that I've had to implement in the last 10 years.
A developer needs to recognize what the problem is they're trying to solve. React helps developers to solve a lot of problems that would previously take a lot more effort to solve, which is why it became a popular framework.
Comparing a CMS and a frontend framework is somewhat farfetched... There's good CMSes built on top of React or other modern frontend frameworks also. No need to stick with something archeic like Wordpress. And yes, if you have a simple use-case that doesnt require much custom business logic, you can use a CMS. Knowing how the virtual DOM works has no influence on that decision. The question is: "Is my data model simple enough that I can use a pre-built CMS, or is there so much custom business logic that I require something custom."
Full stack has nothing to do with what framework you use. Full stack is about knowing how to work on both frontend and backend code.
If your goal is to come up with your own framework thats better than React, sure then you can deep dive in how React is actually manipulation the virtual DOM internally. However this is not required knowledge to become a good developer. Knowing how to properly use the tools that you need, is what makes you a good developer. Similarly, a carpenter doesn't need to know what happens internally in a hammer when they use it to whack a nail, they just need to know how to whack properly. Unless the carpenter comes to the conclusion they can't find a proper hammer to do the job and decides to built their own hammer.
To clarify I mean updates as in literally as in FPS, ticks and reconciliation. Your hammer analogy is good, I was not referring to framework*s* though I was referring to React and it is fairly blunt :p. I have a lot of respect for the CRA team and how they have approached things. I will quickly say that a carpenter should know their tools.
Like I said if you have just been programmed in how to use JSX for React are you truly full-stack. Can you add the layers and sometimes complex workaround which are required (for instance when updating legacy versions -- I guess that's a rock to a hammer), or solve a mess of a modal window somebody hashed together years ago because React was the only option.
You need to understand how React works in order to justify using it for a lot of the small SPAs which it has been used for which have literally bloated the internet. I am not saying that React doesn't have use-cases, I am not saying React can't be SEO friendly but largely that is overlooked without additional plugins.
To me it feels like when a CS student first discovers bootstrap. They have a whole library of problems to cut corners and leave all the unnecessary functionality.
We have gone off topic. React is good enough because it is flexible, Solid is fast and considers virtual doms to be bloat, Svelte is loved for intuity and ingenuity, Ruby on Rails has a different kind of battle tested simplicity. Likewise Angular is the full package and extends the dom but is perceived as complex.
A dev wants the right tool for the job and there are plenty of good enough's out there. If you want reactivity from react you need some understanding of the virtual dom implimentation. I have thrown you some edge cases but programming is solving problems through automation and hammering out some JSX which misses a tick isn't that.
This reads like a long rant. There are some excellent devs out there who use react, there are less excellent react devs - I won't say they are unicorns but I will say they are limiting themselves.
Edit - had a quick snoop at some of your answers and liked the one where you are basically agreeing with my overall point
Edit 2 -- On revisit my first post wasn't clear 👍 I hope I have clarified a bit?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Cooncidentally this is actually a pretty good article for people to get started with React haha.
I'm not sure if I would appreciate being asked these questions in an interview though... Answering these kind of higher level concepts is really difficult in a person-to-person conversation, if there's doubt about the candidates capabilities as a React developer it's better to give them a small assignment to see how they deal with prop drilling or a broken example that they need to fix/optimize by memoizing a value etc...
On the other hand these are also things that can be taught pretty quickly through code reviews, so if a company starts asking these kind of questions it's an indication that they're concerned about the wrong things.
That's only shows you know how to to use jsx not why react has implemented the features which it has this results in in dev's not knowing how things work means that when the next major update comes out the Dev in questions performance shall drop
What exactly are you talking about? Knowing how what things work? Knowing how the virtual dom works does not help you to write better performing code. The virtual dom is encapsulated in the React framework black box which is a black box for a reason. Unless you want to start working at React, there's no reason to increase your knowledge of what the virtual dom is and how it works, thats why you use React, to abstract that complexity for you, so you can focus on implementing business logic in the best way possible.
My examples would be that Understanding how the virtual react stores and updates state has a marked importance for performance accessibility and seo. That is what my main focus is and programming people to spit out JSX has also a recognised issue when it comes to just using libraries on top of dependencies or not considering the issues with purely client side rendering.
I completely agree that it is easy to teach JSX but understanding where and why it has emerged and the practicality of a framework built for Facebook is important and often overlooked. If you are down to using the is odd lib/ dependency and using bootstrap without purging or treeshaking why not just use a cms with plugins. It is often not right package for the job even though it works. You need to understand it quite deeply to make your own reactivity optimal abstraction aside.
For many use cases React has a great community but is very average while WordPress is excellent.
I hope this clarifies my position. A programmer should be able to look at patterns, recognise what they need and have a work flow that removes what they don't another reason I used WordPress as an example.
If the global [you] don't understand why your framework is widely used but just know how than can [you] really claim to be full stack. Coincidentally this has been discussed and dissected here although a quote about javascript in 2008 is quoting a different language the future was predicted unsurprisingly well.
The virtual DOM does not store and update state, React does. those state updates are reflected in the virtual DOM by React and then it decides which parts of the actual DOM need to be rerendered. The exact logic behind this is not relevant for any business logic that I've had to implement in the last 10 years.
A developer needs to recognize what the problem is they're trying to solve. React helps developers to solve a lot of problems that would previously take a lot more effort to solve, which is why it became a popular framework.
Comparing a CMS and a frontend framework is somewhat farfetched... There's good CMSes built on top of React or other modern frontend frameworks also. No need to stick with something archeic like Wordpress. And yes, if you have a simple use-case that doesnt require much custom business logic, you can use a CMS. Knowing how the virtual DOM works has no influence on that decision. The question is: "Is my data model simple enough that I can use a pre-built CMS, or is there so much custom business logic that I require something custom."
Full stack has nothing to do with what framework you use. Full stack is about knowing how to work on both frontend and backend code.
If your goal is to come up with your own framework thats better than React, sure then you can deep dive in how React is actually manipulation the virtual DOM internally. However this is not required knowledge to become a good developer. Knowing how to properly use the tools that you need, is what makes you a good developer. Similarly, a carpenter doesn't need to know what happens internally in a hammer when they use it to whack a nail, they just need to know how to whack properly. Unless the carpenter comes to the conclusion they can't find a proper hammer to do the job and decides to built their own hammer.
To clarify I mean updates as in literally as in FPS, ticks and reconciliation. Your hammer analogy is good, I was not referring to framework*s* though I was referring to React and it is fairly blunt :p. I have a lot of respect for the CRA team and how they have approached things. I will quickly say that a carpenter should know their tools.
Like I said if you have just been programmed in how to use JSX for React are you truly full-stack. Can you add the layers and sometimes complex workaround which are required (for instance when updating legacy versions -- I guess that's a rock to a hammer), or solve a mess of a modal window somebody hashed together years ago because React was the only option.
You need to understand how React works in order to justify using it for a lot of the small SPAs which it has been used for which have literally bloated the internet. I am not saying that React doesn't have use-cases, I am not saying React can't be SEO friendly but largely that is overlooked without additional plugins.
To me it feels like when a CS student first discovers bootstrap. They have a whole library of problems to cut corners and leave all the unnecessary functionality.
We have gone off topic. React is good enough because it is flexible, Solid is fast and considers virtual doms to be bloat, Svelte is loved for intuity and ingenuity, Ruby on Rails has a different kind of battle tested simplicity. Likewise Angular is the full package and extends the dom but is perceived as complex.
A dev wants the right tool for the job and there are plenty of good enough's out there. If you want reactivity from react you need some understanding of the virtual dom implimentation. I have thrown you some edge cases but programming is solving problems through automation and hammering out some JSX which misses a tick isn't that.
This reads like a long rant. There are some excellent devs out there who use react, there are less excellent react devs - I won't say they are unicorns but I will say they are limiting themselves.
Edit - had a quick snoop at some of your answers and liked the one where you are basically agreeing with my overall point
Edit 2 -- On revisit my first post wasn't clear 👍 I hope I have clarified a bit?