Performance Potential

[btakita]

Hi, I'm taking a look at Van & it looks great! I mostly use SolidJS for its speed, signals, & smallish size (large compared to Van). According to the Krausest benchmark, Van has a slightly better startup time & is notably more memory efficient than SolidJS. Solid has slightly (in clock time terms) better performance benchmarks particularly on the create & modify benchmarks. Do you think Van's benchmark performance will continue to improve? Are some optimizations not possible without significantly increasing the size of Van?

[Tao-VanJS]

Hi @btakita,

That's a great question!

I think VanJS is a very thin layer on top of the native DOM APIs. As for why the clock-time benchmark of VanJS is slightly slower (though the difference is quite small) than some frameworks, I think the main reason is that the specific DOM API VanJS is choosing might be slightly slower than the API other frameworks are choosing, which is very specific to browsers' implementation details. I don't think much of the performance difference is due to VanJS's JS code itself.

Currently I have no immediate plan to further improve the benchmark result. I am not seeing for VanJS's designated use cases, the small difference in benchmark test has any significant impact to the actual user experience.

[btakita]

The benchmark difference is insignificant for most cases. I'm wondering if VanJS can grow into a larger app, both from a performance & DX perspective. There seems to be a tier of component libraries with similar performance benchmarks near VanillaJS on the benchmarks. VanJS is near that tier. I figure that VanJS probably has the potential to get there if it was a priority & enough development was put into it. Or is there some architectural blocker with trade-offs to get to the top tier?

My biggest hesitation is how does VanJS grow with large component trees having dynamic data? Correct me if I'm wrong, my understanding is that VanJS attaches new DOM nodes when state changes by default. I see a custom callback which allows the DOM to be mutated instead. I think the manual callbacks would create a app size inflection point; e.g. how many TodoMVC apps worth of components with custom DOM mutation would it take for the VanJS to grow bigger than another component library. It also seems like a bigger maintenance burden as well.

[Tao-VanJS]

Thanks @btakita for the remark!

First, my belief is that the small difference in the benchmark results between VanJS and the top-tier is mainly due to the API choices of the DOM API, rather than the overhead of the thin layer of JavaScript code. That means it's really hard to improve the numeric values of the benchmark results unless we re-implement VanJS with a different set of DOM API to use. That said, I don't think the small difference in benchmark results can translate to any noticable effect of user experience in real-world applications, thus we probably don't have much motivation to improve the status quo as well.

Second, regarding your concerns on performance degeneration when the DOM tree gets larger, I don't think this will be the case. Note that, the actual DOM tree used in the benchmark is already far larger than the DOM trees in most real-world applications. Very few real-world applications have something even close to 1,000 rows in a table (as a reference, there are only 25 rows rendered in the desktop version of GitHub discussion page), let alone 10,000 rows in some portion of the test.

Last but not the least, on whether the custom stateful binding function could significantly bloat the client code, I don't think we need to worry about that either. Stateful binding functions tend to be small (and if there are many such functions we can always refactor the code to extract the common part). This is different from Svelte where client code is the compiled results.

Recently we launched VanX which has a function vanX.list that allows you to build a TODO list (or any list in general) efficiently without a need of custom stateful binding function. With vanX.list there is 0 size overhead for rendering a list.

[btakita]

Sounds good. I'm giving VanJS a try for my personal site. I think creating many nodes is important in SVG data visualizations, where scatter plots typically have > 10k elements. Also, full SPA's, particularly data-oriented, have many elements.

I like the level of low level control with VanJS is nice. One thing I noticed is that cloneNode is not used.

https://www.measurethat.net/Benchmarks/Show/265/0/createelement-vs-clonenode#latest_results_block

Perhaps a lazy-loading a prototype node in tagsNS would help? I can submit a PR. I don't see any tests though. How do you verify changes?

[Tao-VanJS]

We have browser-based test for VanJS. You can refer to #37 for the process. It's not a polished process though. Hope it can be useful.

[efpage]

Hi @btakita,

There are several factors that will affect your page performance, but DOM interactions are usually not that important. I made a new post on this topic here

[btakita]

Thank you for the article. I agree with you that a common bottleneck has to do with data transfer, FCP, TTI, CLS. For example, I use custom hydration w/ Astro b/c the general purpose hydration solutions tend to be bloated, under difficult ongoing development, opaque, & easy to mistakenly hydrate components that should only be rendered on the server. Custom hydration is not difficult & used to be a common practice with MPA apps (where the server side was written in another programming language). Now that we have isomorphic JS apps, the hydration can be re-used to bind events to DOM components on render & initialized on page load when the components are SSR. I & others have built lightweight hydration apis to do this.

I think that benchmark performance, while a less common bottleneck, does indicate other factors. For example, React, being a bit on the slower end, had to introduce Fibers, Hooks, a bunch of libraries, & various other ways to make component rendering more performant for large apps...which increases the cyclomatic complexity due to the library.

[efpage]

We should not talk about bottlenecks, as I think this leads on a wrong path. There are many things going on in parallel if you show a page, and only the slowest event chain will determine your page speed. It really does not matter if building the DOM tree takes 1 ms or 10 ms, if the app needs to wait for some ressources to be loaded.

If you measure the time to update the DOM, this is often very short compared to anything else going on. So, the question is, when does this really start to matter?

[Tao-VanJS]

Thanks @efpage and @btakita for the wonderful discussion! Here are my 2 cents:

On one hand, I agree with @efpage that network latency usually takes the most part of page load time, which is also why I believe the ultra-small size of VanJS is very helpful :-). On the other hand, the performance of DOM updates that each framework provides, is more relevant to the user perception of the "responsiveness" of the web app. A framework that spends too many CPU cycles on executing JavaScript code will make web apps feel sluggish.

I think this is also the reason why WebAssembly apps (which usually have longer network latency for the first time load due to the size) have their use cases, especially for compute-intensive use cases.

[btakita]

This is one of those "it doesn't matter until it does" situations. For example, I have some financial apps that render > 10000 SVG tags within a single interactive visualization. Having multiple of these visualizations on a single page, rendering logic & performance matters. Ideally, it would be great to have the programmer focus solely on the domain & not on tweaking performance.

If the default usage is optimized, then less effort will be necessary to maintain the app when performance issues do come up. If we can rule out a missing optimization within VanJS, then it helps to focus optimization in other places. This may be more about perception, but having the possibility that rendering performance is the culprit means one more thing to account for.

Also note that apps commonly have dependencies, all of which use the same CPU. I also see VanJS being great for embedding components into other apps, due to it's small size & closeness to the DOM. All of these dependencies & other code use the CPU as well.

That being said, VanJS already does well with the Krausest benchmark & there is still low-hanging fruit to improve the rendering performance.

[Hunter-Gu]

I also see VanJS being great for embedding components into other apps, due to it's small size & closeness to the DOM.

Totally agree with you! I think maybe VanJS is the best choice when create a UI component library. It can be a meta framework for utilities in a way.