3 ms·

This looks really great! Can you mention some of the differences between Tetra and Unpoly? The full page diff approach Unpoly uses matches my mental model (and

This looks really great! Can you mention some of the differences between Tetra and Unpoly? The full page diff approach Unpoly uses matches my mental model (and follows Django's natural request/response cycle). It sounds like Tetra does something similar? In my tests, HTMX takes about half the time to render vs Unpoly. I assume HTMX is a lot faster than Unpoly because it's only processing fragments versus a full-page diff. How does the rendering speed with HTMX vs. Tetra's stack up if you've done any testing?

samwillis 4y ago
I'm not as familiar with Unpoly so this is based on limited knowledge. I think Unpoly is more based the concept of "frames" that can be changed dynamically, so in some ways it is very similar to HTMX with it's updating fragments. But I'm assuming it is diffing the DOM rather than just replacing it as HTMX does. Tetra on the other hand is very "component" focused, everything is built up out of nested components. These are rendered on the server and a diff/merge is performed by the Alpine.js Morph plugin to update the dom. So Tetra doesn't re-render the whole page, only the component that changes, therefore it probably sits somewhere between Unpoly and HTMX, but I have done no benchmarking. Tetra is also tightly linked to Python, each components server state is "frozen" and sent to the browser when it first renders (encrypted and signed). If you then call any public methods on the component the state is sent back to the server and "resumed". This makes the component fully statefull between server public method calls. Neither HTMX or Unpoly have this, you have to manually implement the end points for all updates. Tetra does that all for you. Compared with HTMX and Unpoly you should be writing less code with Tetra.
- infamia 4y ago
  > I think Unpoly is more based the concept of "frames" that can be changed dynamically, so in some ways it is very similar to HTMX with it's updating fragments. But I'm assuming it is diffing the DOM rather than just replacing it as HTMX does. That's fascinating, thanks for sharing. I will have to play around with Tetra. Based on your description, it certainly feels like, "Greetings. We are from the future." :-) My experience with HTMX and Unpoly is limited to building three prototypes (once each in HTMX and Unpoly). Based on that: * For Unpoly, you mark HTML elements that you want Unpoly to monitor/manipulate. Then some event happens (e.g. the user submits a form, clicks a link, etc.). * Then Django returns the entire page, just like an old school, web 1.0 app. * Finally, Unpoly looks at the entire page and finds the elements it's told to monitor/change. Then it swaps those elements in the DOM (if needed), which prevents a page reload. You should look at Unpoly to see if it sparks any ideas. Its layers feature [0] in particular is really awesome. In the link below, it shows how to (from a high level) use layers to build something pretty complicated like Gmail, while keeping the back end code relatively simple using any SSR framework (Django, Rails, etc.). [0] https://unpoly.com/tutorial https://unpoly.com/tutorial

samwillis 4y ago

I'm not as familiar with Unpoly so this is based on limited knowledge. I think Unpoly is more based the concept of "frames" that can be changed dynamically, so in some ways it is very similar to HTMX with it's updating fragments. But I'm assuming it is diffing the DOM rather than just replacing it as HTMX does. Tetra on the other hand is very "component" focused, everything is built up out of nested components. These are rendered on the server and a diff/merge is performed by the Alpine.js Morph plugin to update the dom. So Tetra doesn't re-render the whole page, only the component that changes, therefore it probably sits somewhere between Unpoly and HTMX, but I have done no benchmarking. Tetra is also tightly linked to Python, each components server state is "frozen" and sent to the browser when it first renders (encrypted and signed). If you then call any public methods on the component the state is sent back to the server and "resumed". This makes the component fully statefull between server public method calls. Neither HTMX or Unpoly have this, you have to manually implement the end points for all updates. Tetra does that all for you. Compared with HTMX and Unpoly you should be writing less code with Tetra.

infamia 4y ago
> I think Unpoly is more based the concept of "frames" that can be changed dynamically, so in some ways it is very similar to HTMX with it's updating fragments. But I'm assuming it is diffing the DOM rather than just replacing it as HTMX does. That's fascinating, thanks for sharing. I will have to play around with Tetra. Based on your description, it certainly feels like, "Greetings. We are from the future." :-) My experience with HTMX and Unpoly is limited to building three prototypes (once each in HTMX and Unpoly). Based on that: * For Unpoly, you mark HTML elements that you want Unpoly to monitor/manipulate. Then some event happens (e.g. the user submits a form, clicks a link, etc.). * Then Django returns the entire page, just like an old school, web 1.0 app. * Finally, Unpoly looks at the entire page and finds the elements it's told to monitor/change. Then it swaps those elements in the DOM (if needed), which prevents a page reload. You should look at Unpoly to see if it sparks any ideas. Its layers feature [0] in particular is really awesome. In the link below, it shows how to (from a high level) use layers to build something pretty complicated like Gmail, while keeping the back end code relatively simple using any SSR framework (Django, Rails, etc.). [0] https://unpoly.com/tutorial https://unpoly.com/tutorial