4 ms·

I did a couple of project in Svelte (proof: all the tools on https://onlinetool.io/ https://onlinetool.io/ are in Svelte). I understand (I think) what htmx doe

by kjksf 4y ago

I did a couple of project in Svelte (proof: all the tools on https://onlinetool.io/ https://onlinetool.io/ are in Svelte). I understand (I think) what htmx does. I don't get at all the need to add htmx to Svelte. It looks like cargo culting because Svelte does what htmx does and more. htmx has a use case where you mostly generate html e.g. on the backend and then want to sprinkle bits of interactivity by making it easy to replace parts of your HTML with another HTML generated by the server. Svelte has it's own, superior, way of doing interactivity. The whole point is to make it easy to generate HTML client side. Anything you would want to do with htmx you can do just in Svelte. You've already paid the price (setting up Svelte transpilation toolchain) you might just as well get all the benefits of Svelte.

CameronNemo 4y ago
Thanks for your input. I have experience with Svelte, but not so much with htmx. I always wondered if I would benefit from using htmx for a project, but kind of doubted it.
- SCUSKU 4y ago
  I am a fan of htmx, but the only time I've found it useful was when I wanted a radio option in a form to send a POST request or something like that (which was probably an anti-pattern anyway) using django templates. I do think it's a welcome addition to the web dev space, but for me personally, it was more of a stepping stone from learning jQuery, then htmx, and then going to SPAs.
listenallyall 4y ago
> Svelte has it's own, superior, way of doing interactivity. The whole point is to make it easy to generate HTML client side. I'm not a Svelte user, I am an HTMX fan. It would seem, in my experience, that if the data intended to be presented to the user lives on a server (i.e. in a database, retrieved via API, etc.) then it's not going to be so easy to generate that HTML client-side. Obviously, you have to call the server... why not simply allow it to send you back an HTML segment that's ready to be plugged in as-is, rather than requiring any client-side transformation?
- CameronNemo 4y ago
  Sometimes you can use postgrest, postgraphile, hasura, or some similar contraption to just get a REST or GraphQL API with no effort. Then you can handle the final presentation bits on the client side. Business logic that must exist as non-SQL code can be implemented easily with various REST or graphql frameworks. In Python, for example, you can use FastAPI or Strawberry for nice type safe APIs. It does take an extra layer of code in many cases, sure. But the architecture is cleaner IMO. Presentation layer lives in one codebase, with a clean link to the data via the API layer. The API layer can abstract different data sources or workflows.
- kjksf 4y ago
  It's a combination of capabilities and productivity. To use a concrete example from another app I built: it's a web-based file browser for S3 (think Norton Commander for S3 on the web). You enter S3 creds and my backend code gets a list of files and sends to the client as JSON. I generate UI (HTML) from that JSON. Could the backend generate that HTML? Not really, because it's not just a static list. It's a sophisticated file browser. The user can double-click to "enter" a directory, navigate the list of files with a keyboard, right click to get context menu with options to delete, rename files etc. My UI (HTML) needs to be mutated and it's not even possible to offload those kinds of things to the backend because they are driven by the state in the client (mouse movements, keyboard events, scroll events etc.). That's the capability part: a lot of things can only be done in the client. As to productivity: even if the needs are not as sophisticated, my productivity in Svelte is off the charts. Let's say you just generate static HTML for the list of files. Generating HTML is a very iterative process: you start with the basic structure, you try it and then you tweak the CSS to make it look better. Since my backends are in Go, changing a single line of Go code requires killing the server, rebuilding it and restarting it and since I lost all the state, re-doing all the steps needed to get to a page I'm working on. My iteration loop per single change is minutes and very annoying. With Svelte I have an amazing HTML templating language and with HMR (Hot Module Reload) I often don't even have to refresh the page: I change my .svelte file to, say, add a class to <td> element, I save it in Visual Studio Code and the page get magically refreshed with new visuals, without loosing the state. My iteration loop is basically nothing. Over many iterations, that all adds up.
pier25 4y ago
> Svelte has it's own, superior, way of doing interactivity. I love Svelte and have been using it daily for about 3 years now. But "superior"? That's extremely subjective. HTMX might make more sense in certain views that don't need much interactivity. It would keep the JS size down because you only need to download the 14kB of HTMX once, for the whole application.
synergy20 4y ago
I tried svelte for a while and gave up due to its SSR-first sveltekit stuff, is your project CSR SPA, if so what client side routing you use?
- toastercat 4y ago
  Try lukeed/navaid or page.js
  - tommica 4y ago
    And for people that are looking into svelte+page.js, this might be a good read: https://blog.jscrambler.com/svelte-routing-with-page-js https://blog.jscrambler.com/svelte-routing-with-page-js

by kjksf 4y ago

CameronNemo 4y ago

Thanks for your input. I have experience with Svelte, but not so much with htmx. I always wondered if I would benefit from using htmx for a project, but kind of doubted it.

SCUSKU 4y ago
I am a fan of htmx, but the only time I've found it useful was when I wanted a radio option in a form to send a POST request or something like that (which was probably an anti-pattern anyway) using django templates. I do think it's a welcome addition to the web dev space, but for me personally, it was more of a stepping stone from learning jQuery, then htmx, and then going to SPAs.

listenallyall 4y ago

> Svelte has it's own, superior, way of doing interactivity. The whole point is to make it easy to generate HTML client side. I'm not a Svelte user, I am an HTMX fan. It would seem, in my experience, that if the data intended to be presented to the user lives on a server (i.e. in a database, retrieved via API, etc.) then it's not going to be so easy to generate that HTML client-side. Obviously, you have to call the server... why not simply allow it to send you back an HTML segment that's ready to be plugged in as-is, rather than requiring any client-side transformation?

CameronNemo 4y ago
Sometimes you can use postgrest, postgraphile, hasura, or some similar contraption to just get a REST or GraphQL API with no effort. Then you can handle the final presentation bits on the client side. Business logic that must exist as non-SQL code can be implemented easily with various REST or graphql frameworks. In Python, for example, you can use FastAPI or Strawberry for nice type safe APIs. It does take an extra layer of code in many cases, sure. But the architecture is cleaner IMO. Presentation layer lives in one codebase, with a clean link to the data via the API layer. The API layer can abstract different data sources or workflows.
kjksf 4y ago
It's a combination of capabilities and productivity. To use a concrete example from another app I built: it's a web-based file browser for S3 (think Norton Commander for S3 on the web). You enter S3 creds and my backend code gets a list of files and sends to the client as JSON. I generate UI (HTML) from that JSON. Could the backend generate that HTML? Not really, because it's not just a static list. It's a sophisticated file browser. The user can double-click to "enter" a directory, navigate the list of files with a keyboard, right click to get context menu with options to delete, rename files etc. My UI (HTML) needs to be mutated and it's not even possible to offload those kinds of things to the backend because they are driven by the state in the client (mouse movements, keyboard events, scroll events etc.). That's the capability part: a lot of things can only be done in the client. As to productivity: even if the needs are not as sophisticated, my productivity in Svelte is off the charts. Let's say you just generate static HTML for the list of files. Generating HTML is a very iterative process: you start with the basic structure, you try it and then you tweak the CSS to make it look better. Since my backends are in Go, changing a single line of Go code requires killing the server, rebuilding it and restarting it and since I lost all the state, re-doing all the steps needed to get to a page I'm working on. My iteration loop per single change is minutes and very annoying. With Svelte I have an amazing HTML templating language and with HMR (Hot Module Reload) I often don't even have to refresh the page: I change my .svelte file to, say, add a class to <td> element, I save it in Visual Studio Code and the page get magically refreshed with new visuals, without loosing the state. My iteration loop is basically nothing. Over many iterations, that all adds up.

pier25 4y ago

> Svelte has it's own, superior, way of doing interactivity. I love Svelte and have been using it daily for about 3 years now. But "superior"? That's extremely subjective. HTMX might make more sense in certain views that don't need much interactivity. It would keep the JS size down because you only need to download the 14kB of HTMX once, for the whole application.

synergy20 4y ago

I tried svelte for a while and gave up due to its SSR-first sveltekit stuff, is your project CSR SPA, if so what client side routing you use?

toastercat 4y ago
Try lukeed/navaid or page.js
- tommica 4y ago
  And for people that are looking into svelte+page.js, this might be a good read: https://blog.jscrambler.com/svelte-routing-with-page-js https://blog.jscrambler.com/svelte-routing-with-page-js