localvoid

5 ms·

1.
by localvoid 1y ago
There is a lot of interesting research outside of the webdev bubble in the incremental computation problem space, and self-adjusting computations (signals) aren't even that interesting.
2.
by localvoid 1y ago
If I understand it correctly, the main argument in favor of tagged templates is that it doesn't require any changes to the js engine and that is why it will be way much easier to push forward. Browser implementation should be quite str
3.
by localvoid 1y ago
I would prefer a more expressive language like Kotlin[1] that makes it easier to work with many different domains instead of JSX hacks :) 1. https://developer.android.com/develop/ui/compose/kotlin
4.
by localvoid 1y ago
Just want to add that even though ivi is using tagged templates, I am strongly against using tagged templates to describe UIs as a Web Standard. One of the most useful features that could make a lot of incremental computation problems easi
5.
by localvoid 3y ago
I've stopped paying close attention to the web framework scene in the past couple of years, as most of the interesting ideas on this topics are usually coming from different communities. But as I understand, the majority of popular web
6.
by localvoid 3y ago
If anyone is interested in this topic, I would recommend to start from fundamentals, so it would provide some answers on why some "not so modern" frameworks aren't jumping on a "signals" hype-train. - Incremental co
7.
by localvoid 3y ago
There was a bug in ivi 2.0.0 with `shouldComponentUpdate` optimization, it was completely ignored. This benchmark submission rerenders and diffs everything on each change, all other `f(state) => UI` libraries in this benchmark are implem
8.
by localvoid 4y ago
> Duplicate vnodes doesnt work, so you HAVE to use some function to generate it instead? Yes. Mutable vnodes is a huge mistake that I've done long time ago when I've tried to figure out how to write efficient diffing algorithm
9.
by localvoid 4y ago
> I’m sure it’s very powerful JSX is only appealing to a webdev community. Modern native react-like UI libraries are perfectly fine without XML-like syntaxes: Flutter[1], Jetpack Compose[2], SwiftUI[3]. 1. https://flutter.dev&
10.
by localvoid 4y ago
> The only problem with hooks is that people don't get them. But once you get them, every other approach looks like a complicated pile of shit. No, some people actually get them and there are way much better alternatives[1]. 1. htt
11.
by localvoid 4y ago
> (and Solid which is quite similar to React) How is it similar when React lets you write non-incremental algorithms when you working with your state and with Solid you are forced to write incremental algorithms? Simple aggregate (GROUP
12.
by localvoid 4y ago
> I stated this very clearly, saying "complex implicit reactive effects seem fragile and difficult to debug and reason about". It is definitely easier to reason about dataflow in a good incremental library with dependency autot
13.
by localvoid 4y ago
> for example I hate dependency arrays It is also an optimization and I agree that it is worse in terms of DX than autotracking dependencies.
14.
by localvoid 4y ago
> I guess performance in some cases, but mainly better developer experience. It has better developer experience when you apply it to optimize performance. It is impossible to beat from-scratch recomputation in terms of DX.
15.
by localvoid 4y ago
> And if there are any other good resources out there, then do share! :) Unfortunately there aren't any good resources on this topics. Everyone is just focusing on a diffing and unable to see a bigger picture. In the end, all featur
16.
by localvoid 4y ago
It is an old idea with reactive graph created at runtime and direct bindings (knockout.js, etc), but as always, implementation is way more important than some abstract idea, and ~6 years ago Adam showed that it is actually possible to imple
17.
by localvoid 4y ago
> then diffed with the real DOM Diffing with real DOM is slow, majority of vdom libraries aren't diffing with real DOM. As an author of a "vdom" library, I don't like to think about "reconciler" as a diffing
18.
by localvoid 4y ago
No, solid.js is building reactive graph at runtime and in theory should be able to also detect static inputs at runtime (not sure how much effort he put into reactive graph optimization techniques). Personally, nowadays I prefer S.js/s
19.
by localvoid 4y ago
> It's a very simple approach and very, very hard to beat in the fast/small/simple/buildless tradeoff space. Author of the ivi library here. Completely agree with an idea that such approach could lead to a better perf
20.
by localvoid 7y ago
Your library has the same issue. Also, you are using linear search[1] when removing edges. 1. https://github.com/luwes/sinuous/blob/e33c5e8bcdb461be61f7d0...
21.
by localvoid 7y ago
All "top ranked" libraries that use fine-grained observables graph in this benchmark are actually "broken"[1]. 1. https://github.com/ryansolid/solid/issues/46
22.
by localvoid 8y ago
> this far outweigh the extra O(N) memory consumption. Calculating memory overhead for vdom is actually pretty hard. With imperative code there will be several different code paths for initial rendering, updates and removal, and dependin
23.
by localvoid 8y ago
Full disclosure: I wrote a vdom library ivi[1]. Being fast is not just about micro updates, I think that most vdom authors don't care too much about micro updates performance because it isn't a bottleneck. For example, Virtual DOM
24.
by localvoid 8y ago
I hope you are aware about this attack vector[1] that was fixed in React long time ago. 1. http://danlec.com/blog/xss-via-a-spoofed-react-element
25.
by localvoid 8y ago
To make element visible, you need to attach it to the document :)
26.
by localvoid 8y ago
I am finally figured out how to do it with Surplus :) Its documentation is super confusing, first it talks that there are no lifecycle hooks, but then I see lifecycle hooks[1], then it talks that there are no diffing, and then I see ineffic
27.
by localvoid 8y ago
When you don't have any information how ordered lists were transformed(data snapshots), there is a huge difference between basic values when you can assign the latest value, and ordered list where you need to figure out how to rearrang
28.
by localvoid 8y ago
Sorry that I can't clearly explain this problem to you, and you obviously don't understand about what I am talking. Maybe you can try to think about ordered lists and complex data transformations, not just basic values. Or maybe I
29.
by localvoid 8y ago
> S.js already handles that for you but at the data model level It only works as long as it is able to track changes, many client-server applications doesn't send you list of changes that you should apply to your data, they just sen
30.
by localvoid 8y ago
> Clearly anything with only 10% overhead over vanilla JS is definitely fast enough And now is the main question :) If virtual dom is competitive in benchmark that is super biased towards direct data bindings libraries, what is the point

More ›