1. What is the React Virtual DOM?
Virtual DOM is a concept where a virtual representation of the real DOM is kept inside the memory and ...
For further actions, you may consider blocking this person and/or reporting abuse
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?
Agreed.
Cool article tho!
Oh this is so good for beginners! Very concise and well put together šš¼
Nice compilation, thanks
THX for that.
I appreciate you spending your precious time to write down such lengthy thoughts!
Best!
I want to work with this guy! š
I've also done my fair share of technical interviews, and it doesn't matter if they know what a Portal is, because they can always go read the documentation and learn it in a couple of minutes.
I'm always wary of people with this attitude. The thing is its hard to find strong engineers. If you are an engineer lacking knowledge in these areas then its possible that you will not be able to contribute at the same level as someone who does. You don't need to use this knowledge day-in-day-out, but when tricky problems come up, you should be able to easily know what options you have for solving them.
To use the same car driver anology. Yes, to be a good driver, you don't need to know the composition of oil. But if your car breaks down, are you going to have the skills to fix it? Or will you need to hire a mechanic? Maybe you can spend 5 hours googling what the car is doing with the oil you are putting in to maybe understand what is going wrong.
Point is, if you are going to use a tool, as an engineer, you can probably go far knowing the bare minimum (how to drive), until you are working on complex systems that rely on the core functionality of those tools; if you don't know anything beyond the bare minimum, there's going to be a limit to how much you can help.
And specifically speaking about React, the react core is REALLY small, so expecting that engineers know many of these topics mentioned in this blog is not outragous.
But even if you don't know the answer to these questions, you should be able to participate in a conversation about these things, which is what the interviews should be ultimately. If you see these questions as a red flag, honestly I think you as a candidate are a red flag -- it just shows that have no interest in having a deep understanding of the tools you use daily, and/or you are not a great communicator (not able to have conversations about things you don't know about). I'm not speaking in behalf of all interviewers here, but myself, as someone who carries out interviews as a conversation more so than a test.
Also, In my opinion, the culture of "I'll google it when I need it" leads to many engineers building sub-optimal solutions, (not just in terms of performance, but speaking generally), and many times, code that is coppied-and-pasted from blogs or stack overflow without the author thinking critically about what is needed and not needed for their specific problem. Ultimately this is what interviewing is about for me. Getting indicators that the candidate has the ability to think for himself and solve a problem using (hopefully) a wide range of technical skills in their respective area. And there just isn't a way around that other than making them solve some problems and start conversations about these topics.
Lastly I'll say, the reason why I'm so moved by this is that it does no good to encourage people to not spend the time learning these things. By learning these things, they are able to contribute at a higher-level than someone who doesn't, and can become a better asset for their teams. Is your opinion that this may be a red flag, but in my opinion, it only HELPS to spend time learning these things, if you are planning to work with React daily.
Most of these questions are pretty vague and honestly do not seem like "absolutely should know" questions.
Like StrictMode is definitely useful but to consider it a must-know for a React job interview is a little silly IMO.
I agree with much of what you said I think I misunderstood your stance. But I didn't appreciate your tone which seemed a bit condescending (at times) š
I agree, interviews should not be carried out like exams with close ended questions, but there's nothing wrong with digging into these topics in an interview. I think its totally fair to ask someone to explain their mental model for understanding what react does, it doesn't have to be a text book definition, but I think its completely reasonable to expect that developers have SOME mental model for what react is doing under the hood, and asking them to explain that is reasonable in my opinion.
Also, on the topic of googling, OBVIOUSLY every engineer googles things, like API documentation, common approaches for a given problem etc. Research is part of the job. But also is internalizing the research and making a decision on what you are going to do. What I was speaking about was about a breed of developers that google then copy and paste solutions without thinking critically about the code they are committing. My opinion (and one of my points) is that this group of developers overlap with the developers that do not take the time to learn the fundamentals of the technologies they work with (like virtual dom, and core react APIs if you work with react). I was projecting an assumption -- I may be wrong, but I've seen this correlation before.
Advanced??? Really. All of these are basic concepts, good for beginners.