Hacker News Reader

Comment by jl2718 | Hacker News Reader

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.

View on HN

(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.

Yeah, not really. I've worked at some big companies, and currently at one you almost certainly have heard about in the news. The features you describe don't justify the complexity of these apps. Usually these features are implemented without any real consideration for the overall architecture, independently, and within a bubble such that the engineers and PMs on the project locally maximize the feature's complexity. Then it cascades when the feature is integrated into the rest of the app.

I think we differ in what we consider "justification." It seems to me that you are using the moral judgement of the sacrifice of perfect-pretty-code while I am considering the business-operations evaluation.

For a company which needs teams to implement features independently, the bubble you judge to be negative could indeed be an acceptable, or even necessary, compromise. The business decision to have independent teams might introduce complexity, sure, but within the context of the company's needs and goals, it might be a good choice and thus the added complexity is justified in my view.

The goal of any company is not to generate the most optimized code base. It only needs code that works for its purposes. It's a necessary balance which carries risks and opportunities.

I don't disagree with your last paragraph. I think we just disagree on where that line is reasonably drawn.

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 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?

Reply on news.ycombinator.com