Replace swap built-in with reconcile #654
Conversation
|
@ts-thomas you can do what you want but yes people are going to point out when things are not equivalent. Swap might be the most obvious, but this whole benchmark was setup to compare data-driven libraries. It started with mostly Virtual DOM libraries and continued on to other libraries that can operate similarly. So changing Swap doesn't completely do it. Your Run leverages the fact that you explicitly clear since you know that Replace is a full Replace. Other libraries actually check. Similarly with Append. You Append when other libraries actually check what has changed. I understand it's a by-design thing but it's because they are data-driven. As long as Mikado is singularly different why would anyone take it to be equivalent? Especially when these are easy things that any library could do (like explicitly clearing before replace). Yes reconciliation is an implementation detail here but it's the very thing that allows comparison. It is literally the only thing we could somewhat agree upon, after tons and tons of discussions. (#430 #230, #126, #104, #22) and while we are at it (#521, #519).
Undeniably here it is. And I think that it would be safe to actually say in general it is standard. With the exception of jQuery and Backbone(and maybe Bootstrap if you count that) the top 10 popular JavaScript UI frameworks/libraries use this approach (React, Angular, Vue, Ember, Svelte, Polymer, Mithril, and so on). As to the suggestion of this 3rd category. I am not opposed to in general as a way to put aside reference builds but they sort of uninteresting because everyone will just pretty much match Vanilla JS performance. It is already getting so close with reconciled libraries given the overhead in the DOM vs the actually JavaScript. But you can see other overheads here, like Web Components and wrappers. And people can work towards making the idealized Vanilla implementation. However to the suggestions specifically:
This is an interesting idea but hard to standardize on or take meaning from. Not sure. A few of the tests have warmup runs so that sort of accounts for a handful of these actions happening. I mean what do think is more natural a page section loading once and being swapped out a couple of times, or that views of the same shape are blasted over and over in succession? It depends on the app I suppose but this sort of optimization feels like view windowing for large lists. It's a thing but it is very specific and is situationally desireable.
I'm sure this was discussed before. You are describing a large category of benchmarks (I'd say most). I call them data snapshot benchmarks. That just isn't what this benchmark is. Data Snapshot benchmarks have just as many quirks in how data is handled, and it doesn't allow libraries that manage their own data primitives to compete. The reason this benchmark is popular is it starts from a natural place. A basic list app. Something that any library could picture implementing in a generic way and then runs it through simulated user action like tests. Going the snapshot way not only alienates libraries more so, it removes the basis of this at all resembling actual library usage. What I love about this benchmark is I can go in and look at the code and "get" how writing a simple app would look like. For many libraries having a single function driving data is not natural even remotely. And let's face it personally if I was looking for that I would point you to the very good UIBench by ivi's author @localvoid. I guess what I'm trying to say is what makes this Benchmark good is it being exactly the way it is. You can go plenty of other places to get those tests. There is value in being able to showcase libraries this way. It's the same reason I'm like do whatever with Mikado implementation. Since all I have do is look at the implementation to understand oh look there is Append and Swap, this library is doing things a little differently. I will have to decide what I think about it. To me that is great. While 99% of implementations reconcile, you don't have to. Sure people like myself or @leeoniya will call you out on it at times. But @krausest has kept things pretty open and he can because of this setup. I've written a recent article on medium on the topic (here is the link that gets you past the paywall). Understanding JavaScript UI Benchmarking. I hope that it can serve as a good introduction for people coming confused by a lot of the discussion going on here. It has links to many benchmarks in different styles to help people understand the differences. |
|
There was nothing to read about a strict data-driven implementation. Also nothing to read about to strictly use the 1-single-magic-reconcile function to do all tests. So what you like to have and what is given are 2 different things. |
|
The best of all is I changed this stupid thing and now you continue this discussion. Could you remember on my first post? I supposed that become a never ending story. As almost, I was absolutely right. |
|
"and it doesn't allow libraries that manage their own data primitives to compete" that depends on the implementation, I also solved this by providing 3 different modes in my benchmark which basically control how is data created and passed to the render functions ... and it was not that complicated. |
|
The uibench is not documented, that's why I did not implement it. Btw also not transparent enough for me that I would thrust them. I wonder if it is so hard to provide a simple, clear and transparent benchmark environment (e.g. like this one). And these are the basic requirements every benchmark should have, otherwise it makes it useless. |
|
That you all celebrate yourself all the time is really annoying. Always the same names, always the same libs, always the same crap ... its like a tour in a carousel where you get sick. |
|
The article isn't purely aimed at you. You know this stuff (or atleast I believe you do) I think it's just confusing for anyone trying to follow along. We've been here before, this isn't the first time these topics came up (as linked and documented). If you go through the history of this benchmark you will see these topics have come up before numerous times. Seriously check any first-time pull request for non-keyed libraries. It comes up almost every time. This isn't a personal attack. These aren't false facts. I try to back up what I say. You changed the one thing(swap) that everyone was harping about, but the whole implementation is still more of the same. It really doesn't matter though. I think diversity is good, just don't try to mask it as being the same thing. That's all this has ever been about. Note: Until Chrome 78 came there were performance issues with Chrome 76/77 so I just grabbed a previous screenshot that I happened to have from Chrome 75 before Mikado was submitted. You are correct it's subtle advertisement but has nothing to do with the content of the article. I clipped off what the benchmarks were refering to etc.. It was just a stock image for all purposes. |
|
I'm sorry, I took that too personally. |
After I got the 3rd shit storm about this swap method I change this built-in method with reconciliation. Please be aware that the keyed test will not become a reconcile test. The first is a paradigm the other is just an implementation detail. It's the same group of library authors which have made its own reconcile libs (which are quite equal^^) and of course they would like to have the best environment for its kind of library. But the truth is that reconcile isn't the holy grail and certainly by far not a standard.
But I would really like to see a 3rd test category especially for this purpose (besides keyed/non-keyed). If you like that idea I would also like to make some suggestions for this new section:
Note: just the keyed test was updated, the non-keyed stayed as it is