Better name for vanillajs-1

[benmccann]

What is vanillajs-1? Could we come up with a more descriptive name?

[krausest]

Maybe vanillajs-#2 would be better 🤣 (was created due to #403)
I always wanted to get back to a single vanillajs implementation, but I haven't managed to decide which one to keep.
Maybe I just should stick with the one that will be faster on chrome 84.

[nweldev]

I need to compare performance variances between different rendering approaches using vanillajs (plus some micro-libraries) and, after some investigation on my own, this project seems the best fit for that.

So, I forked the repo and will create some more vanillajs implementations. @krausest Should I make a PR with those when I'm done? (I guess not based on your comment "I always wanted to get back to a single vanillajs implementation" 😄) If so, I could rename existing vanillajs implementations for more clarity.

Also, if you would be kind enough to share more information about your own investigations on this specific topic, it would help a lot.

[krausest]

The only thing better than one vanillajs implementations would be several vanillajs implementations 😄 but with clear and distinct implementation strategies (and appropriate naming). So I'd say we should take a look at those implementations and discuss here which should be added. But I want to restrict it to adding only keyed vanillajs implementations.

Sadly I have failed to make vanillajs the fastest implementation so I can't give you good advice.

[ryansolid]

The difference between the 2 implementations is VanillaJS keeps an array of nodes around and VanillaJS-1 does not. This reduced memory usage(although as of late that advantage has almost vanished) and code size.

You would think it would improve performance not keeping an array in sync. However, as we know the DOM is expensive. So stuff like this hasn't really made a big impact to get past any variance. Sometimes I think that walking down the 2 nodes from either end on the Swap test is more expensive than having the array for the entirety of the tests.

[nweldev]

I have failed to make VanillaJS the fastest implementation - @krausest

My main focus right now isn't to find "The fastest" VanillaJS implementation. It's more about investigating the balance between developer experience (i.e. maintainability & readability) and performance. Based on some discussions, I see this project always forbid over-optimization (as it would be "cheating") except for VanillaJS.

IMO, it's the right choice. Having "the fastest" VanillaJS implementation would be a really good thing for comparison purposes indeed.

Yet, developing a "VanillaJS Web App" IRL is more than often not especially about over-optimization, as DX has to be considered. Calling a project "VanillaJS" is often too far fetched, as most of these projects use micro-libraries and helpers from the community (Open-WC, Polymer Project, VanillaJS toolkit, etc.).

This is why I'm currently writing several poorly optimized implementations to better understand what approach should be avoided or not, depending on the context. I think it's outside the scope of this project, but I may send some PR anyway for feedback. Based on some comments in the VanillaJS implementations, you seem to have investigated this a lot already.

(BTW, I deleted my previous comment after I found it was dumb, as I'm new to this project 😅 I still have to read all @krausest blog posts + the one @ryansolid wrote + some discussions here)

[ryansolid]

I think keyed, non-keyed is still an important distinction because it describes completely different expected behavior.

That being said yes there are a ton of pitfalls when using vanilla js if you are looking at performance. It's unfortunate and most aren't super critical but we've done a lot of work to try to find the most optimal approaches.

I think this project is great at discovering those although more often than not you are left scratching your head. So your learnt knowledge feels almost anecdotal. It would probably be worth pulling out as many articles as possible that corroborate the findings with actual technical details. V8 blog posts are great in those areas. But sadly most of the stuff we find is just through trial and error. There is so much of that now I don't even really realize and think about most of it unless I see code doing something less optimal.

(By the way the article you linked is great but it focuses mostly on how to reduce the overhead of having a reactive system rather than much pure about the DOM operations, although there are probably a few hints in there).

[nweldev]

Thx for this great answer @ryansolid. I'm still struggling to find the exact distinction between keyed and non-keyed for a VanillaJS implementation. What would be your definition?

As I go through the different implementations and this project history, I can indeed see all the work you've done to find the most optimal approaches. Kudos for that 👍

This is exactly why I was first trying to find some way to just benchmark small pieces of code (e.g. innerHTML vs create then append). But getting the actual rendering time (i.e. from run to the end of paint) is really complicated. I guess I could do so using Puppeteer trace (in the same way this project uses selenium), but I miss time for that right now.

So, after writing my own VanillaJS implementation for this project and testing one optimization after the other, I was able to test some hypotheses. But each test involves a lot of code, which gets on the way of these kinds of tests.

in keyed/vanillajs-wc
deletion may be optimized using the "row elements array" key instead of the row id (in order to avoid all the findIndex loops) even if this has nothing to do with rendering

in keyed/lit-element
using Array.map() when swapping store entries may be leading to some overhead compared the vanilla implementation

Also, following some bad practices could lead to better performances, even when the associated good practice itself doesn't affect rendering

in keyed/vanillajs-wc
when the row custom element self-apply classes

Of course, this makes sense when you want to compare VanillaJS with Frameworks like Angular & Co. But not so much when you compare VanillaJS implementations between them. This is why I think my work is out of this project's scope.

[nweldev]

(back on this issue actual topic 😅 )

IMO this project should only have (x2 for non-keyed and keyed):

1. one "over-optimized" vanillajs implementation, with poor DX but with the best performances.
   IMO vanillajs-1 is the one to keep
   I do not have all your performance optimization expertise, so I do not pretend to be able to do better, at all. I'm just trying to classify each approach based on its impact on rendering performances.
2. a "real-life" one, using Web Components and following all the commonly followed good practices (WhatWG, W3C, google, gold-standard or even the mdn examples). Here, this is not the case with vanillajs-wc, and we can't really do that as it would require to attach a shadow dom to the other components.

Right now, my focus is on the second one.

[ryansolid]

Thx for this great answer @ryansolid. I'm still struggling to find the exact distinction between keyed and non-keyed for a VanillaJS implementation. What would be your definition?

Keyed is when the data for a row always is tied to a specific DOM element. You swap the data in the list, you swap the whole DOM element, You delete the data, you remove that row from the DOM. You replace all the data in the list, you remove and add all new DOM nodes.

Non-Keyed means that data can just latch on to whatever DOM elements that happen to be around, regardless of their current internal state etc.. Most common form is "Keyed by Index", but really it's any implementation where the data responsible for creating a DOM node becomes disassociated from its particle node. When you swap the data in the list, you simply update the text in the label. When you delete the data, you remove the last row in the DOM and just update the text for every row from the index until the end. When you replace all the data in the list you just replace all the text in the existing nodes and don't remove or create any new ones. If your implementation does any of those things it is non-keyed.

[krausest]

Over time the performance of vanillajs and vanillajs-1 got so close again that I plan to remove vanillajs-1.