search

solidjs / solid

A declarative, efficient, and flexible JavaScript library for building user interfaces.
https://solidjs.com
MIT License
32.42k stars 925 forks source link

Should I consider Submitting a Signal version to JS Frameworks Benchmark? #15

Closed ryansolid closed 5 years ago

ryansolid commented 5 years ago

Sort of torn since I like to show off the ergonomics of Solid and its compact State object. However, I do have a faster implementation that is by no means anymore hacky using pure Signals that removes the proxy overhead from the execution, and is lower in memory usage and faster in performance. It could be enough to take top spot on the benchmark. But is it worth it to show off the raw speed of this approach?

Freak613 commented 5 years ago

Everything that push the limits is good to show.

ryansolid commented 5 years ago

Yeah.. it's just one of those less interesting things in while it demonstrates the overhead of proxies it's basically the equivalent of the Surplus implementation. Faster than Solid implementation today but still behind Stage0 or DomC(although closer) in most benchmarks except partial updates and select rows. It just on average scores better. Improvements from Chrome 72 that came out this past week reduce the the difference.

It's tricky because I'm trading the ergonomics that inspired me to write Solid in the first place for a couple points. Maybe I'm supposed to submit a second version. Solid-signals or something.

Freak613 commented 5 years ago

Then, yes, it will look like Surplus + Node cloning. However, still interesting to look at, since Surplus didn't yet adopt cloning.

ryansolid commented 5 years ago

Yeah I think I will wait for the dust to settle on the current discussion there around what is acceptable before trying to submit something else. But I appreciate the sentiment. I think the discussion might weigh in on what should be submitted in general.

trusktr commented 5 years ago

But is it worth it to show off the raw speed of this approach?

The benefit may be that it shows people the options (or helps make the options more clear), and will help the community as a whole better weigh those options, and ultimately help us all have the best framework (regardless of which framework that ultimately is).

brodycj commented 5 years ago

I do have a faster implementation that is by no means anymore hacky using pure Signals [...]

Did you get a chance to share the faster implementation somewhere? Did I miss anything?

ryansolid commented 5 years ago

No I didn't yet. I was meaning to open a question on the repo about multiple versions. I am concerned Solid isn't established enough offer multiple entries. I've been trying to promote the library the past 2 months to mediocre success to reduce friction. Thousands of views and hundreds of claps on Medium hasn't translated into Github Stars yet. I've focused on Test Coverage, adding more examples, and Documentation. But in all honesty it's a hard time to be yet another Javascript UI Library.

Mostly, I feel the current implementation sells the vision more even if the other version is slightly more performant. The current version uses proxies is a clean 76 lines of code, where as the more performant version is a little more code (~100 LOCs) and less clean aesthetically. While less important in a performance benchmark I do like the fact that, in my humble opinion, Solid isn't only one of the fastest libraries, but the cleanest looking. When I asked the question I wasn't sure the importance of this. But since I've been promoting the library and writing articles I think it's more important than I even was originally thinking.

The second reason is that the current version of Chrome, 73, has some pretty big regressions in memory and partial update performance (proxies seemed to also take a bit of a hit as well) that negatively impacted all my implementations (vanilla-js-1, solid, ko-jsx, mobx-jsx, react-hooks). Compared to 72 all these libraries drop a couple points relative to their competitors. So it's hard for me to do much meaningful performance tweaking right now. I have already created this version, but I'd release it as a new version since there have been some updates to Solid in general since the last submission which I need to still do some performance tweaking to I'd imagine.

brodycj commented 5 years ago

Thanks @ryansolid for the detailed response. Couldn't you make some kind of a WIP branch or "next API" version?

And I definitely hear you about the challenge of promoting yet another new UI library. But I really think the quality of your work should at least be able to influence some of the more popular frameworks to improve, even if you would not win in terms of direct traction.

ryansolid commented 5 years ago

I ended up writing a medium article showcasing the different versions of Solid including this Signals version. https://medium.com/@ryansolid/the-fastest-way-to-render-the-dom-e3b226b15ca3

ryansolid commented 5 years ago

So I finally submitted after a change in the testing platform seems to punish proxies more. As expected it's in dead heat with DomC. Whether I keep it in is another matter, but for now you can see the results here: https://krausest.github.io/js-framework-benchmark/current.html