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.
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()` :)
> The biggest constraint when developing an efficient UI framework with good DX is JavaScript.
for perf, s/JavaScript/DOM, i think.
good DX comes from ecosystem and amount of time invested in making good tooling. JSX would be a non-starter without IDEs helping autocomplete, linting/format, syntax coloring, and webpack/babel to do the compilation.
tagged templates could reach at least the same level of DX as JSX if the community invested the resources to make that better. i'm not saying it's the right solution for a standard, but it would be way better than jsx, since tagged templates are already a standard.
> JSX would be a non-starter without IDEs helping autocomplete, linting/format, syntax coloring, and webpack/babel to do the compilation.
and then you immediately go on to say this:
> tagged templates could reach at least the same level of DX as JSX if the community invested the resources to make that better.
So, tagged templates are also non-starters without IDEs helping autocomplete, linting/format, syntax coloring.
> i'm not saying it's the right solution for a standard, but it would be way better than jsx, since tagged templates are already a standard.
They are strings. There's no magic in tagged templates that somehow make them immediately better for some custom non-standard syntax compared to JSX.
You can't just plop a string containing lit's custom non-standard syntax into an IDE (or a browser) and expect it to just work because "it's tagged templates are standard".
For the purpose of templating in the browser there's literally no difference between standardizing a custom syntax based with JSX or tagged templates.
> There's no magic in tagged templates that somehow make them immediately better for some custom non-standard syntax compared to JSX.
they're marginally better since they have a platform-defined way to deliniate static from dynamic parts. ivi _can_ work without a runtime or build-time JS parser, while JSX cannot (because jsx has to be parsed out of full blobs of js)
on the dx/ide side, sure there's not a huge amount of difference if both had the same effort invested.
In the context of "let's create a native templating syntax for the browser" those differences between JSX and tagged templates don't matter. You still need something that the browser needs to parse and understand, you still need something for libs/frameworks to handle/understand/compile to.
My feeling is that tagged templates would actually be a worse fit in this scenario because now you would have to distinguish between "regular" tagged templates and "templating" tag templates.
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.
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.
Vue.js is and isn't. It did ""fine grained reactivity getter setter proxy something"" before it was cool [0].
At this point I can't stop myself from pointing out that the underlying reactivity/diffing system is rarely what makes an application slow. I've heard the creator of XState and Stately [1] say that React's vdom is not fast enough for updating edges in their state chart in real time without lots of optimisations and I believe him. It's just that most people don't encounter such issues and spend adding a dozen tracking scripts that run before the actual application does.
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).
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.
> 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.
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].
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.
> 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 :)
It's a matter of opinion at best, for example I hate dependency arrays, and rules of hooks I find very weird, I understand why they are there, but to my brain they just fundamentally feel like workarounds for the lack of signals.
