12 ms·

> as you reach a more “app like” experience with multiple layers of state control on the front end you need to reach for a front end JS framework I think that

> as you reach a more “app like” experience with multiple layers of state control on the front end you need to reach for a front end JS framework I think that if you fully embrace HTMX's model, you can go far further than anticipated without a JS framework. Do you really need to be managing state on the client? Is it really faster to communicate via JSON, or protobuf, whatever, rather than atomic data and returning just small bits of replacement HTML -- inserted seamlessly that it's a better UI than many client-side components? Why have HTML elements react to changes in data or state, rather than just insert new HTML elements already updated with the new state? I think you're describing a, let's do React in HTMX mindset, rather than let's go all in on the HTMX model. And I might be giving HTMX too much credit, but it has totally changed how I go about building web applications.

jbverschoor 4y ago
Oh god please let’s not go back to JSF
- jaytaylo 4y ago
  How was it worse than the current state of affairs of complexity with React? Bowser, npm, typescript, obfuscation, compressors, build pipelines.. it’s a lot. Life at the front-end today is so discombobulated, creating a bunch of backend APIs which will generally only be used and consumed by a single browser front-end. I’m genuinely curious, because I never used JSF except for a single school exercise
  - nine_k 4y ago
    Frankly, with yarn, typescript, and a packaging / compressing tools of your choice, web frontend development is pretty pleasant and efficient these days. (To say nothing of using Elm, if you can afford it.) Typescript is particular is nice compared to, say, Python, and even to Java (though modern Java is quite neat.) The only unpleasant part is dependency management, but you have the same, or worse, with Python or Ruby, and neither Java nor Go are completely hassle-free either.
    - nathanappere 4y ago
      Really curious, how is it worse with Ruby?
      - chris12321 4y ago
        With bundler, Ruby dependency management is excellent. I don't think I've ever had a problem setting up an app where the Ruby dependencies are the issue. I certainly can't say the same for JavaScript apps.
    - germandiago 4y ago
      Typescript nicer than Python? Bc of speed? Python has typing module + mypy to be warned about typing mistakes.
      - KuiN 4y ago
        It may have improved significantly since I last used it (9 months ago?) but mypy was a world away from the ergonomics, quality of tooling and maturity of TypeScript.
  - jbverschoor 4y ago
    I’ve used JSF when it was still beta. It was chosen by an external “architect” as the front end for a big site with millions of views (he was anticipating that JSF would be come popular, and a big project with it would be good on his resume). Salesforce (classic) is JSF. It’s full of bugs and quirks. But it’s kind of nice in certain situations. The big problem here is performance load on both client and server. State is sent back and forth and it that kan be huge, and needs to be deserializes, altered, and serialized back again every action. It also doesn’t reflect any http verbs. Everything is POST The big site was technically running on JSF, but in such a way that it wasn’t JSF any more
    - throwawaysfdc 4y ago
      > Salesforce (classic) is JSF. Here's a little bit of trivia... The Visualforce framework (that customers can write interactive pages in, and a small minority of the standard UI is build in) is based on JSF, but most of Salesforce classic standard UI is written in a home-grown system that generates HTML described in imperative Java. It's more akin to an HTML generating Tk.
      - jbverschoor 4y ago
        Makes sense and they had a few big architectural changes of their front end. Lighting is unbelievably slow
  - egeozcan 4y ago
    Primefaces makes it a bit more tolerable, but JSF is an ancient, slow, buggy beast that's hard to integrate with anything. Managing state on the server for every little thing is not scale-able, even for a measly number of clients. You don't have to grow to be a Facebook to feel the effects of the bad design of JSF.
samwillis 4y ago
Oh, I completely agree with you. The vast VAST majority of sites don’t need that level of client side state management. I’m currently working on a bio-informatics data modelling web app where htmx would not have been the right choice. But it’s in that 1-5% where that is the case. That’s kind of my point. Outside of that project, I’m all in on the the HTMX model of server side rendered fragments.
nawgz 4y ago
I think that if you’re building tools and you want to do anything nice like optimistic rendering it’s not possible in HTMX, so I always wonder what kind of user experience is actually delivered on an HTMX app
- thunky 4y ago
  Like this? https://htmx.org/extensions/preload/ https://htmx.org/extensions/preload/
  - nawgz 4y ago
    Sort of. It’s more like when you create an object, you can display the object inline immediately with a JS layer, plus show some status attribute or however deep you like. This explicitly only works with GETters and I can’t imagine how you can show async state with a tool like HTMX easily
    - halfcat 4y ago
      What if combined with this? https://htmx.org/examples/lazy-load/ https://htmx.org/examples/lazy-load/
      - nawgz 4y ago
        With respect to showing a loader, it’s a solution. Not fully sure I understand the mechanism - is it based on the class or does all content of the div with hx-trigger get replaced? Or even worse is the image still there with opacity 0? However, this doesn’t solve the optimistic rendering situation at all. In general the approach of HTML over the wire clearly seems barred from solving that, you need a client layer for that
        thunky 4y ago
        IIUC I think it's possible, but maybe a bit clunky. Htmx let's you choose the swap target, and you can replace any part the page, not just the section that triggered the swap. You can also replace multiple targets. https://htmx.org/attributes/hx-swap-oob/ https://htmx.org/attributes/hx-swap-oob/ Also, there's nothing stopping you from writing a bit of JS to handle something htmx can't do. For example, the initial GET could return two partials, one hidden by default until a user action triggers a JS swap while htmx performs the request and eventually replaces the div again along with any other out of band div(s).
MatthiasPortzel 4y ago
The slippery slope that scares me (as a React developer) about htmx (or Hotwire.dev, in particular is the one I was looking at), is that you start making the assumption that the client's internet is fast. There was demo that showed it normally takes ~100ms to click a mouse, and if you attach to the on-mouse-down, then by the time the mouse has been released (100ms later), you can have already fetched an updated rendered component from the server. And while that's very cool, my second reaction is "is it ever acceptable to round-trip to the server to re-render a component that could have been updated fully-client side?" What happens when my internet (or the server) is slow, and it takes more than 100ms to fetch that data? Suddenly that's a really bad user-experience. In the general case this is a subjective question. I personally would rather wait longer for the site to load, but have a more responsive site once it did. There's not a perfect solution to this, because in a complex site there are times that both the server and the client need to update the UI state. But having the source of truth for the UI located in a server miles away from the user is not a general-purpose solution. (I'm not advocating for the status quo, either. I just wanted to bring up one concern of mine.)
- mediumdeviation 4y ago
  For a real world example of this, GitHub uses server-side rendered fragments. Working with low latency and fast internet in the office, the experience is excellent. Trying to do the same outside with mobile internet, and even with a 5G connection, the increased latency makes the application frustrating to use. Every click is delayed, even for simple actions like opening menus on comments, filtering files or expanding collapsed code sections. I'm actually worried about developers in developing countries where mobile internet is the dominant way to access the Internet and GitHub is now the de facto way to participate in open source, that this is creating an invisible barrier to access.
  - qwertyzxcvmnbvw 4y ago
    Side note: in Thailand and the Philippines, at least, mobile internet is blazing fast and not more expensive.
ris58h 4y ago
> Do you really need to be managing state on the client? Sometimes an "app" needs to work offline.
galaxyLogic 4y ago
> Why have HTML elements react to changes in data or state, rather than just insert new HTML elements already updated with the new state? But what's the big difference? Something somewhere must react to change. Either modify the DOM by client-side code, or modify/replace it by loading content-fragments from the server. I would (perhaps naively) think that doing more on the client is faster than both re-rendering on the server and reloading from the server. Maybe it's just that React is too big and complicated and therefore slow.
branko_d 4y ago
I think the point of a SPA is not how to refresh the screen when you have to do the round-trip to the server. The point is that you can do more things without making the round-trip in the first place.

jbverschoor 4y ago

Oh god please let’s not go back to JSF

jaytaylo 4y ago
How was it worse than the current state of affairs of complexity with React? Bowser, npm, typescript, obfuscation, compressors, build pipelines.. it’s a lot. Life at the front-end today is so discombobulated, creating a bunch of backend APIs which will generally only be used and consumed by a single browser front-end. I’m genuinely curious, because I never used JSF except for a single school exercise
- nine_k 4y ago
  Frankly, with yarn, typescript, and a packaging / compressing tools of your choice, web frontend development is pretty pleasant and efficient these days. (To say nothing of using Elm, if you can afford it.) Typescript is particular is nice compared to, say, Python, and even to Java (though modern Java is quite neat.) The only unpleasant part is dependency management, but you have the same, or worse, with Python or Ruby, and neither Java nor Go are completely hassle-free either.
  - nathanappere 4y ago
    Really curious, how is it worse with Ruby?
    - chris12321 4y ago
      With bundler, Ruby dependency management is excellent. I don't think I've ever had a problem setting up an app where the Ruby dependencies are the issue. I certainly can't say the same for JavaScript apps.
  - germandiago 4y ago
    Typescript nicer than Python? Bc of speed? Python has typing module + mypy to be warned about typing mistakes.
    - KuiN 4y ago
      It may have improved significantly since I last used it (9 months ago?) but mypy was a world away from the ergonomics, quality of tooling and maturity of TypeScript.
- jbverschoor 4y ago
  I’ve used JSF when it was still beta. It was chosen by an external “architect” as the front end for a big site with millions of views (he was anticipating that JSF would be come popular, and a big project with it would be good on his resume). Salesforce (classic) is JSF. It’s full of bugs and quirks. But it’s kind of nice in certain situations. The big problem here is performance load on both client and server. State is sent back and forth and it that kan be huge, and needs to be deserializes, altered, and serialized back again every action. It also doesn’t reflect any http verbs. Everything is POST The big site was technically running on JSF, but in such a way that it wasn’t JSF any more
  - throwawaysfdc 4y ago
    > Salesforce (classic) is JSF. Here's a little bit of trivia... The Visualforce framework (that customers can write interactive pages in, and a small minority of the standard UI is build in) is based on JSF, but most of Salesforce classic standard UI is written in a home-grown system that generates HTML described in imperative Java. It's more akin to an HTML generating Tk.
    - jbverschoor 4y ago
      Makes sense and they had a few big architectural changes of their front end. Lighting is unbelievably slow
- egeozcan 4y ago
  Primefaces makes it a bit more tolerable, but JSF is an ancient, slow, buggy beast that's hard to integrate with anything. Managing state on the server for every little thing is not scale-able, even for a measly number of clients. You don't have to grow to be a Facebook to feel the effects of the bad design of JSF.

samwillis 4y ago

Oh, I completely agree with you. The vast VAST majority of sites don’t need that level of client side state management. I’m currently working on a bio-informatics data modelling web app where htmx would not have been the right choice. But it’s in that 1-5% where that is the case. That’s kind of my point. Outside of that project, I’m all in on the the HTMX model of server side rendered fragments.

nawgz 4y ago

I think that if you’re building tools and you want to do anything nice like optimistic rendering it’s not possible in HTMX, so I always wonder what kind of user experience is actually delivered on an HTMX app

thunky 4y ago
Like this? https://htmx.org/extensions/preload/ https://htmx.org/extensions/preload/
- nawgz 4y ago
  Sort of. It’s more like when you create an object, you can display the object inline immediately with a JS layer, plus show some status attribute or however deep you like. This explicitly only works with GETters and I can’t imagine how you can show async state with a tool like HTMX easily
  - halfcat 4y ago
    What if combined with this? https://htmx.org/examples/lazy-load/ https://htmx.org/examples/lazy-load/
    - nawgz 4y ago
      With respect to showing a loader, it’s a solution. Not fully sure I understand the mechanism - is it based on the class or does all content of the div with hx-trigger get replaced? Or even worse is the image still there with opacity 0? However, this doesn’t solve the optimistic rendering situation at all. In general the approach of HTML over the wire clearly seems barred from solving that, you need a client layer for that
      - thunky 4y ago
        IIUC I think it's possible, but maybe a bit clunky. Htmx let's you choose the swap target, and you can replace any part the page, not just the section that triggered the swap. You can also replace multiple targets. https://htmx.org/attributes/hx-swap-oob/ https://htmx.org/attributes/hx-swap-oob/ Also, there's nothing stopping you from writing a bit of JS to handle something htmx can't do. For example, the initial GET could return two partials, one hidden by default until a user action triggers a JS swap while htmx performs the request and eventually replaces the div again along with any other out of band div(s).

MatthiasPortzel 4y ago

The slippery slope that scares me (as a React developer) about htmx (or Hotwire.dev, in particular is the one I was looking at), is that you start making the assumption that the client's internet is fast. There was demo that showed it normally takes ~100ms to click a mouse, and if you attach to the on-mouse-down, then by the time the mouse has been released (100ms later), you can have already fetched an updated rendered component from the server. And while that's very cool, my second reaction is "is it ever acceptable to round-trip to the server to re-render a component that could have been updated fully-client side?" What happens when my internet (or the server) is slow, and it takes more than 100ms to fetch that data? Suddenly that's a really bad user-experience. In the general case this is a subjective question. I personally would rather wait longer for the site to load, but have a more responsive site once it did. There's not a perfect solution to this, because in a complex site there are times that both the server and the client need to update the UI state. But having the source of truth for the UI located in a server miles away from the user is not a general-purpose solution. (I'm not advocating for the status quo, either. I just wanted to bring up one concern of mine.)

mediumdeviation 4y ago
For a real world example of this, GitHub uses server-side rendered fragments. Working with low latency and fast internet in the office, the experience is excellent. Trying to do the same outside with mobile internet, and even with a 5G connection, the increased latency makes the application frustrating to use. Every click is delayed, even for simple actions like opening menus on comments, filtering files or expanding collapsed code sections. I'm actually worried about developers in developing countries where mobile internet is the dominant way to access the Internet and GitHub is now the de facto way to participate in open source, that this is creating an invisible barrier to access.
- qwertyzxcvmnbvw 4y ago
  Side note: in Thailand and the Philippines, at least, mobile internet is blazing fast and not more expensive.

ris58h 4y ago

> Do you really need to be managing state on the client? Sometimes an "app" needs to work offline.

galaxyLogic 4y ago

> Why have HTML elements react to changes in data or state, rather than just insert new HTML elements already updated with the new state? But what's the big difference? Something somewhere must react to change. Either modify the DOM by client-side code, or modify/replace it by loading content-fragments from the server. I would (perhaps naively) think that doing more on the client is faster than both re-rendering on the server and reloading from the server. Maybe it's just that React is too big and complicated and therefore slow.

branko_d 4y ago

I think the point of a SPA is not how to refresh the screen when you have to do the round-trip to the server. The point is that you can do more things without making the round-trip in the first place.