Hyperapp: Performance: Pure Vanilla JS VS Hyperapp

[matschik]

I'm working in a full JavaScript UI project used by many big websites for 6 years.
We are aiming for performance first but it needs refactoring at the moment.
The output file of the whole project is only a JavaScript file.

It's written in ES5, pattern prototype as classes for performance with only one library: 400 bytes for templating library.

So I wonder if Hyperapp is more performant than pure Vanilla JS DOM manipulation. I know that VDOM is more performant for DOM changes but the most important in this project is: the UI must load fast at first load. With Hyperapp & Webpack, I will be able to remove our templating library, and make our code more maintainable.
Websites using it are basic PHP websites and a few Angular apps.

So what's the more performant for this project: Vanilla JS or Hyperapp ?

If I forgot some informations, do not hesitate to ask me.
Your help or any discussion would be gold ! Thank you so much !

[zaceno]

@Matschik

I know that VDOM is more performant for DOM changes

This is a widely held misconception. VDOM has no magical secret sauce that can make it more performant than Vanilla JS DOM manipulation. At best VDOM can only be as fast as optimised Vanilla JS DOM operations.

The problem with Vanilla DOM ops though, is that it is so darned complicated when your UI is more complex than a button or a single input field. It's very hard to keep track of what you're doing –– let alone knowing if you're doing it in the optimal way.

For this reason, people usually end up writing helper code or including third party libraries (like jQuery or client-side templating languages). Now it's no longer truly vanilla DOM, and performance issues creep in via these helpers.

The reason VDOM's are used, and why using them often has a performance benefit, is that it is such an elegant and simple approach to DOM manipulation. And it takes all of the burden of deciding which DOM operations to perform when, out of the hands of the application programmer. This means it can optimise for things that e g jQuery can't.

As for the question of first render: are you prerendering the UI with PHP? If you are, Hyperapp can handle that and you will see no difference in performance. If you are doing all the rendering (including the first) using client-side logic and templating today, then there is a chance there will be a slight performance drop, but I'd say that's unlikely. More likely you'll notice nothing (possibly even a performance improvement). Anyhow: the only way to know is to try it.

Fortunately: trying it should be pretty simple :) It should be quite trivial to put together an example app that only does the first render with hyperapp. Then compare the performance on some weak device like a smartphone or something (to make differences more noticeable).

[jorgebucaran]

@Matschik So, I wonder if Hyperapp is more performant than pure Vanilla JS DOM manipulation.

No, it isn't. And neither is React, Vue or Angular. The point of the virtual DOM is not to improve performance (although performance is taken into consideration), but to allow us to architect applications using a functional/immutable paradigm.

In the words of Sebastian Markbage (one of the engineers on the React team):

It's a misconception that React needs the virtual DOM for performance. It's foremost an immutable shim over an inherently mutable DOM API.

Of course, the same is true (if not truer) about Hyperapp. 💯

---

Here are some issues that discuss V1/V2 performance.