> Whenever the page changes—or the user explicitly saves the page—we grab all the HTML, make a few modifications, and then POST it to the backend’s “save” endpoint.
Wait, so instead of storing JSON we store HTML with all its verbosity and all its tags that have nothing to do with the user edit (e.g. a small profile description change) ? What about if the webmaster then wants to change the HTML title of the profile description block ? The user's version just diverged from the webmaster's ?
> instead of storing JSON we store HTML with all its verbosity and all its tags that have nothing to do with the user edit
Yes. In exchange, we get a portable, malleable, self-contained application. That's the tradeoff.
> What about if the webmaster then wants to change the HTML title
1. The webmaster owns my-app.hyperlay.com (or somecustomdomain.com).
2. The user forks their version and gets user-version.hyperclay.com (or user-version.somecustomdomain.com)
You need to fork before editing. In the future, we'll have support for shipping updates to forked applications that can be accepted or denied by the end users.
Do we need a story with illustration to understand how a new framework works ? What's the plain markdown 2 to 3 paragraph that explains the concept ?
Edit : here it is. https://docs.hyperclay.com/docs/docs-tldr-paste-in-llm/#how-...
> Whenever the page changes—or the user explicitly saves the page—we grab all the HTML, make a few modifications, and then POST it to the backend’s “save” endpoint.
Wait, so instead of storing JSON we store HTML with all its verbosity and all its tags that have nothing to do with the user edit (e.g. a small profile description change) ? What about if the webmaster then wants to change the HTML title of the profile description block ? The user's version just diverged from the webmaster's ?