localvoid

8 ms·

31.
by localvoid 8y ago
https://i.imgur.com/MG3eGTM.png Inferno here is also slightly patched[1], instead of using stateless components, it is using stateful components to demonstrate how fast it can go down when you start using high-level abstrac
32.
by localvoid 8y ago
Couple of small changes to the surplus benchmark implementation[1], and it is not the fastest anymore[2] even when benchmark is super biased towards fine-grained direct DOM manipulation libraries like surplus (ratio of data binding per DOM
33.
by localvoid 8y ago
> In theory, a compiled, static template approach should be faster than V-DOM Maybe faster in basic microbenchmarks. As soon as you start optimizing UI library for complex applications, there are many other optimization goals you should
34.
by localvoid 8y ago
> making separate implementations no longer necessary Until you actually start to implement gesture disambiguation and realize that pointer events are useless [1][2] 1. https://github.com/w3c/pointerevents/issue
35.
by localvoid 8y ago
> 1. benchmarks have zero information value Statements without any proof is more valuable than "benchmarks with zero information value"? > what I mean is that compiled templates are usually much faster than doing vdom diffin
36.
by localvoid 8y ago
> Since there hasn't been nearly as much effort put into alternative algorithms Angular2+ team is actually have done an awesome job at experimenting in this problem space. And they've moved away from generating code that is sim
37.
by localvoid 8y ago
> so that it doesn't have to do any expensive VDOM diffs. I am wondering, how is it possible that such non-expensive algorithm is more expensive than many VDOM libraries in this benchmark[1] ? 1. https://rawgit.com/k
38.
by localvoid 9y ago
> They have virtually nothing in common. If you think so, then there is really nothing to discuss ;)
39.
by localvoid 9y ago
Lifecycles has nothing to do with vdom. Even web components has lifecycle hooks https://developer.mozilla.org/en-US/docs/Web/Web_Components/... Have you tried to build a components library, or have you s
40.
by localvoid 9y ago
> It's inherently memory intensive Even if we pretend that other architectures doesn't have any memory overhead, vdom memory overhead in a large UI app will be less than a single small decoded image. But in reality, KVO can be
41.
by localvoid 9y ago
> but that changes are tracked with a data reactivity library reminiscent of knockout called s.js instead Surplus is fast because it doesn't have many features that available in many other libraries. For example, component model wit
42.
by localvoid 9y ago
I haven't talked about Moon, don't know too much about it. Just wanted to say that small size doesn't always mean that it will have low TTI. And Moon is small because it doesn't have features that are necessary to build
43.
by localvoid 9y ago
> This is really great to see the emphasis on static vs dynamic parts in templates. Polymer, Glimmer, and some other template systems make the distinction between static and dynamic content, but React and most other vdom libraries don&#x
44.
by localvoid 9y ago
But many libraries that has a primary focus on library size are usually sacrificing runtime performance to reduce size. Yes, they've reduced parse time, but significantly increased bootstrap time. I understand that they are doing it be
45.
by localvoid 9y ago
He tried to solve performance problems in complex applications, and obviously complex applications doesn't need to preserve internal state when children list is changing :)
46.
by localvoid 9y ago
>They probably are faster than vanilla code that you'd be able to write on your own, but that says more about your abilities than the performance of frameworks. I won't be able to write efficient vanilla code for something even
47.
by localvoid 9y ago
https://community.oracle.com/blogs/kgh/2004/10/19/multithrea...
48.
by localvoid 10y ago
Also, it seems that many people are defending WCs with an argument about interoperability. But in reality, if we start adding components that are using different frameworks, there will be problems with layout thrashing, etc, because there i
49.
by localvoid 10y ago
I also curious to see how web components will be faster than simple javascript objects :) React apps are usually built with many layers of components that returns another components. And with standard Web API, there will be significantly mo
50.
by localvoid 10y ago
Nobody cares when it is 6ms instead of 3ms for partial updates. What is really important is how fast you can create and remove huge amount of nodes (switching pages in SPA, etc), because it is already takes a huge amount of time, and Bindin
51.
by localvoid 10y ago
uibench results on Chrome 54 with full render time and disabled sCU: https://cdn.rawgit.com/localvoid/6715c4b23eadc460112e671b4ad...
52.
by localvoid 10y ago
>Creating elements with the DOM API is faster than innerHTML roughly by a factor of 4 on Chrome Canary last I benchmarked it yes, almost by a factor of 4 :D check out "render" test cases: https://cdn.rawgit.com/
53.
by localvoid 10y ago
It depends on the code base. When I've migrated from js code base with 100% gcc type coverage to TypeScript, gcc(without tsickle) in advanced mode stopped rewriting many methods into simple functions, didn't minified many symbols,
54.
by localvoid 10y ago
There also an amazing tool[0] that processes TypeScript and adds JSDoc annotations for closure compiler, so it can optimize way much better[1] [0]: https://github.com/angular/tsickle [1]: https://github.com&
55.
by localvoid 11y ago
All libraries in uibench have batching, and batching doesn't improve performance, it just prevents from doing unnecessary work during one frame. It is pointless to test performance of different state changes with enabled batching.
56.
by localvoid 11y ago
Preact is using implicit dom recycling, so it heavily breaks use cases like "tree/[*]/render". Just hold mouse over its time and it will display "max" time, it will be much closer to reality. All other librarie
57.
by localvoid 11y ago
In a real application, you'll need to deal with moving elements, document shape will be changing, etc. Trying to solve this cases is the most complicated part of vdom libraries. If you try to do naive replace/update, it will be si
58.
by localvoid 11y ago
>Let's be clear, manually updating the DOM is as optimized as you can possibly be. Virtual-DOM isn't somehow magically more efficient than direct, imperative manipulation of the DOM. The actual problem is how to efficiently tra
59.
by localvoid 11y ago
>Virtual DOM approaches never really were about performance. "React abstracts away the DOM from you, giving a simpler programming model and better performance" https://github.com/facebook/react It seems st
60.
by localvoid 11y ago
Don't look at "overall time" to compare performance, I've added it just because some of the vdom library devs asked it, so they can easily track regressions/improvements in their libraries. Numbers in this benchmark

More ›