[HN Gopher] Building a single-page app with Htmx
___________________________________________________________________
Building a single-page app with Htmx
Author : veggieroll
Score : 198 points
Date : 2024-10-07 15:19 UTC (7 hours ago)
(HTM) web link (jakelazaroff.com)
(TXT) w3m dump (jakelazaroff.com)
| nsonha wrote:
| "Simple"
| pier25 wrote:
| I'm thinking of starting a project with HTMX and islands of
| interactivity (probably web components). Anyone used this pattern
| in production?
| yawnxyz wrote:
| I tried it and it works nicely for small sites where you look
| up some data / fill in some forms!
|
| Then I really wanted data reactivity, so I started using
| `nanostores`, but I kept wanting more, and eventually added
| `alpinejs`
|
| And then it got a bit too complicated for a one page microsite
| so I switched to Astro (for the interactive islands bit)
| BiteCode_dev wrote:
| Yes, first boosts, then a few gets then a few events that
| cascade. It's nice.
| ebinkebin wrote:
| You should check out astro too!
| pier25 wrote:
| It's my go-to for static sites but for backend I'd rather use
| something else.
| synergy20 wrote:
| seems to me a stretch for what it's best for and designed for
| Bengalilol wrote:
| I wanted to send a UX feedback : Multiline text shrinks the 'x'
| button (the more text, the more shrunk the button gets).
| BiteCode_dev wrote:
| Which means offline htmx is possible, althought I wouldn't love
| to maintain that.
| davidedicillo wrote:
| FWIW, as a hobbyist developer who never had a chance to learn
| React, I found HTMX really helpful to make my Flask projects more
| reactive without adding much complexity.
| itsoktocry wrote:
| Yeah, I'm the same. HTMX may not be great for non-trivial work
| frontend devs are doing, but for hackers piecing together web
| interactivity, it's pretty nice!
| rutierut wrote:
| I see a couple of people here bashing on the practicality of this
| project. That's obviously not the point, it's an interesting
| weird use case that's more explorative/educational than
| practical. I thought it was an interesting and inspiring read!
| baggachipz wrote:
| _" Your scientists were so preoccupied with whether they could,
| they didn't stop to think if they should"_
|
| At that point, maybe stop fighting with service workers and
| simply use a framework like Vue. It allows html templates to be
| swapped in, in much the same way. Except you can actually debug
| it and store in localStorage if you desire.
| jakelazaroff wrote:
| But if I'd used Vue it wouldn't be an interesting article :)
| koolala wrote:
| I hope we build Single-page apps with iFrames one day like how
| the web originally used <frame>. Everyone only talks about
| iFrames as if their only purpose is cross-origin content and
| <frame> is forgotten.
| packetlost wrote:
| Isn't there a bunch of complexity and security issues that come
| with using <iframe>? I'm not as familiar with <frame>.
| koolala wrote:
| No, thats the misconception. All the security is around
| cross-origin usage and optional if using same-origin html
| like a SPA. Each iframe gets its own window element but that
| can simplify component design a ton if embraced.
|
| A <frame> was a system for loading same-origin html files
| from an Index. It was the original Single-page multi-page
| system and at the time seemed good enough for 90% of html 1.0
| sites. <iframe> was supposed to replace it but then everyone
| used it for Ads and closed-source widgets.
| int_19h wrote:
| I remember the days back when <frame> was still common, and
| I wouldn't call it good enough because of the way it
| interacted with URL and history. It was basically
| impossible to bookmark a specific page on a website that
| used frames.
| swyx wrote:
| imo any experienced frontend framework person will be able to
| pick out the issues with this impl. OP is returning entire
| strings of HTML (App, Todo, Icon) to rerender on state changes.
| this works when 1) you dont care about keeping UI state on the
| parts that are replaced (incl any stateful children of the UI
| element that happen to be there in your DOM structure), and 2)
| when you dont have to update the app in any other places when
| your state changes. go ahead and build your whole app by
| replacing innerHtml, frontend frameworks will be right here when
| you get back from speedrunning the last 10 years.
|
| in other words, this todo app is just about the most complex of a
| frontend you can easily* build with htmx, i'm afraid. try to fix
| either 1 or 2 and you end up building components and your own
| little framework.
|
| as an exercise to demonstrate, try taking OPs code and adding a
| count of todos on each All/Active/Completed tab that should
| update every time u add/edit/delete the todos. see how much extra
| ui code that takes. compare with equivalent [framework of choice]
| impl (in most it will just involve 1 state update, thats it).
| this is htmx's explosion of complexity that makes it not [
| optimized for change ] (https://overreacted.io/optimized-for-
| change/). code that is hard to change eventually calcifies and
| consumes code that is easy to change if you do not consistently
| garbage collect (nobody does)
|
| i bought the hype too until i tried building something nontrivial
| in htmx and im afraid the aforementioned islands of interactivity
| you can build are very very smol islands indeed.
|
| happy to revisit my opinion if there are componentlike design
| patterns in htmx i am not aware of.
|
| *emphasis on easily; with enough elbow grease u can do anything
| ofc. but then you fall out of htmx's very narrow [ pit of success
| ](obligatory codinghorror dot com link)
| aaronbrethorst wrote:
| I'm not super-stoked about the idea of building SPAs on top of
| htmx, but what I have found works incredibly well is to build a
| traditional MPA (SSR etc), embed islands of interactivity where
| needed, and where something fancier is really necessary, embed
| a React or Svelte app into just that one portion of a single
| page.
| swyx wrote:
| yea im not even talking about SPAs in my post, just the
| complexity explosion that comes with updating state in more
| than 1 place / preserving ui state in the place that gets
| rerendered. it blows up in your face quickly if you have even
| any requirement volatility
| (https://stackoverflow.blog/2020/02/20/requirements-
| volatilit...)
| jonathrg wrote:
| I agree that it becomes complex if you have state on the
| frontend. htmx scales better if you keep all or most of
| your state on the backend. I've found that using the
| websockets extension really helps with automatically
| keeping the frontend in sync.
| ctvo wrote:
| > I've found that using the websockets extension really
| helps with automatically keeping the frontend in sync.
|
| I choked reading this imagining people thinking they're
| doing something simple (as in not complex) by introducing
| websockets so they can keep state in their Go backend and
| sync it with their front-end, ya know, to keep track of
| the # of TODOs checked.
| jonathrg wrote:
| But it is simple :) The underlying technology might be
| more complex, but the library is solid, it's trivial to
| update any part of the page once you have the libraries
| set up, and you don't need to write any javascript. Works
| for me!
| maddalax wrote:
| why websockets and not just SSE + XHR? Or even just XHR
|
| Edit: SSE*
| jonathrg wrote:
| It is SSR, in the sense that the server sends HTML over
| the websocket. HTMX swaps out content based on the
| element id. Doc: https://v1.htmx.org/extensions/web-
| sockets/
|
| If you mean SSE, then yes that would work just as well
| (unless you need the bidirectionality for the client to
| modify some aspect of the connection after the page has
| loaded). There is an htmx-sse extension too.
|
| I'm not sure how XHR alone would let you automatically
| get backend state changes reflected to the frontend. You
| can poll one or more endpoint, but that's more
| complicated to get right and less efficient.
| maddalax wrote:
| Sorry yes I meant SSE, mistyped!
| jonathrg wrote:
| > Mostly just thinking that XHR to mutate (form
| submissions, etc) and then SSE to send the updated DOM
| elements would be a good combo
|
| Yes, that's basically the idea.
| maddalax wrote:
| Mostly just thinking that XHR to mutate (form
| submissions, etc) and then SSE to send the updated DOM
| elements would be a good combo
| klibertp wrote:
| > I'm not sure how XHR alone would let you automatically
| get backend state changes reflected to the frontend.
|
| Long polling.
|
| Check out (history of) "Comet": https://en.wikipedia.org/
| wiki/Comet_(programming)#Implementa...
| ctvo wrote:
| > But it is simple :)
|
| I think you may mean easy. It may be _easy_, but it's not
| simple. There are so many more moving pieces, failure
| modes, operational issues now to consider. Websocket
| connections aren't free.
| jonathrg wrote:
| I guess I just have to disagree. My experience is that it
| is robust, and removes an entire category of problems
| that appear when your state is spread across the back-
| and frontend.
|
| As someone else mentioned, SSE is a somewhat simpler
| protocol that achieves the same purpose. Same idea
| though.
| dingnuts wrote:
| there's nothing to sync, the state is only in the
| backend. if you tell the user that the TODO is checked
| and you're only keeping track of it in the frontend and
| you don't sync it to the server and it's lost in the
| meantime, your UI lied to the user when they checked it
| and it showed as checked. With state on the backend, the
| user doesn't see that their data is saved until, you
| know, it actually is. And if all the state is rendered
| from the backend it can't get out of sync with the
| display
|
| I hate it when a UI tells me I did an action when really
| there's an asynchronous background task happening that
| may fail
| mslip1 wrote:
| So I'm building something with HTMX - combining it with alpine
| has been pretty nice for interactivity managed by client side
| state
| swyx wrote:
| i havent tried the combination - perhaps this is the thing
| ive been missing. any recommended intro/resource for alpine +
| htmx that we can browse?
| dimfeld wrote:
| Google for AHA stack. (Astro, HTMX, Alpine) There was a
| great site by Flavio Copes that went into a lot of detail
| on using them together but it looks like it's gone.
| flaviocopes wrote:
| Dropped it a couple days ago to revisit it as a blog
| post, good timing I guess. Restored https://ahastack.dev/
| martinbaun wrote:
| It's pretty good combo. I use Alpinejs for the client side
| interactivty such as modals, but then use htmx for as much
| as I can that interacts with the backend.
|
| You could be using only htmx or only alpine but the combo
| is really nice
| wk_end wrote:
| It seems like it makes easy things easy and hard things hard,
| which seems like a pretty poor value proposition - at least
| relative to some of the hype around it.
| afavour wrote:
| I think the takeaway here is "make the easy things easy,
| don't use it for the hard things".
|
| One of the most exhausting things about any discussion about
| front end web dev is that it gets treated like a monolith. It
| _can_ be incredibly complicated. In many scenarios that
| complication is unwarranted. But in some it's justified.
|
| Htmx is a poor choice for a full single page app. That's
| fine. It excels in other areas. Right tool for the right job.
| wk_end wrote:
| But easy things are also relatively easy when using other
| tools that scale up better. Even if HTMX makes the easy
| things slightly easier, is that worth investing time and
| energy into learning it in addition to those tools that
| scale up better? Is it worth building things with it if I
| know that months down the line I'm going to need to scrap
| it once my easy thing becomes slightly less easy?
|
| Like I said, this seems like a poor value proposition to
| me. Of course, if other people are happy with it more power
| to 'em.
|
| To me it feels like people are eager to latch onto this
| because it's different, and because there's a dopamine hit
| associated with seeing the easy thing become a little
| easier when taking a new path that's overoptimized for it -
| hence the hype - not because it's actually good
| engineering, in terms of the tradeoffs you're making.
|
| Of course, I feel the same way about Tailwind, so maybe I'm
| just old and grumpy.
| Spivak wrote:
| Because it's a drop-in, no-dependency, no build-step
| library that can make your static MPA a little less
| static for the little bits of interactivity you need with
| not much effort. It's what you reach for to avoid "write
| the whole website in JS."
|
| React -> "The site exists in JS, HTML is just a render
| target."
|
| jQuery -> "Poke at the HTML from JS." Which is brittle as
| hell.
|
| htmx -> "The site exists in HTML, extend HTML to handle
| the common tasks you want to do with it."
| afavour wrote:
| > Even if HTMX makes the easy things slightly easier, is
| that worth investing time and energy into learning it in
| addition to those tools that scale up better?
|
| Depends what your aim is. Do you want to become a full
| time front end engineer? Then no, probably focus on other
| frameworks. But do you, from time to time, want to put
| small pieces of interactivity on web pages when it isn't
| the sole (or even major) focus of your job? Htmx might be
| ideal.
| librasteve wrote:
| For me the strength of htmx is to allow non JS languages
| and frameworks on the server side. Now I can use
| Raku+Cro+Red to make a modern website with dynamical modern
| UX. The standard paradigm is keep all state in isolated
| htmx state machines (eg modelling a form submission) or
| real state stored in my db and this works fine for my
| simple site needs.
| nsonha wrote:
| > strength of htmx is to allow non JS languages and
| frameworks on the server side
|
| I don't see how that has anything to do with the choice
| of htmlx. You always have the freedom to use any
| languages in the backend. If anything, htmlx impose a
| bunch of hypermedia convention on top of your
| conventional API, regardless of languages.
|
| Back-end devs think htmlx will allow them to be comfy in
| the back-end and just trash their front end with "thin
| client" that has no framework or any sort of
| organization. Eventually someone who understands front-
| end have to rebuild it and decouple the 2. Happens all
| the time.
| yellowapple wrote:
| On the contrary, making easy things easy and hard things
| possible is about as good of a value proposition as I can
| realistically expect. Hard things are going to be hard no
| matter what, and making them easy usually either adds
| excessive complexity or else makes easy things hard (if not
| impossible).
| wk_end wrote:
| Making easy things easy and hard things possible is great,
| I agree...but that's not what I wrote. And I don't think
| that's what HTMX provides - it mostly gets in your way with
| the hard things.
| yellowapple wrote:
| > but that's not what I wrote.
|
| Making hard things hard is a subset of making hard things
| possible. Better than making hard things _im_ possible,
| which is the usual result of making easy things easy :)
|
| > And I don't think that's what HTMX provides - it mostly
| gets in your way with the hard things.
|
| And yet they're still possible. Like I said: hard things
| are going to be hard no matter what. Even if the hard
| things are harder, that's still a worthwhile tradeoff for
| maximizing the easy things.
| traverseda wrote:
| > when you dont have to update the app in any other places when
| your state change
|
| You can replace elements outside of your direct tree if you
| want. The simplest case you replace the whole page and pick
| what elements you actually want to change.
|
| You're thinking about HTMX wrong. It's for progressive
| enhancement, the default is a full page reload and then you
| progressively enhance parts of the HTML. You should be using
| the same code paths and template to generate the islands of
| interactivity as you do for the whole page. You can then
| optionally send less HTML by just sending the parts that you
| expect to have actually changed, your "islands".
| LudwigNagasena wrote:
| > You can then optionally send less HTML by just sending the
| parts that you expect to have actually changed, your
| "islands".
|
| And then you end up with modern SSR frameworks that do the
| bookkeeping for you.
| Imustaskforhelp wrote:
| yes but mostly the island architecture is only dominant in
| the javascript world
|
| we can basically get the benefits of spa without having to
| learn js / use minimal js using htmx in some sense
|
| https://github.com/donseba/go-htmx check this out
| dingnuts wrote:
| If you render HTML on the client you still have to render a
| transport format (usually JSON) on the server side. Sending
| HTML just lets you skip the transport format and the client
| side rendering.
| swyx wrote:
| appreciate that. ive been given the progressive enhancement
| spiel a few times. its obviously a judgement call that will
| be the right call for some people. but i think many people
| underestimate how requirements grow over time because our UI
| standards have gone up over time, even for basic sites that
| you dont traditionally think of as SPAs. data drives
| everything, you want your UI to be a function of data.
|
| for the other stuff, the growing browser stdlib has basically
| replaced most of jquery's usecases. so (in the most non
| condescending or negative way possible) htmx occupies a very
| awkward sliver between "The Platform" and Frameworkland and
| after giving it some time I have yet to see the benefit from
| keeping any of it in my head
| poincaredisk wrote:
| I'm obviously in the minority, but I breathe a sigh of
| relief every time I encounter a website that works workout
| JS, don't hijack basic browser functionality, don't make
| dozens of AJAX requests in the background, and overall just
| focuses on presenting the data I want.
| mpweiher wrote:
| I don't think you are in the minority.
|
| At all.
|
| Every time web sites reimplement basic browser behavior,
| which they invariably do these days, they get worse,
| often significantly, because they never get it right.
| yawaramin wrote:
| > i think many people underestimate how requirements grow
| over time because our UI standards have gone up over time
|
| I think you are overestimating how much 'UI standards' have
| gone up over time, actually. Nobody except for a small
| 'extremely online' set of people and control-freak
| designers care about all those complex UI/UX requirements.
| Users certainly don't care. They want fast-loading,
| responsive pages that get out of the way and don't drain
| their batteries or clog up their connection.
|
| The other thing here is that approximately no one can
| actually tackle the complexity introduced by SPA frameworks
| and 'UI standards', and it's far more likely that they
| bungle it up and make giant, wasteful, UX pitfall-ridden
| apps. With server rendered pages, plain old HTML, and
| progressive enhancement, we at least have a better chance
| of producing something usable.
| L3viathan wrote:
| While I agree with this project being a bad idea, both 1 and 2
| are addressed by HTMX itself, via hx-preserve and Out-Of-Bounds
| swaps.
| swyx wrote:
| thanks. yeah i will be the first to admit i've only spent
| like 2 days with htmx so i wont know everything (but
| still...)
|
| re: hx-preserve. what if i want to "conditionally preserve" -
| preserve this element when my state is one way, but not in
| other states? i dont see a way.
|
| re: hx-swap-oob. looking at https://htmx.org/attributes/hx-
| swap-oob/ i think it still does not address what i'm looking
| for. any master-detail list kind of UI will want updates in
| 2-3 places when 1 piece of state updates (aka ui consistency,
| ui as a function of state). i fail to see how attaching an
| attribute with 1 place for an ID solves that. perhaps theres
| another api for "multiswap"? even if it existed... idk if i'd
| be comfortable using it man (ofc, i am clearly biased/taught
| to "think in components" from 7 years of react exp)
| jdiff wrote:
| You're misunderstanding hx-swap-oob. Each element with that
| attribute will go and replace the element with the matching
| ID, keeping them all in sync with one response from the
| server.
| artificialLimbs wrote:
| 'preserve this element when my state is one way, but not in
| other states'
|
| You could send the state back to the server with the
| request and respond appropriately on the backend. Or check
| in the db without sending it, if it lives in the db (it
| probably should?).
| jdiff wrote:
| > 1) you dont care about keeping UI state on the parts that are
| replaced (incl any stateful children of the UI element that
| happen to be there in your DOM structure), and 2) when you dont
| have to update the app in any other places when your state
| changes
|
| Htmx does have tools for both of these cases. Out of the box,
| htmx throws out state, but there are plugins such as morphdom-
| swap for merging in the new DOM fragment into the old while
| keeping state. I have some client-only state that holds
| references to DOM elements in Javascript, and by default, yes,
| htmx breaks all those references as those elements no longer
| exist. Link in morphdom-swap, and my references live on across
| reloads, even across attribute and content changes.
|
| And for #2, htmx also allows you to swap in elements that are
| not the target element, just by specifying that that's what you
| want.
|
| IMO these are pretty basic tools of htmx. Like you said,
| without them about the most complex thing you can create is a
| to-do list, and sometimes not even that.
| swyx wrote:
| > morphdom-swap
|
| this https://github.com/bigskysoftware/htmx-
| extensions/tree/main/... with 159 stars is a basic tool of
| htmx? is this the community consensus?
| jdiff wrote:
| No. Morph swaps[0] are the basic tool of htmx. Morphdom-
| swap is simply the one that works for my usecase.
|
| [0] https://htmx.org/docs/#morphing
| jonathrg wrote:
| Parts of htmx were yoinked out of the core library into an
| extensions repo relatively recently, as part of htmx 2.0.
| That might explain the relatively lower number of stars.
| More important than github stars is that it is indeed part
| of the htmx project and is documented here
| https://htmx.org/extensions/
| throwitaway1123 wrote:
| The htmx author maintains his own swapping library which
| has more stars (although I wouldn't judge a project solely
| based on Github stars):
| https://github.com/bigskysoftware/idiomorph?tab=readme-ov-
| fi...
| nsonha wrote:
| Just step back for a second and think about programming
| without modeling the states. Framework or not, no amount of
| hacking/tooling can help you with that.
| stuckinhell wrote:
| I agree with you. After seeing some internal prototypes at my
| job abusing htmx boost. I'm slowly going on the anti-htmx
| bandwagon. I'm still not pro-react or pro-vue. We need a
| stabler frontend js framework.
| jerrygenser wrote:
| I was just looking into htmx the other day. Came across the
| following library: https://github.com/iwanalabs/django-htmx-
| components
|
| It's an example using django-components. Does this satisfy your
| comment about component at all?
| mordechai9000 wrote:
| In that case, IIUC, state is managed on the server, and the
| client is only responsible for rendering views generated on
| the backend and returning user input via form or json. This
| is what htmx was really designed for, anyway.
| normanthreep wrote:
| >smol
|
| small. thanks
| low_tech_punk wrote:
| The author swyx is the founder of https://smol.ai/ It's
| either a typo out of habit, or an intentional reference
| normanthreep wrote:
| the word is still spelled "small". fight meme speak
| int_19h wrote:
| So long as people understand it, why should anybody care?
| tshaddox wrote:
| > frontend frameworks will be right here when you get back from
| speedrunning the last 10 years
|
| More like speedrunning the period between 20 years ago and 10
| years ago! React is 11 years old, much older than jQuery was
| when React was initially released.
| evantbyrne wrote:
| In my decades of experience building web applications, I have
| found it exceedingly rare for components to benefit from SPA-
| style state management. These frameworks build layers of
| abstractions to replace functionality that exists in the
| browser. For example, web forms should never require the level
| of complexity that frameworks like React steer developers
| towards: downloading JS components, listening to events to
| build a local state, crafting an AJAX request, rendering the
| return JSON as HTML. It almost seems as though there is an
| entire generation of frontend developers who never learned that
| there are way simpler alternatives that perform just as well in
| the real world. htmx might not end up being a SPA-killer, but
| progressive enhancement has always been a worthy contender.
| davedx wrote:
| I don't know about the kind of web apps you've been building,
| but most of the ones I've built over the last 10-15 years
| have had too much interactivity to be done with simpler
| server side rendering.
| evantbyrne wrote:
| Everything from MPAs, to SPAs, to animation heavy websites
| that could only dream on being tailwind. Progressive
| enhancement doesn't mean giving up on frontend validation,
| dynamic functionality, and juice. I'm curious what problems
| you haven't been able to solve without converting whole
| applications to JSX.
| endemic wrote:
| That's the exact opposite of my experience. Completely
| boring biz software that was, in essence, collections of
| forms. Didn't need the additional development burden of an
| extra JavaScript codebase, but that's what's in vogue, so
| -\\_(tsu)_/-
| pseudosavant wrote:
| I think the SPA and the no-JS SSR people get it wrong by
| making it so black and white. By choosing to use something
| like React, you've made everything only SPA. With SSR, you
| can at least choose to progressively enhance the
| interactions. Look at amazon.com. They have plenty of full
| page reloads, yet their site also has tons of
| interactivity. Just make sure that the thing you require a
| full page reload for happens at a natural transition where
| it isn't interrupting the user's experience.
| nsonha wrote:
| I notice you started by a blanket statment and use a strawman
| that is forms in React, framework known for being the worst
| for forms (if you don't know the right library). Overall a
| poor criticism of SPA as a whole.
| malkarouri wrote:
| Honestly interested in your experience.
|
| I am not surprised around (1). HTMX is based on REST, which is
| by nature based towards having the state in the server and
| having a stateless client. But what is the advantage of having
| the state in the client. Isn't that just a bias of the current
| frameworks?
|
| I can see cases where you really need a thick client, and in
| that case I would use GraphQL rather than REST for those. But,
| there are quite a few cases that can work with REST and mostly
| server side.
|
| I think (2) is solved by out of band capabilities of HTMX. I
| don't think that is naturally a limitation of the
| conceptualisation.
| low_tech_punk wrote:
| Glad to see you here swyx. I think the issue you outlined is
| acknowledged by the htmx's authors and addressed in the Morph
| Swaps documentation: https://htmx.org/docs/#morphing
|
| What is ironic though, is that the morphing algorithms are
| similar to what modern SPA frameworks do, except that it can be
| addressed without introducing new concepts such as vdom, zones,
| signal etc.
|
| I agree that the island architecture is limiting when it comes
| to large scale application with state shared across multiple
| areas in the UI. I'd be curious to hear others finding success
| in building apps.
|
| p.s. I appreciate the smol island :)
| pjs_ wrote:
| On item 2, you can use hx-swap-oob to update as many other
| parts of the page as you like. That will work great for the
| count that you propose.
|
| https://htmx.org/attributes/hx-swap-oob/
| turtlebits wrote:
| IME, Htmx is best for enriching server side rendered (non-SPA)
| apps. I'm having an great time with single file web apps using
| FastHTML (python).
|
| I've rewritten a bunch of my JS framework apps for simplicity and
| don't miss much.
| huuhee3 wrote:
| I agree. I'm building some internal tools at work, and htmx is
| awesome when you just want to add a bit of interactivity to
| server side generated pages. With minimum amount of code I can
| just update the view by returning the relevant parts from the
| templating engine. It promotes code reuse and is faster to
| implement than any other framework based solution.
| altbdoor wrote:
| I made a somewhat similar prototype by mocking XHR instead of
| service workers, in
| https://stackblitz.com/edit/typescript-h3wfwx?file=index.ts
|
| It was fun for a bit to quickly experiment with how htmx works,
| but I find it difficult to scale in terms of state.
| extr wrote:
| I am a backend/ML engineer and tried using HTMX to create a
| website with:
|
| * Search box
|
| * Typeahead
|
| * Instantly updating search results
|
| It was super instructive. In the end, I realized HTMX was
| probably not the best tool for that job, but it really helped me
| bridge the gap between "I get in theory why we use JS on the FE"
| and "Ah, I can see why client side JS is the obvious choice for
| this".
| berkes wrote:
| I'm not sure if I follow this example, though.
|
| Doesn't a searchbox with typeahead and instantly updating
| results still require a backend? Isn't that backend not the
| most important ingredient of this use-case?
|
| Or did you send a large payload of objects to the frontend and
| have it indexed clientside with e.g. lunr.js? I've used fuse.js
| for this, but for a use-case where we knew we had less than a
| hundred documents to index and where the access control was
| simple and the content reasonably stable. I'd never use this
| for a search feature in e.g. an admin backend or a large,
| content-rich webapp.
| extr wrote:
| Yeah the "pure" backend side (DB/queries to it) was not a
| problem and something I was already comfortable with. I did
| not use a client JS library for filtering, I was trying to
| stick to pure HTML response routes as much as possible. In
| addition to the typeahead search I had some dropdown and
| radio toggle filters. I wanted these to all be reactive to
| each other, eg, you shouldn't be able to select the region
| "North America" if none of the current typeahead results have
| that as a region. I found this confusing to implement within
| the HTMX paradigm. I had a lot of HTML partial templates and
| had trouble mentally modeling how it was all fitting
| together.
|
| TBF, probably partially a skill issue. But I know that just
| going back to a "normal" approach where my backend returned a
| huge payload and then I wrote the filtering/rendering in JS,
| was sooo much simpler to think about, even if it resulted in
| more total code.
| smallerfish wrote:
| What issues did you run into with this? I do exactly this in a
| couple of apps. You can use a `keyup changed
| delay:${delayMs}ms` event, and you target the area on your page
| where you want search results.
| extr wrote:
| I also took that approach. The problem wasn't the keyup
| trigger, moreso trying to make the typeahead suggestions play
| nicely with radio/toggle filters, plus the results, made
| things really confusing for me personally. I was taking the
| approach of ONLY returning HTML from my endpoints and found
| it hard to mentally model how all the templates were fitting
| together (probably a skill issue, I am very new to webdev).
|
| Once I abandoned the pure HTML/HTMX approach and just focused
| on returning a big payload with the search results in JSON
| and rendering it with vanilla JS, the whole thing became a
| lot easier.
| leephillips wrote:
| I don't know if the article describes the best use of HTMX, but
| when I wanted to experiment with building an interactive physics
| application on the web that used Julia on the backend, it was a
| perfect fit. I could design the whole page without any javascript
| (almost):
|
| https://lee-phillips.org/pluckit/
| tzahifadida wrote:
| Was wondering if any1 embeds react spa apps in golang binaries to
| build a lean SaaS?
| uhtred wrote:
| I think 68% of SPAs don't need to be SPAs. The end user doesn't
| care if the browser page refreshes if it is quick.
| tigroferoce wrote:
| I'm adding onto this: I think that the whole SPA concept is
| wrong most of the time. You want most of the time some sort of
| state persistence in the url, so that you can bookmark/pass
| around something that is meaningful, not something that is
| always the starting point of everything.
|
| If I'm seeing a list of todos and I've filter actives there's
| really no benefit into not having the filters reflected in the
| url. The same goes if I'm navigating some data in the form of
| some table and I'm, let's say, at page 2.
| int_19h wrote:
| The usual argument is that a well-written SPA will track its
| state correctly in the URL, including things like filters,
| current page etc.
|
| The practical issue is that very few SPA apps actually do
| that consistently. Moreover, because it requires a conscious
| effort on behalf of developers, a fresh new app might be
| well-written in that regard, but over the years, as "got to
| fix this quickly for release" cruft piles up, it becomes
| worse and worse in that regard.
|
| I think the only way to actually make this concept work
| reliably is to _force_ people to store state in the URL
| somehow, or at least make that easier than storing it
| anywhere else.
| robertoandred wrote:
| So they don't need to be MPAs either.
| sgt wrote:
| I'm not sure about this approach but it does look interesting. I
| think it'll work fine.
|
| My method is however to use Django and templates to build a
| regular MPA, and then switch out link changes (between pages)
| with htmx functionality so there is no browser reload. At least
| then you'll have a webapp that acts mostly like an SPA.
|
| Next up, you can add more interactivity using htmx as much as you
| want (with some kind of Django components, ideally). You can even
| add VueJS to one of the pages if you want, but full blown SPA
| frameworks tend to eat into development time, so rather not
| unless absolutely needed.
| kccqzy wrote:
| Anyone who says React has mired developers in complexity needs to
| go back ten years and use jQuery to build a single-page app and
| remind themselves how much less complex React is. I know that
| because I rewrote a jQuery-based SPA in React back in 2015 and
| that experience was so revelatory that I will never forget it.
|
| It is then that they will realize complexity comes from single-
| page apps. Pushing back against that complexity should result in
| not building SPAs, which is where Htmx comes in. There are still
| plenty of very successful web apps that are not SPAs.
|
| If a product owner asks to build a SPA, a developer's job is to
| stop and ask why. Most likely what the product owner really has
| in mind can be accomplished without a SPA.
| hinkley wrote:
| I've noticed there's some mental block where managers and
| product owners behave as if adding new pages to a multipage app
| is too expensive so they just keep cramming more functionality
| into the existing half-dozen, dozen, or twenty pages. After
| three or more years it feels like you have a handful of single
| page apps, and jquery and many other tools struggle there.
| v3ss0n wrote:
| This is really bad abomination .. please keep SPA to SPA
| Frameworks and leave HTMX out of it..
| JodieBenitez wrote:
| It's already bad enough that too many devs think only in SPA
| mode, now you're trying to use the wrong tool for the wrong
| solution !
|
| Fun experiment though, in the true "hacker" spirit ;-)
| davedx wrote:
| Htmx - the hipster tech of the decade, honestly
| maddalax wrote:
| imo htmx is good but its a bit too low level to use directly, you
| sort of have to rebuild all the features frameworks like React
| have, such as components in your server programming language.
|
| I'm building https://htmgo.dev to do that with go + htmx, and
| http://fastht.ml seems like a good contender for python
___________________________________________________________________
(page generated 2024-10-07 23:01 UTC)