4 ms·

> If web interface is an application backed by a remote state What does that mean?

tancop 6mo ago
anything where you need popups or tiled windows, code editing, rich text features more complex than "render markdown into a div", heavy content like videos, multiplayer, real time chat, anything that has to work offline... htmx is only good enough for something like a company homepage or simple shop not big complicated apps. its actually the same reason i dont like htmx, the whole "true REST" approach is about making everything depend more on the server with a thin client that can only do a couple very simple things with the loaded page. if your connection to that server is slow or unreliable your whole app breaks. its also the perfect opposite of "true web3" and ethereums original vision, where you load all static assets from ipfs, most app logic is client side and the server or blockchain only comes in (json api, no html fragments or full pages) when you need to interact with other users. still believe in it even after the crypto bros took the name for a bunch of scams and hosted everything on cloudflare anyway. the only thing they have in common i could find is no bundling but for different reasons - everything on server vs compiled libraries shared between apps.
- blastslot 6mo ago
  [dead]
- ashwinsundar 6mo ago
  This is a mix of specious, and just outright incorrect. https://en.wikipedia.org/wiki/Gish_gallop https://en.wikipedia.org/wiki/Gish_gallop Here are a few brief replies: popups/tiling - use `<dialog>` real-time chat - use websockets slow/unreliable connections - well yeah this is a problem for any app...if you're delivering a 2MB paylaod to start the web app so that it doesn't need a connection, you're just betting that the user has a fast connection initially. what if that's not true either? back to square one. REST/Hypermedia encourages sending small payloads and working within those real constraints I have no idea what you're talking about with "true web3 and ethereum". HTMX has nothing to do with web3 or crypto.
0x457 6mo ago
Facebook, Spotify, Figma, really anything interactive beyond sending a simple form.
- ashwinsundar 6mo ago
  You can achieve a great deal of interactivity with pure get/post requests, along with a sprinkling of javascript one-liners and maybe alpine.js if client interactivity is important.
  - 0x457 6mo ago
    Yes, but doing with just HTMX, a framework we're talking in this thread, would be very painful. Every project I started with alpine.js eventually transitioned to something heavier because it was hard to maintain once you're having something more interactive than an accordion or sliding drawer.
    - ashwinsundar 6mo ago
      It's just not. I have done all these things. Maintenance is a piece of cake. Sorry that you struggled with this.
      - 0x457 6mo ago
        Well agree to disagree. To me, it felt like HTMX was a wrong tool for anything other than pure server side representation (i.e. a little bit more advanced than refreshing entire page on new data). I guess it's easier if you move all client logic to server, but I didn't want backend to know about web representation details.

anything where you need popups or tiled windows, code editing, rich text features more complex than "render markdown into a div", heavy content like videos, multiplayer, real time chat, anything that has to work offline... htmx is only good enough for something like a company homepage or simple shop not big complicated apps. its actually the same reason i dont like htmx, the whole "true REST" approach is about making everything depend more on the server with a thin client that can only do a couple very simple things with the loaded page. if your connection to that server is slow or unreliable your whole app breaks. its also the perfect opposite of "true web3" and ethereums original vision, where you load all static assets from ipfs, most app logic is client side and the server or blockchain only comes in (json api, no html fragments or full pages) when you need to interact with other users. still believe in it even after the crypto bros took the name for a bunch of scams and hosted everything on cloudflare anyway. the only thing they have in common i could find is no bundling but for different reasons - everything on server vs compiled libraries shared between apps.

blastslot 6mo ago
[dead]
ashwinsundar 6mo ago
This is a mix of specious, and just outright incorrect. https://en.wikipedia.org/wiki/Gish_gallop https://en.wikipedia.org/wiki/Gish_gallop Here are a few brief replies: popups/tiling - use `<dialog>` real-time chat - use websockets slow/unreliable connections - well yeah this is a problem for any app...if you're delivering a 2MB paylaod to start the web app so that it doesn't need a connection, you're just betting that the user has a fast connection initially. what if that's not true either? back to square one. REST/Hypermedia encourages sending small payloads and working within those real constraints I have no idea what you're talking about with "true web3 and ethereum". HTMX has nothing to do with web3 or crypto.

0x457 6mo ago

Facebook, Spotify, Figma, really anything interactive beyond sending a simple form.

ashwinsundar 6mo ago
You can achieve a great deal of interactivity with pure get/post requests, along with a sprinkling of javascript one-liners and maybe alpine.js if client interactivity is important.
- 0x457 6mo ago
  Yes, but doing with just HTMX, a framework we're talking in this thread, would be very painful. Every project I started with alpine.js eventually transitioned to something heavier because it was hard to maintain once you're having something more interactive than an accordion or sliding drawer.
  - ashwinsundar 6mo ago
    It's just not. I have done all these things. Maintenance is a piece of cake. Sorry that you struggled with this.
    - 0x457 6mo ago
      Well agree to disagree. To me, it felt like HTMX was a wrong tool for anything other than pure server side representation (i.e. a little bit more advanced than refreshing entire page on new data). I guess it's easier if you move all client logic to server, but I didn't want backend to know about web representation details.