I can only imagine the views exploding for a modestly complex site. For my small apps, I could do everything in one view that took three or more views with HTMX. create layers of interactivity that update lower layers automatically) and is centered around full page requests/diffs and less focused on injecting small page fragments everywhere. For an alternative, take a look at Unpoly which has more batteries included (i.e. It's a huge step forward! However, for my tastes it demands too many tiny views and micromanaging, which somewhat felt like a drag on my productivity. This was almost exactly my first impression of HTMX as well. Splitting off small small views to return just the right html after a hx-post is more labor intenstive than i would like, bit overall it's nice. If you start out knowing you will do HTMX, then I found everything is much easier. Overall I'd give it a silver-coated bullet rating. The way it cascades htmx values down the tree is really handy, and lends itself to consise attributes on the html. I've ended up using a lot of HX-Refresh in responses (causes a page refresh) because it was easier to do that than to ensure all the different parts of the page updated at the right time. The hardest part I found was being able to have a fine level of control around the user experience, and solving that required adding a lot of javascript, which made me wonder if it was worth the effort and should have instead just used Vue to handle it. I pick the tool based on the the amount of interactivity I need on the page. In the system I've used a mix of regular django templates, some Django unicorn, some HTMX, and some HTMX+Alpinejs I've used it a fair bit in a equipment finance app I have built for a small company. Is there a way to use htmx without forfeiting the benefits of CSP? I know there's hx-disable, but this degrades CSP's effect from "secure by default" to "secure when the developer remembers to mark the subtree as containing user-controlled data." The attacker can inject JS through htmx directives. Htmx is compatible with CSP, but it effectively reverses the protection it offers. And I'm reluctant to forfeit CSP to use a JS library since CSP is the most robust solution I've found for preventing XSS.Īlpine is working on a CSP-compatible build, but it hasn't been released and doesn't seem to be a priority. One of the hurdles I keep running into with libraries like htmx and Alpine is that they don't play nicely with Content Security Policy. I share your sentiments about SPAs, and I've been trying to get back to a simpler web stack. Thanks for sharing and for your work on intercooler.js and htmx! For this use case I think at some point we should move all the way into just delivering apps, if not native apps, something like wasm, where the browser tab would just be a vm player. On top of that, we pretend apps are documents and for all the imperative code we need we use a scripting language that was not meant for that, and we need a really complex VM just to keep it more or less performant. To deliver this, right now we have a browser that has become almost an OS inside an OS, to the point only Google can keep up with the complexity. This would be things like Google Docs, Photopea and most real-time games. Examples of this are Gmail and most social networks and forums including this one.ī) Desktop apps-but-I-don't-want-to-have-to-install-them. It should ideally be provided by the browser and htmx shouldn't need to exist. This can be provided by htmx and should always have been developed declaratively. Basically web 1.0 but today we want fancier transitions and interactions. For me this feels like finally jumping back to the good timeline.įrom the user point of view, I think there are two main types of experiences on the Web:Ī ) Interactive documents.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |