7 ms·
Less Htmx Is More
- deleted 2y ago[deleted]
- rpgbr 2y ago> Like any new tool, especially a tool that got popular as quickly as htmx, there are differing schools of thought on how best to use it. My approach—which I believe necessary to achieve the results described above—requires you to internalize something that htmx certainly hints at, but doesn’t enforce: use plain HTML wherever possible. That’s the path for ultimate long term functional web pages!
- Ringz 2y agoAgreed! TLDR: Use plain HTML wherever possible for long term functional web pages!
- freeamz 2y agoI have made many many web pages over the last 15 years of so that is for just a few months or days. What I do is archive it on way back machine, and if the page works on way back machine then that is my stamp of approval for the page. It can also tell you the page is self contained! It works pretty well with WebGL and event audio playlist. There is NO point of making web dev so complicated just because FANNG company are using the framework. It is designed for they corporate structure. Anyone else should NOT use FANNG based framework! For long term web, I stay way from SPA with a long stick.
- mycall 2y agoIn the pursuit of ultimate long term functional web pages, how does that affect maintainability, e.g. changing requirements? In my mind, the less characters used the less effort it takes to change it, but this might be obsolete thinking wrt AI assisted (or fully written) sites.
- rpgbr 2y agoI agree! As a journalist that codes his own site/blog, I've never took the time to learn anything more complex than good and old HTML and CSS to structure a page, and the short incursions I had in complex system (node, SCSS, frameworks), the returns for the kind of sites I developed was so little I couldn't be bothered to climb the learning curve. HTML + CSS + sprinkles of vanilla JS is the perfect recipe for readable, fast, and high resilient web pages.
- taneq 2y agoHaving been out of the web dev game (or at least ‘front end’ as you cool kids are calling it? ;) for a while, I was a little dismayed when I asked an LLM for a web page that did a specific thing. It required Bootstrap and Angular and a bunch of other stuff. Asked it nicely to redo it in plain HTML and JS and the resulting code was simpler and no longer then the original, with no external dependencies.
- chabska 2y ago> In practice, this is virtually impossible to get right Somehow every other JS frontend framework manages to hook into the History API just fine?
- t-writescode 2y agoThe way I read it is that there are frustrating edge cases that (at least the author) has run into, regularly, that would imply it's ... more difficult to custom handle that than to just let the browser do it.
- swiftcoder 2y agoThey do, but mostly they make this work by recreating the entire frontend ecosystem within that framework. Mix-and-match a history-aware JS library from outside the framework's ecosystem, and you may find it's less robust than you expect.
- ForHackernews 2y agoWhat? They all butcher it. On a weekly basis I make the the mistake of clicking some link to a site and find I can't hit the back button to escape. Maybe this is technically the site developers' fault, not the library devs, but it's a lousy experience for users.
- philipwhiuk 2y agoSometimes it's definitely deliberate
- ffsm8 2y agoHeh ,I actually once added a bug like that too. Angular has "redirect" routes (path matches with redirect to a new path). I didn't realize that this will make the back button effective unusable, because the redirected url will still be in the history unless you manually redirect with a bare component. Hence whenever someone used back, the redirect pushed them back to the route they just left. I just used it as I came from a backend perspective, where redirects are fine as there is a delay between the request and the redirect, giving the user the time to just double press back... Obviously not so with a JS redirect. I believe that continues to be an angular Anti-Feature to date.(Just checked, they still have it in their docs - without the ability to surpress the redirected history entry as far as I can see)
- t-writescode 2y agoI have used htmx just a little bit; but I have found htmx + solid.js for some small reactive components to be ... very, very pleasant and very much else of what this blog post says to be accurate. I've written a lot more html than I have in the past and it just ... feels good? html has upgraded quite a bit in the last decades since I learned it.
- DeathArrow 2y agoI thought HTMX is useful mostly for SPA style apps. If you want a website with individual pages you can mostly use HTML and a bit of vanilla JS for the stuff that needs to be dynamically updated.
- uzyn 2y agoIt's the other way around. HTMX is not suitable for client-side scripting heavy app like SPA. It's more for "traditional" AJAX-style web app.
- skydhash 2y agoAnd if you’re not building a very interactive desktop app, you have no need for an SPA.
- DeathArrow 2y agoHow would something like Facebook, Instagram, Netflix work and look if they weren't Spas?
- skydhash 2y agoThere's nothing inherent to those sites that warrant SPAs. Things that do warrant SPA are full blown apps like Gmail, Figma, Google Maps,... or if you're building a desktop-like dashboard like Synology NAS's.
- t-writescode 2y agohtmx gets rid of the "bit of vanilla js" and replaces it with "a couple very, very short tags" and then the backend returns partial html, making the experience seamless. It's written in Javascript, so yes, some vanilla JS can do the same thing; but this library makes that experience easier for the masses, and likely well-tested to the point where more trust can be given to it to be correct.
- kookamamie 2y ago> In my opinion, most websites should be using htmx In my opinion, in five years no one uses htmx, but another shiny toy. Hence, how about not starting to use it at all?
- mort96 2y agoThis applies to every single web framework/library, so I guess your point is that nobody should start making web things?
- kookamamie 2y agoIt kind of is - although, with a twist. I think most things done currently with the frontend "frameworks", could be achieved with standard HTML5+JS, without any "build steps" or other bloat involved. This said, there is a case for building on a commonly used mature platform, such as React, to speed up the development cycle and in order not inventing the wheel again.
- nevertoolate 2y agoNobody gets fired for buying IBM, I guess :(
- ffsm8 2y agoI don't share the opinion you've quoted there, but neither do I share yours. Hmtx isn't actually a shiny new toy, it's just a rebrand of intercoolerjs - and I found out about that one in 2014. That makes the time since it's inception to date longer then the time between initial react release and initial intercoolerjs release
- alexpetros 2y agoHi, author here. The full quote is: "In my opinion, most websites should be using htmx for either:", and then I list two cases where I think htmx is appropriate. In context, it's clear that I'm not saying "everyone should use htmx," but rather "if you are using htmx, here is how I recommend you do it." As for the shiny object concern, I have a talk (which you can also find on this blog) called "Building the Hundred-Year Web Service", that dives into that question.
- kolektiv 2y agoIt is amazing how quickly a simple, traditional, "collection of pages" type website actually works if you don't do annoying things to slow it down. Most websites would be absolutely fine if a) HTTP was used reasonably well to set things like cache headers, and so (as mentioned in the article) and b) if a load of user-irrelevant stuff like tracking and advertising code wasn't thrown in as well. A simple page with standard HTML, passably optimised assets where needed, and only the JS needed for actual functionality, should be almost instant on most modern connections.
- Manfred 2y agoI believe some of these issues are caused by framework abstractions. New developers learn the framework and never learn how HTTP and HTML work. Experienced developers have to learn how to punch through the framework to get to these features we get automatically with statically hosted assets.
- kolektiv 2y agoVery likely. I remember reading a while back about developers who thought of rendering things on the server side as novel, which was absolutely wild to someone who was writing web pages before JS was a thing! It's such a shame because HTTP + HTML is actually a very, very simple system to learn with literally decades of hard-won knowledge baked in (particularly HTTP and surrounding standards). People end up inventing incredibly complex solutions to problems that could have been alleviated by reading a few RFCs.
- thrance 2y agoI don't believe you can break past "absolute beginner" without learning some HTTP and HTML. Most JS frameworks aren't very good abstractions (which is fine).
- skydhash 2y agoThey know the keywords, but not how everything fit together, even in the basic sense.
- cientifico 2y agoI like Hotwire/Turbo more than HTMX because of its core philosophy: start by building a fully functional page without any JavaScript, and then layer in enhancements only as needed. That approach has stayed consistent for years and feels really straightforward to work with.
- JonoBB 2y agoThis is exactly how I use htmx. Is there an expectation that you use htmx differently?
- Ringz 2y ago> The idea here is that the website still has a sound URL structure, which is managed by the core browser functionality, while interactivity is carefully layered on top, with targeted updates. It’s a long time since I have to work with websites. JQuery was the hot stuff back then. But we didn’t used it. It was all HTML and a Java backend. This sentence implies that right now basic stuff isn’t managed by the browser (but by React, Vue and so on?) which seems to be simply wrong.
- CharlieDigital 2y ago> This sentence implies that right now basic stuff isn’t managed by the browser (but by React, Vue and so on?) which seems to be simply wrong. That's exactly what's happened. A React SPA .html is just an empty shell. A Next.js app renders HTML using React on the first load and then becomes an SPA on the client.
- intrasight 2y agoWhile I agree that full page refreshes probably shouldn't use HTMX, I'll also claim that it's pretty rare that you would do a full page refresh. Almost every website I create has context that is present on every single page. Typically the branding at the top and the site map at the bottom does not change and hence there are no full refreshes.
- JodieBenitez 2y agohence why unpoly targets the <main> element by default: https://unpoly.com/up.fragment.config https://unpoly.com/up.fragment.config
- can3p 2y agoThere are two sides to the argument which I think should be treated separately: a) Is it a good idea overall? and b) is htmx implementation good enough? a) I think so, yes. I've seen much more spa that have a completely broken page navigation. This approach does not fit all use cases, but if you remember that the whole idea of htmx is that you rely on webserver giving you page updates as opposed to having a thick js app rendering it all the way it makes sense. And yes, js libraries should be wrapped to function properly in many cases, but you would do the same with no react-native components in any react app for example b) I don't think so. htmx boost functionality is an afterthought and it will always be like this. Compare it with turbo [1] where this is a core feature and the approach is to use turbo together with stimulus.js which gives you automagical component life cycle management. Turbo still has it's pains (my favorite gh issue [2]), but otherwise it works fine [1]: https://turbo.hotwired.dev/ https://turbo.hotwired.dev/ [2]: https://github.com/hotwired/turbo/issues/37 https://github.com/hotwired/turbo/issues/37
- recursivedoubts 2y agohx-boost is an afterthought and we haven't pushed the idea further because we expect view transitions via normal navigation to continue to fill in that area htmx focuses on generalizing hypermedia controls: https://dl.acm.org/doi/pdf/10.1145/3648188.3675127 https://dl.acm.org/doi/pdf/10.1145/3648188.3675127 we also have a minimalist version of the idea, fixi: https://github.com/bigskysoftware/fixi https://github.com/bigskysoftware/fixi
- can3p 2y agoThanks for the correction!
- evantbyrne 2y agoWould like to second the turbo rec. I've had good results with it for nontrivial use cases. Would like to hear from people if they have different experiences. Also, praying that everything gets cached first load and hand waving that view transitions will eventually work is not a position I want to hear from an engineer in a commercial context. Really happy to see the author bring more attention to how good vanilla web technologies have gotten though.
- axegon_ 2y ago> Updates that users would not expect to see on a refresh (or a new page load) I always hated this idea. As a user, a refresh indicates that something is happening and it's abundantly clear when something is wrong. People don't always handle errors and in all fairness they shouldn't - a developer has no way of knowing what custom stuff I have on my browser, whether I'm using any blockers or pi-holes or whatever and they should not know. Simple navigation, refreshes and server side rendering is something which worked great, the web was fast and could run on anything with a graphical output. These days a single page eats up 150+ mb while it loads. All that so the page doesn't "refresh".
- sgt 2y agoIt's not that smooth looking if a refresh takes 500 milliseconds. Then it flickers.
- foobahify 2y ago500ms means a slow connection, high latency or significant bloat. Optimising the page and using a CDN can help alot. It is a shame HTML doesn't have rel="swap" in links to "swap" in a new page.
- axegon_ 2y agoOh yeah a 15 second spinning circle and 250mb memory is sooooo much better than a 500ms refresh </sarcasm>
- sgt 2y agoI don't disagree with you :)
- earthnail 2y agoA 2s spinning circle may indeed be better than a 500ms flashing reload. Try it on your mom (“waaah why did it flash??”). I also dislike SPAs but there is business value in this slow spinner that you shouldn’t discount. Luckily, turbo or htmx solve this just as well. And maybe even more importantly, I can’t think of a modern browser that still flickers.
- seanwilson 2y agoAnyone replace some HTMX usage with the View Transition API that's now in Chrome and Safari? https://developer.chrome.com/docs/web-platform/view-transitions https://developer.chrome.com/docs/web-platform/view-transiti... This looks appealing where it makes sense (page transitions, table sorting/pagination) and if Firefox gets around to adding it.
- titaphraz 2y agoI really hope this won't become the new craze. The examples triggers all my irritation triggers. I couldn't use a website like that.
- _heimdall 2y agoI really want to like the transitions API but I've been frustrated by it multiple times. It feels like they wanted to build page animations similar to what Windows Phone had 15 years ago. That would be great, Windows Phone transition were surprisingly nice. It just doesn't work on the web though, its an after thought. Animations on windows phone only worked because it was designed into the UI library and rendering engine from the beginning.
- seanwilson 2y agoCan you go into more detail about what's frustrating? You can customize the animations, right?
- _heimdall 2y agoYeah you can customize them a bit. What I've always wanted to be able to do though is restyle the actual DOM element as it animates from one part of the screen to another. Unless this changed pretty recently, my understanding is that the browser is basically grabbing a screenshot of the DOM element before it navigates and animates the snapshot itself across the screen. I've also run into random issues related to having to tag the element targets. I don't remember all the details now so I can't give a great example, but especially when using libraries like HTMX I was having issues trying to make sure the right elements were tagged to animate correctly. Conditional animations can be done, though its a little odd to wrangle and you can end up with code mixed between HTML, JS, and CSS to work with it.
- echoangle 2y ago(2024)
- sgt 2y agoHow do you get flicker free navigation using htmx without using hx-swap or boost? I see that this article refers to https://unplannedobsolescence.com https://unplannedobsolescence.com which has a header that remains the same, but it also doesn't change. Normally a header will do some type of change, e.g. showing which menu item is currently selected. That's when the flickering starts, in my experience.
- anentropic 2y agohttps://htmx.org/essays/view-transitions/ https://htmx.org/essays/view-transitions/
- ahmetsait 2y agoBrowsers already have built-in mechanism to prevent flicker while switching pages, unless your page has issues such as flash of unstyled content or something similar.
- davedx 2y agoDoes anyone have examples of non trivial websites or apps built with Htmx?
- recursivedoubts 2y agotwo I know of: https://zorro.management/ https://zorro.management/ https://www.commspace.co.za/ https://www.commspace.co.za/
- foobahify 2y agoYes if you click a regular link in a modern browser on a noJS or lowJS reasonable size page it is darn fast. And the predictability is a boon. Open in new tab, back button etc.
- throw10920 2y agoWhile I get the emotional appeal, I still don't understand the use-case for htmx. If you're making a completely static page, you just use HTML. If you're making a dynamic page, then you want to push as much logic to the client as possible because far more users are latency-limited than compute-limited (compare [1] vs [2]), so you use normal frontend technologies. Mixing htmx and traditional frontend tech seems like it'd result in extra unnecessary complexity. What's the target audience? Edit: "Normal/traditional frontend" here means both vanilla (HTML+JS+CSS) and the most popular frameworks (React, Angular, Vue, Next). [1] https://danluu.com/slow-device/ https://danluu.com/slow-device/ [2] https://danluu.com/web-bloat/ https://danluu.com/web-bloat/
- pavlov 2y agoHtmx is “frontend tech”.
- deleted 2y ago[deleted]
- throw10920 2y agoI said "normal frontend tech" in my comment. It's also easy to tell from context what I mean. I'd appreciate not trying to be pedantic and instead responding to the substance of my comment :)
- pavlov 2y agoWhat defines normal? It’s a strange idea when the typical stack for web front-end keeps changing. There isn’t even a single answer to the client/server split. Is JQuery normal? What about the Google Closure compiler? ColdFusion? Silverlight? Ruby and CoffeeScript? Angular? SPA React with classes? Elm? SSR React with a server framework? Client-only vanilla DOM manipulation? Your idea of normal is presumably whatever you’ve been using for the past few years. For someone who starts using Htmx now, it becomes normal. And if there’s enough of those people, their idea of normal becomes commonplace.
- codemonkey-zeta 2y ago> “You didn’t solve anything! Doing validation is complex and you just magic wanded it away by designing a perfect interface for it.” Yes. Exactly. That is what interfaces are supposed to do. Better semantics make it possible for the programmer to describe what the element does, and for someone else to take care of the details for them. Gosh I couldn't agree more, what a wonderfully succinct way to communicate what I spend a ridiculous amount of time trying to explain to my colleagues when designing programs! [EDIT]: I just realized I had read this on one of the linked articles https://unplannedobsolescence.com/blog/behavior-belongs-in-html/ https://unplannedobsolescence.com/blog/behavior-belongs-in-h...
- panstromek 2y agoYea, in my opinion, hx-swap or turbolinks is a bit of an antipattern. Seems to me you get worst of both worlds: - something that kinda looks like full reload - but with all problems of client side routing - and without preserving the DOM state like SPA would - and you don't get the immediate response that is the main reason to build the SPA in the first place In fact, it's often even slower than native navigation, because native navigation can start processing the stream during download and there's overhead with pre and post processing of the response in the boosted link version. Try to profile GitHub links to see what I'm talking about, opening a link in new tab can be 2x faster than clicking in the same tab.
- ksec 2y ago>Triptych—the HTML proposals that Carson and I are working on—would render htmx obsolete for the type of website I describe here. Which we discussed here [1], is still no where near getting even looked at. Browser maker are not interested in anything HTMX. Vast majority of browser developers still want JS driven web apps, served with AVIF image. [1] https://news.ycombinator.com/item?id=42615646 https://news.ycombinator.com/item?id=42615646