5 ms·

> fresh perspective, embracing server-driven architecture This is not fresh perspective. I used to be on "team everything on server" but it's a mistake on insi

> fresh perspective, embracing server-driven architecture This is not fresh perspective. I used to be on "team everything on server" but it's a mistake on insist on that today.

sudodevnull 1y ago
I think, at least as the creator, I've seen the "fight" be MPA vs SPA. IMO, both are wrong. It's about state management. MOST state lives in the backend but you still need fine grain reactivity on the frontend. On the number line between React and HTMX; Datastar is complex :)
- candiddevmike 1y ago
  Data may live in the backend, but it is used more in the frontend. Having it local (in memory, or even indexeddb) makes more responsive apps, especially if it's a typical CRUD app with 70/30 or more split between reads/writes.
  - sudodevnull 1y ago
    We'll just have to disagree here. The browser is REALLY smart about caching and no amount of JS localStorage is gonna match proper E-Tags and CDNs. If it's dynamic content your point is moot anyways.
  - mattbrewsbytes 1y ago
    Where the data is used most will vary by app. Some applications are really heavy in the backend, dealing with integrations to other systems, file processing, etc. and the UI is for setting up all that processing, some workflows and business logic.
  - nchmy 1y ago
    Its possible to run the datastar TS/JS SDK in a service worker, if you want to do (isomorphic with the backend) templating from there or just returning pre-cached html fragments.
    - sudodevnull 1y ago
      Datastar is fully plugin based. If you don't like my take on SSE, cool let's talk. The core is just making data-* attribute into reactive expressions, everything else is a plugin by design. I want it to be OK for me to be wrong without losing the declarative approach
      - nchmy 1y ago
        Did you mean to respond to another comment? Because I'm not following either the relevance or tone of your comment. The parent comment wanted a way to "serve" requests on the client device, so I suggested a way to do that that is also compatible with normal d* usage... How to get the data to the client and keep it in sync is an entirely other problem that they'd face with any framework/approach. Would be foolish for some applications and perfectly possible for others. Offline/local-first apps are getting considerable attention these days, for good reason. I'm a big fan and cheerleader of everything you've done. Keep up the great work.

> fresh perspective, embracing server-driven architecture This is not fresh perspective. I used to be on "team everything on server" but it's a mistake on insist on that today.

sudodevnull 1y ago

I think, at least as the creator, I've seen the "fight" be MPA vs SPA. IMO, both are wrong. It's about state management. MOST state lives in the backend but you still need fine grain reactivity on the frontend. On the number line between React and HTMX; Datastar is complex :)

candiddevmike 1y ago
Data may live in the backend, but it is used more in the frontend. Having it local (in memory, or even indexeddb) makes more responsive apps, especially if it's a typical CRUD app with 70/30 or more split between reads/writes.
- sudodevnull 1y ago
  We'll just have to disagree here. The browser is REALLY smart about caching and no amount of JS localStorage is gonna match proper E-Tags and CDNs. If it's dynamic content your point is moot anyways.
- mattbrewsbytes 1y ago
  Where the data is used most will vary by app. Some applications are really heavy in the backend, dealing with integrations to other systems, file processing, etc. and the UI is for setting up all that processing, some workflows and business logic.
- nchmy 1y ago
  Its possible to run the datastar TS/JS SDK in a service worker, if you want to do (isomorphic with the backend) templating from there or just returning pre-cached html fragments.
  - sudodevnull 1y ago
    Datastar is fully plugin based. If you don't like my take on SSE, cool let's talk. The core is just making data-* attribute into reactive expressions, everything else is a plugin by design. I want it to be OK for me to be wrong without losing the declarative approach
    - nchmy 1y ago
      Did you mean to respond to another comment? Because I'm not following either the relevance or tone of your comment. The parent comment wanted a way to "serve" requests on the client device, so I suggested a way to do that that is also compatible with normal d* usage... How to get the data to the client and keep it in sync is an entirely other problem that they'd face with any framework/approach. Would be foolish for some applications and perfectly possible for others. Offline/local-first apps are getting considerable attention these days, for good reason. I'm a big fan and cheerleader of everything you've done. Keep up the great work.