It seems like it's a non-effective way of doing it. In large DOM trees you need to manually interfere to make them update fast because (1) building even the virtual DOM and (2) then comparing this to the real DOM become slow => i.e the "React way" doesn't actually scale. Perhaps for a product guy this doesn't matter, but for an engineer it just feels wrong. Why not solve the real problem?
Because the real DOM exists in a separate world where you have to cross a trust boundary. The vdom is an implementation detail of React because the real DOM is too slow to traverse to diff on every render. Think of it like this.. jquery is a wrapper around a querying API, so it’s like running a sql query that can be indexed in a b-tree or a hash map, because you query by id or class or some other attribute. React on the other hand needs the entire state, which is equivalent to a select *.
If you say why does react need the whole state, it’s because React is a translation layer between an immediate mode representation and a retained mode system (the DOM). To illustrate this in a basic way, think of a checkbox. It is an entity in the DOM, but it is also retaining state itself (there is a Checked property that persists as long as it is set, so you know it has state). The only way to know if that checkbox is checked or not is to query the DOM to get the checkbox entity, or to “control” the rendering of the component so you can always derive the checked state from somewhere in your code, and force its state to match. React controlled components are a way to express unidirectional state from your code to the UI.
What situation were you in where vdom was the problem? I’d love to see an example. It is likely that vdom was not the performance issue, something was wrong with the implementation and causing a full re-render. Could you link a sandbox?
I understand why it's convenient to derive the UI from the state, no need to explain that.
But what react does is: for any change in state it creates the entire virtual DOM" regardless of if there was a single checkbox change and everything else remained the same. Then it compares this whole tree* to the real DOM, and then only replaces the parts that changed. The "win" of react is that instead of rendering the entire real DOM again and again it just renders something that is not seen and then swaps out the changed parts in the real DOM.
Why not short-circuit from changes in state to real DOM instead?
I think any google sheet like app would do: you type into some box, this changes state which triggers the creation of the virtual DOM for the entire sheet. Then it compares this entire sheet to the real DOM, finds that only one cell has changed and swaps that out. There will be one entire virtual DOM per character typed. Which is why I'd presume most if not all such applications need to add custom code (using `shouldComponentUpdate`) to fix this scaling issue.
> (1) I have no leaks and (2) I don't know how to create them -- These don't really square with each other.
If he runs his service for a long time and the memory usage doesn't keep growing, no resource exhaustion problem occurs, then he can reasonably say he has no leaks. At least, he has no significant leaks.
I don't have to know how to create nuclear bomb to know I don't have one.
While I agree with not "blaming" people for the mistake as if it's their fault as a person. I disagree with all of his reasoning and the action he choose not to do in this case.
I also take the position of "criticizing the idea/code, not the people" when it comes to other people's work. I rarely have a problem with criticizing myself.
Especially when it comes to "your" own code. You should be able to apologize for your mistake.
> It reinforces the idea that any one person or piece of code can be blamed for a given failure. Short of malice, this is never the case.
You can be attributed to your action. If you can be attributed to the good things in your work, then you can be attributed to bugs. Unless you are claiming that you have no control what so ever about how your code turns out, at which point, what are the different from you and a typewriter?
The thing is, you can be attributed for an instance of error. You can be blamed for the error you did. But you should never be categories as "the error".
> It gives the impression that, when you wrote the code, you should have written it better. This is a counterfactual that rarely holds up to examination.
Yes. There are instances that I could have written it better.
> It positions shame as the correct emotion to feel about bugs in your code: if you were a better engineer – a better teammate – the bug wouldn’t exist.
> If you’re a more senior engineer on your team, the effects of these anti-patterns are magnified: people see you apologizing for bugs, so they think that they should be striving to write bug-free code. They may feel ashamed if their code has bugs.
I take the approach and culture of "be strict with yourself but be kind to others". When I talks about other people's bug I always criticize the bugs itself and talks about problem and process in general without tying it to them. But when I talked about my code, I will also express what I could have done better or what is the pros and cons of my coding decision.
The thing is there's different between people striving to better themselves, and people blaming others for not being better.
You should strive to be better, while at the same times not being a snob or looking down on other for not being perfect.
In every day's life there's no permanently good people or bad people. There's bad action that people do. You should still be able to attribute a certain instance of event to a person. You just don't have to hold grudge and judge them forever based on it.
I am probably reaching it here, but I feel that the author is the kind of person that can't take criticism of his idea well because he feel that his idea is himself.
Your idea and action is yours. But your idea and action is not who you are. If you think it is yourself, then you become blindly defensive and either never acknowledge that you did it, like the author did, or never change.
You can use HTTP client to contact any HTTP compatible service. You can only use Kafka client to connect to Kafka.
That sounds like a tautology but it's practical.
There is way higher chance that you can make any of your future service response speak HTTP, than all of them speaking Kafka. If you add HTTP client libs today, there's higher chance of reuse than adding Kafka libs.
That reminds me of the villian robot in I, Robot movie. They don't want to harm human, they just want to keep them in the house, so that there is less crime, and less people die.
It may take away freedom. But freedom should not be a reason to trade lives.
Some may say the playground is about happiness, some may say it's about the freedom to experience.
One day React could change from using Virtual Dom to the Svelte way and most user of library wouldn't notice.
The point of the article is that React remember where to make the modification for you.