Re: [whatwg/dom] Proposal: a DocumentFragment whose nodes do not get removed once inserted (#736)

FrameMuse left a comment (whatwg/dom#736)

## Meeting Summary

### 🔑 Key Takeaways

- **Purpose of `GroupNodes`:** The proposal introduces a lightweight mechanism to group DOM nodes, aiming to facilitate operations like moving or updating node groups, particularly beneficial for server-side rendering (SSR) and hydration scenarios

- **Comparison with DOM Parts:** `GroupNodes` is viewed as a minimalistic alternative to DOM Parts. While DOM Parts offers extensive features, `GroupNodes` focuses on simplicity, potentially serving as a foundational primitive for more complex abstractions

- **Use of Comment Nodes:** Currently, comment nodes delineate group boundaries in the DOM. However, concerns about performance impacts and parser behavior suggest a need for alternative boundary markers or enhancements to existing parsing mechanisms

- **Framework Integration:** Framework developers, including those from SolidJS, express interest in `GroupNodes` for its potential to streamline code and reduce reliance on non-standard libraries

- **Implementation Considerations:** Discussions highlight the importance of ensuring that `GroupNodes` can operate efficiently without extensive DOM crawling or parsing, which are common in current library implementations

---

### 📌 Additional Insights

- **API Design:** There's a consensus on the need for a minimal yet expressive API that allows for batch operations on node groups without introducing significant complexity.

- **Hydration Support:** `GroupNodes` should seamlessly support hydration processes, enabling frameworks to rehydrate server-rendered content effectively.

- **Potential Evolution:** While starting as a minimal feature, `GroupNodes` could evolve to incorporate more functionalities, possibly aligning closer with DOM Parts or serving as a stepping stone toward more comprehensive solutions like template instantiation.

- **Standardization Goals:** Formalizing `GroupNodes` aims to unify disparate library approaches, promoting consistency and reducing the need for custom implementations across different framework.

---

### ✅ Next Steps

- **Assess Implementation Impact:** Evaluate how `GroupNodes` can be implemented since using Comment Nodes is negatively impacting performance. DOM crawling (and alternatives) and parsing should be evaluated as well.

- **Define Minimal API:** Collaborate to establish a core set of functionalities that provide value independently, ensuring that `GroupNodes` is beneficial even outside large framework.

- **Engage with Framework Authors:** Gather feedback from framework developers to understand real-world use cases and refine the proposal accordingly.

- **Explore Parser Enhancements:** Investigate the feasibility of parser modifications to support new boundary markers, reducing reliance on comment node.

---

### 💬 Notable Quotes

- **Anne:** "We shouldn’t shoehorn this into range; we should figure out what we wan."

- **Justin:** "If we release something minimal, then it doesn’t get usage, and then there isn’t motivation to move forward on improving it beyond the limited versio."

- **Steve:** "It would be valuable to try to make sure it’s valuable on its own, rather than only in large framework."

---

_Made based on the meeting notes with a help of ChatGPT._

Yes this looks very general, but this is basically how it was, I'm looking forward to next meeting to discuss more things deeply.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/736#issuecomment-2802695109
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/736/2802695109@github.com>