It is not about complex UI per se, it is about complex state. With jQuery, the State is duplicated in the DOM instead of mirrored and is very hard to keep in sync.
In sounds nice in theory, but in practice, it doesn't work out. The example linked is a good one, a popover, the underlying DOM disappears, but the "state" behind it remains at least a bit longer.
Out of curiosity, which is the internal framework used by VSCode ? Would like to take a look at that. According to Erich Gamma, there is no use of a UI framework just a conventional model-View-Presenter with JS/TS constructed HTMLElement components.
There is no such thing as "conventional" MVP, every implementation is slightly different.
It is not an official framework per se, but it is a framework nonetheless, except without comprehensive documentation and developer availability or much commercial value in investing your time to learn it.
The main point is that if you're arguing against React or any framework "because abstraction bad", you will end up with them anyways, enjoy:
Well, we will need to agree to disagree. I see some utility libraries in `base/common` for disposables management, eventing and actions that you are terming a "framework". I don't even know how I would use this as an independent framework outside vscode. Even if I could, the rendering and organization logic would be mine not delegated to fundamentally unique framework paradigms like React/Vue/Angular.
> I see some utility libraries in `base/common` for disposables management, eventing and actions that you are terming a "framework".
It is because you didn't look deep enough, VSCode for all intent and purposes has a "framework" that it is built on top of.
What is a frameworks anyways?
"Frameworks model a specific domain or an important aspect thereof. They represent the domain as an abstract design, consisting of abstract classes (or interfaces). The abstract design is more than a set of classes, because it defines how instances of the classes are allowed to collaborate with each other at runtime. Effectively, it acts as a skeleton, or a scaffolding, that determines how framework objects relate to each other."
If it walks like a duck, and quacks like a duck, it probably also Reacts like a duck.
> the rendering and organization logic would be mine.
This is cute and nice for a weekend project. But if you want to build commercially viable products or even a GA open-source software, "Mine" is of no value.
Good documentation, extensive testing, developer availability, on the other hand are far more important.
Clear (mostly one-way) data binding is definitely one of React’s strengths.
It appears that Puter handles templating with a pattern like:
let h = ``
h += `<div>${exampleContent}</div>`
h += `<div>${moreExampleContent}</div>`
$(targetEl).append(h)
And handles events in the traditional way:
$(targetEl).on('click', function () { /* do stuff */ });
Searching for “React” or “jQuery” in this thread, there are several other conversations with thoughtful comments about pros and cons. One curious tidbit that I learned is that Visual Studio Code doesn’t use a framework either and, like Puter, updates the DOM directly.
The main issue is that "$(targetEl).append(h)" is not idempotent.
This might seem like a small issue on the surface but as your application grows, this either becomes a big problem or you have reinvented React, Vue, or something similar, but without the extensive testing and developer/community availability. Which is essentially what VSCode does for example, using some sort of MVP* pattern.
