localvoid
Joined 12 years ago
Karma
75
Submissions
61
Member since
Sep 19
Recent submissions
Comment · 1 year 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.
Comment · 1 year 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 straightforward and it will be possible to implement a semi-efficient polyfill.
Personally, I don't think that it will have any significant impact, everyone will continue using React,Vue,Svelte and it is highly unlikely that they are going to adapt this new API.
Comment · 1 year 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 :)
Comment · 1 year 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 easier is "value types"[1], but unfortunately it seems that isn't going to happen anytime soon. The biggest constraint when developing an efficient UI framework with good DX is JavaScript. Also, it would be nice to have `Node.prototype.insertAfter()` :)
Comment · 2 years 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 frameworks (React, Vue3, Angular) are still using tree diffing or hybrid "signals"+tree diffing strategies.
In my opinion, one of the most interesting ideas to explore in this problem space is a hybrid solution: differential dataflow[1][2](model) + self-adjusting computations(view-model + view).
Comment · 2 years 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 computing - https://en.wikipedia.org/wiki/Incremental_computing
- Self-Adjusting Computation (Umut A. Acar) - https://www.cs.cmu.edu/~rwh/students/acar.pdf
- Introducing incremental (JaneStreet) - https://blog.janestreet.com/introducing-incremental/
- Incremental computation and the web (JaneStreet) - https://blog.janestreet.com/incrementality-and-the-web/
- Self Adjusting DOM (JaneStreet) - https://blog.janestreet.com/self-adjusting-dom/
- Self Adjusting DOM and Diffable Data (JaneStreet) - https://blog.janestreet.com/self-adjusting-dom-and-diffable-...
- Incremental Computation (Draft of part 1) (Rado Kirov) - https://rkirov.github.io/posts/incremental_computation/
- Incremental Computation (Draft of part 2) (Rado Kirov) - https://rkirov.github.io/posts/incremental_computation_2/
- Incremental Computation (Draft of part 3) (Rado Kirov) - https://rkirov.github.io/posts/incremental_computation_3/
- Towards a unified theory of reactive UI (Raph Levien) - https://raphlinus.github.io/ui/druid/2019/11/22/reactive-ui....
Comment · 3 years 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 implemented with `shouldComponentUpdate` optimization. Also, unlike majority of libraries on the left side of the table, ivi doesn't use any type of event delegation(implicit or explicit) to get better results, just plain old `addEventListener()` is used internally to attach event listeners.
Comment · 4 years 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 (2014-2015), and a lot of libraries copied that terrible idea without deep understanding why I've done it in the first place.
Comment · 4 years 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].
Comment · 4 years 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. http://intelligiblebabble.com/compose-from-first-principles/
Comment · 4 years 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 BY) use cases that your average junior developer will be able to solve in 5 minutes with React will be a huge problem even for experienced Solid developers. The only similarity is that it is also using JSX syntax, but with completely different semantics.
Comment · 4 years 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 autotracking ("Self-Adjusting Computation"[1]) than to reason about nondeterministic concurrent rendering in React :)
Comment · 4 years 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.
Comment · 4 years 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.
Comment · 4 years 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 feature-complete libraries implement diffing algorithms for dynamic children lists and attribute diffing for "spread attributes", so with this features we are kinda already implementing almost everything to work with DOM and create a vdom API, everything else are just slight optimizations to reduce diffing overhead. But working with DOM is only a part of a problem, it is also important how everything else is implemented, all this different features are going to be intertwined and we can end up with combinatorial explosion in complexity if we aren't careful enough. Svelte is a good example of a library that tried to optimize work with DOM nodes at the cost of everything else. As an experiment, I would recommend to take any library from this[1] benchmark that makes a lot of claims about its performance, and start making small modifications to the benchmark implementation by wrapping DOM nodes into separate components, add conditional rendering, add more dynamic bindings, etc and look how different features will affect its performance. Also, I'd recommend to run tests in a browser with ublock and grammarly extensions.
And again, it is possible to implement a library with a declarative API that avoids vDOM diffing and it will be faster that any "vdom" library in every possible use cases, but it shouldn't be done at the cost of everything else. But unfortunately, some authors of popular libraries are spreading a lot of misinformation about "vdom overhead" and even unable to compete with the fastest ones.