ADD Mikado keyed/non-keyed

[ts-thomas]

Hello, I would like to add the Mikado templating library. First of all thanks to this community for providing such a good comparison playground. I need some help to find out what kind of functionality is accepted and which not. I read a lot within the issues but at the end I'm not really sure what the rules are.

The current implementation is able to restore all states when rendering would be forced.

[leeoniya]

@krausest should we strip all timing-related code from all impls? every new impl goes through the work of adding it, which is a waste of time.

[ts-thomas]

I fully checked the implementation again and made some changes. This should be fine now. The whole application logic is located in src/main.js, this is one of the smallest implementation on this list and produces the best benchmark actually on my machine. I'm also the author of flexsearch and fat, they are also provides the best performance in its league. @krausest I would be happy if you can merge these PR.

[ryansolid]

On the surface looks fine. I personally find it more illustrative of how the engine works when everything inside the "main" div is rendered and bound by the library. I've suggested this as criteria before, but not all implementations follow this. It just shows more so how the table fits into an application as if you were picturing a TodoMVC app etc. It's straight forward for small libraries to just focus on the rows so I get it, but say someone building an app with React would never do it that way. It's the management of the switch in the context that is interesting. Libraries like Stage0 start showing their tradeoffs in those scenarios because of the expectation of the end-user to manage renders and nested repercussions themselves.

[ryansolid]

Just had a chance to check out the library. Interesting approach. If I understand correctly the control flow is outside of the template and managed from tightly binding data object to the render. From there all updates are restricted to specific types of operations that allow direct manipulation so "reconcilliation" is a simple for-loop. This allows essentially the same sort of performance as VanillaJS since it's almost the same as taking the VanillaJS implementation and wrapping each function in a library. In so there are no diffing or unknowns. Most libraries when you append 1000 rows pass in the whole list to reconcile. This library calls an append function very much like what you would do if you wrote it in VanillaJS.

It is definitely different than other libraries. It probably shares the most in common with Stage0 in that it provides a simple template layer and the library provides methods you can almost view as DOM wrappers to join the pieces together. However unlike Stage0, given this library doesn't really do any diffing or have the overhead of a fine-grained event system, I'd expect performance to be pretty much identical to Vanilla assuming all the same DOM manipulation is being done. I am a bit surprised this is the first entry like this that has shown up.

[ts-thomas]

The concept behind the render process is my main motivation of creating this framework. I'm thinking about creating a blog post which explains and illustrates the strategy more in detail. Im also a fan of TodoMVC and I had already done a demo application for an older framework a time ago. That is a good suggestion and I will provide a TodoMVC for this framework too. At least to show that sugar will not eat performance :)

[ts-thomas]

I take a look into stage0 for the first time. You are right, is has some similarities. Nice to see that it also uses a dynamically created function as its base.

What is the current state about this PR, should I have to make/change something?

[krausest]

From a first run it seems like the keyed implementation isn’t completely right. Seemed like swap rows doesn‘t swap the dom nodes and thus isn‘t keyed.
I‘ll give you details later this day when I‘m back home.

[ts-thomas]

You are right, the keyed version did not swap nodes. Thanks for this hint. I will fix that now.

[ts-thomas]

It is fixed now, the "reuse" option was not checked during swap method.

[krausest]

Thanks. Now all tests pass and the PR is merged and results are updated.
It's really fast, but of course comparison of mikado vs a data driven or reactive framework seems not really fair. Still I'd prefer mikado over the vanillajs version at any time!

[ts-thomas]

Thanks a lot! Great :)

[ryansolid]

Thanks. Now all tests pass and the PR is merged and results are updated.
It's really fast, but of course comparison of mikado vs a data driven or reactive framework seems not really fair. Still I'd prefer mikado over the vanillajs version at any time!

Yeah I might have had something to say about this at one point, but the truth of the matter is DOM being the bottleneck we are getting so close to Vanilla Performance now that, much like the size argument (which really doesn't matter in TTI, script bootup time, within a 10kb range), in these common situations (lists etc..) we are reaching a boundary where the top-performing libraries on a good day can all match/surpass VanillaJS. Which moves the conversation back to the perferred DX abstraction. I like that Mikado hammers this home to an extreme. From Vanilla to Light Wrapper to Full Abstraction are only ms apart.