https://htmx.org logo
Powered by
# htmx-general
  • m
    but it's on my list
  • r
    Well that would be a major improvement. I'm also trying to see if I can use htmx for some simple websockets usage. As a trivial example I just want to be able to have a textarea in one browser tab be reflected in real time in a textarea in another browser tab. Is that possible just using htmx by itself?
  • m
  • m
    yes, you need to stream down updates with the same format as out of band swaps
  • r
    Ok I'm using the example in the docs and the console says the Websocket connection failed. I have no idea what to do about it.
  • s
    "... when content gets swapped out and the body replaced". I thought about this some weeks ago and came to this conclusion: I want small snippets from the server XOR I want a full page refresh. If I want a full page refresh, then do it the normal way. I don't see the big benefit in replacing the whole body. What benefits do I get if I replace the whole body (compared to a usual full page reload)?
  • r
    The benefit of switching pages with just the body replaced is that scripts and styles in the head aren't loaded and parsed on every page load and that's really what takes the browser so long to do when you change pages the normal way. It makes a huge difference.
  • r
    Turbo in Hotwire also caches the page automatically which also speeds things up considerably. However, this is actually better done using service workers to do the caching so the htmx way is the ultimate better way but it takes a whole lot of extra effort to setup correctly with service workers. It's not just plug and play like the hotwire turbo implementation. So on second thought maybe its current behavior is ok to leave as it is and the boost behavior should be implemented as an extension instead.
  • s
    if you have small pages with only some css and some js. And you have a good network. Then how much faster is this "boosting" which hotwire does (compared to traditional full page reload)?
  • r
    The less css and javascript you have the less benefits you get. But css and javascript in the head are what holds up the first paint because they have to be loaded and evaluated first before anything on the page is displayed. When the browser doesn't have to do that on every page load you effectively turn your site into like an app shell and it feels real close to an SPA without all the complicated bloat and developer pain it takes to do an actual SPA. Then you just surgically piece in the data the htmx way for things like edit in place.
  • s
    Yes, and a general implementation would allow all snippets to contain new css/js. Imagine you have a fancy date-picker which is written in JS. You don't want to load this JS on every page load, since only few people edit the date field. You could load the js via hx-get if the user clicks on the button to edit the date field. Maybe I am blind, but it should not make difference if I change the body tag or an other tag on the page.
  • r
    Better yet you put the new css/js within a date-picker web component and load that component with hx-get. We've been building a system for doing just that with an integrated html/css/js framework custom built to work with html over the wire solutions like htmx. I've been going back and forth whether to go with htmx or hotwire as the underlying basis for going public with the initial implementation. I really like both and they both have their pros and cons.
  • m
    yep, the two libraries reflect two different design sensibilities. 37signals and dhh have always liked "magic" and things "just working" and their software reflects that. I came at it from the perspective of "let's improve HTML" which is lower level and more incremental. It isn't as complete a solution, but, I believe, is more flexible and ultimately dovetails better with most web development.
  • m
    I tend to load everything up in a single CSS file that is dumped on the client up front, and then cached from there out, but I don't know how bad that is in terms of modern web practice...
  • m
    I'd like to investigate what it would take to do better head processing in 
    hx-boost
    (which was kind of an afterthought, to be frank)
  • m
    unfortunately right now I'm at the end of the semester at my university and so I'm slammed, but I should have plenty of time to look at it in a few weeks
  • m
    @User I will also look at testing docs at that point
  • s
    No hurry, I create the issues, so that it don't get lost. I dream that some motivated developer magically appears and starts to solve these things. Has someone a clue how we make this dream come true?
  • m
    hello I just discovered htmx
  • m
    seems awesome
  • g
    welcome to the party
  • m
    We think it’s pretty good 😀
  • m
    Is there something like turbo frames in htmx?
  • m
    nope, htmx is lower level, more like HTML++ rather than a complete front end solution
  • m
    You can target elements via a CSS selector
  • b
    So, I've been working on a demo of django + htmx. The one issue I'm running into is aesthetic - I end up with extra 's in my table, and I'm not sure where they're coming from. Maybe I'm using an inappropriate hx-swap/hx-target approach? I only noticed it because I'm using table striping, and, well, it's all solid gray. Looking at the output, I see that between each row of content, there's an extra blank row, but I can't seem to figure out where it's coming from. Any suggestions? Code https://replit.com/@OmenApps/django-htmx-todo-list https://github.com/OmenApps/django-htmx-todo-list See it in action: https://htmxforms.omenapps.repl.co/
  • u
    hey guys
  • u
    Is it possible to have an htmx save the from values to cookies?
  • u
    I'm using htmx to submit a dropdown selection form and I'd like to store those selections to use on next page load for the user so they don't have to keep selecting
  • g
    Not directly. Usually, cookies are set by the server (and ignored by the client)
1...227228229...1146Latest