LLM made README.md flow better

Author: DeepDoge

README.md

@@ -16,23 +16,21 @@
     <b>purify.js</b> is a 1.0kB <i>(minified, gzipped)</i> 1.0kB DOM utility library, focusing on building reactive UI. 🚀
 </p>
 
-# Features 🌟🚀
+## Features 🌟🚀
 
 - 🔥 **Keeps you close to the DOM.**
 - ✍️ `HTMLElement` builder allows you to differentiate between attributes and properties.
 - 🌐 Builder doesn't only work with `HTMLElement`(s) but works with any `Node` instance including `ShadowRoot`, `DocumentFragment`,
   `Document`... any `Node` type, including future ones.
 - 🎩 Builder converts existing methods on the `Node` instance to builder pattern with `Proxy`.
 - ⚡ **Signal implementation that makes sense and useable.**
-- 🧙 **Signals are extendable,** allowing chaining with utilities like .pipe() and .derive() to build custom workflows..
+- 🧙 **Signals are extendable,** allowing chaining with utilities like `.pipe()` and `.derive()` to build custom workflows.
 - ✂️ Allows direct DOM manipulation.
 - 📁 No special file extensions.
 - 🔧 Only deal with `.ts` files, so use it with any existing formatting, linting, and other tools.
-- ⚡ **No extra LSP and IDE extensions/plugins:** fast IDE responses, autocompletion, and no weird framework specific LSP issues.
+- ⚡ **No extra LSP and IDE extensions/plugins:** fast IDE responses, autocompletion, and no weird framework-specific LSP issues.
 - ✅ **All verifiable TypeScript code.**
 
----
-
 ## Compare 📏⚖️
 
 ### Size ⚡📊
@@ -47,13 +45,13 @@
 | ReactDOM 18.2.0 | 130.2kB | 42kB       |
 | Angular 17.1.0  | 310kB   | 104kB      |
 
----
-
 ## Installation and Docs 📦🍙
 
-[jsr.io/@purifyjs/core](https://jsr.io/@purifyjs/core).
+[jsr.io/@purifyjs/core](https://jsr.io/@purifyjs/core)
 
----
+## Guide 📖🥡
+
+Coming soon.
 
 ## Examples 🍤
 
@@ -188,97 +186,96 @@ class CounterElement extends WithLifecycle(HTMLElement) {
 document.body.append(App().$node);
 ```
 
-## Guide 📖🥡
-
-Coming soon.
-
 ## Why Not JSX Templating? 🤔🍕
 
 - **Lack of Type Safety**: An `<img>` element created with JSX cannot have the `HTMLImageElement` type because all JSX elements must return
-  the same type. This causes issues if you expect a `HTMLImageElement` some where in the code but all JSX returns is `HTMLElement` or
-  something like `JSX.Element`. Also, it has some other issues related to the generics, discriminated unions and more.
+  the same type. This causes issues if you expect an `HTMLImageElement` somewhere in the code but all JSX returns is `HTMLElement` or
+  `JSX.Element`. It also has issues with generics, discriminated unions, and more.
 
 - **Build Step Required**: JSX necessitates a build step, adding complexity to the development workflow. In contrast, **purify.js** avoids
   this, enabling a simpler and more streamlined development process by working directly with native JavaScript and TypeScript.
 
-- **Attributes vs. Properties**: In **purify.js**, I can differentiate between attributes and properties of an element while building it,
+- **Attributes vs. Properties**: In **purify.js**, you can differentiate between attributes and properties of an element while building it,
   which is not currently possible with JSX. This distinction enhances clarity and control when defining element characteristics.
 
 JSX is not part of this library natively, but a wrapper can be made quite easily.
 
 ## Limitations ⚠️🦀
 
-- Since I use extended custom elements, safari doesn't support this yet, so if you care about safari for some reasons, use
-  [ungap/custom-elements](https://github.com/ungap/custom-elements) polyfill. You can follow support at
+- Since purify.js uses extended custom elements, **Safari doesn’t support this yet**. If you care about Safari for some reason, use the
+  [ungap/custom-elements](https://github.com/ungap/custom-elements) polyfill. You can follow support status at
   [caniuse](https://caniuse.com/mdn-html_global_attributes_is).
 
-  But I don't recommend that you support Safari.<br> _Don't suffer for Safari, let the Safari users suffer_
+  But **I don’t recommend that you support Safari.**\
+  _Don't suffer for Safari, let Safari users suffer._
 
 ## Future 🔮🦀
 
-- Right now, when a `Signal` is connected to DOM via `Builder`, we update all of the children of the `ParentNode` with
+- Right now, when a `Signal` is connected to the DOM via `Builder`, it updates all children of the `ParentNode` with
   `ParentNode.prototype.replaceChildren()`.
 
-  This is obviously not that great, previously at `0.1.6` I was using a `<div>` element with the style `display:contents` to wrap a rendered
-  `Signal` on the DOM. This was also allowing me to follow it's lifecyle via `connectedCallback`/`disconnectedCallback` which was allowing
-  me to follow or unfollow the `Signal`, making cleanup easier.
+  This is obviously not great. In version `0.1.6`, I was using a `<div>` element with `display:contents` to wrap a rendered `Signal` in the
+  DOM. This allowed tracking its lifecycle via `connectedCallback`/`disconnectedCallback`, making cleanup easier.
 
-  But since we wrap it with an `HTMLElement` it was causing problems with CSS selectors, since now each `Signal` is an `HTMLElement` on the
-  DOM.
+  However, wrapping it with an `HTMLElement` caused **CSS selector issues**, since each `Signal` became an actual `HTMLElement`.
 
-  So at `0.2.0` I made it so that all children of the `ParentNode` updates when a `Signal` child changes. Tho this issue can be escaped by
-  seperating things while writing the code. Or make use of things like `.replaceChild()`. Since all support `Signal`(s) now.
+  So, in version `0.2.0`, I made it so that **all children** of a `ParentNode` update when a `Signal` child changes. This issue can be
+  managed by structuring code carefully or using `.replaceChild()`, since all nodes now support `Signal`(s).
 
-  You might be saying "Why not just use comment nodes?": Yes, creating ranges with comment nodes is the traditional solution to this issue.
-  But it's not a native ranging solution, and the frameworks that use it break as soon as you mutate the DOM without the framework, which is
-  against the philosophy of the library.
+  Some might ask, _"Why not just use comment nodes?"_ Yes, using comment nodes for tracking ranges is a traditional solution. But it’s not
+  **a native ranging solution**, and frameworks that rely on it **break if the DOM is mutated manually**, which goes against this library’s
+  philosophy.
 
-  So to solve the core of this issue JS needs a real `DocumentFragment` with persistent children.
+  **The real solution?** JavaScript needs a **real** `DocumentFragment` with persistent children.
 
-  This proposal might solve this issue:
+  A relevant proposal:\
   [DOM#739 Proposal: a DocumentFragment whose nodes do not get removed once inserted](https://github.com/whatwg/dom/issues/736).
 
-  In the proposal they propose making the fragment undetactable with `childNodes` or `children` which I am against and don't like at all.
-  `DocumentFragment` should be a `ParentNode` should have it's own children, and can be `ChildNode` of other `ParentNode`. Normal hierarchy,
-  no trasparency other than CSS.
+  However, they propose making the fragment **undetectable** via `childNodes` or `children`, which I don’t support. A `DocumentFragment`
+  should be a `ParentNode` with its own children, and it should behave hierarchically like any other `ParentNode`.
 
-  But it's a good start, but just by having a real, working as intended, `DocumentFragment` we are not done.
+  But it’s a start. However, just **having a working DocumentFragment is not enough**.
 
-  Which brings be to the next point.
+- We also need a **native, synchronous, and easy way to follow the lifecycle of any `ChildNode`** (or at least `Element` and the proposed
+  persistent `DocumentFragment`).
 
-- We also need a native, sync and easy to use way to follow lifecycle of any DOM `ChildNode`, or at least all `Element` and this new
-  persistent `DocumentFragment`. Because without a lifecycle feature we can't bind a `Signal` to the DOM, start, stop/cleanup them
-  automatically.
+  An open issue on this:\
+  [DOM#533 Make it possible to observe connected-ness of a node](https://github.com/whatwg/dom/issues/533).
 
-  An issue is open here [DOM#533 Make it possible to observe connected-ness of a node](https://github.com/whatwg/dom/issues/533).
+  Right now, **Custom Elements are the only sync way** to track element lifecycle. This is why **purify.js heavily relies on them**. We
+  auto-create Custom Elements via the `tags` proxy and `WithLifecycle` `HTMLElement` mixin.
 
-  But also, DOM already has a sync way to follow lifecycle of custom `HTMLElement`(s). And since this is the only way, at this time we
-  heavily relay on that. Currently we use auto created Custom Elements via `tags` proxy and `WithLifecycle` `HTMLElement` mixin. And allow
-  `Signal` related things only on those elements.
+- If the above feature is not introduced soon, we also keep an eye on this proposal:\
+  [webcomponents#1029 Proposal: Custom attributes for all elements, enhancements for more complex use cases](https://github.com/WICG/webcomponents/issues/1029).
 
-- If this feature above doesn't come sooner we also keep an eye of this other proposal which has more attraction:
-  [webcomponents#1029 Proposal: Custom attributes for all elements, enhancements for more complex use cases](https://github.com/WICG/webcomponents/issues/1029)
+  This **doesn’t solve the DocumentFragment issue** but improves and modularizes `HTMLElement` lifecycles.
 
-  This proposal doesn't fix the issue with `DocumentFragment`(s), but improves and makes `HTMLElement` based lifecycles more modular and DX
-  friendly.
+  Currently, we use a mixin function called `WithLifecycle`, like this:
 
-  Right now, we have a mixing function called `WithLifecycle` which can be used like:
   ```ts
   WithLifecycle(HTMLElement); // or
   WithLifecycle(HTMLDivElement);
   ```
-  It adds a lifecycle function called `$bind()` to any `HTMLElement` type. Which can later be extended by a custom element like
+
+  It adds a `$bind()` lifecycle function to any `HTMLElement`. Later, it can be extended into a custom element:
+
   ```ts
   class MyElement extends WithLifecycle(HTMLElement)
   ```
-  Allowing you to create your own custom `HTMLElement` type with lifecycle. the `tags` proxy also uses `WithLifecycle` in combination with
-  `Builder` internally. so when you do `tags.div()` you are actually getting a `<div is="pure-div">` with a lifecycle. _But the `[is]`
-  attribute is not visible in the DOM since this element created by JS, not HTML_.
 
-  Anyway since this method requires you to decide if something is an element with lifecycle ahead of time, and also requires use to create
-  `pure-*` variant of native `HTMLElement` types in order to make them have lifecycle, it's kinda a lot. It makes sense. But it's kind of a
-  lot.
+  This allows defining custom `HTMLElement` types with lifecycles. The `tags` proxy also uses `WithLifecycle` internally.
+
+  So when you do:
+
+  ```ts
+  tags.div();
+  ```
+
+  You’re actually getting a `<div is="pure-div">` with lifecycle tracking. **The `[is]` attribute is invisible in the DOM because the
+  element is created via JavaScript, not HTML.**
+
+  However, since this method requires you to **decide lifecycle elements ahead of time**, it also means we must create **"pure-*" versions
+  of native elements**. While it makes sense, it’s a bit cumbersome.
 
-  So this new custom attributes proposal can let us have lifecycle on any `Element` easily by simily adding an attribute to it. And this can
-  reshape a big portion of this codebase. And would make things connected to lifecyle of the `Element` more visible in the DOM. Which is
-  great.
+  This is why the **custom attributes proposal** could significantly improve how lifecycles work. It would make lifecycle-related behavior
+  **explicit in the DOM**, which is a big advantage.