6 ms·
Let's make the worst Htmx
- sparse-Matrix 3mo agoBravo! I never would have thought this would be so simple. As a direct consequence of this exercise: I now know something about what, precisely, htmx does. cheers
- wren6991 3mo agoHuh, so every interactive event has a network request in the loop, with perceptible latency? And you still end up obligating client-side JS for the plumbing? I'd been meaning to look into HTMX but based on the content of this post it seems like a worst-of-all-worlds technical solution. Is it at least pleasant to work with?
- dmoreno 3mo agoThat's why many times HTMX is used together with alpinejs [1]. For areas that need server side, if you use say react and return a JSON you have to deserialize and do the render. It might be much more efficient to just replace. Having said that I use HTMX /alpinejs for small projects, and still trust react for bigger more interactive ones. [1] https://alpinejs.dev/ https://alpinejs.dev/
- yawaramin 3mo agoNo, every interactive event doesn't need to have a network request in the loop. And you only need a tiny bit of client-side JS for a most of the plumbing. It is quite pleasant to work with, because you don't have to worry about a constant stream of vulnerabilities or supply chain attacks. You just vendornthe script in your repo, add it as a <script> tag on the page, and you're done.
- deadbabe 3mo agoWho is worrying? If JavaScript is on the front end the supply chain attacks are really not your problem.
- traverseda 3mo agoWhat? It handles your password fields.
- cpburns2009 3mo agoThe supply chain attacks you need to worry about come from using npm.
- Rohansi 3mo agoNo, it's not specifically npm. All package managers enable remote code execution by design - you tell it to download code and then you run that code, likely without sandboxing, by using it. Most people are not inspecting the code before they download and run it. You will still see compromised packages making their way through npm even though they disabled install scripts.
- cpburns2009 3mo agoI agree. I just pointed out npm because it's the most prominent javascript one.
- Rohansi 3mo agoSupply chain attacks are not a JavaScript or npm exclusive risk. If you pull in any dependencies you have a supply chain risk.
- barrkel 3mo agoAs is well known, security is not a binary, it's a spectrum. It's why you add security in layers, and why it's generally a trade-off between risk and usability. Your mileage may vary, but I sleep better with my own projects not having any node_modules in their build tree.
- robertoandred 3mo agoHow is htmx invulnerable to vulnerabilities and attacks?
- stymaar 3mo agoIt's not invulnerable, I think gp just means that reducing your amount of dependencies reduces the attack surface.
- inigyou 3mo agothe network is faster than so much shitty client-side JS these days.
- grebc 3mo agoWhen you say these days, I’d argue since mid/late 2000’s for internet with a cable vs. radio waves. Radio waves caught up in developed countries with 4G roll outs in my opinion(is that mid 2010’s?). Large client side JS has been garbage for most things since it’s inception.
- deleted 3mo ago[deleted]
- simonbarker87 3mo agoIt’s only has a network request in the loop if the interaction requires a network request. Htmx is a replacement for network interactions, not every bit of UI interactivity.
- muvlon 3mo agoIt's for building extremely backend-brained frontend stuff, like a sort of anti-NextJS. Also like NextJS, this sort of domain-bending has some unfortunate operational consequences.
- draw_down 3mo ago[dead]
- yyyk 3mo agoThe problem with HTMX is not network traffic but needing to use hyperscript for anything advanced.
- antihero 3mo agoAlso don't you entirely lose typing? My favourite thing about TSX is that it is typechecked. How do you do that with random strings of HTML?
- igor47 3mo agoI still write tsx and my components look very similar to react -- just no hooks. The difference is I render to html server side and send the rendered html. Look into it in hono
- JSR_FDED 3mo agoDatastar has a lean and mean signals implementation that handles all the front-end reactive stuff - so you don’t have to go to the server for interactivity.
- andy_parhelia 3mo ago[flagged]
- dang 3mo agoCan you please not post AI-generated or AI-edited comments to HN? It's not allowed here - see https://news.ycombinator.com/newsguidelines.html#generated https://news.ycombinator.com/newsguidelines.html#generated and https://news.ycombinator.com/item?id=47340079 https://news.ycombinator.com/item?id=47340079. Of course, it's impossible to know for sure what was LLM processed or not, but some of your posts (like this one) have been getting classified that way.
- pixel_popping 3mo agoThe Github link at the bottom contains a `,` char, might want to fix it.
- htmxxx 3mo agoWe already have the naughtiest htmx https://github.com/bigguysoftware/htmxxx https://github.com/bigguysoftware/htmxxx
- sodapopcan 3mo agoIs there something known wrong with github rn (aside from everything, I guess)? It claims there are 422 contributors but when you click in there are only three.
- ameliaquining 3mo agoChange the period from "last 3 months" to "all".
- sodapopcan 3mo agoI did. Still 3. But then I'd ask my original question that I didn't post: how the hell does this repo have 422 contributors?
- ameliaquining 3mo agoYou're seeing only three contributors at https://github.com/bigguysoftware/htmxxx/graphs/contributors?all=1 https://github.com/bigguysoftware/htmxxx/graphs/contributors...? I have no explanation for that, it doesn't match what I'm seeing. GitHub's contributor graph is based on authorship of Git commits, and doesn't track whether a given GitHub account ever actually interacted with a given GitHub repo. This Git repo is a fork of the htmx Git repo (though it's not marked as such on GitHub), so all contributors to htmx as of the fork date are also contributors here.
- sodapopcan 3mo agoAhhh makes sense if it's a fork. Odd that it's not marked as one. Sort of an odd thing that you can get associated with a repo you don't even know exists. Thanks for engaging me and my confusion.
- oaxacaoaxaca 3mo ago>Or you can just use htmx? great idea thank you for the recommendation
- n4pw01f 3mo agoHave a pretty large application running HTMX + WebComponents + Hono + Cloud Functions to serve up frontends, happy with it for about 2 years now People throw salt at my stack but it’s fast, and straightforward to manage attack surface
- esperent 3mo agoI'm using Hono + Tanstack Router as a Next.js replacement. Best software related decision I ever made, it feels like I stopped fighting with the stack.
- roundwego 3mo ago[flagged]
- Aeolos 3mo agoI highly recommend everyone to give htmx or datastar a try, especially if your main experience is react or nextjs. We recently rewrote a half-million LOC codebase from react to datastar, with a detour through htmx first, and the results are staggering. First page load is 20KB down from a 750KB js bundle. 1 network request vs 40+. Total load time 0.1 seconds down from 2 seconds of spinners. Page refresh is so fast, the browser doesn’t even flash - there’s no massive js bundle to parse, so it can start rendering instantly. But the most staggering result is that in-document navigation over SSE achieves up to 5000:1 compression ratio for network requests within the Brotli compression window. Yes, 5000:1, you read that right. When changing server state we rerender the entire page, like an immediate-mode game engine, and push it to the client over an SSE “fat morph”, in about 100 bytes. It’s so fast and so much more stable, our users are literally having fun. With a medical device. And this ends up ~50% less code to maintain for a VASTLY superior UIX. You are really missing out if you don’t learn how this works. It can give you a significant competitive edge if you care enough to try. Edit: Big BIG thanks to bigskysoftware and the datastar team for making the web a sane place again. You really deserve all the props.
- bramhaag 3mo agoSince you tried both, what made you choose datastar over htmx?
- andersmurphy 3mo agoA focus on morph by default means you don't have an explosion of endpoints and can write programs like the 300 redirect days. [1] Once you want realtime/collaborative app SSE + morph lets you do that easily. Add streaming compression and this approach is suddenly crazy bandwidth efficient. For people coming from react this gives you v = f(state) over the wire. Lastly signals handle the edge cases where an out of bound morph would nuke your ephemeral client side state (mostly text input). You can do this in htmx but you are fighting the design the whole way. Turbo is a bit better but doesn't have signals. [1] https://dev.37signals.com/a-happier-happy-path-in-turbo-with-morphing/ https://dev.37signals.com/a-happier-happy-path-in-turbo-with...
- 3mo ago
- worthless-trash 3mo agoThey didnt mention the real side benefit of HTMX, and thats the twitter account memes.
- brettermeier 3mo agoNice, I really like this series, this made me really understand those web frameworks much better as before. Thank you.
- cyanregiment 3mo agoHTMX is amazing on paper, not in real life. It loses things like scroll position and text highlighting on re-render - it’s not high performance like React. This is for server sided or static web pages not building rich UI. There is no robust state management or DOM performance improvements you get with React with larger components. HTMX team should build a game with it. Load some 3D in WebGL/WebGPU, showcase high performance UI. Or showcase complex state management. I need more than syntax idealism.
- vb-8448 3mo ago> HTMX team should build a game with it. Load some 3D in WebGL/WebGPU, showcase high performance UI. Why? Why you'd pick htmx (or even reactjs?!?) to build a game?
- cyanregiment 3mo agoBecause I would need to see a UI paradigm prove it can handle performance before considering using it for UI. react-three-fiber solves a lot of problems. React state is also perfectly in line with game loop architecture, r3f unifying the Three.js/React render loop is incredibly good for game dev. But even for SaaS or whatever, I need to know that it can handle complex states of the UI - HTMX can't. They are overselling it. It's not really a competitor to React, it's more like a competitor to Jade templating or HAML which nobody already uses anymore.
- vb-8448 3mo agoIf I have to build something that is basically logic on backend, forms, tables, some static pages, some interactivity here and there(btw is what most of the sites and web apps out there are) I don't need 3d or game engine capabilities ... And no way react is going to be faster for the above use case. You miss the point of tools like htmx/datastar/turbo/unpoly/alpine, they are not a react competitor in the rich and complex web apps space. They fill a gap between the native browser capabilities and tools like react/vue/svelte/ecc.
- ErroneousBosh 3mo agoI wrote a really tiny web app using Django and HTMX to do a find-as-you-type telephone directory, and it worked really well. I wish I did more front-end stuff so I could play with it more.
- cpburns2009 3mo agoI really want to try htmx but it specifically prohibits my most common usecases: 1) I want to take a JSON response, create HTML from it, and replace the target element with the generated HTML. 2) Similar to the above, take a JSON response, perform some action, and do nothing to the source element. Is there a plugin to add this? I want to move away from jQuery, and having a small framework to wire up hooks would be useful.
- igor47 3mo agoWhy are you so wedded to JSON responses? HTMX is meant to be used to render html; my big HTMX app basically never(1) renders JSON, so much so that I have a standing instruction to coding agents that if they're rendering JSON they're probably doing something wrong. If you're attached to JSON because you're working with external API s you don't control, a good place to perform those kinds of actions is in your backend, which can then return html to your frontend (1) the exception is I think in one place concerned a flow for uploading images, where client side requests a signed url, uploads to that url, then registers completion. Getting the signed url back is JSON meant for the uploader
- wasting_time 3mo agoI made a UI with htmx, it works great. But now I want to add a JSON API to the program: I could reuse the same routes (/create, etc), but require an application+json header; or add a full /api/ component essentially duplicating the logic from the main app. Neither option is great.
- igor47 3mo agoI do get kind of annoyed that htmx submits forms using form url encoding. It's non trivial to validate, see https://igor.moomers.org/posts/zod-schemas-htmx https://igor.moomers.org/posts/zod-schemas-htmx As a result for POST requests you have to have htmx routes that accept urlencode and API routes that accept JSON, and JSON is far superior. But for outputs I actually think separating your UI and API is helpful. The code reuse is not worth the entanglement of concerns.
- stevoski 3mo agoPart of the beauty of htmx is how simple it is to recreate. As this post shows, the fundamental concepts of htmx really are straightforward. Of course, there are all sorts of edge cases and minor features to add to make it complete.