0.11.10: Further bundle size reduction

[Tao-VanJS]

• Further reduce the bundle size to 1185 bytes 🎉
• Ignore comment and other non-element node types in HTML to VanJS code converter
• Revise the https://vanjs.org website and README.md

---

This discussion was created from the release 0.11.10: Further bundle size reduction.

[artydev]

Thank you Tao

[efpage]

Hy Tao,

you code is really a marvel. You packed so many valuable features in such a small package.

In general, keeping packages small, is a good thing, but is it really necessary to fight for every byte? I checked VanJS.org and found a lot things that need to be loaded anyway:

• van.css 5kB
• ulil.css 13kB
• w3.css 23kB
  not talking about all the external ressouces. Even the VanJS-logo is 13kB.

So, while it might be a tempting challenge to build the world smallest framework, this should not be the only guideline. Sometimes readability und usability are also important. And some compressions on the library size might force us, to make the page source more verbose, which in the reslult may lead to larger bundle sizes.

[Tao-VanJS]

VanJS becomes the smallest reactive UI framework because of its simplicity, its minimalist design principle, as well as lots of hand-crafted optimizations for the bundle size. However, size is not the only goal for VanJS. It might not even be most important goal. There are a bunch of planned usability features (e.g.: #27 and #38) which will inevitably increase the bundle size. I am also considering some performance optimization which is expected to increase the bundle size as well.

[efpage]

Referring to the performance I want to note, that - referring to own measurements - the execution time of Javascript to build the DOM is only a small fraction of the total update time of a page. I did some tests with direct dom manipulation which usually finished after 1-2 ms for a complete page update, while the rebuilding of the page took up to 700 ms AFTER the DOM update was finished.

It is always good to write optimized code, just using I would not except to have any measureable effect of the way a loop is build on the page update time, unless we do not start to write numerical simulations in Javascript.