[HN Gopher] PrimateJS: Svelte and Htmx Quick Start
___________________________________________________________________
PrimateJS: Svelte and Htmx Quick Start
Author : phaleth
Score : 42 points
Date : 2023-04-11 16:16 UTC (6 hours ago)
(HTM) web link (primatejs.com)
(TXT) w3m dump (primatejs.com)
| kjksf wrote:
| I did a couple of project in Svelte (proof: all the tools on
| 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.
| pier25 wrote:
| > _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.
| CameronNemo wrote:
| 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 wrote:
| 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 wrote:
| > 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?
| xmonkee wrote:
| 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.
| kjksf wrote:
| 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.
| mixmastamyk wrote:
| You can do most of these things with html and browser dev
| tools.
| jonomacd wrote:
| 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.
| TylerE wrote:
| 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.
| jonomacd wrote:
| 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.
| CameronNemo wrote:
| 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.
| toinbis wrote:
| 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.
| [deleted]
| 3535546hhh73 wrote:
| Nmkik B
| yawnxyz wrote:
| Is this supposed to be a smaller Sveltekit alternative? I'm
| confused as to what it adds to the ecosystem
| sosodev wrote:
| 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.
| ActionHank wrote:
| yes
| jmull wrote:
| 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.
| yewenjie wrote:
| I would really appreciate if there is a Why <New hot framework>
| section in the homepage of such new hot frameworks.
| yoyohello13 wrote:
| This seems like a product created by ChatGPT...
| Finnucane wrote:
| That sounds like something Bard would say.
| earthboundkid wrote:
| The kaleidoscope theory of framework design: shake it up first,
| see if the jumble makes any sense afterwards.
| billllll wrote:
| 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.
| unsupp0rted wrote:
| A "Why PrimateJS?" section at very the top would be helpful.
| [deleted]
| DrKerryKing wrote:
| [flagged]
___________________________________________________________________
(page generated 2023-04-11 23:01 UTC)