Viewing profile — localvoid

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 interes…

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 p…

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/u…

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 tha…

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 commun…

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 "si…

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 othe…

> 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 figur…

> 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 C…

> 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 an…

> (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 …

> 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…

> 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.

> 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 …

> 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 un…

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…

> 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 abou…

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 optimiz…

> 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…

Your library has the same issue. Also, you are using linear search[1] when removing edges. 1. https://github.com/luwes/sinuous/blob/e33c5e8bcdb461be61f7d0...

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

> 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…

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 becau…

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

To make element visible, you need to attach it to the document :)