3 ms·

While I think the "resumability" that Builder have developed for Qwik is very clever, I increasingly prefer the approach taken by HTMX and Alpine.js. Move back

While I think the "resumability" that Builder have developed for Qwik is very clever, I increasingly prefer the approach taken by HTMX and Alpine.js. Move back from JSON apis and render your html fragments on the server (you need to anyway!). It removes so much duplication of logic, simplifies your tool stack and reduces your risk of vulnerabilities. I would even be tempted to say, both "Hydration" and "Resumability" are workarounds. Attaching your event handlers to the DOM via HTML attributes rendered on the server à la HTMX, Alpine.js or god forbid even 'on{event}=""' attributes removes so much of this complexity. There will however always be places for client side html rendering though, the closer your webpage becomes to being an "App" the more likely you will need to do client side rendering, especially if you want to work offline.

AngeloR 4y ago
I haven't dug into Alpine.js, but I've been messing with HTMX on some personal projects for a few months now and am really pleased with it. It's honestly made it a pleasure for me to return to front-end work.
graboid 4y ago
I just had to do a site which involved a fair amount of interactivity. A sidebar with different types of filters, a search bar at the top, and a complex boolean filter builder inside a modal (think like infinitely-nestable AND/OR filters, where each filter involved 5 dropdowns interacting with each other). Then some area to collect the results and do some operations on them. I was feeling brave and decided to skip Vue which we otherwise use for complex UIs and do the whole page with HTMX and nothing else. And it worked. It took me longer, thats for sure, but also because I had to get a feeling for how to approach many things I would have just routinely plumbed together with Vue. And the feeling at the end was really satisfying, a fast-loading, complex interactive page, powered by ~10kb of Javascript, with all filtering logic, validation etc. completely server-side (we use ASP.net). And I have confidence it will work exactly as it is years from now. With our Javascript tooling, I expect things to break by that time. That said, I certainly pushed the library in parts, and the vote is still out on how easy it will be to understand the flow of interaction if some time has passed.
- yuretz 4y ago
  Just curious, if it's pure htmx, doesn't this mean that most of UI interactive actions do a roundtrip to the server to update the app state? Or have you used hyperscript for some parts?
  - graboid 4y ago
    Yes, no hyperscript, and yes, all interactive actions do a roundtrip. I tried not to get too detailed with the updates, so e.g. when you are in the filter builder dialog, and change the value of a select (and now the other selects have to change their data accordingly), the whole dialog is fetched again from server, instead of just the other selects. I felt that, while more selectively updating the UI would be more performant (htmx has to switch out less elements and the request payload is smaller), I don't want to cluster up my server with lots of small endpoints that return bits of HTML. All in all it was like 10 new endpoints returning HTML for that site, which was okay in my book. Could probably have been less if I had been more clever. What I learned was to really pay more attention to make my HTML "leaner" than normal, because I noticed that if I don't pay attention to that, payloads can get big quite faster than when using JSON.

AngeloR 4y ago

I haven't dug into Alpine.js, but I've been messing with HTMX on some personal projects for a few months now and am really pleased with it. It's honestly made it a pleasure for me to return to front-end work.

graboid 4y ago

I just had to do a site which involved a fair amount of interactivity. A sidebar with different types of filters, a search bar at the top, and a complex boolean filter builder inside a modal (think like infinitely-nestable AND/OR filters, where each filter involved 5 dropdowns interacting with each other). Then some area to collect the results and do some operations on them. I was feeling brave and decided to skip Vue which we otherwise use for complex UIs and do the whole page with HTMX and nothing else. And it worked. It took me longer, thats for sure, but also because I had to get a feeling for how to approach many things I would have just routinely plumbed together with Vue. And the feeling at the end was really satisfying, a fast-loading, complex interactive page, powered by ~10kb of Javascript, with all filtering logic, validation etc. completely server-side (we use ASP.net). And I have confidence it will work exactly as it is years from now. With our Javascript tooling, I expect things to break by that time. That said, I certainly pushed the library in parts, and the vote is still out on how easy it will be to understand the flow of interaction if some time has passed.

yuretz 4y ago
Just curious, if it's pure htmx, doesn't this mean that most of UI interactive actions do a roundtrip to the server to update the app state? Or have you used hyperscript for some parts?
- graboid 4y ago
  Yes, no hyperscript, and yes, all interactive actions do a roundtrip. I tried not to get too detailed with the updates, so e.g. when you are in the filter builder dialog, and change the value of a select (and now the other selects have to change their data accordingly), the whole dialog is fetched again from server, instead of just the other selects. I felt that, while more selectively updating the UI would be more performant (htmx has to switch out less elements and the request payload is smaller), I don't want to cluster up my server with lots of small endpoints that return bits of HTML. All in all it was like 10 new endpoints returning HTML for that site, which was okay in my book. Could probably have been less if I had been more clever. What I learned was to really pay more attention to make my HTML "leaner" than normal, because I noticed that if I don't pay attention to that, payloads can get big quite faster than when using JSON.