15 ms·
htmx
- bluedays 3y agohow many times has this been posted here?
- vyrotek 3y agohttps://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=htmx.org&sort=byDate&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
- dmix 3y agoI count about ~6 generic submissions to htmx root domain or direct /docs with upvotes. More generally it's higher if you include blog posts or self-HN posts. The original submission had 728 upvotes: https://news.ycombinator.com/item?id=23330881 https://news.ycombinator.com/item?id=23330881 react.dev and reactjs.org has had 2 root url submissions: (728 upvotes) https://news.ycombinator.com/item?id=35186812 https://news.ycombinator.com/item?id=35186812 and older https://news.ycombinator.com/item?id=15366446 https://news.ycombinator.com/item?id=15366446 vuejs.org only had about ~1 meaningful root domain submission: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=%22vuejs.org%2F%22&sort=byPopularity&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... I suspect HTMX is more of an idea that people like to talk about on HN more generally, like Clojure and Erlang. Being the underdog matters on social media. Maybe it feels more authentic or relevant to discourse because it's still niche.
- sodapopcan 3y ago> I suspect HTMX is more of an idea that people like to talk about on HN more generally, like Clojure and Erlang. Being the underdog matters on social media. Maybe it feels more authentic or relevant to discourse because it's still niche. Pretty glib take. The more exposure this stuff gets the better. I'd really like to have more job options out there that don't involve maintaining an internal web API so that two applications you own can talk to each other.
- dmix 3y agoI might have been using HN too long but you start to notice some pet technologies everyone here loves to safely upvote on HN but IRL stays niche for a reason. Especially in the serious business world of software development, not side projects or stuff we like talking about on social media. And I say that as a big fan of both Erlang and Clojure.
- sodapopcan 3y agoIt can, though. Lots of enterprise apps are just page after page of forms, as was the one enterprise app I worked on. There's no reason those things need frontend frameworks talking through APIs to separate backends. It's good for jobs, of course.
- leke 3y agoNot enough
- laex 3y agoCan HTMX be used with static site generators, such as Hugo, to create interactive documentation websites?
- varenc 3y agoTechnically feasible? Absolutely. You can already create interactive documentation just with client side JS in your Hugo generated site. And HTMX is just a client-side JS system for building that sort of JS-required interactivity in HTML alone without directly touching JavaScript. That said, I don't think the tooling to make this simple to get started with in Hugo is there yet. Though you could certainly build it.
- cpitman 3y agoI think that unpoly(https://unpoly.com/ https://unpoly.com/) would be easier for that use case. htmx generally expects succesive http requests to only return the fragment of html that will be swapped into the target, not the entire page. So you generally want something server side that can check the request and either return the full page (either for a first hit or disabled javascript) or return just a fragment (an htmx request). Unpoly has similar goals to htmx, but by default works with full page responses, swapping only the identified content in the page.
- 0xblinq 3y agoUnpoly is great. I used it a few years ago for reimplementing the UI of an application built with a traditional MVC framework and I was impressed with the results. Nobody could tell it was not React/vue/etc from the outside and the frontend code was quite simple and minimal.
- adamckay 3y agoYou're correct that it's the general expectation, but it is possible to select certain elements from the response using `hx-select` [1], so it is possible, just not particularly efficient... [1] https://htmx.org/attributes/hx-select/ https://htmx.org/attributes/hx-select/
- earthboundkid 3y ago
- cosmojg 3y agoHeh, the "Memes" section of their Essays page is brilliant: https://htmx.org/essays/#memes https://htmx.org/essays/#memes
- vyrotek 3y agoAnd lots more if you follow him on Twitter. https://twitter.com/htmx_org https://twitter.com/htmx_org
- hliyan 3y agoI actually found their haiku quite insightful: javascript fatigue: longing for a hypertext already in hand
- shearos 3y agoso good
- winrid 3y agoThose are great. What's the logo of the cornucopia looking thing next to the django and rails logos?
- DarkCrusader2 3y agoFlask, a python micro framework.
- 411111111111111 3y agoA lot are also missing the point entirely for comedy's sake. Which is admittedly fine for a meme... While I love making projects with htmx, doing the equivalent for the complicated frontends we've got at my dayjob would not be enjoyable to maintain either. You'd end up with with fragment routes all over the place and will have serious issues finding where which is used, as the routes are all just strings with variable substitutions. Its also annoying to write non-e2e tests for the resulting backend IME, which is totally fine for a lot of applications, but forces you to restructure your code awkwardly to be able to write unit-tests in the backend
- chatmasta 3y agoI continue to be impressed at the effort people will put into avoiding writing any JavaScript. Is it really easier to learn yet another DSL embedded in attribute tags rather than taking a day to setup your JS dev environment and then writing idiomatic code for running inside a web browser? Surely your htmx project will eventually cross a complexity threshold where you've added enough scaffolding that you may as well have setup a JS bundler in the first place, and yet the debugging, testing and deploying challenges will continue to push you into less-trodden territory. I believe there might be a sweet spot for small projects unlikely to grow in complexity, maintained by a Python dev who is allergic to JS. But I don't see why you would want to invite yet another abstraction into the web stack, when it's built on top of the very language you're trying to avoid, and which you'll inevitably encounter in all its automagically obfuscated glory as soon as you run into a moderately complex problem.
- pphysch 3y agohtmx isn't about avoiding JS, it's about removing arbitrary limitations from HTML that have elsewhere been circumvented with JS. Users write less JS as a side effect of having an actually useful, modern "HTML", and with any luck the core features of htmx will eventually make it into standard HTML
- candiddevmike 3y agoThat makes no sense, HTML is by design not supposed to be dynamic, that's the point of JS. There's a nice, clean, separation of concerns with HTML, CSS, and JS. As an aside, htmx uses JS under the covers to make HTML dynamic.
- pphysch 3y ago> HTML is by design not supposed to be dynamic, that's the point of JS. You are putting far too much faith in the design of web standards. Anyways, here's a counterexample to your claim: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...
- mrcwinn 3y agoFor those with flexibility or a new project, also consider Phoenix LiveView. It’s been a joy to work with so far.
- graypegg 3y agoOr possibly Hotwire! (Turbo frames really) [0] Also found it to be wonderful to work with. [0] https://hotwired.dev https://hotwired.dev
- sodapopcan 3y agoThere are a variety of these types of frameworks for most peoples' favourite web-programming language (LiveView, Hotwire, LiveWire, Blazor...).
- llambda 3y agoHow does htmx compare with alpinejs (https://alpinejs.dev/ https://alpinejs.dev/)?
- earthboundkid 3y agoAlpine is more of a Vue replacement and HTMX is more of a fetch replacement. You can use both, although it’s a little redundant.
- halfcat 3y agoHTMX and Alpine pair well together. Generally, Alpine would handle pure client-side functionality, like toggling classes, expanding a drop-down multi-select, etc. HTMX for server interactions, fetching, posting updates, etc. One can accomplish a lot with little to no JS, with the app primarily driven by the backend. Which is quite a benefit if you know and like PHP/Python/Go/Elixir/C++ better than JS. Or just don’t like working in JS.
- jhp123 3y agoMy problem with this approach is the same one raised by Dijkstra against the goto statement. These update actions are too unrestricted and don't offer any way to analyze the program's progress systematically, based on the program source code.
- fallat 3y agoCould you elaborate? Genuinely curious.
- jhp123 3y agolet's say that you have an upvote button <button hx-post="/upvote" hx-trigger="click" hx-target="#notification-bar" hx-swap="outerHTML" > Upvote </button> Well where is this notification-bar? It could be anywhere on the page. Maybe it was introduced by another htmx action from another endpoint. Answering this simple question could take a lot of work. There is no way to work it out systematically short of auditing every interaction on the page.
- sodapopcan 3y agoHTML ids are globally unique so the answer is wherever `id="notification-bar"` lives.
- Semaphor 3y agoWhat’s the difference to writing vanilla JS to do the same thing?
- panic 3y ago"Load HTML from a URL and replace part of the page with it" is a powerful technique for progressive enhancement, even if you don't want to use a framework like this. A button can send users without JavaScript to the URL directly, while users with JavaScript can have that part of the page replaced inline.
- scoofy 3y agoI use htmx heavily on https://golfcourse.wiki https://golfcourse.wiki It’s nice and easy to work with, and lets me keep almost everything in python (flask). It’s a bit more bandwidth, but it’s a hobby/bootstrapped project right now, and since it’s an api, if I ever make any money, it’ll be easy to rewrite and heavy lifting. I like it because I’ll write 3x the code in the same amount of time if it’s python. I just don’t like js much even though I know it’s fine.
- rafark 3y agoThis is VERY cool. I’m very excited to see a project like this. Is it me or there has been a lack of wow-factor projects lately like when jquery was introduced. Or templating engines like handlebars. Or when angular and react took over. Browsing the htmx site felt like learning about those aforementioned projects for the first time.
- asah 3y agocan htmx be used offline? i.e. am I screwed if I load an htmx page, close a laptop and get on a plane?
- fredrikholm 3y agoIf the page has loaded, it's loaded. There's no moving parts once you have rendered HTML from the wire.
- whatscooking 3y agoAh yes…the daily htmx post
- recursivedoubts 3y agoi really have no idea why this is happening and am kinda nervous...
- replwoacause 3y agoYep, I’m delighted when I see it and then I give it my automatic upvote.
- robertoandred 3y ago“Aren’t you sick of new web frameworks? Here’s a new web framework!! It’s different and special because we said so.”
- jedberg 3y agoSeriously, why does this keep popping up? I get it, it's cool. But I feel like in a month we're going to see "How I gamed the HN front page to put my website on the top every day for a month".
- jaxrtech 3y agoThis vaguely reminds me of Adobe's ColdFusion except in the browser for better or worse.
- pbohun 3y agoThis is the first time I've been excited to learn about a new web technology in a while. I'm going to have to play around with this to see how I want to use it. I wonder what other little things like this could be used to simplify webdev?
- nneonneo 3y agoThe filler text on some of the examples (e.g. https://htmx.org/examples/tabs-hyperscript/ https://htmx.org/examples/tabs-hyperscript/) seems to be generated by Hipster Ipsum https://hipsum.co/ https://hipsum.co/. Cute. I kinda like the aesthetic. It feels a bit like what HTML might have looked like if XHR had been baked in.
- sgc 3y agoDoes this cause problems for web crawlers indexing sites, since these are not typical js event listeners etc? Even though they must use them in the background, there is an abstraction the crawler must be able to navigate. I had an entire site de-indexed for getting too fancy once, so I worry about this type of thing perpetually now.
- psnehanshu 3y agoIt won't matter as long as you are using regular `a` tags for links. You anyway don't want robots to submit forms and perform any actions that are meant for users.
- 8organicbits 3y agoI'd think HTMX would work with even the most basic of crawlers, since it doesn't require JS at all to be usable. But I don't know how well a JS aware crawler would do with it. I guess you could block htmx.js in robots.txt to force them to the non-JS experience?
- PrimeMcFly 3y agoI personally don't see the utility in this too much, but then I'm old fashioned and go out of my way to use as little JS as possible, doing everything via CSS as much as I can. Even though JS is ubiquitous and small, well written JS is harmless, I still try to avoid it like the plague. Maybe just to somewhat fight back against all the excessive JS that plagues every site.
- quacker 3y agoI'm old fashioned and go out of my way to use as little JS as possible The point of HTMX is to avoid writing custom JavaScript.
- PrimeMcFly 3y agoBut it does that by including a bunch of JavaScript and obscuring it. So not exactly including as little JS as possible.
- replwoacause 3y agoI love htmx and have used it to build internal tools quite successfully. It allows me to work in my preferred language on the backend, write some basic ass html and spinkle in a few attributes and get some frontend reactivity that I otherwise wouldn’t have because I hate Javascript.
- KevinChen6 3y agoLearning to use any new tool comes at a time cost, and if I learn this and then a newer, more convenient tool emerges that can replace it, I get stuck in the question. Are people driving the tools? Or are the tools binding people?
- emodendroket 3y agoPerhaps too cynical from my dislike of frontend but I sometimes suspect the churn is spicing up monotonous work for some people.
- KevinChen6 3y agoYes, I also don't like doing front-end development work, not because front-end development work itself is offensive, but doing front-end development work is a very meticulous thing, which requires me to invest a lot of time, which will reduce my energy investment in other work content.
- adamredwoods 3y agoI'm not a fan of adding functionality to hypertext attributes. I want an expected set of attributes to a component, not a new set of attributes that extend existing components. A lot of functionality can get obfuscated.
- emodendroket 3y agoStrictly speaking you could already do this with x- attributes and plain JS, right?
- L0stLink 3y agohow do you feel about JSX?
- chatmasta 3y agoJSX is a templating language, not hypertext.
- sandGorgon 3y agoHTMX + Java is almost as good as react! I think people mistake what htmx is - they think it is a way to not write react/js in a node environment. Where HTMX really shines is being able to bring the experience of writing React-like code without a nodejs environment in Java for e.g. (or Golang, Rust, etc)
- davidatbu 3y ago> Where HTMX really shines is being able to bring the experience of writing React-like code without a nodejs environment. FWIW, if that's all you're after, and you've mastered the Rust borrow checker, Yew (a React-like experience), or Leptos (a SolidJS-like experience) might be interesting to look at.
- sandGorgon 3y agonot its not the same thing. I work in Java (not rust), but the analogy will hold. Yew is writing Rust to create html. Same as Java Thymeleaf. Here's the problem - Java developers are bad at UI. And good UI designers/developers think in HTML. I am not pro or anti this situation...im just talking about the reality. The tooling is also around html. Figma-to-HTML is the most effective way to have your design cycle work. This is where HTMX shines. HTMX is just HTML++. It is is not Rust or Java. Which means your design cycles will continue to work.
- davidatbu 3y agoI never meant to claim "it's the same thing". I was just suggesting, if, by "react-like" code, you meant "a UI library that uses a vDOM to transform functionally written code into DOM nodes", Yew fits the bill. Also, typically, one writes JSX when writing react, not HTML. It's similar with Yew[0]. If you're already aware of Yew, I'm not trying to change your mind. I was just trying to make you aware if you weren't already. [0] It says so right on the homepage: https://yew.rs/ https://yew.rs/
- ulrischa 3y agoA lot of this what htmx does is a one-liner in Jquery. I know: the unpopular old thing :)
- TekMol 3y agoHmmmm... no. This: <button hx-post="/clicked" hx-swap="outerHTML"> Click Me </button> Should be just this: <button onclick="htmx.post('/clicked', 'outerHTML')"> Click Me </button> This way, no magic would be needed, a lot of indirection and complexity would be avoided and everybody who knows HTML and JS could immediately read and understand it: - When does something happen here? When the button is clicked. - What does happen? htmx.post() is called.
- the_gipsy 3y agoYou're missing the "swap".
- TekMol 3y agoIt's always an interesting question how explicit one wants to get. In this case, I would say the 'outerHTML' parameter is enough to define what will be done with the post result.
- yscodes 3y agoI like your change. Much clearer. Makes me more interested than the current syntax.
- listenallyall 3y agoYour opinion is totally valid. However, is it really difficult or tricky to recognize that 'click' the default event of a 'button' tag? Isn't 'onclick=' kind of redundant?
- recursivedoubts 3y agowe don't specify "click" on anchors or "submit" on forms, do we?
- mekoka 3y ago> no magic would be needed, a lot of indirection and complexity would be avoided Is this an informed criticism based on your experience having worked with htmx, or is it just an off the cuff opinion? Personally, I don't think the goal should be "no magic", or "no indirection", or "no salt", or no "sugar". I feel that aiming for just the right amount of those things, to have the goody without crossing over to disgust, is a sound goal.
- 0xblinq 3y agoI'd still pick Unpoly over it. Seems far more high level, feature rich and easier to use although less popular. And if I wanted a popular approach I'd pick Hotwire which can be used with any backend framework anyways. https://unpoly.com/ https://unpoly.com/ https://hotwired.dev/ https://hotwired.dev/
- JodieBenitez 3y agoCan you expand a bit on why you prefer unpoly over htmx ? I like htmx but I'm genuinely interested in alternatives around the same concept.
- 0xblinq 3y agoJust answered this on a sibling comment.
- replwoacause 3y agoI am also interested in why you like Unpoly more. Genuinely curious because I use and like HTMX and don’t really understand what you get with Unpoly that you don’t with HTMX.
- 0xblinq 3y agoI could ask the same question I guess, what do you get from HTMX that I can't get from Unpoly?. I think you can achieve the same thing with both, but Unpoly is higher level, that means I have to write less attributes/code to achieve the same stuff I guess. "Compilers" are also a nice way to attach custom code. All the helpers for form validations, the extremely easy way it provides to do modals, and layers in general. The navigation feedback (a'la turbolinks) when navigating across pages, the caching, the error handling. The up-keep for keeping a video player or anything else across pages transitions, and absolutely everything of this can be accessed from a JavaScript API in case you need to perform any of this from your own code and most of these APIs also trigger events. Probably you can do all of this with HTMX too, but it is more work.
- marko-lev 3y agoHTMX is just HTML. HTMX substitutes a DOM element with the HTML response you get from an on-click HTTP request instead of redirecting to a new page. Claims of HTMX being yet another complexity or yet another JavaScript framework fail to acknowledge this.
- 411111111111111 3y agono, htmx is (technically speaking) just another JS framework. Just look how VueJS got started, it began with sprinkled in html and was marketed as the framework for backend devs, as you were just writing html to render lists/objects etc. And htmx does more then what you're alluding to here, as should be obvious from reading their docs about server-side events, notifications, lazy loading, JS extension api etc
- pavlov 3y agoLong arguments here about whether HTMX or React or something else can qualify as idiomatic HTML. But the truth is, HTML itself does so very little that it’s barely useful as a starting point for building applications. Arguing about idiomatic HTML in this context is like arguing about how to write a scientific paper in idiomatic toddler language. One faction thinks you should stick to monosyllabic words. Another believes drawings of colorful balloons are key. Both are held back by the fundamental assumption.
- emodendroket 3y agoSeems like a horrible idea that totally breaks separation of concerns, so I’m sure it will be a huge success you’ll see everywhere very soon.
- the_gipsy 3y agoThere are multiple ways of separating concerns. Htmx is faithful to the original HTML separation of structure / presentation / behavior. Elm cuts this way too but with a completely different approach. React does components. Pick your poison because in any case there will be crossing of those concerns. Personally I've never seen react code that doesn't go sour beyond a toy demo.
- emodendroket 3y agoMore of an Angular fan though I haven't used post 1.x much.
- justusw 3y agoOn the one hand I see the appeal of staying inside, say, Django the whole time and getting 3x done. On the other hand I am so pampered by front end component based templating especially with Tailwind. It would be cool if I could just import my Svelte components from Django.
- adieth 3y agoHave you looked at something like Slippers[1]? It allows you to have a set of components that you use in Django templates. I'm using Bulma, not Tailwind, for my project and I like how it creates an abstracts over e.g. CSS classes. [1]: https://mitchel.me/slippers/docs/introduction/ https://mitchel.me/slippers/docs/introduction/
- winrid 3y agoI really want to use htmx on the next project but I am not sure how to make it handle poor network connections yet. The app I'm building will be used in areas with poor mobile connections - I want to submit a form, add it to a list and say it's pending saving, while the user can add more. Have to use hyperscript probably? Can trivially do it in vanillajs so I'm sure it's possible?
- yavor99 3y agoHmmmm... can you define a "poor connection"? The web used to work the "htmx"/hypermedia through all the dial-up years where things were REALLY slow. I see no reason it would not work now.
- timetraveller26 3y agostop trying to make htmx happen, it's not going to happen
- silver-arrow 3y agoI have immensely enjoyed and benefited from using htmx for the past 18 months on projects with Clojure as the backend language. I had done years of full-stack Angular then React on the front-end and Java Rest endpoints on the back-end with teams of all sizes. htmx has been a revelation and has really opened my eyes to the nuances of hypermedia development modalities that I was ignorant of. For me, it has become very clear that htmx and hypermedia development is far more simple, productive, beneficial, and FUN for 90% of web dev use cases. I feel huge disappointment how unnecessarily web development evolved into bad client server rpc json protocol for basically everything web. Kudos to the htxm creator and his vision of what should have been. My experience absolutely corroborates his thinking on these things.
- ChrisArchitect 3y agoAnything new here? Some discussion 5 months ago: https://news.ycombinator.com/item?id=33987578 https://news.ycombinator.com/item?id=33987578
- camdenlock 3y agoThe crucial flaw with htmx is that it’s an enhancement of html itself; if a fancy and interesting new UI pattern is invented somewhere, the htmx devs or contributors will have to add support for it into htmx itself! And imagine if htmx became absorbed into the real html standard. It would take much longer for the standards body (and then browser makers) to respond and implement. So the crucial flaw is that it will always be reacting instead of innovating. And more generally, this is likely why the “thick client” approach is more popular on the web these days. Nobody wanted to wait around for standards bodies and browser makers.