PrimateJS: Svelte and Htmx Quick Start(primatejs.com)
primatejs.com
PrimateJS: Svelte and Htmx Quick Start
https://primatejs.com/svelte-htmx-esbuild-jump-start/
12 comments
> 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?
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?
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.
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.
Don't think you need to kill go server unless you've templates embedded into the binary itself.
Also, even if serve returns HTML as list of files instead of JSON, HTML can be seen as a flexible data format in itself that has few added advantages.
JSON is superfluous when the only consumer is the browser based UI and no third party is going to have that response ever.
Also, even if serve returns HTML as list of files instead of JSON, HTML can be seen as a flexible data format in itself that has few added advantages.
JSON is superfluous when the only consumer is the browser based UI and no third party is going to have that response ever.
so then you send HTML to the client, but then you still have to 'hydrate' it to make it interactive. and now you've reinvented React SSR.
You don't have to hydrate the html as events get triggered from "hx-" attributes on the elements as rendered server side. htmx takes care of it for you.
So where are the event listeners then? On the body tag, and they bubble up and then examine the hx attribute? Is that how it works?
You can do most of these things with html and browser dev tools.
htmx is built to mutate html from the backend based on server side events. I'm not going to say it is better or worse than svelte for your use case but how you are describing it here is selling it short. I suspect you could make a decent files app with htmx and a sprinkle of JavaScript.
As per your development process, if you use htmx you can serve the template files from disk. Then all you need to do is edit the html templates which your backend reads in. No need to rebuild your golang application. For some changes you wouldn't have to reload the page just click the interaction to get the html fragment from the server.
You would need to rebuild your go application if you are changing parameters input into the template but that is conceptually the same as a client side template needing an API change. This also requires a rebuild.
As per your development process, if you use htmx you can serve the template files from disk. Then all you need to do is edit the html templates which your backend reads in. No need to rebuild your golang application. For some changes you wouldn't have to reload the page just click the interaction to get the html fragment from the server.
You would need to rebuild your go application if you are changing parameters input into the template but that is conceptually the same as a client side template needing an API change. This also requires a rebuild.
How would that work? If I’m readying it right, there are client side actions that need to mutate the html, that have no server side component at all, and you wouldn’t want to round trip because the latency would be too annoying anyway.
Again I don't know if it is the best for their current use case but you could probably make something that is quite elegant in htmx.
There are a few actions that are exclusively client side, like opening a context menu, that I'd use a "sprinkle of JavaScript". There is a recently added htmx attribute "hx-on" that might work well for those cases.
I'd also not discount doing a round trip for some of that. Those GET requests can be very fast and will be cached. Given the poor performance of many SPA's a quick, cache-able GET request might look pretty good.
There are a few actions that are exclusively client side, like opening a context menu, that I'd use a "sprinkle of JavaScript". There is a recently added htmx attribute "hx-on" that might work well for those cases.
I'd also not discount doing a round trip for some of that. Those GET requests can be very fast and will be cached. Given the poor performance of many SPA's a quick, cache-able GET request might look pretty good.
It kind of seems you are discrediting HTMX based on Go's lack of hot reloading on the backend.
Not going to debate you line by line, but HTMX doesn't prevent you from using client-side JS, for example to create your right-click context menus.
Not going to debate you line by line, but HTMX doesn't prevent you from using client-side JS, for example to create your right-click context menus.
Thanks for sharing, I'm interested in hearing more about your approach here. Do you go:embed to add the production svelte assets to your Go binary or do you ship both as separate apps and/or involve a CDN?
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.
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.
I've never used htmx so I can't comment on it, but I'd note SvelteKit ships with both server-side and client-side rendering.
Because my client knows how to display the data, and my server doesn't? I have a button in my app that, when clicked, sends a mutation to the server, and then changes it's display based on what the server returns. At this point, moving this functionality to htmx means that both my client and my server need to know how to style this button.
This particular example isn't very convincing. All HTMX needs to send back is a button element (or DIV with button inside it, whatever) with a class attribute. You already said the styling is based on what the server returns, so the server is perfectly capable of applying the correct class. Let client-side CSS do the styling, the server doesn't need to know anything.
> 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.
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.
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?
Try lukeed/navaid or page.js
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
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.
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.
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.
Indeed it's hard to grasp what mission the framework is up to.
I'll just say though that am very happy to see htmx getting more traction. I'm a technical marketer and I was really saddened to see trend of bussiness logic being expresses in TS and spitted out into small bundles for marketers to have no clue on what's going on.
Now I just say this magic combo to frontend team: htmx+alpine+xstate-fsm. And suddenly I have gained the control back! JS-in-markup is a dream comming true for those who actually keep working on optimizing the websites after developers create them.
I'll just say though that am very happy to see htmx getting more traction. I'm a technical marketer and I was really saddened to see trend of bussiness logic being expresses in TS and spitted out into small bundles for marketers to have no clue on what's going on.
Now I just say this magic combo to frontend team: htmx+alpine+xstate-fsm. And suddenly I have gained the control back! JS-in-markup is a dream comming true for those who actually keep working on optimizing the websites after developers create them.
I would like to see HTMX cut down to a tiny size. It's already larger than several network packets for many network configurations (15.05 kB gzip / 42.58 kB size). Now we need an htmx-lite that focuses on not growing into it's own JS framework (that's kind of the whole point after all)
The kaleidoscope theory of framework design: shake it up first, see if the jumble makes any sense afterwards.
My theory is that there is so much money on the table, that every single possible permutation of software is being tried no matter how nonsensical. It's like everybody is simultaneously brute-forcing a combination lock.
To me, I would think there is negative synergy with combining a UI framework like Svelte, with htmx's replacement abilities. One of the value props of htmx is that you don't need to use a framework like Svelte, I don't quite see the point in combining them.
To me, I would think there is negative synergy with combining a UI framework like Svelte, with htmx's replacement abilities. One of the value props of htmx is that you don't need to use a framework like Svelte, I don't quite see the point in combining them.
What is this supposed to be? I familiar with Svelte and HTMX but I don't understand from any of the documentation here what PrimateJS is.
I don't think it's coherent.
It doesn't really make sense to use htmx and svelte together.
(This QuickStart just shows svelte. htmx imported but not really used.)
I think I remember this was posted a few weeks ago too, but maybe then it really was htmx?
But it's really unclear why you'd use this over, say, sveltekit (the "native" app framework for svelte the reactive UI library) or, if you don't want to use that style of framework, any of the many other routers, server, etc.
Good name, though. Maybe that's why it keeps catching my eye.
It doesn't really make sense to use htmx and svelte together.
(This QuickStart just shows svelte. htmx imported but not really used.)
I think I remember this was posted a few weeks ago too, but maybe then it really was htmx?
But it's really unclear why you'd use this over, say, sveltekit (the "native" app framework for svelte the reactive UI library) or, if you don't want to use that style of framework, any of the many other routers, server, etc.
Good name, though. Maybe that's why it keeps catching my eye.
yes
A "Why PrimateJS?" section at very the top would be helpful.
This seems like a product created by ChatGPT...
That sounds like something Bard would say.
I would really appreciate if there is a Why <New hot framework> section in the homepage of such new hot frameworks.
Is this supposed to be a smaller Sveltekit alternative? I'm confused as to what it adds to the ecosystem
[deleted]
Nmkik
B
[deleted]
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.