3 ms·

I've been wanting to rewrite a side project SPA using htmx. I've never been that interested in Web Components, but it is an intriguing idea to use with htmx. It

I've been wanting to rewrite a side project SPA using htmx. I've never been that interested in Web Components, but it is an intriguing idea to use with htmx. It'd certainly make generating the HTML fragments server-side less complex to template. On a side note about htmx. Really compelling concept, I wish there was a larger community around it. Chicken and the egg kind of a problem, but there just aren't a lot of resources (blog posts, videos, etc) compared to many other web frameworks. Basic stuff like how do integrate something like Auth0 auth into an htmx app.

traverseda 3y ago
There is no "htmx app". You'd search for how to include auth0 in, say, a django app.
- pseudosavant 3y ago
  It seems like examples are usually oriented around specific popular SPA frameworks (e.g. React) or focused on an existing server side rendered app that you are adding interactivity into. I understand extending server-side way. The kind of stuff I used to do with jQuery back in the day adding interactivity into otherwise SSR pages. In a world of either SPAs or SSRs, htmx straddles the two. That is what makes it so interesting and unique, but it is also a different enough model to not always cleanly map from my pre-existing skills/patterns. For the app I'm doing, I'd really prefer to keep it an SPA. In that the URL never changes, and there is never a full page reload (outside of OIDC/sign-in). I'm sure I can get there, I just need to think about the architecture a bit. I'm kind of obsessive in this app about loading the app being nearly instant (I personally use it countless times a day). I really love the idea of returning back a full rendered page of HTML that wouldn't require any other API calls before showing the content. The current stack (which I hate, but it works, I wrote it, and so who am I going to blame?) - is PHP/MySQL. My concept for something that will be lower maintenance going forward (keeping up on PHP versions...ugh.) is to use Deno + oak + SQLite (running in Deno using WASM) on the server to render HTML fragments/pages, and htmx on the front end. With no build step and no database server to maintain.
infecto 3y ago
The community is relatively large but I understand what you are saying. I think really all you need to do is start using it. The HTMX api is minimal but powerful. At the end of the day you are requesting chunks of html that replace existing sections in your html. You are building an HTML driven app so your auth workflow is going to be whatever HTML can handle.
candiddevmike 3y ago
If your SPA is written in Typescript, you're going to throw away a lot of safety checks moving to htmx.
- hudon 3y ago
  A move from SPA means business logic moves to the backend and becomes hypermedia-driven, so the correct comparison if you want to think about type safety is if the backend server is type-safe. htmx is mostly declarative and its correct use could be statically checked with basic tools--it's not meant to contain complex logic.

traverseda 3y ago

There is no "htmx app". You'd search for how to include auth0 in, say, a django app.

pseudosavant 3y ago
It seems like examples are usually oriented around specific popular SPA frameworks (e.g. React) or focused on an existing server side rendered app that you are adding interactivity into. I understand extending server-side way. The kind of stuff I used to do with jQuery back in the day adding interactivity into otherwise SSR pages. In a world of either SPAs or SSRs, htmx straddles the two. That is what makes it so interesting and unique, but it is also a different enough model to not always cleanly map from my pre-existing skills/patterns. For the app I'm doing, I'd really prefer to keep it an SPA. In that the URL never changes, and there is never a full page reload (outside of OIDC/sign-in). I'm sure I can get there, I just need to think about the architecture a bit. I'm kind of obsessive in this app about loading the app being nearly instant (I personally use it countless times a day). I really love the idea of returning back a full rendered page of HTML that wouldn't require any other API calls before showing the content. The current stack (which I hate, but it works, I wrote it, and so who am I going to blame?) - is PHP/MySQL. My concept for something that will be lower maintenance going forward (keeping up on PHP versions...ugh.) is to use Deno + oak + SQLite (running in Deno using WASM) on the server to render HTML fragments/pages, and htmx on the front end. With no build step and no database server to maintain.

infecto 3y ago

The community is relatively large but I understand what you are saying. I think really all you need to do is start using it. The HTMX api is minimal but powerful. At the end of the day you are requesting chunks of html that replace existing sections in your html. You are building an HTML driven app so your auth workflow is going to be whatever HTML can handle.

candiddevmike 3y ago

If your SPA is written in Typescript, you're going to throw away a lot of safety checks moving to htmx.

hudon 3y ago
A move from SPA means business logic moves to the backend and becomes hypermedia-driven, so the correct comparison if you want to think about type safety is if the backend server is type-safe. htmx is mostly declarative and its correct use could be statically checked with basic tools--it's not meant to contain complex logic.