Comment by jl2718
4 years ago
I read this and still have no idea what the ‘memoized DOM’ is. There is a broken link to ‘how it really works’. Apparently there is a huge speed-up over react. I don’t actually care about this; I’d rather know what the slow parts of browser DOM changes are, and how it gets around them.
Forgive my ignorance if I’m missing something obvious; I am completely new to JavaScript, but so far have found react/vue/etc confusing, outdated, and unnecessary for my performance needs, versus going raw with the latest features. It sounds like I might be missing something that could hurt me down the line. Thanks.
(Disclaimer: I'm the author of Mithril.js)
I looked at this a few years ago and IIRC, it refers to a very specific optimization for recycling DOM nodes in very specific cases. Recycling basically just means reusing pre-existing DOM subtrees instead of naively creating new ones. To my knowledge, Inferno.js and Mithril.js implemented a similar optimization but eventually dropped it because it was difficult to compute when the optimization could be applied and it wasn't worth the complexity (when using virtual dom anyways; my understanding is that imba doesn't do virtual dom)
I recall Imba always had quite nice perf numbers. Recycling DOM nodes did indeed give huge performance increases in synthetic proofs of concepts I did for Mithril.js. A good real world example where it's supposed to shine is tabular data: typically you'd key your rows to get good array diff performance, but this means paginating recreates the entire table from scratch every time. Recycling means reusing the existing DOM instead of re-incurring document.createElement call overheads for the entire table. Of course, in practice it's quite a bit more difficult to deal with edge cases (e.g. DOM state such as element focus)
The two things that I thought were problematic with Imba were a) lack of typing (which has since been addressed) and b) compiled output readability (i.e. it looks nothing like source code). It looks very nice otherwise, and it has come a long way since 7 years ago.
Most frontend frameworks are not created to solve performance of vanilla web applications, but rather to make engineering larger and complex applications easier.
Your comment reminds of the Facebook blog complaining that Apple couldn't handle their app's scale, and that's why it was so slow.
Most "larger and complex [frontend/client] applications" don't need to be as large and complex. By "most" I mean "almost all." In fact, I can't think of a single web application or mobile app I've used that can justify all the terribly complex garbage that goes into many of them.
The complexity of many applications does not come from the client-facing features but rather from other business requirements.
For example, interaction analytics, A/B testing support, targeted updates, predictive caching, obfuscation and security, etc. For large companies, setting up the code base so new junior employees can start making contributions fast is also important and that adds to the total complexity too.
It's so much simpler to build an app if all you needed to do is get the minimum features done.
3 replies →
I learned React to know what it was about and what people were talking about. I think a lot of people get the wrong idea about React. They say the virtual DOM is the most important feature, but I think it's actually the fact that it forces you to componentize your code. And it does this by making non-componentized code very painful to work with, so you have to componentize to be able to have any shot at getting React to work.
But if you already have the componentization mindset, I don't think React really adds anything. As you have said, managing raw DOM operations can be significantly faster. And because you have componentized your code, they are significantly easier to reason about.
The only problem is that working with a medium-sized smash of code is not as painful in vanilla JS as it is in React. So if you've grown your application over time, adding bits and bobs to it piecemeal, you're likely to end up with an application structure that is inherently difficult to manage. Then folks rewrite in React, get forced to componentize, and lo-and-behold, everything is much easier to manage.
At this point, whatever gets you there, gets you there, I guess. Personally, I make VR applications that run in the browser, so I coveteth performance.
Modularity or componentization as you call it (I like that! :P) is definitely one of React's main advantages. But I'd say just as important is that it acts as a trojan horse, essentially, to get people using the "good parts" of functional programming without having to understand FP deeply.
Just like React encourages components, it also encourages immutable data, one-way data flow, functional reactivity, and thinking in terms of state machines, even if you aren't necessarily familiar with that terminology.
All this stuff makes building a complex UI far more manageable and helps to avoid common pitfalls.
> They say the virtual DOM is the most important feature
Who says that now? I mean, in recent years VDOM seems to be more often criticized as the problem (with performance, but also otherwise) with React, even by people who like its basic dev-facing structure. Which is why you see frameworks with JSX and React-like structure (even Hooks, but without the explicit dependency pain point in the case of Solidjs) whose key selling point is no VDOM.
"I know almost nothing about the subject at hand, so here's my expert opinion on it"
I've been a software developer for 20 years. I've been doing JavaScript since it was invented. I do actually know a lot about these things.
4 replies →
I like the components. I do not like having to do everything through a JSX template. I do not like debugging through a transpiler. I do not like testing a DOM tree I didn’t build.
Just my novice view.
You're going to struggle as a novice if you're quick to form opinions about things that you don't fully understand, especially if those opinions involve rejecting wildly popular tools used by people with far more expertise than you have.
People who understand React/Vue/Angular are free to criticize them (and have many valid reasons for doing so), but when you do it after following a beginner tutorial or two, you're just being ignorant.
How do I know this? Because you're criticizing React for forcing you to "do everything through a JSX template" and "debugging through a transpiler", which tells me that you aren't aware that React can be used without JSX and without any transpiling.
Since that information is available to you on about the fourth paragraph of the "Getting Started" page on reactjs.org, you clearly haven't bothered to learn much about it at all.
> I do not like testing a DOM tree I didn’t build.
What does this mean?