Update Solid v0.13.0 (and KO JSX, MobX JSX) #655
Conversation
ryansolid
changed the title
What do you mean? Those aren't tricks. I mean sure VDOM triggers a render/diff routine. But your proxies technically are triggers. They cause the DOM to be updated. To me that is a distinction on syntax. Solid could use Proxies the same way but choose not too for reasons (in the article link and explained in my other posts). All you are describing is fine grained versus course grain updates. Fundamentally it is still the same. End user sets data, triggers update, DOM is updated. Data-driven. The means of the trigger is syntax. In this case it doesn't have the same spirit versus mechanism thing I was describing above since regardless it works the same way. You perform a mutation on the data independent of thinking of how the DOM will update and DOM updates. It isn't any different. |
As I've been saying that swap alone told me nothing. I looked and saw what Mikado keyed implementation was doing and was like. "Oh this is just directly wrapping DOM operations. It is tightly coupled like jQuery. Hmm.. I'm sure we've all thought about doing this. Surprised no one has bothered building around it. Cool." Look back at my first impression(#632 (comment)). Clearly your proxy doesn't work the same way. That's also cool. I don't know what you expect. I mean do you want me to dissect?
Definitely. However the library author audience isn't going to give accolades here simply because I'm sure they've all thought of doing stuff similar, but it didn't fit with their experience goals etc.. I acknowledge it is the fastest. Before you were the fastest Solid(Sinuous) was, before that it was DomC, before that it was Surplus, before that it was ivi, before that it was inferno.. and so on. Libraries have been in that place at various times. Some people might not agree with how you got there but ultimately bottom line is it is undeniable. As I've always said let the end user look at the implementation and decide what experience they prefer.
Opinion. Many library author believe they have accomplished this. Talk to lit-html, talk to Svelte and so on.
Is it? Cool. It is good when people push what can be done here. So it's all positive. Although it wasn't what you submitted when you submitted your keyed implementation. So no one here even knows about it.
I think this very cool. This is an area I'm super interested in general. I'm going to check it out when I get the chance. Notice no one has said anything negative about this. I mean we've all seen MobX, Vue3, Svelte (compiler rather than proxy but looks similar), not to mention some of us are familiar with Knockout, Solid, Surplus, Sinuous etc.. which work off similar concepts. I think this is still relatively new ground so it is unique in that sense. I personally look forward to it. I was actually going to write something positive on that PR and thumbs up, until I read the post where you yet again came off as combative.
I think that's great. |
|
On an aside, have you thought of how to best benchmark the Mikado-Proxy implementation (reuse: false, store: store) submitted here? I'm gathering it would have a similar issue in your benchmark even under data-driven. Just something to think about. Because if you can handle that case the other reactive libraries would also probably be better represented. |
Mithril author is probably one of the nicest people in a javascript reddit community and he genuinely tried to help you when it was obvious that you didn't even understand the basics.
Nobody cares because you aren't even competing with libraries like React/Solid, your library in the same category as stage0.
Every library author here is probably thinking that their library has "the lowest complexity for developers" :)
Nested loop, wow, such effective 🤷♂️
All reactive libraries that applied DOM mutations synchronously died in early 2010s 🤷♂️
How is it possible that you didn't even understood initially how to create keyed implementations with libraries like React in your benchmark? I seriously can't imagine how it is possible for someone who used React, because React will print a lot of warnings as soon as you start render dynamic lists.
Just looked at Xone sources, it looks like a library from early 2010s.
We've learned all this techniques how to inflate benchmark numbers 5 years ago, we've done all this benchmarketing bullshit a long time ago. Do you seriously think that nobody thought about adding keyed recycling in a benchmark that applies DOM mutations without flushing DOM ops? We've seen this 100x benchmark improvements, nobody cares about this useless "optimizations". |
|
It looks like you've learned a lot, but sadly by far not enough :( ... although I wish you good luck with celebrating yourself |
|
My library uses also proxy for reactive changes... is the best solution. |
|
https://github.com/dozjs/doz/blob/master/example/todolist.html |
|
@fabioricali if I understand correctly, your library works like Vue and it just provides a different API on top of the proxy API, it is a perfectly fine solution. With mikado, when you remove element from an observable array, it will immediately trigger DOM mutation like it was done in old reactive libraries, until library authors realized that it is important to have batching, computeds, glitch-free computations etc,etc... |
|
@localvoid also in my library at each mutation of an array/object is called the "render" method. Doz uses the virtual DOM anyway. |
|
omg, you just pick one paradigm which is supported by this lib ... |
|
https://github.com/nextapps-de/mikado#extern |
|
@ts-thomas To be fair while Mikado supports many different modes, the only thing really relevant here is what is in the implementations that are submitted in this benchmark. So in a sense @localvoid didn't pick the paradigm, you did in how you chose to represent your library here. But I don't think you should be necessarily too swayed by opinion and do whatever feels right for Mikado. |
|
@ryansolid I've followed your suggestion and added "mikado-proxy" to all 3 test categories: https://github.com/nextapps-de/mikado/blob/master/bench/README.md#keyed |
|
@ryansolid Thanks for the update. Results are here: https://krausest.github.io/js-framework-benchmark/2019/table_chrome_78.html |
Haven't updated for a while so thought I'd submit. There have actually been a lot of changes. Primarily:
{( )}syntax for dynamic bindings. Now a heuristic is used to determine if the binding could be dynamic. It simplifies things greatly for end users but requires a bit more diligence for getting optimal performance (ko-jsx, mobx-jsx hoist out their list mapping now in the implementation)As usual I've learned a couple of things along the way to improve performance, so it is my hope that the performance is fairly comparable to the previous version.