9 ms·

Building a single-page app with Htmx

252 points by veggieroll 2y ago

nsonha 2y ago
"Simple"
wetpaws 2y ago
[dead]
pier25 2y ago
I'm thinking of starting a project with HTMX and islands of interactivity (probably web components). Anyone used this pattern in production?
- yawnxyz 2y ago
  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 2y ago
  Yes, first boosts, then a few gets then a few events that cascade. It's nice.
- ebinkebin 2y ago
  You should check out astro too!
  - pier25 2y ago
    It's my go-to for static sites but for backend I'd rather use something else.
synergy20 2y ago
seems to me a stretch for what it's best for and designed for
Bengalilol 2y ago
I wanted to send a UX feedback : Multiline text shrinks the 'x' button (the more text, the more shrunk the button gets).
BiteCode_dev 2y ago
Which means offline htmx is possible, althought I wouldn't love to maintain that.
davidedicillo 2y ago
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 2y ago
  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!
- EasyMark 2y ago
  I’ve used if for some internal pages and it’s fine. I’m not sure I would want to use it to make the next Facebook though. Maybe the next Amazon?
rutierut 2y ago
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 2y ago
"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 2y ago
  But if I’d used Vue it wouldn’t be an interesting article :)
koolala 2y ago
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 2y ago
  Isn't there a bunch of complexity and security issues that come with using <iframe>? I'm not as familiar with <frame>.
  - koolala 2y ago
    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 2y ago
      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.
      - koolala 2y ago
        It's a shame that was never solved because there is no reason it should be "impossible". Nowadays we have more control of URL and history. There must be a way.
        int_19h 2y ago
        Well, the way frames are specified, each has an URL in its own right, so the way to do it would be to come up with some algorithm that combines them all in a single URL without losing any data. The resulting URLs would inevitably be messy, though. These days we basically hack around all this in JS by manually controlling history. Which is brittle as hell, and why so many web apps break "Back" etc. Managing state is always a hard problem. Versionable extensible persistence is harder still. Now add the requirement that this state has to be captured in a concise but human-readable way, and it's really hard to do in a way that doesn't introduce numerous footguns. I'm not saying that there isn't some good solution, but I don't know what it is, and I don't think anyone has figured this out yet.
swyx 2y ago
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/ 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 2y ago
  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 2y ago
    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-volatility-is-the-core-problem-of-software-engineering/ https://stackoverflow.blog/2020/02/20/requirements-volatilit...)
turtlebits 2y ago
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 2y ago
  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 2y ago
I made a somewhat similar prototype by mocking XHR instead of service workers, in https://stackblitz.com/edit/typescript-h3wfwx?file=index.ts 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 2y ago
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 2y ago
  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 2y ago
    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.
    - scottyeager 2y ago
      I'm working on my first project with htmx and had a similar dilemma. The core issue is that the input form itself has some state, in terms of which options are selected or which options are available. Even in the case of a simple drop down, the user's selection can get cleared if they drill into a result and then hit the browser back button. At first I was reaching for JS and this feels good—total control! But I wanted to challenge myself to use a hypermedia based approach, and in the end the outcome felt better. One key insight was that I needed to rerender the form too when I returned the results. At first I only inserted the results into the page and left the form untouched. Later I also realized that if you want to encode the entire search in the url as parameters, then you need a way to render that combo of results and form state on page load anyway. I guess where it can get tricky is with the templating system. I used FastHTML and wrote all my HTML as Python code. This gives the full expressiveness of the programming language, which is nice, but it seems that templating systems typically provide plenty of logic and control flow. A single template can do a lot. For your example of making only certain regions selectable depending on search results, you could pass the list of regions into the template engine and use a for loop capability in the template. But hey, you found a way that works and that's great. Just wanted to share that I found with a bit of paradigm shift I found the hypermedia approach really straightforward and clean.
leephillips 2y ago
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/ https://lee-phillips.org/pluckit/
- deleted 2y ago
  [deleted]
tzahifadida 2y ago
Was wondering if any1 embeds react spa apps in golang binaries to build a lean SaaS?
uhtred 2y ago
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 2y ago
  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 2y ago
    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 2y ago
  So they don't need to be MPAs either.
sgt 2y ago
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 2y ago
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 2y ago
  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 2y ago
This is really bad abomination .. please keep SPA to SPA Frameworks and leave HTMX out of it..
JodieBenitez 2y ago
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 2y ago
Htmx - the hipster tech of the decade, honestly
maddalax 2y ago
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 https://htmgo.dev to do that with go + htmx, and http://fastht.ml http://fastht.ml seems like a good contender for python
VagabundoP 2y ago
For my own hobby useage - ie apps I shared with a few people - htmx is a godsend. It lets me focus most of my time in python/flask. I do have a slightly more complicated TTRPG live character sheet that I use for a game I run. Its got five users at once and sqlite backend. Its gotten moderately more complicated over the last year and now sports htmx, discord integration, and will soon have SSE for me to push events to their character sheets, like ability point refreshes etc and other fun stuff without them having to refresh the page all the time. I'm just thankful I don't have to dive into JS frameworks and can mostly stay in html, maybe a little hyperscript.
sinanisler 2y ago
it's sucks man who even uses this useless thing btw https://swag.htmx.org/products/htmx-sucks-mug https://swag.htmx.org/products/htmx-sucks-mug
pyzn 2y ago
Seems like lots of code for a todo list
zoezoezoezoe 2y ago
HTMX is an idea that I never understood. HTML over the wire sounds like the most egregious idea I could have ever thought of. If you want a sub par SPA experience just build an SPA with PHP ;), and if you want a real SPA that doesnt have 600 ms of latency when I click a button that for some god forsaken reason calls an api endpoint, use React or Vue or Svelte like we always have. Is it perfect? Trust me, as someone who is trying to build something that delivers an actual SPA experience with SSR without Node.js, it's not, but a real SPA is miles better than streaming HTML over the wire.
- recursivedoubts 2y ago
  not always: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/
  - zoezoezoezoe 2y ago
    I think I actually like what they are doing. They're using a combination of Stimulus and HTMX, which I think is a more valid approach than the approach that Hey (the email and calendars site) and many others take, where practically every interaction streams HTML over the wire as opposed to what David and his team are doing where it gets the information on page load so that you arent waiting around for content to come over the wire. I think this approach is how HTMX should be used, but it often is used in a similar fashion to how Hey works, and I think that's the major flaw, take what I say with a grain of salt, but I dont think HTMX pushes the idea that you should preload stuff very well.
    - recursivedoubts 2y ago
      Scripting is part of the web platform and perfectly acceptable in a hypermedia based application: https://htmx.org/essays/hypermedia-friendly-scripting/ https://htmx.org/essays/hypermedia-friendly-scripting/ https://hypermedia.systems/client-side-scripting/ https://hypermedia.systems/client-side-scripting/

252 points by veggieroll 2y ago

nsonha 2y ago

"Simple"

wetpaws 2y ago

[dead]

pier25 2y ago

I'm thinking of starting a project with HTMX and islands of interactivity (probably web components). Anyone used this pattern in production?

yawnxyz 2y ago
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 2y ago
Yes, first boosts, then a few gets then a few events that cascade. It's nice.
ebinkebin 2y ago
You should check out astro too!
- pier25 2y ago
  It's my go-to for static sites but for backend I'd rather use something else.

synergy20 2y ago

seems to me a stretch for what it's best for and designed for

Bengalilol 2y ago

I wanted to send a UX feedback : Multiline text shrinks the 'x' button (the more text, the more shrunk the button gets).

BiteCode_dev 2y ago

Which means offline htmx is possible, althought I wouldn't love to maintain that.

davidedicillo 2y ago

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 2y ago
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!
EasyMark 2y ago
I’ve used if for some internal pages and it’s fine. I’m not sure I would want to use it to make the next Facebook though. Maybe the next Amazon?

rutierut 2y ago

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 2y ago

"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 2y ago
But if I’d used Vue it wouldn’t be an interesting article :)

koolala 2y ago

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 2y ago
Isn't there a bunch of complexity and security issues that come with using <iframe>? I'm not as familiar with <frame>.
- koolala 2y ago
  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 2y ago
    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.
    - koolala 2y ago
      It's a shame that was never solved because there is no reason it should be "impossible". Nowadays we have more control of URL and history. There must be a way.
      - int_19h 2y ago
        Well, the way frames are specified, each has an URL in its own right, so the way to do it would be to come up with some algorithm that combines them all in a single URL without losing any data. The resulting URLs would inevitably be messy, though. These days we basically hack around all this in JS by manually controlling history. Which is brittle as hell, and why so many web apps break "Back" etc. Managing state is always a hard problem. Versionable extensible persistence is harder still. Now add the requirement that this state has to be captured in a concise but human-readable way, and it's really hard to do in a way that doesn't introduce numerous footguns. I'm not saying that there isn't some good solution, but I don't know what it is, and I don't think anyone has figured this out yet.

swyx 2y ago

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/ 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 2y ago
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 2y ago
  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-volatility-is-the-core-problem-of-software-engineering/ https://stackoverflow.blog/2020/02/20/requirements-volatilit...)

turtlebits 2y ago

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 2y ago
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 2y ago

I made a somewhat similar prototype by mocking XHR instead of service workers, in https://stackblitz.com/edit/typescript-h3wfwx?file=index.ts 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 2y ago

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 2y ago
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 2y ago
  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.
  - scottyeager 2y ago
    I'm working on my first project with htmx and had a similar dilemma. The core issue is that the input form itself has some state, in terms of which options are selected or which options are available. Even in the case of a simple drop down, the user's selection can get cleared if they drill into a result and then hit the browser back button. At first I was reaching for JS and this feels good—total control! But I wanted to challenge myself to use a hypermedia based approach, and in the end the outcome felt better. One key insight was that I needed to rerender the form too when I returned the results. At first I only inserted the results into the page and left the form untouched. Later I also realized that if you want to encode the entire search in the url as parameters, then you need a way to render that combo of results and form state on page load anyway. I guess where it can get tricky is with the templating system. I used FastHTML and wrote all my HTML as Python code. This gives the full expressiveness of the programming language, which is nice, but it seems that templating systems typically provide plenty of logic and control flow. A single template can do a lot. For your example of making only certain regions selectable depending on search results, you could pass the list of regions into the template engine and use a for loop capability in the template. But hey, you found a way that works and that's great. Just wanted to share that I found with a bit of paradigm shift I found the hypermedia approach really straightforward and clean.

leephillips 2y ago

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/ https://lee-phillips.org/pluckit/

deleted 2y ago
[deleted]

tzahifadida 2y ago

Was wondering if any1 embeds react spa apps in golang binaries to build a lean SaaS?

uhtred 2y ago

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 2y ago
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 2y ago
  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 2y ago
So they don't need to be MPAs either.

sgt 2y ago

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 2y ago

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 2y ago
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 2y ago

This is really bad abomination .. please keep SPA to SPA Frameworks and leave HTMX out of it..

JodieBenitez 2y ago

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 2y ago

Htmx - the hipster tech of the decade, honestly

maddalax 2y ago

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 https://htmgo.dev to do that with go + htmx, and http://fastht.ml http://fastht.ml seems like a good contender for python

VagabundoP 2y ago

For my own hobby useage - ie apps I shared with a few people - htmx is a godsend. It lets me focus most of my time in python/flask. I do have a slightly more complicated TTRPG live character sheet that I use for a game I run. Its got five users at once and sqlite backend. Its gotten moderately more complicated over the last year and now sports htmx, discord integration, and will soon have SSE for me to push events to their character sheets, like ability point refreshes etc and other fun stuff without them having to refresh the page all the time. I'm just thankful I don't have to dive into JS frameworks and can mostly stay in html, maybe a little hyperscript.

sinanisler 2y ago

it's sucks man who even uses this useless thing btw https://swag.htmx.org/products/htmx-sucks-mug https://swag.htmx.org/products/htmx-sucks-mug

pyzn 2y ago

Seems like lots of code for a todo list

zoezoezoezoe 2y ago

HTMX is an idea that I never understood. HTML over the wire sounds like the most egregious idea I could have ever thought of. If you want a sub par SPA experience just build an SPA with PHP ;), and if you want a real SPA that doesnt have 600 ms of latency when I click a button that for some god forsaken reason calls an api endpoint, use React or Vue or Svelte like we always have. Is it perfect? Trust me, as someone who is trying to build something that delivers an actual SPA experience with SSR without Node.js, it's not, but a real SPA is miles better than streaming HTML over the wire.

recursivedoubts 2y ago
not always: https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/
- zoezoezoezoe 2y ago
  I think I actually like what they are doing. They're using a combination of Stimulus and HTMX, which I think is a more valid approach than the approach that Hey (the email and calendars site) and many others take, where practically every interaction streams HTML over the wire as opposed to what David and his team are doing where it gets the information on page load so that you arent waiting around for content to come over the wire. I think this approach is how HTMX should be used, but it often is used in a similar fashion to how Hey works, and I think that's the major flaw, take what I say with a grain of salt, but I dont think HTMX pushes the idea that you should preload stuff very well.
  - recursivedoubts 2y ago
    Scripting is part of the web platform and perfectly acceptable in a hypermedia based application: https://htmx.org/essays/hypermedia-friendly-scripting/ https://htmx.org/essays/hypermedia-friendly-scripting/ https://hypermedia.systems/client-side-scripting/ https://hypermedia.systems/client-side-scripting/