Readit NewsAll of that hard work, intended to build a business, and nobody is happy.
Now there's a hard fork.
This is shitty.
I intend to make my products source-available but not open source.
I do open source libraries/frameworks that I produce as part of producing the product, but not the product itself.
I don't like the term "rug-pull". It's misleading.
If you have an open source version of Zed today, you can keep it forever, even if future versions switch to closed source or some source-available only model.
I remember the Redis fork and how it fragmented that ecosystem to a large extent.
opt-out is not enough, specially in a program where opt-out happens via text-only config files.
I can never know if I've correctly opted out of all the things I don't want.
"Translated by Nancy Qanfar"
Dead Comment
You'd need to spec out what that looks like. It adds one new API from the users perspective but much more from the browsers perspective.
Additionally the next generation of Frameworks do not use virtual DOM. Solid and svelte do not. Vue is moving away from it. Signals are directionally where they're all heading.
It does not even require the target node to be created with a virtual dom in the first place. Just diff the node with the given tree structure efficiently.
Internally the browser might need to create a few accelerator data structures, but that's an implementation detail.
https://github.com/WICG/webcomponents/issues/1069
My proposal only adds one native function with nothing else: no new data types, no new apis.
More specifically, a native implementation of the "patch" function:
patch(target_dom_node, virtual_dom)
Most of the "slowness" of the DOM come from its requirement to be a 90's era Java style object hierarchy.
Don't call it "templating". Just call it "virtual dom". Everyone knows what that means.
You should show gratitude, not hostility.