[HN Gopher] Htmx in a Nutshell
___________________________________________________________________
Htmx in a Nutshell
Author : tosh
Score : 419 points
Date : 2022-12-14 18:25 UTC (4 hours ago)
(HTM) web link (htmx.org)
(TXT) w3m dump (htmx.org)
| dang wrote:
| Related:
|
| _Moving from React to htmx_ -
| https://news.ycombinator.com/item?id=33218439 - Oct 2022 (315
| comments)
|
| _An SPA Alternative_ -
| https://news.ycombinator.com/item?id=32148253 - July 2022 (138
| comments)
|
| _Reimagining front-end web development with htmx and
| hyperscript_ - https://news.ycombinator.com/item?id=31949621 -
| July 2022 (207 comments)
|
| _Building a fullstack app with Flask and Htmx_ -
| https://news.ycombinator.com/item?id=30843275 - March 2022 (140
| comments)
|
| _The Renaissance of server side rendering with Alpine and HTMX_
| - https://news.ycombinator.com/item?id=30577181 - March 2022 (9
| comments)
|
| _How a hypermedia approach can address usability concerns with
| multi-page apps_ - https://news.ycombinator.com/item?id=29693571
| - Dec 2021 (128 comments)
|
| _Building a simple room-based chat application in Nim (using
| HTMX)_ - https://news.ycombinator.com/item?id=29594763 - Dec 2021
| (28 comments)
|
| _Django, HTMX and Alpine.js: Modern websites, JavaScript
| optional_ - https://news.ycombinator.com/item?id=29319034 - Nov
| 2021 (274 comments)
|
| _Htmx 1.2.0 Release_ -
| https://news.ycombinator.com/item?id=26128229 - Feb 2021 (25
| comments)
|
| _Htmx 1.0.0 Release_ -
| https://news.ycombinator.com/item?id=25232719 - Nov 2020 (58
| comments)
|
| _Htmx - high power tools for HTML_ -
| https://news.ycombinator.com/item?id=23330881 - May 2020 (166
| comments)
| nikhilsimha wrote:
| This gives me hope for webdev. Long time infra guy who dreads any
| front end work with the other frameworks.
| harlanji wrote:
| Happy to see HTMx mentioned every month or two on here lately.
| A+, would recommend to anyone especially newbies. Been doing web
| dev since the Perl / pre-PHP3 / pre-jQuery/Scriptaculous days,
| and I feel reincarnated into a nicely crafted framework from that
| time.
|
| I've been picking up Python for the past 6 months and adding as
| little as possible and slowly as possible. About 2 months ago I
| started building a Twitter client with HTMx + Flask and it's been
| nice. It now supports multilogins for Twitter and Mastodon, as
| well as Twitter Archive and RSS/Atom backends. Very similar to
| programming with PHP back in the day. Minimal JS, just a couple
| functions to integrate with my little Notes app that's not
| running HTMx (yet). Not trying to boast, just showing how far one
| can take it.
|
| Using the server as an engine of state with the Facade pattern is
| something I've already become happy to do, having successfully
| used it for a pretty delicate use case involving multiple iOS App
| Store versions and a backend migration without impacting old App
| versions. I'm a little cautious about offline apps (SPA-domain),
| but have done a Service Worker demo and have some ideas to mess
| around with in mind. It's the one possible downside to not using
| JS (Node) on the backend that I can see: no shared code that can
| run on the backend and client/edge alike (but a language subset
| transpiler fills in the gap, eg. for validation/pure/non-mutant
| logic).
|
| Documentation is pretty clear as well, I've been able to go a
| long way just reading it over and over and trying out features as
| I think of them.
| recursivedoubts wrote:
| howdy, I'm the creator of htmx, happy to talk about it
| francoisdevlin wrote:
| GRUG? Is that you?
| recursivedoubts wrote:
| well of course I know him
|
| he's me
| francoisdevlin wrote:
| You need to start merchandising. Complexity very, very,
| bad.
| agentwiggles wrote:
| this grug much appreciate wise senior grug's advice. thanks
| for many laugh!
| decross wrote:
| in a way, he's all of us
| jonomacd wrote:
| I love the model. I've been writing a golang app with the
| standard library template system and it works really well.
|
| One bit I've found slightly unintuitive is the swap and settled
| states. Took my a while to animate in a sidebar how I wanted.
| It was my fault for not groking it faster but perhaps some more
| examples or guides in that regard could be useful.
| recursivedoubts wrote:
| i agree
|
| and here is a perfect place for you to contribute to the
| project! :)
| jonomacd wrote:
| Ha. Excellent point! I think I need to understand it better
| myself before I try to write something about it.
| recursivedoubts wrote:
| hey now, I didn't understand what I was doing when I
| started htmx either...
|
| not sure I do now, come to think of it
| soperj wrote:
| Honestly, even starting writing about it will likely help
| you (and the person finishing it).
| [deleted]
| can3p wrote:
| Hi, thanks for the libraries!
|
| When I started using them, one of the hardest parts was to
| actually have it imported and built with webpack, since the
| site focuses on cdn and webpack example is really brief. Same
| goes for hyperscript
|
| Do you see cdn as a preferred way of usage?
| recursivedoubts wrote:
| unfortunately I don't know webpack really well, although I'd
| love docs contributions on it if the existing docs aren't
| good
| efields wrote:
| you're not missing anything :-P
|
| there's a big distortion field around expectations vs
| reality with webpack.
| m4lvin wrote:
| How does error handling work? If I try to replace the content
| of some div with a reply I get using htmx, but the request
| fails or times out etc., what content is then put into the div?
| What if the reply is not valid HTML?
|
| Sorry for the newb and lazy questions.
| silver-arrow wrote:
| It's pretty simple to use the htmx events on the Response to
| handle errors dialogs or other behavior
| recursivedoubts wrote:
| htmx doesn't do anything on an error by default, but you can
| override this behavior using the extensive event system it
| has:
|
| https://htmx.org/events/#htmx:responseError
| BeefySwain wrote:
| You have mentioned here and in other places that you use HTMX +
| HyperScript in production. Curious what that looks like, is it
| part of consulting, a side business, a day job ?
| recursivedoubts wrote:
| consulting as a side gig of my day job, which is a CS prof
| sureglymop wrote:
| Two questions. What would you recommend to build the backend
| in, some language that can parse xml/html well? And second
| question, are there any more extensive examples such as working
| authentication?
| silver-arrow wrote:
| That's part of the benefit of htmx and it's hypermedia
| approach, you can build the backend in anything you prefer.
| Some like using language and frameworks that use templates.
| Others, like we do, used fairy basic HTML generation
| libraries. We love Clojure so we use the Hiccup library to
| generate HTML. We use the full power of clojure and functions
| to build reusable HTML type components and their fragments.
| talideon wrote:
| First, I'll preface this that what I'm about to write is meant
| as an _endorsement_ of HTMX.
|
| What HTMX does should've been a W3C standard a decade ago, and
| I've my fingers crossed that some day I'll be able to do what
| I've done with jQuery and remove it.
|
| Thank you for pushing the state of the art forward in a
| meaningful (and RESTful!) way.
| recursivedoubts wrote:
| :) agree 100%, htmx shouldn't have to exist!
| hexmiles wrote:
| Hi, on the subject of hypermedia: I recently saw your talk when
| you showed hyperview.org as an alternative to HTML for mobile
| use case.
|
| As someone who is very interested in the space, are there other
| hypermedia implementation (if is the right word) that you found
| interesting? Or do you have some pointer for those who want to
| explore this space?
|
| Personally I really want some kind of hypermedia framework for
| terminal application, since I often need to work with hardware
| (or bandwidth) where the only interface is a terminal, and I
| never feel productive with manually writing the application
| code, having to reimplement a new client every time.
|
| Also thank you for htmx, I started using for a couple of
| project, and it really is refreshing. Especially kudos for the
| various example, that really helped making it "click".
| amne wrote:
| hx-post .. what? hx-put .. what? hx-delete .. what?
|
| I stopped scrolling as soon as I noticed I have to ask myself
| what am I posting to this URL?
|
| Maybe digging deeper I could find the reference docs explaining
| in very vague terms where the payload is coming from. But this
| was supposed to be simple.
| whichdan wrote:
| https://htmx.org/docs/#parameters
|
| Simple doesn't mean "I should be able to intuitively
| understand this with under a minute of reading"...
| amne wrote:
| With so many tools floating in this space the landing page
| MUST be clear enough. Sorry.
| recursivedoubts wrote:
| here is the landing page:
|
| https://htmx.org
|
| the link here is to the docs, which is more involved
| KyeRussell wrote:
| This project has seemingly picked up a bunch of traction.
| The number of times it has appeared on the front page of
| this website serves as some indication, as well as the
| plethora of conference talks.
|
| You seemed unwilling to put more than 2 minutes into
| looking at an example, or 10 seconds into checking what
| page you were on, yet felt that your experience warranted
| these dismissive comments which cumulatively
| proportionally surely took up just as much time.
|
| You aren't acting in good faith. This doesn't add to the
| conversation at all.
| strangus wrote:
| I hate web dev, but this gives me hope.
| spion wrote:
| I've never used htmx, primarily because I like the concept of
| "components" so much. (They serve two needs - standardizing
| larger blocks of UI and encapsulating them with an alternative
| interface, and providing islands of rich interactivity)
|
| Is there any material on successfully combining htmx with web
| components? It doesn't look to me like the original design
| takes this possibility into consideration...
|
| (note: at a surface glance it doesn't look to me like
| components are in conflict with hypermedia - one could treat
| them as a side channel that "enhances" the standard set of
| elements)
| ColonelPhantom wrote:
| I'm not sure if I've entirely grokked the idea of components,
| but can't you define them server-side? So write them as some
| template magic that creates the "inner HTML". Then you just
| need some HTMX to enable using the component in a richer way.
|
| It's not really Web Components as specified, but iirc those
| are generally pretty much JS-dependent? But hypermedia's
| reliance on server side rendering means that you can just
| move this logic to the server.
| caseyf wrote:
| I use Unpoly and not HTMX but similar idea, what you do for
| components entirely is up to you.
|
| My components look like this. The JS and CSS is included in
| the application's bundles. Ruby renders HTML on the server
| side. app/components/breadcrumbs -
| _breadcrumbs.scss - breadcrumbs_component.rb
| ... app/components/search_field -
| _search_field.scss - search_field_component.rb
| - search_field.js - selections.html.haml
| tiffanyh wrote:
| Would you characterize htmx as the successor to AJAX?
| recursivedoubts wrote:
| I would say htmx is how I think HTML should work as a
| hypermedia, to make it possible to build more interactive
| applications within that paradigm.
| mhitza wrote:
| Quick question, as it made me curious. Can I send the content
| that I want to swap to the server itself? Say I want to submit
| a form to the backend, will it only send form fields or is
| there a way to send the form html itself?
| recursivedoubts wrote:
| that would probably be best accomplished w/ a custom
| htmx:configRequest handler:
|
| https://htmx.org/events/#htmx:configRequest
|
| you could jam the outerHTML of the detail.target into the
| detail.parameters map, maybe based on the presence of an
| attribute...
| mhitza wrote:
| I'm gonna make a note on that when I have cycles to burn to
| experiment with htmx. From my understanding of reading that
| section, parameters being a container of kv pairs, I'd have
| to hack on the internals of htmx for it to be able to send
| a pure string (not form/multipart) as the body of a
| post/put request.
|
| If I get around of experimenting with that, and it fits my
| flow, would that be something you'd accept back into the
| project as a contribution to the code?
| recursivedoubts wrote:
| i don't think you'd need to hack the internals, you just
| hook into that event to do what you need:
| htmx.on("htmx:configRequest", function(evt) {
| evt.detail.parameters['my-html'] = evt.target.outerHTML;
| // or whatever }
|
| you can jump on the discord and we can help you out when
| the time comes:
|
| https://htmx.org/discord
| artificialLimbs wrote:
| Why would you do that? Curious about use case.
| mhitza wrote:
| I have a nifty (or so I'd like to think) slapped together
| HTML parser, that instead of building a DOM tree, streams
| the HTML nodes as a list. Which in practice makes it easier
| to validate a field, and insert the appropriate validation
| message at the right location, without switching from
| request -> data representation -> validation failure model
| -> templating language ifdefs to inline the validation
| classes and additional helper text.
|
| Might sound not that convenient for basic things like login
| forms, but I have frontend code that builds dynamic form
| fields, which I'd like to not replicate via the backend
| templating language, if extracting data from HTML itself is
| a breeze in my case.
|
| Of course I'm going to do that myself anyway, but I'd
| rather use an established library which also handles in
| browser page restoration/caching (possibly also fragments),
| instead of rolling my own JS lib.
| vladstudio wrote:
| I feel warm and fuzzy inside every time HTMX is featured on the
| front page :-)
|
| Btw if you are interested in the reasoning of HTMX:
| https://htmx.org/essays/
| leetrout wrote:
| I am burnt out (but recovering!) with web dev and htmx is what I
| am using for my project.
|
| Django, DRF, Postgres, tailwind and HTMX.
|
| I am so tired of all the front end frameworks and all the
| complexity that gets added. At some point I think you need it and
| you get returns from it but hearing more people in the industry
| recognize and talk about how JS everything isn't always the
| answer gives me hope.
|
| I like what HTMX has to offer and I am excited to see it continue
| to get air time.
| codegeek wrote:
| Can I ask you how long you have been using this stack for and
| what are your findings ? Do you have a complex UI heavy
| application and can you deterministically say that this stack
| can replace frameworks like React/Vue for JS heavy frontend ?
|
| Is HTMX really mature and stable for production and massive UI
| heavy apps ?
|
| I am asking because we are starting a big project in Django,
| Postgres, Tailwind and for frontend, still trying to use VueJS
| and we hate SPAs so curious what our options are.
| czx4f4bd wrote:
| https://htmx.org/essays/when-to-use-hypermedia/ addresses
| your first question. The tl;dr is "probably not" as htmx is
| not really designed to handle complex browser-based UIs, but
| I have seen people in this thread and elsewhere discuss more
| complex use cases, so YMMV.
|
| https://htmx.org/essays/a-real-world-react-to-htmx-port/ is
| about porting a serious production Django application from
| React to htmx.
|
| If you hate SPAs and are chafing against Vue for building
| your app, it's probably worth considering if your app
| absolutely needs to be a JS/frontend-heavy product, or if it
| would be viable using a more traditional HTML+AJAX design.
| rgrieselhuber wrote:
| After going through a fever swamp project involving React,
| I am definitely in the camp of getting back to basics.
| papertokyo wrote:
| SvelteKit just hit 1.0. Out of all the 'modern' meta
| frameworks, it's the one that feels most like just
| writing HTML.
| todotask wrote:
| Quasar framework seems to fit UI heavy and supported wide
| range of UI components. I have manage to integrate Tailwind.
| [deleted]
| Quekid5 wrote:
| Not sure what you mean by "heavy" frontend, but you might
| want to look into LiveViewJS (and/or similar) if there's a
| lot of frontend iteractivity, but you still want to do most
| of the logic/interaction on the backend.
|
| I don't have much experience with HTMX, but it seems to be
| aimed at sites with a little bit of interactivity, especially
| if you want to be "forced" to maintain compatibility with no-
| js. (I mean "forced" in the positive sense. It keeps you
| honest.)
| fatboy wrote:
| Can you speak of your experience with liveviewjs? I've been
| looking at it, and htmx, and everything else, over the past
| few months for a heavily-interactive frontend project I
| need to start.
|
| I'm an experienced ios dev, but in at the deepens with all
| this js frontend stuff. There are so many options! The one
| thing I'm sure of is I don't want to use react.
| dsego wrote:
| Have you considered https://inertiajs.com? It's still
| SPA-ish, but keeps server-side routing and controllers.
| To me it sort of looks like templates rendered in the
| browser with almost no need to keep state and juggle xhr
| calls, the app component just re-renders with new props
| whenever something is submitted to the server.
| Quekid5 wrote:
| The only real advice I can offer is:
|
| Try to implement an example of the most complicated UI
| interaction that you have in your (conceptual)
| application in both and then decide.
|
| Development-by-random-recommendation is usually a recipe
| for disaster.
| fatboy wrote:
| That is sound advice and I take it to heart. I was mainly
| wondering if you'd hit any roadblocks whose existence
| might not have been obvious from the outset?
| Quekid5 wrote:
| Nothing in particular that I wouldn't have predicted
| (from a detailed reading of the tech). I guess one thing
| to always keep in mind that these are frameworks that are
| limited by the client<->server interaction as a critical
| path. If you're doing a full SPA-type-thing you have to
| option to do optimistic updates and that sort of thing,
| but IME that's advanced stuff that only major orgs should
| even attempt to do.
| quickthrower2 wrote:
| I played with HTMX and I think it just pushes complexity into
| the back end that now needs to render full and partial pages.
| Granted on the back end you get to do traditional programming
| and pick your language
| spinningslate wrote:
| Not sure I agree. Yes, it requires more work on the back end:
| rendering templates for whole pages and parts of pages, then
| integrating them. I've done it with Python (FastAPI/Jinja2 &
| htmx). My only SPA experience is with dotnet on the back end
| and Angular on the front. Based on that experience:
|
| 1. Python with htmx has less accidental complexity. It
| doesn't get rid of intrinsic complexity of the domain, but it
| does reduce technology-induced overhead.
|
| 2. Dotnet/Angular tech split has organisational implications,
| tending to encourage a division between front end and back
| end developers. Communication and coordination overhad goes
| up correspondingly (Conway's law).
|
| 3. htmx is stable. There's a lot less churn than with
| Angular. I haven't measured this, but subjectively, there's
| less time spent updating packages and re-testing. Keeping
| FastAPI/Django/Python update is approximately equivalent
| keeping the dotnet back end up to date.
|
| 4. State management is simpler. There's no front end caching
| to deal with, and so no corresponding cache invalidation
| questions.
|
| I'm not building tech unicorn sites, so can't comment on
| whether the technical overhead is justified at that scale. I
| _have_ been pleasantly surprised at the level of UI
| sophistication that can be achieved with server side
| rendering and htmx.
|
| I'm not a big javascript fan generally, so definitely have
| bias. I also have an increasingly allergic reaction to
| accidental complexity, so am constantly looking for ways to
| minimise it.
|
| Based on those biases and experiences, my default starting
| point is SSR+htmx. In my experience the accidental complexity
| is lower, productivity higher, and intra-team communication
| better. YMMV obviously.
| devmunchies wrote:
| I imagine that by moving this to the backend you could
| guarantee (at compile time) that all Ajax calls on the client
| have an associated backend endpoint. This eliminates dead
| urls, and gives you more opportunities for code generation or
| IDE-style autocomplete when creating Htmx views.
|
| Do this in a static functional language and your whole app
| will more "deterministically pure".
|
| So yes, it causes more work on backend but, given more
| tooling, it can provide more opportunities for less code
| written overall via code-generation (like how creating a
| model in Rails generates lots of helpers).
| 88913527 wrote:
| It's tiring, but for those of us that have the humility to
| know, for example, that we aren't experts in implementing every
| last detail of WCAG-spec compliant accessibility --and the
| application I'm building requires it-- it's better to build on
| top of someone else's solution. There's so many pitfalls to
| quite easily writing un-semantic, incorrect HTML. Browsers are
| forgiving, but a screen reader won't be.
| scarmig wrote:
| IME, HTML-driven web applications (to say nothing of simple
| pages) in the field are generally more screen reader friendly
| than SPAs, though you can certainly achieve good
| accessibility with the right team and resources.
| colordrops wrote:
| I am so tired of everyone complaining about complexity in front
| end frameworks, as if this sort of thing doesn't exist in other
| languages and stacks, and as if frontend dev isn't as complex
| as other domains. Just ignore them or do something else.
| kkapelon wrote:
| > as if this sort of thing doesn't exist in other languages
| and stacks
|
| It doesn't.
|
| For example in the Java world and in the last 10 years there
| were only two "frameworks". Just Spring and Oracle/Java EE
|
| Now two more have appeared (Quarkus and Micronaut) bringing
| the total number of frameworks to 4.
| icedchai wrote:
| Sure, if you ignore Dropwizard and tons of other less
| popular java frameworks out there.
| kkapelon wrote:
| Maybe I am missing something but Dropwizard is not a
| framework on its own but instead of collection of
| external and independently developed libraries
| icedchai wrote:
| Maybe you are? Yes, it integrates existing frameworks and
| libraries. In fact, the home page says "Dropwizard is a
| Java framework for developing ops-friendly, high-
| performance, RESTful web services."
| kkapelon wrote:
| While I would love to argue whether DropWizard is a
| framework or not there is no need for that.
|
| Just go to google trends and compare Spring and
| Dropwizard. Or look at
| https://www.jetbrains.com/lp/devecosystem-2021/java/.
| Dropwizard doesn't even appear in the list of web
| frameworks.
|
| I mean, if you still believe that Java has as many
| frameworks as Javascript has (and had in the past) there
| is nothing I can say that will convince you.
| icedchai wrote:
| I've been using Java on and off since 1996. It absolutely
| has had a ton of frameworks over the years. Yes, I
| realize many of them are niche or no longer in use, but
| that doesn't mean there isn't a legacy application where
| you have to maintain 10 or 20 year old garbage.
|
| FYI, I despise both J2EE and Spring. (Maybe Spring Boot
| is okay.)
| kelnos wrote:
| Is the argument here that there are too many JS frameworks,
| or that the complexity of the frameworks themselves tends
| to grow over time?
|
| If the former, totally agree. If the latter, Java
| frameworks are _plenty_ complicated.
|
| Also not sure how you've missed a lot of other frameworks;
| Spring and J2EE are certainly not the only ones that have
| been around for 10+ years. Dropwizard, Vert.x, akka-http,
| GWT, Play... just to name a few.
| kkapelon wrote:
| The argument is that I could learn Spring in 2002, find a
| Job then I could learn Spring in 2008 and find a job and
| then I could learn Spring in 2013 and find a job and then
| learn Spring in 2018 and find a job and then learn Spring
| in 2023 and find a job.
|
| Spring IS complex, but you learn it once and you are done
| with it.
| dpistole wrote:
| I'm not a java man but a quick google leads to a lot of "10
| java frameworks you should know", "17 popular java
| frameworks", and a "list of java frameworks" on Wikipedia
| that's dozens long.
|
| Frontend wise it seems similar at a glance, in that you
| could use react for the last 10 years and be fine. Or you
| could jump from react to vue to svelte and make life hard
| for yourself.
| kkapelon wrote:
| I looked at some of the articles you mention and they are
| completely clueless
|
| They include stuff like
|
| - Hibernate - this is just an ORM
|
| - JHipster - this is just opinionated Spring
|
| - mybatis - again ORM
|
| - Grails - > This is Groovy and not Java
|
| - Play -> This is Scala primary
|
| - Primefaces -> an implementation of Oracle/JavaEE
|
| I think you get the idea. I am actually amazed at who is
| the target audience of this kind of blog posts.
| dpistole wrote:
| Makes sense, probably just ad click driving spam page,
| appreciate the info :)
|
| I wonder how much of people being burnout on "front end
| frameworks" is because of "17 must know javascript
| frameworks" articles akin to the JAVA stuff at the top of
| google.
| codegeek wrote:
| There is a reason we complain about front end frameworks. The
| fatigue is real. The npm and node_modules hell is real. The
| constant quirks with JS to make it work with our backend is
| real. I have been programming professionally for 18+ years
| and even though I can do anything, JS frameworks give me the
| most anxiety. Just this other day, something broke with an
| npm package and the error messages require me to hire a
| cryptography expert. I am half joking.
|
| I am all in for something that keeps us on server side
| templates/HTML with dynamic capabilities.
| afavour wrote:
| I'm tired of everyone talking about the frontend as if it's a
| monolith. In a world where web uses span all the way from a
| blog with a contact form to an entire app like Gmail it's
| silly to pretend there's only one answer.
|
| I think we're still suffering from "everything with React"
| syndrome, I've never used htmx but if it can help as an
| antidote I'm all in.
| recursivedoubts wrote:
| or try htmx!
| danielvaughn wrote:
| I'm a huge proponent of Tailwind. What I tell people is to
| ignore their gut impression and just try it out.
|
| Equivalently, my first impression of HTMX is that I kind of
| hate it. But I could see it being similar to Tailwind, where
| you just need to try it out and then it'll click. Is that fair
| to say?
| mathgladiator wrote:
| I second Tailwind as I can't stand complexity, so I'm trying
| to simplify the entire stack down for _just_ my needs.
| Tailwind is a big part of simplifying my life.
|
| The other part is that I'm trying to simply "fix HTML", and I
| believe HTMX is pretty great. I'm taking a different approach
| as I have a reactive backend, and I can make the HTML simply
| be a template of a streaming JSON object. It's like mustache
| with reactive data binding.
|
| I'm enjoying, but I'm not a consultancy so I don't need to
| push the framework for every usecase.
| runarberg wrote:
| If you are burned out because of tooling, but trying to
| recover, I do recommend throwing out tailwind and just use pure
| CSS for your styling. Modern CSS is plenty fun, there is no
| need for an external framework to do a complex layout. CSS grid
| is the simplest way to do layout even if you include CSS
| frameworks. Custom properties (CSS variables) are more powerful
| then reusable styles from frameworks.
|
| The final peace of the puzzle is getting component scoped
| styles, which you can do by packaging your components into a
| web component and using the shadow DOM. CSS custom properties
| actually penetrate the shadow boundaries so it is a nice catch-
| all. If web components scare you (which is reasonable, they are
| scary) then there are other systems (as simple as class naming
| conventions) which you can use to reach component scoped styles
| without tailwind.
| wwweston wrote:
| Do you have any specific suggestions for resources for
| exercising grid & shadow dom knowledge/chops?
|
| I'm updating my CSS understanding after having left the front
| end for ~6 years (but having done a _lot_ of front-end work
| for the previous 10), loving custom properties and am
| intrigued with some of the systems built around them (e.g.
| Pollen), trying to figure out where else I should be
| directing attention.
| runarberg wrote:
| The guides and references on mdn is pretty good for grid:
| https://developer.mozilla.org/en-
| US/docs/Learn/CSS/CSS_layou...
|
| As for the shadow DOM, it is pretty advanced, I don't
| recommend going there unless you really want to learn it.
| Using web components without understanding can cause way
| more problems then it solves. And at the end of the journey
| you get a very verbose system with a lot of boilerplate
| just to get component scoped styles, which is not worth it.
| But if you still want to learn it, this is a good place to
| start: https://developer.mozilla.org/en-
| US/docs/Web/Web_Components
| fatboy wrote:
| I've just done a small project using web components. I
| didn't use the shadow dom at all (please note I have no
| idea what I'm doing).
|
| This was after reading a single hacker news comment
| saying not to bother with it, after days of research
| where everything I read spoke about web components and
| the shadow dom as if they were inextricably linked.
|
| I didn't want the styles to be encapsulated. I wanted the
| css to cascade in like it does everywhere else. I don't
| really see many use cases where you would actually want
| to style a component from the inside and not have the
| user of the component be able to style it themselves.
|
| All the blogs I read spoke about exposing a styling api
| using css variables. But by doing that, are you not going
| to great lengths to recreate what already exists in the
| normal dom?
|
| Am I missing the point?
| runarberg wrote:
| Not really, the shadow DOM is an opt in choice for that
| reason. Only a subset of cases do you actually want the
| styles to be encapsulated. The shadow DOM is actually
| harmful for form components as interactive relations are
| voided if there is a shadow barrier between them (which
| has implications on both UX and accessibility; I think
| there is an effort in WHATWG to fix this). But when there
| is a usecase, the shadow DOM can be really nice. As you
| get nice things like component scoped styles and unique
| idref, among others.
|
| > All the blogs I read spoke about exposing a styling api
| using css variables.
|
| This might be an outdated advice. You are supposed to use
| a mix of CSS variables and ::part()[1]. CSS variables
| should cover the most basic styling while you are
| supposed to expose style-able elements of your components
| with the part attribute.
|
| 1: https://developer.mozilla.org/en-
| US/docs/Web/CSS/::part
| arcanemachiner wrote:
| I had good results doing the exact same thing.
| sureglymop wrote:
| I completely agree with you and I felt the same way when
| using Angular and styling Angular components.
| leetrout wrote:
| I bought Tailwind UI and am using all their components (or as
| much as I can). I don't disagree with anything you said but I
| do like the tailwind features and design philosophy.
|
| I have completely ignored web components and need to learn
| all about them.
| lta wrote:
| I hear you loud and clear ! <3
|
| I wish I had known about it when I started my most recent
| project a yard and a half who.
| dysoco wrote:
| Curious at why are you using DRF with HTMX; isn't DRF more
| common when you need to return JSON for example and render in
| the frontend? Wouldn't returning Django templates to use with
| HTMX be the best option? Or is it for POST requests?
| leetrout wrote:
| I still have some API things and I like the router and
| serializers.
| TechBro8615 wrote:
| Does the server renderer call the API routes via HTTP, or
| does it have a more direct path to fetching the same data?
| If HTTP, what interface does it use - loopback or the
| public address of the server?
|
| In my experience this distinction has been a source of
| complexity in server-rendered apps that consume the same
| API as the client but at a different address, leading to
| problems like untrusted self-signed certificates,
| mismatching hostnames, and leaky proxy routes.
|
| Or perhaps none of your server rendered pages even call the
| API directly, and you just expose it for other clients?
| FlyingSnake wrote:
| Web isn't the only interface. DRF might also serve REST API
| to mobile or webhooks etc.
| iamgopal wrote:
| HTMX can be used with templates and JSON with extensions.
| zelphirkalt wrote:
| But HTMX is a JS library. Anything done with it is basically
| done with JS.
| theptip wrote:
| The point you're missing here is that if you use HTMX, you
| often don't need to write any JS. You just write HTML with
| some special tags, and the library handles everything for
| you.
| drdaeman wrote:
| Spoiler warning: it doesn't.
|
| Unless you only consider the happiest path, as in "I
| develop on localhost with zero latency, 100% uptime, and my
| backend validation logic perfectly matches my frontend
| policies" (and probably a lot more other "if"s and
| "only"s).
| mirekrusin wrote:
| Kernel is done with C. Everything is basically done with C.
| Even JavaScript.
| zelphirkalt wrote:
| That doesn't address the implications of something only
| working with JS at all.
| TechBro8615 wrote:
| The most popular JavaScript engine (V8) is written mostly
| in C++. Same with WebKit. Other JS engines are written in
| Rust, like Deno or Servo (used in parts of Firefox).
|
| I'm not aware of a major Javascript engine which is written
| in C, except for QuickJS, which is not "major" in any sense
| of popularity but is an efficient engine for embedded use
| cases (and anything from Fabrice Bellard is always work a
| look).
| hirvi74 wrote:
| It's all binary at the end of the day.
| nudpiedo wrote:
| It's all just energy moving around
| dunno7456 wrote:
| On sand.
| I_complete_me wrote:
| And those turtles that go all the way down lay their eggs
| in that sand.
| [deleted]
| devmunchies wrote:
| It's almost like htmx is a byte code target that you feed to
| the htmx JavaScript library. It's easy to generate htmx
| markup with any backend language.
|
| So instead of a backend language transpiling to JavaScript
| (like clojurescript), I can just generate htmx markup.
| drdaeman wrote:
| I'd say it's not about what can be done, it's about how it's
| defined. HTMX is a abstraction layer on top of an existing
| abstractions that you still have to know, because it's
| defined in terms of those abstractions.
|
| So when you write something like `hx-trigger="click" hx-
| put="/api/my"` you're actually actively thinking of an
| `addEventListener("click", ...)`, `this.innerHTML` assignment
| and `fetch("/api/my", { method: "PUT" }))`. Can't use HTMX
| without knowing the underlying principles and primitives.
|
| And then you still have to do JS because how else you're
| supposed to handle `htmx:responseError` and stuff. And maybe
| I'm wrong but it feels risky because the logic could end up
| all around the place and not in a single nice function/code
| block.
|
| So, basically, it's a nice DSL providing a bunch of
| shortcuts, but it doesn't magically alleviate knowing any
| underlying principles and nuances of JS and DOM. Again, it's
| even defined in terms of those systems (`hx-swap="outerHTML"`
| being a very clear indicator example).
| [deleted]
| Zamicol wrote:
| "The best thing we can do today to JavaScript is to retire it."
|
| - Douglas Crockford, creator of JSON
| mirekrusin wrote:
| We already did in favor of TypeScript.
| bogwog wrote:
| Typescript is a bandaid.
|
| We need improved DOM access for web assembly, followed by a
| new icon in the URL bar that indicates you're on a "legacy"
| site if it's using javascript (my vote is for a cute snail
| emoji)
| nop_slide wrote:
| Funny enough I just watched this talk last night by the creator
| of HTMX
|
| https://www.youtube.com/watch?v=LRrrxQXWdhI
|
| He mentions that "With HTMX we use a little bit of JavaScript
| so that we don't have to use any JavaScript."
| talideon wrote:
| HTMX is the perfect example of a project that, like jQuery,
| exists to be replaced with a W3C standard. And I don't think the
| people behind it would feel at all bad about that, as it fills a
| real niche that ought to have been filled a decade ago.
| recursivedoubts wrote:
| 100% I would love it if htmx was pulled into the HTML standard,
| that's where it belongs and I would get more sleep :)
| BeFlatXIII wrote:
| We could've been saved from gigabytes of JavaScript if HTML 1.0
| specified that tables must be sortable by clicking their
| headers.
| namuol wrote:
| Would love to see more opinionated approaches for client side
| templates/components to enable things like optimistic updates
| with similar ergonomics.
| rglover wrote:
| If you just want to use plain HTML with JavaScript, take a peek
| at Joystick [1].
|
| 100% plain HTML, CSS, and JavaScript based components (zero
| attribute hacks or compiler tricks). No external libraries for
| basic functionality (state, data fetching, url handling--all
| included or relies on native browser functionality). All a part
| of one full-stack framework that works out of the box.
|
| [1] https://github.com/cheatcode/joystick
| Gys wrote:
| I had a quick look at joystick and wonder if you have even read
| anything related to htmx. Nothing against joystick but it seems
| more an alternative for frameworks like react and svelte. Those
| are also npm and jsx based. Htmx is nog ;)
| rglover wrote:
| Yes, I have. It was one of the things I looked at as part of
| my initial research before deciding to work on Joystick. What
| I don't like about is that it's a non-standards based pattern
| for implementing interactivity in HTML (the same reason I
| didn't like React, Vue, Svelte, etc).
|
| All of these frameworks try to wedge stuff in between the
| core languages of the web (HTML, CSS, and JavaScript) for the
| sake of speed/being clever, but ultimately lead developers
| into a proprietary skills trap. It's all 100% unnecessary and
| will (arguably, has) lead to massive confusion and messes in
| the industry.
|
| By contrast, Joystick uses plain HTML, plain JavaScript DOM
| events, and plain CSS to build your UI. It just adds some
| very thin API abstractions over those features to help you
| move faster.
| ttfkam wrote:
| Honestly, Joystick doesn't seem at all like React, Vue, or
| Svelte. You have a lot there in terms of email templates,
| database connections, and other "full stack" items that far
| exceed the scope of the others.
|
| React is certainly a LOT more cognitive overhead than plain
| old HTML/CSS/JS. Vue, yes, to a lesser extent than React.
| But honestly, Svelte is closer to "just plain CSS and HTML"
| as I've even seen in a framework that also allows two-way
| data binding, which let's face it is a RPITA in vanilla JS.
| Automatic scoping of CSS to a component is also nice when
| you aren't trying to set a global style.
|
| This by the way is coming from a guy who started writing
| for the web in 1996, back when document.write() was de
| rigueur. That said, I honestly do miss the old days of
| figuring out how to make something on a web page by simply
| hitting "View Source" and picking out the relevant tags.
| rglover wrote:
| > Honestly, Joystick doesn't seem at all like React, Vue,
| or Svelte.
|
| The component framework (@joystick.js/ui) portion is best
| compared to those.
|
| > Svelte is closer to "just plain CSS and HTML" as I've
| even seen in a framework that also allows two-way data
| binding
|
| Joystick does this too but with zero need for a special
| compiler/extra syntax.
|
| > Automatic scoping of CSS to a component is also nice
| when you aren't trying to set a global style.
|
| Joystick also does this without any special compiler.
| Whatever CSS you define on a component is explicitly
| scoped to the HTML rendered by that component.
|
| ---
|
| The compiler and data attribute stuff are the hang up for
| me. It's adding stuff in that's non-standard. Admittedly,
| it's neat/clever, but that line of thought has lead
| (JavaScript-driven) web development down a rabbit hole. I
| started about 10 years after you (2006) and want to get
| back to that level of simplicity--sans IE6 rendering bugs
| --without compromising productivity. I think Joystick
| hits the sweet spot on that.
| revskill wrote:
| Modern frontend is easy to get burn out not by the complexities
| of tooling. It's more about upgrade and backward compatibility.
| Same story as backend, but backend is likely less broken on that
| aspect.
| pvorb wrote:
| This looks very similar to Hotwire. Does anyone have experience
| in both libraries and give a few hints about pros and cons of
| both libraries?
| qbasic_forever wrote:
| My only complaint with htmx is that it is _nearly impossible_ to
| Google search for info about it. You just get tons of noise from
| Google 'helpfully' deciding you really just want to search for
| 'html'. You need to search for "htmx" (including quotes) to find
| docs, articles, etc. about it.
| stronglikedan wrote:
| I get decent results from Yandex by putting a plus before htmx
| ("+htmx") and excluding the results for html ("-html").
| recursivedoubts wrote:
| a known issue, but it was too good a name (and domain) to pass
| up!
|
| hopefully over time the problem will subside
| shanebellone wrote:
| I'll stick with Python and HTML.
| donatj wrote:
| Makes me smile because everything old is new again. This is very
| similar to features MooTools had like 10+ years ago before JSON
| took off big.
| spjwebster wrote:
| Makes me smile too. Around 2008 while I was at Yahoo! I built a
| standalone library called Dhaka (literally stuck a pin in a map
| and used the place name as the project name) that did almost
| exactly this. It was used on a few of the EU sites but I left
| before I got chance to open source it. The problem I was trying
| to solve was eliminating a bunch of duplicate JavaScript that
| was essentially sending/fetching data to/from a remote source
| and inserting/replacing it into the current page.
| hadnayeer wrote:
| Wow really? That's crasy!
| recursivedoubts wrote:
| if you like the retro-vibe of htmx, you might also like my
| homage to HyperTalk, the scripting language from HyperCard:
|
| https://hyperscript.org
| CharlesW wrote:
| Hey, I didn't know the same person made both of these! How
| close would you say HyperScript 0.9.7 is to production-ready?
| recursivedoubts wrote:
| i'm using it in production and I don't expect any major
| breaking changes before 1.0 (H1 2023)
|
| i would stick with what it is designed for: light front end
| scripting, rather than writing a huge app in it, but within
| that domain I think it'll be pretty reliable
| scoofy wrote:
| Htmx isn't everything I want it to be, but it lets me program
| python back end with a mostly python api.
|
| I use it for http://golfcourse.wiki and I'd recommend it to
| others who prefer to avoid JS when they can.
| sureglymop wrote:
| Interesting! Is it open source?
| scoofy wrote:
| Not yet. Eventually, but right now it's just a hobby trying
| to become a business, and until I get a big enough database
| to provide a moat, I'm a bit nervous about giving it away for
| free.
|
| I'm not sure if that's the best course of action, but I'm
| just a guy who's a bit embarrassed to really like to
| programming in python and playing golf.
| sureglymop wrote:
| I completely understand, best of luck with your project!
|
| I was looking for an example authentication implementation
| in htmx that's why it caught my attention.
| ferdowsi wrote:
| I'm curious about htmx, but all of the HTML mini-syntax very
| similar in aesthetic to Angular 1.0, which was pretty quickly
| supplanted by React. What excites people about htmx? Do people
| like the mini-syntax but dislike the ceremony of state
| management?
| toinbis wrote:
| I guess it's important to note that in many cases you'll be
| willing to pair htmx with either alpine.js (using
| https://htmx.org/extensions/alpine-morph/), or with hyperscript
| (https://hyperscript.org/, developed by same team as htmx).
|
| Things that don't require request to server - managed by alpine,
| things that do require - by htmx. There are situations where both
| tools can be used, one has to pick.
| gryzzly wrote:
| could these directives live in an actual js file so the
| html/templates stay dsl free?
| Xeoncross wrote:
| Is there something like this that is a bit lighter than 135KB
| (source) / 40KB (dist)?
| recursivedoubts wrote:
| htmx is 13kb min/ziped, or 15ms over emerging 4G:
|
| https://bundlephobia.com/package/htmx.org@1.8.4
| bitterblotter wrote:
| I've been working on a HTMX Playground!
|
| https://lassebomh.github.io/htmx-sandbox/
|
| It runs a small mock server inside the browser which is very
| Django inspired, so it should be very familiar if you have
| experience with it.
|
| The mock server runs using PollyJS and Nunjucks as the templating
| engine. There is sadly no mobile support or the ability to save
| yet, but it's still a great place to start tinkering without
| needing a full setup.
|
| Repo: https://github.com/lassebomh/htmx-sandbox
| recursivedoubts wrote:
| very cool! you should post this in the #showcase channel on the
| htmx discord! and submit it to the /r/htmx!
|
| https://htmx.org/discord
| bitterblotter wrote:
| Absolutely! I will definitely do that when you can save and
| share playgrounds :)
| candiddevmike wrote:
| htmx keeps getting posted here and choosing it comes down to "do
| you trust that your user's internet is stable" IMO. For a lot of
| interactive web apps, the answer is no, and htmx is not a good
| fit.
| jonomacd wrote:
| SPAs make tons backend calls to get data. This isn't
| particularly different. To me the main difference is it is hard
| to build an offline app out of htmx as compared to a SPA but so
| few webapps are offline anyway...
| qbasic_forever wrote:
| I don't see why it couldn't be used in a PWA with a service
| worker providing offline HTML responses to hx directive
| elements though. You can see an example here that uses a WASM-
| based service worker (but you don't have to do that, it could
| just be plain old JS generating HTML):
| https://github.com/richardanaya/wasm-service
| infogulch wrote:
| Check out the live demo! https://richardanaya.github.io/wasm-
| service/
|
| Last month I contributed the todos functionality to this
| project after it was submitted to HN.
| https://news.ycombinator.com/item?id=33228891
|
| I think this is a great idea and could eventually enable htmx
| projects to transition from server-side-only to being a PWA
| with very little code changes (given the right backend).
|
| Unfortunately this particular implementation exhibits some
| blocking issues which I was not able to solve yet:
|
| 1. The Service Worker is eventually unloaded from memory,
| which means all data is lost because it currently stores
| everything in memory. This isn't a _defect_ as much as it is
| lacking a persistence feature; this is a MVP (emphasis on
| minimal) after all. The most promising solution in my opinion
| would be to use the OPFS /File System Access API with SQLite,
| which is yet to be shipped in all browsers.
|
| 2. The bigger issue is that once the SW is unloaded _it doesn
| 't come back_. The SW getting reaped after being idle is
| fine, that's part of the expected behavior. But there are no
| events or any other indication that it was disconnected, at
| some point it just stops intercepting requests. I don't know
| why. If anyone can chip in here to say why it does this and
| how I can detect or somehow restart SW fetch interception on
| demand I would be glad to hear it.
|
| ( For some more detail see the "# Remaining Issues" in my PR
| #5: https://github.com/richardanaya/wasm-service/pull/5 )
| Darmody wrote:
| What does the internet stability have to do with htmx?
| [deleted]
| wild_egg wrote:
| The creator himself calls out that htmx is not a good fit for
| highly interactive web apps
|
| https://htmx.org/essays/when-to-use-hypermedia/
| [deleted]
| silver-arrow wrote:
| Have been using htmx for a little over a year now, and I am so
| thankful for this library. It has simplified our development
| tremendously from ClojureScript / React to vanilla Clojure on the
| backend doing SSR of HTML with htmx HTML element attributes. All
| with 1 script tag that includes this wonderful library. Kudos to
| the creator of htmx!
|
| This is what hypermedia architecture with true HATEOAS is all
| about. It feels like we took a wrong turn a decade ago, and we
| have been trying to reinvent rich clients with JSON RPC designs
| from the 90s. It has resulted in too much churn and complexity
| IMO.
| bnert wrote:
| Doing something similar with janet. Really does simplify so
| much, and being able to not have to worry about always
| translating json -> html via { insert SPA framework here } is a
| breath of fresh air.
| silver-arrow wrote:
| Agreed that it is a breath of fresh air. It totally
| eliminates heavy complexity in the development environment
| and networking protocol layers. What makes me happy is that
| it completely reinvigorates the server side language you
| prefer to use.
| harryvederci wrote:
| Same here, also using Janet + htmx!
| mrits wrote:
| I've done a few years of solid frontend dev in the last decade
| and became efficient in a few different modern frameworks. For
| personal projects I just pull in a bootstrap and jquery
| framework from a CDN. I think htmx is going to replace this
| practice.
| 0x6c6f6c wrote:
| I would love to see some example projects of stacks like this
| hyuuu wrote:
| how would htmx handle application like pages? for example,
| something along the lines of google spreadsheets? Where each cell
| is interactive.
| lowonkarma wrote:
| Not a good fit for that. But you might be able to use HTMX on
| the settings page of that spreadsheet app.
| alexbezhan wrote:
| I'm building a SaaS that looks a lot like spreadsheets, but
| more specialized for PPC managers (my customers).
|
| Doing it in htmx. Works great.
| recursivedoubts wrote:
| htmx (and hypermedia in general) isn't a good fit for an online
| spreadsheet:
|
| https://htmx.org/essays/when-to-use-hypermedia/
| cpsns wrote:
| HTMX is awesome. In a world of front end frameworks I don't
| understand and frankly don't care to understand, it lets me write
| nice, interactive websites in a very simple way.
|
| I've normally extremely skeptical of anything like this, but HTMX
| just feels right when using it.
| efields wrote:
| This is refreshing, and not unlike what Stimulus is trying to do
| in the RoR space. This is simpler than Stimulus, IMHO.
|
| So much about modern FE dev requires knowing stuff that was
| intentionally abstracted to purer forms years if not _decades_
| ago and easy to pull off in a browser<>server relationship with a
| little bit of JS for state management or swapping content. The
| author even uses the phrase "AJAX," which I feel like I haven't
| seen used in earnest in years. This library is for the OGs.
|
| Obviously, trade offs etc etc. If you're starting a new web based
| project, something that's just submitting forms and showing
| results, why would you really use anything more complicated than
| this? It's sorta hilarious that JSX took off; it shows that the
| declarative nature of HTML was right all along.
| beauHD wrote:
| > The fastest way to get going with htmx is to load it via a CDN
|
| HTMLX is great and all, but loading it from a CDN is insecure and
| wrought with problems. Namely, the JS file in question could be
| hijacked and replaced with a malicious version that can steal
| data. It's unlikely, but still a plausible scenario. Also: the
| resource could just 404 and not be available due to work-in-
| progress scenarios on the CDN side.
|
| I would much rather host it on my own domain that I control.
| KyeRussell wrote:
| An odd nitpick given that the CDN example in the documentation
| protects against exactly this.
| can3p wrote:
| It's not hard to have it imported from node modules and built
| with webpack or similar
| _whiteCaps_ wrote:
| I haven't done much frontend dev work, but I thought that's
| what the integrity keyword is for: <script
| src="https://example.com/example-framework.js" integrity=
| "sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1
| wx4JwY8wC" crossorigin="anonymous"></script>
| infogulch wrote:
| The Installing section suggests exactly this for users just
| getting started: https://htmx.org/docs/#installing
|
| And then it says in the docs right after:
|
| > While the CDN approach is extremely simple, _you may want
| to consider not using CDNs in production._
|
| > The next easiest way to install htmx is to _simply copy it
| into your project_.
|
| > Download htmx.min.js from unpkg.com and add it to the
| appropriate directory in your project and include it where
| necessary with a <script> tag:
|
| Someone else in the thread was asking about webpack.
| _webpack_. What has javascript done to people 's
| expectations?
| Royaljj wrote:
| > I would much rather host it on my own domain that I control.
|
| You can and they encourage users to consider not using CDNs in
| production
| digitalsankhara wrote:
| It is available for download - see "Installing" under the table
| of contents. I always prefer to host locally myself and I do
| this for htmx.
| decross wrote:
| just download it and serve it from your own site.
| altano wrote:
| Using JS off a CDN is not a security issue if you use
| Subresource Integrity: https://developer.mozilla.org/en-
| US/docs/Web/Security/Subres...
|
| You can ensure you're always running the version of the script
| you validated, assuming you even validate the code (which
| presumably no one does).
| rlawson wrote:
| htmx like all great ideas seems obvious in retrospect. Why can't
| other html elements do what links and forms do? Htmx simplifying
| it all back down to html - I had that "of course!" reaction.
| jonesnc wrote:
| We're migrating our apps from Vue.js to HTMX, and it has been a
| great experience. The size of our codebase has consistently gone
| down as we move things to HTMX, and it feels like the level of
| complexity goes down as well.
|
| I highly recommend using HTMX.
| hedgehog wrote:
| What kind of apps? I used Intercooler (sort of a predecessor to
| HTMX) for a personal project and it worked well but I didn't
| get a good feel for what it would be like to build more
| complicated UI.
| megaman821 wrote:
| I don't think UI is part of HTMX's concerns. It is a library
| for submitting data and loading HTML fragments. For general
| UI components, I like https://shoelace.style/.
| codegeek wrote:
| Would you be open to sharing your experience on this a bit more
| ? We have a JS heavy app with 100s of VueJS components. Could
| those be transferred to HTMX ?
| StreamBright wrote:
| We are planning to do the same thing. Would you have any write
| up that you could share?
| StreamBright wrote:
| My problem with JS is that every framework we tried sucks in
| different ways. The worst is to handle the kind of silly crap
| that JS does (wat). The other big part is the every bricking API
| of pretty much everything. We are lucky if there is no warning
| about deprecation for a couple of day after updating a library.
| Minor version changes regularly break the build. The best is when
| yarn dev works and after building the app and deploying it to
| prod it breaks.
|
| After dealing with these issues for years I am really happy to
| return HTML from a backend API that uses a language where [1, 2,
| 12, 3].sort() return what I expect from a sorting function
| sorting integers.
|
| That is all, and that is what htmx gives us. I am not sure if we
| can replace our UIs that are written in Vue for now but at least
| it I have a good time porting some of the web things to htmx +
| Rust from Vue + Python.
| Xeoncross wrote:
| 1. One of the most painful thing with SSR forms is passing the
| data back-and-forth between the server and client when there are
| validation errors. Sometimes the data is very sensitive and you
| have to return the form with some values (like SSN) empty and
| make the user retype that along with with whatever field(s) were
| the actual issue. I'm also curious about how file uploads would
| work.
|
| 2. REST/GraphQL/gRPC API. Often, if you want to open up your API
| to internal or external users it's a lot easier if the frontend
| was already written to deal with protobuf or JSON endpoints.
| Seems like it would be painful to add an API to an htmlx backend.
|
| Is there a good way to address these with htmlx?
| harryvederci wrote:
| 1. I think you can just throw an error, and instead of swapping
| your filled-in form, you make a validation error appear below
| the form, e.g.
|
| 2. So far in my experience a rest API for my own front end has
| been pretty specific, so I'd want to add a separate API anyway
| for that purpose.
| recursivedoubts wrote:
| https
| roywiggins wrote:
| With something like Django you can make a quick and dirty json
| API by just returning the context dictionary that you were
| passing into the template renderer.
| fearthetelomere wrote:
| Regarding #1, I've found that Phoenix + LiveView has been
| helpful for these cases. They have great form validation tools
| using Changesets and the `phx-change` attribute [1]. You can
| redact certain fields [2], and even treat certain fields like
| virtual fields (like password not being stored vs the password
| hash being stored) [3].
|
| Of course, the (potential) drawback is in using Elixir for both
| front-end and back-end which may be a tough sell to a client or
| employer.
|
| -----
|
| [1]: https://blog.appsignal.com/2021/09/28/real-time-form-
| validat...
|
| [2]: https://hexdocs.pm/ecto/Ecto.Schema.html#module-redacting-
| fi...
|
| [3]: https://elixircasts.io/ecto-virtual-attributes
| christophilus wrote:
| Why can't you hydrate the form with the SSN? If you're serving
| it via TLS, there shouldn't be any problem. It's no different
| sending it up to the client than it is for the client to send
| it down to you. Unless you're logging every rendered page for
| some reason, I guess.
| makapuf wrote:
| This pattern is very pleasant and I sure hope browsers would
| embed as HTML standard a simple version of this (with simple hx-
| get/post, hx-target and hx-event to start)
| k__ wrote:
| _" When a user clicks on this link, issue an HTTP GET request to
| '/blog' and load the response content into the browser window"_
|
| Why do you want that?
|
| Sounds a bit like the hacky stuff PHP did in the first half of
| the 00s.
| bogwog wrote:
| It's for building SPAs (https://en.wikipedia.org/wiki/Single-
| page_application)
| k__ wrote:
| Yeah, but with SSR?
|
| I'm not convinced.
| casey2 wrote:
| I don't know any javascript, but is it really that bad of a
| language that you need new libraries every day and workarounds so
| that you don't have to write it?
| benji-york wrote:
| The language itself isn't great, but the tooling it (appears
| to) necessitate and the fact that the browser isn't a great
| environment for what many people want to do combine to turn
| many people off.
| silent_cal wrote:
| Yep!
| artificialLimbs wrote:
| https://www.destroyallsoftware.com/talks/wat
| camdenlock wrote:
| Yes.
| bogwog wrote:
| I don't love the idea of implementing common app state logic via
| attributes. It probably works a lot better than I'm assuming, but
| it feels hacky to me. Like it can't solve every problem you'd
| actually encounter when making a complex app, so eventually
| you'll need to fall back to using javascript, and possibly a
| framework or three...on top of htmx.
|
| But it does seem like this would be fun to play around with using
| PHP as your backend. No more JSON, or GraphQL, or bloated
| frameworks, just intermixed code and markup in the same PHP
| file...just like the good ol' days! For the situations where it
| does work, this could simplify the architecture of an app
| significantly.
|
| Also, 10/10 meme page.
|
| EDIT: are there any large and complex projects using this that
| are publicly accessible?
| recursivedoubts wrote:
| htmx uses the original state model of the web, Hypermedia As
| The Engine Of Application State (HATEOAS):
|
| https://htmx.org/essays/hateoas/
|
| it really tries to focus on extending HTML & the original model
| of the web, rather than replacing it w/something else
|
| good for some stuff, not good for other stuff
|
| i like using events when I need to tie things together with
| some scripting:
|
| https://htmx.org/essays/hypermedia-friendly-scripting/
| quickthrower2 wrote:
| For something between static html pages (good for information
| websites no need for HTMX) and SPA (good for complex SaaS
| services outgrown HTMX).
| artificialLimbs wrote:
| I screwed around for hours trying to get my first JS fetch code
| implemented recently.
|
| I found HTMX a few months after, and had it doing AJAX in
| probably 10 minutes. It has been unbelievably easy to use and
| helpful.
| marty331 wrote:
| I've used HTMX on several projects (Django) and it's truly a
| great add in. You can basically build a "React" style app with
| Django. I can't praise it enough.
| alexbezhan wrote:
| I'm using htmx for my SaaS web app. It has a lot of
| spreadsheets. User can filter, sort, highlight with color, etc.
| It's for PPC managers, they work a lot with spreadsheets. So
| I'm making a specialized version of that. First two weeks was
| tough, but after I adapted and found htmx idiomatic recipes to
| common tasks, it is crazy productive. I can show, if you are
| curious hit me at twitter @alexblearns.
|
| PS. I just believe people have to try it, because it's so much
| easier to do web apps this way.
| lukeramsden wrote:
| Sounds like you should be writing some blog posts about
| writing complex applications with this stuff
| PaulHoule wrote:
| I work on a collection of React applications at work and it is OK
| but at night I am building a workflow engine that trains a text
| classification model and automates its activities based on that
| model.
|
| It is almost the kind of web application that I built in 2001 but
| I find it a lot easier to write today than I did back then thanks
| to my own maturity and numerous refinements to the web platform.
| The backend is written in Python and uses aiohttp without any
| "framework" other than some very basic stuff I write myself.
|
| I worked for a company that had built something similar (that one
| was named "Themis", this one is named "Nemesis") that had parts
| written in Python, Scala and Typescript and we faced the problem
| of having to update three codebases whenever we made some change,
| having to deal with three kinds of "dependency hell", etc. It is
| all the more acute for an R&D project where adding a new task or
| model should be a day's work.
|
| With very little Javascript I am getting performance close to a
| desktop application when my server is on localhost, it helps that
| I am paging out small screenfuls of data. I have to admit that a
| library like Htmx could be a big help for this kind of
| application but I've yet to really wrap my head around fitting it
| into my application.
| christophilus wrote:
| I did something similar with Bun recently. I built a little
| finance / budgeting app (and some bookmarklets) to track,
| categorize, and visualize my spending. There's almost no
| client-side JS. But when I need to sprinkle it in, I just write
| a function and it's serialized and sent to the browser
| automatically by my JSX template layer (built into Bun). It's
| quite nice.
| jstummbillig wrote:
| Can anyone with experience in both talk about how stimulus and
| htmx compare? Or why they don't?
| Alifatisk wrote:
| Is this similar to Alpine.js?
| bnert wrote:
| I'd say it's more complementary, from my experience. Alpine
| serves the purpose of local state and rendering logic for user
| interaction in a manner similar to a SPA, whereas htmx services
| integrating w/ your backend service and handling DOM patching
| for updates/data oriented interactive bits.
| cod1r wrote:
| https://news.ycombinator.com/from?site=htmx.org
| synergy20 wrote:
| while I like htmx it's really for SSR frameworks specifically for
| django as rails has hotwire and laravel has livewire all do
| similar things.
|
| then you have alpine.js that is more a simple jquery for frontend
| js work.
|
| if you do django, use htmx, I'm not sure how it works for other
| scenarios. For rich desktop like apps, SPA is still probably the
| only option.
| can3p wrote:
| I like gymzaal and hyperscript - they solve few cases but those
| cover something like 99% of what a average app needs.
|
| My biggest pain point lies with the docs, there are not many of
| them and it takes time to figure out what's happening
|
| For example, there was no simple way to understand that both
| libraries are loaded correctly, also it wasn't immediately
| obvious where to use htmx and where to start using hyperscript
| decross wrote:
| but contrast that with the Herculean job that is learning
| angular, react or vue...
| butonic wrote:
| Is it possible to send any HTTP verbs, say PROPFIND, SEARCH or
| REPORT from WebDAV?
| recursivedoubts wrote:
| not currently, but I'd be interested in looking at that if
| those actions are supported!
| t8sr wrote:
| I'm confused about what value this adds. The introductory example
| is certainly not helpful, as it takes an `<a
| href="/blog">Blog</a>` and turns into 7 lines of markup to
| accomplish the same thing. (And then it says a bunch of things
| that are arguably not desirable, like "any element can now
| trigger requests".)
|
| Like: what's the point of using this over HTML5+js? I've spent 15
| minutes reading the website and I still don't understand why I
| should want this, especially if I already know HTML/CSS/JS. All
| it seems to do is add a SGML DSL into your HTML, so you can be
| all declarative about `onclick` attributes.
|
| I am sure I'm missing something - what is it?
| newbieuser wrote:
| this lib can offer tremendous taste for those looking for an
| html soup recipe.
| [deleted]
| cryptonector wrote:
| It's just a JS library that attaches behavior to HTML elements
| based on attributes where you'd otherwise have to write a bunch
| of JS yourself. It's just a framework where all the metadata is
| just embedded in the HTML.
| t8sr wrote:
| Yeah, but why? Why is it better to remember a bunch of
| attributes than to remember 3-4 javascript functions?
| Freebytes wrote:
| While I am just now discovering it so have not used it, I
| personally love this approach because it keeps the HTML
| syntax. It is like programming in two different languages
| when you only need one. Normally, you would add an onclick
| event handler to the element to call a function. Then, you
| scroll up to the function and back down to the anchor. Back
| up to the function. Back down to the anchor. This puts
| everything in one place with cleaner syntax.
| cryptonector wrote:
| It's pretty clear that TFA means that this is better
| because that's how HTML should have been, in their opinion.
|
| Is it better? Well, I think so. Practically speaking, for
| example, if you use NoScript or something like that, it
| kind of would be if you could block scripts but not HTMX.
| Also practically speaking the cognitive load of HTMX should
| be lower than the cognitive load of JS (especially for
| beginners). More generally speaking, I think it's quite
| right to say that HTML should have had a lot more of this
| early on, but the pressure for HTML to evolve clearly
| dropped once JS came along since JS provided a way to work
| around the limitations of HTML.
|
| IMO it is a good idea to standardize a bunch of behaviors
| as HTML attributes for these reasons.
| xmonkee wrote:
| Consider the case of calling your backend with a POST call and
| then updating your app in response.
|
| Typically, for a SPA: your backend would return some data, and
| your frontend would then figure out how to update your html in
| response to it.
|
| For a multi-page-app: your backend will redirect the user to a
| whole new page with new HTML.
|
| This is somewhere in between: Your backend will send just a
| little bit of HTML and you can update your existing HTML with
| it. It should feel like coding an MPA, but get the benefits of
| an SPA.
| t8sr wrote:
| Yeah, that I understand. I am not a huge fan of sending JSON
| that's not backwards compatible. Sending HTML is probably a
| good choice for some applications, but that was already well
| supported 20 years ago. Why is htmx better than one line of
| javascript saying `onload = function() { e.innerHTML =
| response.body` } ?
| crote wrote:
| In practice you don't want to just swap the content 100% of
| the time. Appending to the current content is quite common
| too, as is deleting from it. You sometimes need to touch
| other elements too, or maybe show a progress spinner. Or
| perhaps push a URL to the navigation history.
|
| Htmx provides a batteries-included data-driven experience.
| It is a means to avoid having to write dozens of slightly
| different variants of the same 5-10 lines of Javascript.
| KyeRussell wrote:
| Look at each of the distinct things that htmx lets you do,
| and tell me what would be required to do it in vanilla
| JavaScript. Notwithstanding that even in your example
| `onload = function() { e.innerHTML = response.body` } [sic{
| doesn't even tell the whole story, HTMX does more than just
| this and this is blindingly obvious from its documentation.
| If you need those things more than, say, a couple of times
| in your project, the natural thing to do is to factor them
| out to what essentially becomes a framework. This is what
| that is. HTML element attributes is used as the interface
| because there are a whole lot of people that don't like
| switching to writing JavaScript. You can argue all you like
| that you're not a fan of this, but plenty of people are.
| You can also argue all you like that one will eventually
| need to write some JS which will make the whole thing
| confusing to follow. The reality is that there are a whole
| load of projects where this isn't the case. If you've spent
| this long going back and forth with people about the merits
| of this project, and still don't see it's value, then it
| legitimately isn't addressing a problem you have, or, more
| likely, it isn't to your personal style/taste, or for
| whatever reason you are unable to relate it to any personal
| circumstances you've ever been in. The documentation gives
| tonnes of practical examples of how the framework can be
| useful, and there's mountains of third party examples.
| Beyond that, your arguments seem to revolve around a lot of
| technical, performance, and DX hypotheticals that you could
| test yourself by experimenting with the project. Part of
| its selling point after all is the lack of a need for
| complex build tooling. If you still legitimately can't see
| the value then it doesn't seem worth the discussion.
| mejutoco wrote:
| Please see my answer above, but htmx has some swap
| attributes where you can declaratively update as many
| elements of the page as you want. You can grep this id and
| find all the updates easily.
| recursivedoubts wrote:
| https://htmx.org/examples
| t8sr wrote:
| I've looked at a few of those and I still don't understand.
| Also, hilariously, several of them are already broken. (Like
| the table one that's not updating.)
|
| EDIT: Sorry, nevermind. The Bulk Edit example does work, I
| think it either does not like Safari, or something failed to
| load before, but it works in Chrome.
| return_to_monke wrote:
| which table one? all of them seem to work for me.
| recursivedoubts wrote:
| no problem
|
| if you can, try to give the idea some time: it's a bit
| different than other approaches, but it's at least an
| interesting alternative to other front end libraries, even
| if it isn't right for everything
| theptip wrote:
| The great thing about HTMX is it fits really nicely with
| templated server-rendered frameworks like Django.
|
| You can have a page with a list of items. The page is one
| template, and it includes a sub-template which is just the <li>
| items. Then you have a separate view for "get list fragment"
| which just returns the updated/sorted/filtered <li>, rendered
| with that same sub-template. If you toggle the ordering, or
| filter the list, HTMX will automatically call the fragment
| renderer and replace just the <li> items, without reloading the
| page.
|
| See this example: https://github.com/adamchainz/django-
| htmx/blob/8054f049f53f0...
|
| This approach solves the common interactivity use-cases
| requiring JS in a server-rendered app, without having to write
| any JS, and without having to build a REST API. Instead you
| just render HTML, which your framework is excellent at.
| t8sr wrote:
| But you can already do that. I was doing it in the 90s, Ruby
| on Rails supports it, etc. Just send the HTML if you want to
| and call `el.innerHTML = response.body`.
|
| The false dichotomy here is that it's either htmx or React.
| Why not... neither?
| recursivedoubts wrote:
| yep, htmx isn't that complicated
|
| but it does support history, collecting parameters from the
| DOM, an extensive event model and extension model,
| targeting other elements, listening for events in
| sophisticated ways, coordinating multiple elements that are
| making requests, etc.
|
| so there's some additional stuff in there that makes
| building a proper hypermedia-driven application easier
| t8sr wrote:
| Replying to myself: I guess the main point of this library is
| to use HTML as the protocol payload between serve and client,
| instead of JSON. I can see the benefit of doing that, although
| I have a bone to pick with the condemnation of all data APIs
| because JSON is awful. Protocol buffers, for example, are
| trivially forward and backward compatible and mostly self-
| describing.
|
| Also if you build stuff on top of hypermedia APIs then bye bye
| performance. It's probably fine for web pages, because you're
| competing with JS+JSON/REST frameworks that are written by
| people who have never heard the term "L2 cache", but I strongly
| suspect the right move is to drop the framework completely, not
| replace it with a new flavour-of-the-week thing.
|
| Just write HTML5. It's fine. Add javascript for the 2-3 bits of
| interactivity you actually need. If you hate JSON, use
| protobufs. Your web page will work forever, because it'll sit
| on the actual API provided by the browser, and it won't make my
| laptop overheat when I load your site.
| taolegal wrote:
| > I guess the main point of this library is to use HTML as
| the protocol payload between serve and client, instead of
| JSON
|
| HTTP is named Hypertext Transfer Protocol after all.
| Exchanging schema-less JSONs is conceptually pretty lame.
| It's plain old RPC architecture. That's why we end up needing
| to write API docs to line up the frontend and backend, or
| otherwise inspect backend code to figure out what's being
| handed over.
|
| Browsers are built to understand HTML. Whereas in the modern
| world we largely ignore that and write double the code we'd
| have to write otherwise passing arbitrary messages and it
| introduces a whole new set of problems making sure those
| codebases line up properly. Whereas HTML produced by the
| backend (properly) contains all the information someone could
| need.
| airstrike wrote:
| This hits the nail on the head so hard that reading it
| feels like waking up from a bad dream.
|
| _> Browsers are built to understand HTML. Whereas in the
| modern world we largely ignore that and write double the
| code we 'd have to write otherwise passing arbitrary
| messages and it introduces a whole new set of problems
| making sure those codebases line up properly._
|
| This belongs in a manifesto. Put it on a shirt and I'll
| gladly wear it
| mejutoco wrote:
| You can use the swap data attribute to update several
| fragments (imagine a saved icon) in several places
| declaratively.Then you can get rid of almost all your js
| code.
|
| The price to pay for this is it does not work offline. For
| quickly prototyping and app it is very fast.
| t8sr wrote:
| > You can use the swap data attribute to update several
| fragments (imagine a saved icon) in several places
| declaratively.
|
| Yeah, but why? The javascript snippet to accomplish the
| same is absolutely trivial and avoids a dependency.
|
| > The price to pay for this is it does not work offline.
| For quickly prototyping and app it is very fast.
|
| The true price is that you've now rewritten your HTML code
| in a non-standard DSL and are forever dependent on a third
| party library, and all that to accomplish a goal that seems
| entirely aesthetic to me.
| jrochkind1 wrote:
| > Also if you build stuff on top of hypermedia APIs then bye
| bye performance.
|
| This is not obvious to me.
| t8sr wrote:
| This idea used to be called microformats. The premise was
| that you send an HTML snippet, and all the semantic
| attributes plus a protocol definition will let you parse it
| as either data or a part of the UX. It's self-documenting
| in the sense that, if you do it right, the snippet has
| clear semantic meaning.
|
| However, it's not backward and forward compatible as either
| UI or data, because that was never an explicit goal of
| HTML. It's also much slower to process because:
|
| 1) Network IO is CPU intensive, so sending more data is
| worse
|
| 2) HTML is not optimized for data interchange. Parsing a
| protobuf is probably at least 10x faster than parsing the
| same data out of an HTML microformat.
| jmull wrote:
| If I'm understanding this correctly, this is a front-end only
| framework... is that right?
|
| If so, what do people pair it with on the backend?
|
| I can see how this approach allows for much more dynamic pages
| with just static content, but what about when there is a database
| involved?
|
| Also, what do people use for "published" static sites (I mean
| where the site is static once published, but the publishing step
| can pull content from dynamic source. Not sure the common
| terminology for that, but in this case, there tends to still be
| app logic to be developed, but it's just executed at publishing
| time rather than run time.) I'd imagine a publishing framework
| that is htmx-aware/friendly would be powerful.
|
| Just curious how people round out the tech stack.
| recursivedoubts wrote:
| htmx focuses on extending HTML as a hypermedia and, like HTML,
| can work with whatever backend can produce HTML, which is
| pretty much all of them.
|
| We call this the HOWL (Hypermedia On Whatever you'd Like)
| stack.
| kitsunesoba wrote:
| I have yet to use it in anything, but conceptually I'm a fan
| of this kind of freedom of choice. It's always a bummer to
| see something that looks cool for frontend use and find that
| it's tied explicitly to a particular back end.
| andy800 wrote:
| Because HTMX is totally unopinionated regarding the backend,
| and also expects pure HTML responses, you have a ton of
| freedom.
|
| In most cases, this means your choice of backend framework in
| virtually any language, anything from Django to RoR to Spring
| to http4k to Laravel, plus some templating framework/language
| such as Handlebars, Jinja, Thymeleaf, Moustache, JTE, etc.
| jonomacd wrote:
| I've been building a golang app that serves html via the go
| standard library template system. It works really well. You can
| define and execute templates inline so you can define entire
| pages in html and then wrap a "block" around any reusable bit
| that you want to serve up dynamically.
|
| Really easy to use.
| decross wrote:
| htmx is pretty agnostic with regard to the backend side of
| things. You can use anything you want, really. There are htmx
| extensions to Django and I am working on a similar one for
| Express. Basically, a very simple middleware to deal with
| custom request and response headers.
| mathgladiator wrote:
| I was inspired by Htmx to simply fix HTML, and I believe HTMX is
| a great way to go if you are using a traditional backend.
|
| However, I believe in a better way if you have a better backend.
| This is what I'm working on as I build a "vertically integrated
| online board game studio" where I own the infrastructure, the
| clients, the frameworks, and now gaming runtimes.
| shireboy wrote:
| I want to like - I feel like the frameworks are all too much
| ceremony now. You need to buy into a bunch of different build
| tools, a cli or two, and are left wondering "where is my app
| again?" I've tried htmx, though, and like the simplicity, but am
| not 100% sold. In the olden days, ASP.NET Web forms Ajax had
| "Update Panels", which were similar to this. You'd wrap a section
| of markup in an "Update Panel" and that made it refresh just that
| bit of the page while keeping the rest. The problem is your "api"
| then ended up being a bunch of pages that output html, and
| passing state was a huge problem. This seems better, but still
| similar concept.
|
| At the end of the day, I want my backend API to be restful
| json(or grpc, graphql) any client can consume. I want the client
| to be written with as few dependencies as possible. Maybe I'm
| misunderstanding though. Put another way: suppose I have an
| existing backend REST API where input/output is json. Can I use
| htmx without any changes to the api or server-side code to
| translate json to markup?
| recursivedoubts wrote:
| Hypermedia APIs and JSON (Data) APIs are different. I have a
| few essays up on these differences here:
|
| https://htmx.org/essays/hypermedia-apis-vs-data-apis/
|
| https://htmx.org/essays/splitting-your-apis/
|
| Generally, I would recommend splitting your data and hypermedia
| APIs up, so you can take advantage of the features of
| hypermedia (the uniform interface) and still provide a good
| data API to clients that want it.
|
| Also, this is pedantic, but a graphql JSON API is almost
| certainly not REST-ful, in the original sense of that term:
|
| https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...
|
| https://htmx.org/essays/hateoas/
|
| More essays and other silliness here:
|
| https://htmx.org/essays/
| TrickardRixx wrote:
| I'm aware that I'm abusing the tool, but I wrote a htmx
| extension that overrides the mimetype and JSON encodes all
| the parameters. The JSON is decoded into a data bag on the
| back end. Basically I can do "fuck it over HTTP"[0] with
| needing close to zero JS. HTMX has been a god-send to me.
|
| [0]: https://twobithistory.org/2020/06/28/rest.html I
| misremembered the name, it is actually "fuck it, overload
| http"
| andy800 wrote:
| I did something similar, for a dashboard type of web app
| that involves a lot of graphs. JS graph APIs pretty much
| all expect data as JSON-formatted JS variables, not HTML.
|
| So I use HTMX to make the server requests, using triggers
| defined in HTMX, replacing a lot of JS code. It's really
| only with the JSON-based responses that I'm going rogue.
| HTMX is so elegant, I feel dirty going against the grain.
| bminor13 wrote:
| Question about this part of the hypermedia vs data APIs
| essay: "This new end point is driven entirely by hypermedia
| needs, not data model needs. This end point can go away if
| the hypermedia needs of the application change"
|
| Presumably these hypermedia endpoints are all equally
| accessible - couldn't the removal of one break another
| application if the latter app decided to depend on a
| particular hypermedia snippet from the first?
|
| If there are multiple teams in an org that own HTMX
| endpoints, aren't the set of endpoints effectively a sort of
| interface boundary? Or is there a good way of declaring
| certain endpoints "private" and ensuring they're only fetched
| from particular applications? (Maybe separate domains for
| every app?)
| recursivedoubts wrote:
| in the sense I'm using, an application is a single
| functional app: you wouldn't have two applications using a
| shared URL because that would break the uniform interface
|
| you might have two separate apps that maintain their own
| hypermedia APIs and that, on the server side, then share a
| data API between each other
|
| the idea is to take advantage of the uniform interface of a
| hypermedia APIs:
|
| https://htmx.org/essays/hateoas/
|
| but there is an assumption there that the server side gives
| a client a sensible representation of state
| decross wrote:
| the creator has already answered you, but I will add that there
| is an htmx extension called client-side-templates here:
| https://htmx.org/extensions/client-side-templates/
| cryptonector wrote:
| Very nice, but this:
|
| > Now any HTTP verb, not just GET and POST, can be used
|
| requires care. I'm assuming HTMX is just a JS library that
| attaches all these behaviors to HTML. That's fine, as that won't
| change anything as far as cross-site scripting goes. It's just
| that if this were coded in the browser, and the responses to
| these requests made available to the page, then bad things would
| happen.
|
| Also regarding this:
|
| > Note that when you are using htmx, on the server side you
| typically respond with HTML, not JSON. This keeps you firmly
| within the original web programming model, using Hypertext As The
| Engine Of Application State without even needing to really
| understand that concept.
|
| it's much easier to write server-side APIs that produce JSON and
| static HTML + JS that consumes it than it is to generate HTML
| (and then also JSON for non-browser apps).
|
| On the whole I like this a lot.
| megaman821 wrote:
| I have been using HTMX with modal and drawer web components. It
| has been nice to specify interactive pieces of content in a nice
| declarative way.
| nop_slide wrote:
| Relevant talk from the creator of HTMX
|
| https://www.youtube.com/watch?v=LRrrxQXWdhI
| infogulch wrote:
| This is the best of various talks presented by the author imo
___________________________________________________________________
(page generated 2022-12-14 23:00 UTC)