tui.el icon indicating copy to clipboard operation
tui.el copied to clipboard

Is reconciling really make sense?

Open cireu opened this issue 4 years ago • 1 comments

Hi ebpa! I' m interesting on your project because I' m looking for a framework to create extensible UI program.

I am wondering dom node reconciling doesn't worth its overhead while rendering. I have to claim that I'm not a regular frontend developer, but I investigate some famouse frontend UI framework like React, Preact, Vue, etc.

These framework do the Vdom reconciling because directly rewrite real DOM is expensive. Vdom diff can help reduce operation on real DOM.

However, we present our UI in Emacs buffer. operating Emacs buffer is lightweight because buffer data structure is tightly integrated with Elisp VM(unlike DOM object, which is far away from JS engine). We just need one call to "insert" and "delete-region" to update the buffer no matter how large the content is. What's worse, reconciling algorithm must implemented in Elisp, which is more complicated and slower than a native function call.

My guess is: Reconciling is over-complicated, We just delete original content and insert new one. It must be admitted that my argument lacks performance test data, so I'd like to dicuss this with you. Do you have any ideas on this? Thanks a lot!

cireu avatar Mar 04 '20 17:03 cireu

Hi, @cireu! Thanks for reaching out! I'd love to collaborate on improving the library's performance if you are interested.

I'd like to hear more about what algorithmic variations you have in mind. I recommend reading this article by Christopher Chedeau https://calendar.perfplanet.com/2013/diff/ for an overview on the basic React algorithm. The reconciliation algorithm is already quite simple and based on my experience with building large/complex UI's in Emacs is quite efficient compared to other UI logic like layout calculation.

So far in tui, I've relied on HTML-like elements as both as a familiar conceptual model and as an intermediate representation (like a dom/vdom). Could you describe a bit more what sort of architecture you are imagining? I'm super-interested in ideas about plain text interfaces. How does the UI model and a one-dimensional elisp buffer connect? Is there an intermediate representation of the UI? What happens if part of the UI/application updates? Does the entire UI re-render or just part? Are parts of the rendered UI cached elsewhere?

I know that's a lot of questions. No pressure about answering all of them; I'm just curious about the notion you have in mind about renders and updates. If you want to start spelunking in the tui code, one good spot is tui-marker-list.el - it's a doubly-linked list structure that's used for tracking segments of the rendered UI.

Also- if you have questions or want help with anything, feel free to open issues here, email me, or message me on Twitter ("[at]ebanders"). I'm going to keep this issue open for discussion about the dom/reconciliation.

ebpa avatar Mar 08 '20 04:03 ebpa

@cireu I'm going to close this issue, but please reach out if you'd like to discuss this topic further! Thanks for your interest :-)

ebpa avatar Jun 19 '23 04:06 ebpa