undefined

points

[-]

> The react model - where you just update the global state and re-render everything - is slower but easier on the brain. The signals model is faster, but so much effort.

there are multiple frameworks now that do fine-grained diffing without relying on signals, proxies, or any other reactive primitives. they basically have the top-down react model but much faster and without the weird concepts like hooks and manual/wasteful dependency arrays.

my favorite one is ivi-js: https://github.com/localvoid/ivi

it's just 8% slower than the fastest / ugliest / imperative / unmaintainable vanilla js you can eventually arrive at if all you care about is winning benchmarks.

https://krausest.github.io/js-framework-benchmark/2025/table...

by localvoid11 hours ago|

parent|

[-]

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()` :)

1. https://github.com/tc39/proposal-record-tuple

by leeoniya7 hours ago|

parent|

[-]

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

by localvoid3 hours ago|

parent|

[-]

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

by troupo6 hours ago|

parent|

prev|

[-]

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

by leeoniya5 hours ago|

parent|

[-]

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

by troupo3 hours ago|

parent|

[-]

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.

by localvoid3 hours ago|

parent|

[-]

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.

by leeoniya1 hours ago|

parent|

[-]

that's a better distillation :)

by jraph11 hours ago|

prev|

[-]

> The react model - where you just update the global state and re-render everything - is slower but easier on the brain.

I would gladly take easier on our hardware, bandwidth and planet even if a bit harder on the developers' brains. (as a developer).

> Most apps out there don’t need to be crazy fast

I wish we recognized that we need apps to be lean.

> and people will choose react because it’s just simpler.

I think you are right, and I dislike React for this.

by dragonwriter15 hours ago|

prev|

[-]

> Microsoft tried (and failed) at defining a ton of models, MVC, MVP, MVVM, and what not,

Microsoft used those at various times, but the only one it defined was MVVM.

MVC was Xerox PARC, MVP was Taligent.