https://htmx.org logo
Powered by
# htmx-general
  • h
    where it statically renders a bunch of html and then builds in htmx tooling to handle page transisitions simlar to next's link?
  • e
    Yes, I suppose. I'll look into adonis. Never used that, but most of the idea came from frameworks like Next and Nuxt. Instead of returning JS components though, it returns HTML components.
  • h
    adonis is to node as django is to python
  • h
    eg server process taking in request -> returning response with a rendered template
  • e
    Just looked at the docs and adonis looks nice! Hype is different, but now I'm questioning if a framework like Hype.js is even needed now lol. The only benefits would be it's simpler and automatic deployments to CDNs where possible, like Next.js, but I feel like each language will come up with their own solution over time. I was inspired to make something like Hype.js because there's Next.js, Nuxt.js, etc. but they didn't really have a choice I guess. On the other hand, htmx has many choices. Hmmmm that's how I know for a fact htmx is good software because it's just really versatile.
  • h
    I think something like adonis/hype that works with vercel out of the box would be really cool
  • h
    so I'm not trying to discourage you 🙂
  • h
    I just am trying to understand the interaction model - EG gatsby "is fast because it's all precompiled"
  • e
    No not at all. I'll still consider it, but it's good to get feedback before I put too much work into it lol I just had the idea and wanted to show it here.
  • h
    I think something like gastby that understands partials/ajax through htmx would be sick
  • h
    so would something like adoinis that understands htmx and converts all links/form interactions to be htmx driven
  • e
    Yeah so the idea was that Hype would have precompiled HTML that can be deployed to CDNs for the best performance. Next, Nuxt, etc. do the same. And then you have HTML that may have to be rerendered on each request, which would just be a standard server basically. Hype would handle all the deployment logic for you automatically like Next or Nuxt. The idea was a framework for getting HTML APIs out there quickly
  • b
    I like the thinking behind this. It feels like there should be a quicker way to get html to the browser. TBH, something like "traditional" PHP feels closest and it's the reason I wrote Dark Star for python. WRT deployment, I think https://arc.codes/ seems like a great candidate for getting things online (if you are okay with AWS). (Pinging @jolly-kite-167 as I know they have played with this).
  • m
    \> Dark Star crazy how many good devs we have around here folks...
  • e
    Yes DarkStar was an inspiration as well! I also mention in the pseudo-docs that I considered using PHP for Hype, but once again Next.js, Nuxt.js, SvelteKit all use Node.js (they have no choice). The idea was to convert users of those frameworks over to htmx by coming out with Hype.js. The Hype to end all hype. No hydration needed.
  • m
    \> mentioning hydration u r on thin ice sir
  • b
    I have promoted it from "playing with code" to "not completely useless". I'm writing a toy app in it and there feels like there's little friction when implementing a change. The LOB stuff is a real win.
  • h
    what's the LOB stuff?
  • b
  • h
    literally arguing about this with one of my guys right now
  • h
    timely
  • h
    (no we don't need to make a ts component file for every component we build, it's ok to just stick the js directly in the html file)
  • g
    Is there a way to set the 
    redirect
    param on a request?
  • g
    I need to set 
    redirect: "follow"
    on a hx-post endpoint and I'm not sure where to put that either on the element or using an event.
  • m
  • g
    Yeah. Tried that, still fails. Here's a pen showing that fetch and xhr requests work, but not HTMX for some reason. https://codepen.io/bbennett/pen/KKZjMaq
  • g
    Its trying to hit a webhook running on Google Apps Script. There's a redirect from the published URL to a private app URL which actually does the work. I think that's where it's failing.
  • g
    The redirect param is my best guess, but you use XHR to make requests, right? So, they should be following automatically.
  • g
    Doing more testing, I think it has to do with the preflight 
    OPTIONS
    header. I can't change which headers are accepted on the platform, so this experiment might be a bust.
  • p
    Is there any overview of the server-side libraries that provider helpers/integration with htmx ? I have found https://django-htmx.readthedocs.io/ but wondering if there are others?
1...660661662...1146Latest