Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature]: Replace the current View for the core editor UI components #2282

Open
pouyamiralayi opened this issue Sep 19, 2019 · 3 comments
Open
Labels

Comments

@pouyamiralayi
Copy link

pouyamiralayi commented Sep 19, 2019

Hi there! the currently used structure of grapesjs is based on leveraging backbonejs model-view concept for implementing the Virtual Dom inside the ecosystem of grapesjs. Virtual Dom is a great practice which has a vast area of applications and benefits; but the downside of virtual dom is the actual gap between virtual and actual dom itself, what this means is that the usage of virtual dom is some sort of performance sacrifice in order to achieve the model-view concept which is the already established architecture of grapesjs, react, vue & etc.
based on the real-time nature of grapesjs and its ability to manage thousands of model objects based on each user interaction, there are cases that performance is poorly appreciated on model updates that as it's result there would be no real-time experience for the end user. as an example of this scenario think about calling addAttributes for property changes on a complex component type that will be invoked every time the end user provides us with new inputs in the associated trait section; each time that user presses a key, there would be a noticeable delay for the model to updates the attributes of the target component according to the user input.
my proposal on this matter is to get rid of virtual dom in the sack of hyperhtml that benefits from actual dom that are bounded to a context object that acts as our current model. the way hyperhtml is achieving the model-view concept for actual dom is leveraging js native template literals and it's associated chunks and interpolations. i know this is a very scary taboo for the current implementation :) but i think if grapesjs architecture has been started up with backbone, the sub parts of the ecosystem should not follow the same lead although this is a common implication in the development path of a complex project like grapesjs; backbone can be really tempting to push developers mind to go with it until the end, but i am suggesting more flexibility by separating grapesjs into a solid core with backbone and all the other parts leveraging hyperhtml to introduce a more lightweight, performance friendly ecosystem that embraces the future with no fear of performance breakdowns.
i am a very naive developer and please forgive me if i am going wrong with this.
hyperhtml
cheers.

@artf artf changed the title [Feature Proposal] hyperhtml as a replacement for virtual dom [Feature]: Replace the current View for the core editor UI components Aug 10, 2023
@artf artf added the feature label Aug 10, 2023
@lexoyo
Copy link
Contributor

lexoyo commented Nov 30, 2023

Nice idea
I use lit-html quite lot, it's the same approach but also adds web components when/if needed
But i don't get where would backbone stop? And what would be without it. I guess it is a question that is broader about what @artf announced in the roadmap (taking things out of the core)

@artf
Copy link
Member

artf commented Dec 7, 2023

Yes @lexoyo the final goal here would be to stop relying on Backbone's View and migrate all editor UI elements to web components. In the end, there will be @grapesjs/core (no UI) and @grapesjs/core-ui with a set of reusable and extendable web components for the editor UI

@lexoyo
Copy link
Contributor

lexoyo commented Dec 7, 2023

Ok that's interesting :)
I can't wait to see that and i will contribute as much as i can

@artf artf mentioned this issue Jan 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: 📋 Accepted
Development

No branches or pull requests

3 participants