12 ms·
Htmx and the Rule of Least Power
- kelnos 3y agoThe ironic thing is that htmx's tagline is "high power tools for HTML".
- niutech 3y ago> You need to do click to edit, lazy loading, infinite scroll, a live search, or anything else that you’d normally be reaching for JavaScript to accomplish, you can now add HTMX to the stack, write a few more attributes on your HTML, get what you need done, and never have to use JavaScript. And what is HTMX? A 44KB-minified JavaScript library! So this statement is false. If you really want to be lightweight, use pure CSS frameworks like Picnic (https://picnicss.com https://picnicss.com) or Spectre (https://github.com/niutech/spectre https://github.com/niutech/spectre) and pure HTML out-of-order streaming (https://github.com/niutech/phooos https://github.com/niutech/phooos). If you really want a sparkle of JS, use 166b (bytes, not kilobytes!) HTMZ (https://leanrada.com/htmz/ https://leanrada.com/htmz/).
- recursivedoubts 3y ago15.2k min/gz'd, 17ms over old 4g and cached forever: https://bundlephobia.com/package/htmx.org@1.9.11 https://bundlephobia.com/package/htmx.org@1.9.11
- niutech 3y agoTransfer size is one thing, but the JS code has to be parsed and executed on every web page load. Moreover, it is often loaded as a blocking <script> in <head>. My point is CSS and no JS is better than JS.
- recursivedoubts 3y agohtmx loads in partials and processes them, you don't pay the price of loading it over and over again
- niutech 3y agoIf you don't use JS at all, you don't pay the price too and it's faster since there is no JS to parse and execute - see e.g. https://github.com/niutech/phooos https://github.com/niutech/phooos
- darkteflon 3y agoI work mainly on the back end but do need to do front end stuff from time to time. Having had my eye on Htmx for quite a while, and having recently gone through a painfully breaking NextJS update, I’m seriously considering going all in on it. From people who have made the switch: any regrets? Any sharp edges? Can I still use all my Tailwind components without issue?
- hruk 3y agoI've used HTMX quite frequently recently for internal frontends (admin pages, reporting, etc.). It's quite good. A pattern I've been using a lot is not changing the backend at all - each endpoint still returns the full page. Each hypermedia control makes liberal use of hx-select and hx-select-oob to update the elements that may have changed. This isn't super efficient, but it provides some "locality of behavior" in that you can look at a hypermedia control and know what other elements might be changed by it. It also means the backend doesn't really need to "know" about HTMX.
- whartung 3y agoNice way to incrementally add capabilities to an existing app. Back in the day, with Java JSP, there was a tag library called DisplayTag, which handled tables. It did a similar thing for in place paging, albeit a bit more brute force. All JSP pages are buffered as they’re rendered. When the tag was rendered in “Ajax” mode, at the start of the tag it simply flushed the buffer, thus eliminating anything generated before, and at the end it simply aborted the remainder of the page. This effectively just returned the entire table element in isolation from the rest of the page. It was a clever mechanic at the time.
- nprateem 3y agoThat actually sounds OK. The lede seems buried in the docs, which focus on how it works not how to do what you want to do.
- jiggawatts 3y agoI toyed around with it, but ended up using server-side rendered interactive Blazor. That’s pretty much the same concept as HTMX, but has a larger ecosystem and more flexibility in some ways.
- seanwilson 3y agoAnyone using Django with HTMX? How are you writing UI tests for HTMX behaviour? The standard Django tests don't run JavaScript so what do you use for this and how is the performance?
- fancy_pantser 3y agoAre you looking for something like Playwright or Cypress for end-to-end testing?
- seanwilson 3y agoAs close to end-to-end as practical. Playwright seems a lot heavier than standard Django tests.
- dqv 3y agoI think I might give it a try in one of my Django projects. In Elixirland we can use Wallaby to test LiveView. This example that uses Playwright with Django has very similar ergonomics: https://github.com/mxschmitt/python-django-playwright/blob/master/test_login.py https://github.com/mxschmitt/python-django-playwright/blob/m...
- hellcow 3y agoThat's the fun part. It's just HTML attributes, so you can test them without a full browser and JS engine. Just parse the HTML. Tests are super fast and never flaky.
- seanwilson 3y agoBut how are you checking that e.g. on submit the HTMX replaced the correct selector inside another form and that on submitting that form HTMX uses a HX-Redirect header to send you to the right page? If you're not testing that, don't you get cases of tests passing when the UI is actually broken in the browser?
- nprateem 3y agoWe did this 20 years ago and you just end up with piles of unmaintainable partials all just used for a single page. It's far better to use something that at least embeds the templates in the web page with some simple js to show it (eg alpinejs) and a simple, private API.
- d-z-m 3y agowhat makes it unmaintainable in your opinion?
- gedy 3y agoNot OP but: spreading a UI amongst a bunch of files, which themselves have server side templating and logic in them and can't be run, imported, or tested in isolation. I was never a JS fanboy but the modern JS/TS frameworks that let you organize and test the UI without an entire system running is better for maintenance imho.
- halfcat 3y agoIt’s unmaintainable when you don’t organize your endpoints well. Which is no different with React, or anything else. It’s a non-point.
- nprateem 3y agoNo it's a point because the number of endpoints and partials explodes to support every action in the page that uses the "get HTML and replace it" pattern.
- gofreddygo 3y agoOk I'll just say it, why not use jquery instead ?
- eternityforest 3y agoI haven't personally used htmx(I use Vue and also like Svelte, and try to keep simple content in Markdown), but it seems declarative. I assume the compiler can give warnings at compile time?
- lgas 3y agoThere's no compiler or compile time.
- PetitPrince 3y agoAn early version of Htmx was in fact based on jQuery (https://intercoolerjs.org https://intercoolerjs.org).
- brabel 3y agoWith JQuery you're still writing JS to do everything. With HTMX, you write almost no JS. You write HTML which contains some directives like "hx-post='/clicked'" which will make a POST request to the `/clicked` URL path, similar to how HTML forms already work... and then you write the logic to generate more HTML in the server. That is: the server becomes responsible for the logic, not the client. You can still do JS on the client here and there, but that becomes much less needed.
- preommr 3y ago> With JQuery you're still writing JS to do everything. With HTMX, you write almost no JS. ...instead write it in htmx, and html partials server-side using a templating library. What could possibly be wrong with splitting up the presentation logic and spreading it throughout the backend instead of just writing a little bit of javascript?
- 3y ago
- s4i 3y ago> suggests choosing the least powerful [computer] language suitable for a given purpose This doesn’t work for projects that are planned to live for years and we aren’t sure of the scope of it beyond the next few months. You may feel you completed all the current features neatly with HTMX or whatever, but what happens when later your PM or designer asks your team to implement, say, a complex multi-step form with a bunch of frontend state and validations? People downplaying the need for tools like React and Next.js don’t usually acknowledge that these tools are used to ensure long-term flexibility of your tech stack and to maximize the talent pool to draw engineers from. It doesn’t matter if your site is slightly less broken for the few people that turn JavaScript off in their browsers.
- plugin-baby 3y agoAre you recommending Next.js for its longevity? My experience over the last 18 months is that every new version introduces breaking changes. I wouldn’t want to come back to a Next.js project in 5 years and have to deal with migrating to Node.js v32 and whatever Next.js has broken in the meantime.
- s4i 3y agoDon’t get me wrong, I’m not a Next.js fan either. Could’ve widened my list of examples to any SPA libraries and server-side JS frameworks. I just wanted to highlight the issue with the analogy: unlike some criminal a police officer is using force against, the nature of issues to be tackled in most software projects will keep changing.
- yungporko 3y agothat is going to be your experience no matter what you use if you want some horrible bloated frontend framework, or in this case, a horrible bloated framework for a horrible bloated front end framework. will we get a next.js framework to make it easier to use next.js to make it easier to use react to make it easier to use javascript in the near future? please for the love of god stop enabling these people.
- 3y ago
- molly0 3y agoFinally an article I can reference when explaining my problems with the “modern” frontend stack.
- zadler 3y agoThere does seem to be a little sleight of hand going on, since much of the work that you do in react is rendering, and with HTMX you’re just shifting that to the server. Is a lighter client and heavier server a good thing? Not always… look at Web3 for example, where many apps can be written against a blockchain and no server at all.
- zadler 3y agoHtmx: I feel sorry for you React: I don’t think about you at all
- selfie 3y agoA HTMX-y app will typically be a fetch-heavy app. Think TODO list, where each time you add a todo, you want that persisted on the server anyway. Yes you are sending more down the wire. I doubt rendering a partial HTML template is that much more work than formatting JSON but there is more crap to send down the line for sure. Where the application is doing lots of micro-level stuff, like maybe you are drawing on a canvas and occasionally sending a payload of updates to a server, I think then HTMX would be much slower and clunkier, and that is when you dust off your React.
- zadler 3y agoBut you're still doing the work. With React, you render in the client. With HTMX, you split rendering between client and server.
- kolme 3y agoNot really, all the rendering is done in the server. All HTMX is doing is fetching HTML snippets from the backend and patching them onto the DOM.
- SJC_Hacker 3y ago> All HTMX is doing is fetching HTML snippets from the backend and patching them onto the DOM. That's how it should work, although you can get easily get around that and tack on client side rendering.
- BillyTheKing 3y agosooo much effort is going into saving a few milliseconds either by rendering code in the browser or on the server - honestly who actually cares.. I like react because of JSX which I prefer to just normal HTML, but whether that's rendered in the browser, or on the server, also ok to ditch the whole thing and replace it with templating. The actually difficult problem is hardly being addressed though, namely globally distributed data stores, especially with distributed writes. That's the hard problem, I haven't really seen a very convincing solution yet for normal 'web-apps'
- pictur 3y agoYou develop tools that cannot be scaled with such shitty tools and then you curse these tools.
- selfie 3y agoThe rule of least power (a bit like the principle of least privilege) is a great thing for both security and understandability of code.
- worldsayshi 3y agoBut it only seems to make sense to me if you actually get any extra guarantees from it. HTML+CSS without JavaScript gives users a nice guarantee that the content you see is what you get. No extra delays waiting for data. No mutations at a later time. Etc. But I don't see that using htmx instead of react gives you any such guarantees.
- selfie 3y agoThat is right, so from a security perspective, as an end user, you can't "Disable JS, but enable HTMX only". However a a developer or team, if you say "this page only includes the HTMX library and no other scripts" (something that is easy to verify) then you know a lot about what can and can't happen. In a sense HTMX is a framework that provides a non-turing complete DSL with limited interactions. Whereas React alone provides... well nothing, because it isn't a framework. You need JS to initiate it, and do anything with it at all! So a React app by extension must have a lot (or maybe a little, rarely) custom Turing-complete code with access to the entire operating system that is the Web API! (I appreciate that people's definition of Framework vs. Library will differ, but the main point stands that React requires a decent chunk of turing complete code to do anything useful, whereas HTMX requires no turing complete code on the client but just markup.)
- hellcow 3y agoThe founder of HTMX said many times that he hopes the ideas behind it evolve into web standard, such that you wouldn't need JS anymore. I think HTMX is a great showcase for how far "any element can send HTTP requests" can take you.
- marban 3y agoLitestar has HTMX integration: https://docs.litestar.dev/2/usage/htmx.html https://docs.litestar.dev/2/usage/htmx.html
- qwertyuiop12 3y agoThese years I tried many approaches and I felt in love with htmx for my side projects. It’s a return to the old easy times. However, many times I only use a small subset of it. I recommend to begin with small steps and increasing the complexity a little bit on each one before being crazy applying ALL for a “to-do” app: pure html, htmz (a tricky way, TAKE A LOOK), htmx and react or whatever. Finally, I also recommend to follow htmx in Twitter, you will laugh a lot.
- MaxBarraclough 3y agoThis reminds me of a great talk, Constraints Liberate, Liberties Constrain, by Runar Bjarnason. [0] Useful abstractions necessarily impose restrictions compared to a free-form 'all powerful' approach, but abstractions make it easier to perform/compose meaningful operations. A compiler can reason about an AST far more easily than it can reason about a machine-code sequence, for instance. A compiler typically converts from AST to machine-code pretty late in the game, as you want to take advantage of the utility of the abstraction, not the unlimited power of directly working with instructions. [0] https://www.youtube.com/watch?v=GqmsQeSzMdw https://www.youtube.com/watch?v=GqmsQeSzMdw
- adamgordonbell 3y agoSuch a good talk! Constraint at one level enables freedom at another. A good abstraction is precise. So many well stated thoughts in that talk.
- peter-m80 3y agohtmx is computing on the server
- deleted 3y ago[deleted]
- AltruisticGapHN 3y ago> Similarly, CSS is a declarative styling language that is easily analyzed Those were the days... now you need a bible on CSS.
- shepherdjerred 3y agoI own a copy of CSS: The Definitive Guide. It's 1126 pages long, and it is indeed thicker than many bibles.
- recursivedoubts 3y ago"The enemy of art is the absence of limitation." --orson welles
- AltruisticGapHN 3y agoGenuine question, anyone knows the "bootup" time when you load a page? I imagine htmx "engine" needs to find all the elements on the page with hx- prefix. Is this fast?
- recursivedoubts 3y agoyeah, query selectors are pretty fast, we've had a few complaints on really large pages w/ huge tables (20k rows) and lots of elements with htmx attributes on them, but on most sane pages it isn't noticable computers are fast
- auggierose 3y agoSomebody made up a "Rule of Least Power", which is taken as some sort of axiom, and then this article gets going from there without questioning the axiom further. Yeah, why not. But consider this: JavaScript exists because the axiom does not hold for the web. Or rather, a programming language is the least power you need for a general platform such as the web.
- mst 3y agoThe article links to the original Tim Berners-Lee piece that outlines the rule and the reasoning for it. If you're unfamiliar with the name you might be well served to look up his contributions to the web first.
- auggierose 3y agoI know the name. I am not impressed by his reasoning. I mean, HTML and CSS being the result of the rule of least power? CSS is a mess, and there is nothing least about it.
- fbdab103 3y agoI have no idea what CSS 1.0 looked like, but I suspect it was an entirely different world when he made that statement. At that time, the web was really just blobs of text with the most minimal formatting. Not the basis for trillion dollar companies that want pixel perfect alignment.
- auggierose 3y agoThat might be. One more reason not to just take an axiom from these times, even if it comes from TBL, and base your reasoning for current tech on it.
- qrian 3y agoI sense some connection to the concept of [the right level of abstraction](https://www.johndcook.com/blog/2018/09/04/the-right-level-of-abstraction/ https://www.johndcook.com/blog/2018/09/04/the-right-level-of...)
- schindlabua 3y agoIs "rule of least power" why I'm stuck writing yaml that generates yaml for my kunernetes deployments? I think it's perfectly sensible to have a general-purpose programming language in the frontend.
- mst 3y agohttps://yglu.io/ https://yglu.io/ and/or https://yamlscript.org/ https://yamlscript.org/ make that significantly less horribad but turing complete YAML still makes me cry. Of course, when ingy and I worked together on https://p3rl.org/JSONY https://p3rl.org/JSONY to provide something more config-file-like for systems configuration, the developers at the shop that I first got an after action report from ... went "ooh! this is so much simpler than YAML!" ... and promptly invented turing complete JSONY. My next attempt at a configuration system is going to be turing complete out of the box so I can actually design it for that.
- infogulch 3y agoYou want CUE.
- synergy20 3y agoused it on small side projects which worked well,but I am concerned it could lead spaghetti code for larger projects,for that reason I now stick with vuejs
- nsonha 3y agoI thought they were gonna make some argument about least power in the frontend backend dynamic. But then they are like "why are we not using all these programming languages equally?". Because that sounds like complexity and has nothing to do with the rule of the least power?
- rogerthis 3y agoA dev myself, I see any new tech that looks like something I've seen before, but different from the immediately previous, as the natural young revolt against the old (5 years older), in an attempt to be important (i.e., e.g. being paid). Sometimes I'm younger than last year too, and I throw away a lot of what I learned. I should strive for wisdom: knowing what should come and what should go.
- KTibow 3y agoComponent frameworks serve a different purpose, allowing you to manage state and isolate different bits. If you don't need components, don't use components.
- ninkendo 3y agoI’ve been out of the web dev game for 7 years or so, completely missed react. Started in Perl, then ASP.NET, then Rails for about 5 years, then finally ended with an AngularJS SPA that ended up being a maintenance nightmare before I moved on to other areas of dev work that have nothing to do with the web. The angularJS experience was so bad, not just because SPA’s were terrible but coding in JS/npm was a horrible ecosystem… I had a much much better time doing simple UI’s in Rails/HAML/jQuery than anything else. Server side rendering was so much simpler than any time I tried to even look at doing anything in react. Would I like HTMX? What are the best practices around server side rendering? Have folks had good experience with Rust server-side code emitting HTMX pages? Any decent frameworks for this that are as opinionated/useful as Rails was for me?
- andybak 3y agoI tend to regard Rails and Django as being appealing to people with a roughly similar mindset with regards to web development and htmx feels like it fits into that philosophy - at least more so than the fast bulk of the front end ecosystem (which often makes me wonder if my brain is wired differently to the people that make this stuff)
- SJC_Hacker 3y agoIf you like templates and/or mixed-static/server generated HTML, then you might like HTMX. It can get unwieldy if the app requires complex state management. While you can (somehwat hackishly) return JSON, its not really what its for. Its kind of a throwback to the days of PHP, except without the page refreshes.
- erhaetherth 3y agoI still use Twig templates for a couple of my simple marketing websites, backed by about 100 lines of PHP to make it work. Simple enough that my non-programmer friend can edit it, powerful enough that... well it's not that powerful but it can do templates, which is all I want out of it. And I can still fall back to PHP if I do need to sprinkle some server-side magic in it. Stable, no maintenance, just keeps working and working, over a decade later.
- 000ooo000 3y agoFrom the Tim Berners-Lee article that the posted article seems based on: >Web resources that use these technologies [of least power] are more likely to be reused in flexible ways than those expressed in more powerful languages. >The reason for this is that the less powerful the language, the more you can do with the data stored in that language. If you write it in a simple declarative from, anyone can write a program to analyze it in many ways. Seems unclear how we jumped from ideas of information reuse to 'HTMX is better than smelly JS' when information reuse, as pitched by TBL, is miles down the list when evaluating tech. So, not to rain on the HTMX parade because it's obviously the latest thing web devs are getting tattooed, but invoking Principal of Least Power here seems.. awkward/hamfisted.
- llmblockchain 3y agoHoly content shift, batman!
- gloosx 3y agoI don't get it. It seems to be an html where magic happens via attributes, and it just looks ugly to me. Looking at the reference - the third Core™ attribute is literally for calling arbitrary JavaScript inside an HTML attribute tag which for me is really cursed. All these hx-on::before-request, hx-on-htmx-before-request, hx-on="htmx:beforeRequest: alert('Making a request!') htmx:afterRequest: alert('Done making a request!')". Only showing not a single piece of logic more complex than a simple alert. Heck! This looks like a dirty hack, and for some reason it exists, giving htmx the power of the javascript, but now all inside HTML of course. How come it's applying the rule of least power if such thing exists? 36 new custom attributes for HTML, _most_ of what you want should be covered, maybe one day you will want something else, and we will cover it with more custom HTML attributes, until we reach hundred of them for every use case. No javascript needed. And yes, React unlike HTMX is not a framework, it is just a library for building user interfaces, it does not provide a specific structure for developing your application, it is just a tool to perform a specific task: building a view layer of your application.
- recursivedoubts 3y agohtmx is often a good choice when compared with react: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/ the hx-on attributes are to deal with the fact that HTML's native on* attributes don't allow you to capture custom events, they aren't a focus of the library the core idea is hypermedia, we have a book on the idea here: https://hypermedia.systems https://hypermedia.systems
- gloosx 3y agoI can't buy into this essay really because it does not show me which code was ported, probably because it was such a shame to even show it to the public. It seems to me that react application was made terrible from the beginning, and I saw many such terrible applications. 255 dependencies for a simple website? The people who used them certainly did not knew what they are doing. By the way to build react ui you need only two. The rest is your choice to use or not depending on how much you know. I could port this monster to 5000 lines of code using the same react with 99% less js dependencies, 80% less memory usage bla bla bla, because I know how to use this tool. And you're right, htmx is really better for these people because it is a familiar pattern. But for me hypermedia is a step back, I would still prefer my lightsaber instead of a pizza-knife because I'm a master jedi and I won't cut off my own hand with it. Yes, it is a library a bit harder to adopt, learn and use consciously – but you can cut through thick metal doors.
- metalspoon 3y agoTo me, this rule looks like horoscope. Is HTML+CSS+JS more powerful than React? Is Excel more powerful than C? One could argue either way. The better rule is, perhaps, apply KISS to your architecture choice. If I can reduce 100 lines of HTMX into 10 in React, I'd choose React. Because KISS. But according to the least powerful principle, and the author's claim that HTMX is less powerful, I should choose HTMX. Nah...
- recursivedoubts 3y agoi think what you would find is that for many applications htmx would be less code: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/
- metalspoon 3y agoThat's not my point
- recursivedoubts 3y agooh, rather carry on
- SPBS 3y agoThen what's your point? Writing fewer lines of code in a less powerful language to accomplish the same thing as JavaScript is not KISS? React is web scale, use React?
- bluewalt 3y agoWhat's a little frustrating with current webdev state if that there is no silver bullet. I can easily think of use case where a Django+htmx stack is much more relevant than a React/Vue one, but the opposite is true too. People keep genuinely saying it's a good thing to have many tools to apply to the right usage. Personnaly, constantly switching from htmx to vue.js just fucks my brain. I miss the time where I used Django or Rails and didn't need to ask myself all these questions.