5 ms·

If you want new data, you just fetch it again from the server, and the server returns inherently-fresh data, reasonably fast, along with the HTML fragments nece

by vemv 3y ago

If you want new data, you just fetch it again from the server, and the server returns inherently-fresh data, reasonably fast, along with the HTML fragments necessary for a re-render (over ajax or websockets)

willsmith72 3y ago
i thought the whole premise of the article was that you don't want to do that, you want to cache some stuff, and instead of writing the cache stuff (a db) yourself, use a real db in your frontend. if you wanted to just fetch data from your server, it's not a problem anyway, right? a spa can also just fetch fresh data from a server. the whole point of the frontend cache was optimising ux/latency, e.g. for apps with global users but not globally deployed servers
- pas 3y ago
  I'm not a HTMX believer, so excuse my potential ignorance, but as far as I know the whole principle of HTMX is to keep things so simple that things cannot go out of sync. (Mostly because HTMX is basically a set of locally cute JS snippets helping with managing the very local interaction/state of a "user clicks button -> JS disables button, sends request to backend, waits for response, puts response somewhere in the DOM, and re-enables the button (or removes it, etc)" everything else is simply HTML, <a href.., routing is on the backend, etc. and yes, the article is targeting the SPA crowd
  - willsmith72 3y ago
    so for a typical spa, you can: 1. always refetch data. always in sync, but needs a server request, so it's slow. 2. cache some data on the client. faster, but you're "building your own database". can get out of sync (redux) 3. NEW: use SQLSync. fast, client & server stay in sync, don't have to "build your own database" what you're describing just seems like number 1, right?
    - naasking 3y ago
      > 1. always refetch data. always in sync, but needs a server request, so it's slow Except you're not fetching data in htmx, you're fetching hypertext. This is an important distinction. With a JS app you fetch data, integrate it into some local data structure that is then rendered into some form that generates HTML that the browser then renders. With htmx, all of those steps happen in the (faster) server, and the client only receives and renders the HTML. The client-side steps are faster. Furthermore, apps end up structured differently because you're not querying fine-grained data.
      - willsmith72 3y ago
        i get that, and it's a good distinction, but it's not the same as removing a server/network request
        naasking 3y ago
        If apps are structured differently as I said, then that does change the pattern and possibly even the total number of network requests. I've seen a few anecdotal reports of reductions in complexity and latency. I would like to see a more systematic study of this to eliminate the possibility that this may be due to second iterations typically being better engineered than the first when the problem was not fully understood.
qudat 3y ago
You’re not explaining anything that an SPA can’t do and you’re missing everything that an SPA can do that htmx can’t.

by vemv 3y ago

willsmith72 3y ago

i thought the whole premise of the article was that you don't want to do that, you want to cache some stuff, and instead of writing the cache stuff (a db) yourself, use a real db in your frontend. if you wanted to just fetch data from your server, it's not a problem anyway, right? a spa can also just fetch fresh data from a server. the whole point of the frontend cache was optimising ux/latency, e.g. for apps with global users but not globally deployed servers

pas 3y ago
I'm not a HTMX believer, so excuse my potential ignorance, but as far as I know the whole principle of HTMX is to keep things so simple that things cannot go out of sync. (Mostly because HTMX is basically a set of locally cute JS snippets helping with managing the very local interaction/state of a "user clicks button -> JS disables button, sends request to backend, waits for response, puts response somewhere in the DOM, and re-enables the button (or removes it, etc)" everything else is simply HTML, <a href.., routing is on the backend, etc. and yes, the article is targeting the SPA crowd
- willsmith72 3y ago
  so for a typical spa, you can: 1. always refetch data. always in sync, but needs a server request, so it's slow. 2. cache some data on the client. faster, but you're "building your own database". can get out of sync (redux) 3. NEW: use SQLSync. fast, client & server stay in sync, don't have to "build your own database" what you're describing just seems like number 1, right?
  - naasking 3y ago
    > 1. always refetch data. always in sync, but needs a server request, so it's slow Except you're not fetching data in htmx, you're fetching hypertext. This is an important distinction. With a JS app you fetch data, integrate it into some local data structure that is then rendered into some form that generates HTML that the browser then renders. With htmx, all of those steps happen in the (faster) server, and the client only receives and renders the HTML. The client-side steps are faster. Furthermore, apps end up structured differently because you're not querying fine-grained data.
    - willsmith72 3y ago
      i get that, and it's a good distinction, but it's not the same as removing a server/network request
      - naasking 3y ago
        If apps are structured differently as I said, then that does change the pattern and possibly even the total number of network requests. I've seen a few anecdotal reports of reductions in complexity and latency. I would like to see a more systematic study of this to eliminate the possibility that this may be due to second iterations typically being better engineered than the first when the problem was not fully understood.

qudat 3y ago

You’re not explaining anything that an SPA can’t do and you’re missing everything that an SPA can do that htmx can’t.