[HN Gopher] PrimateJS: Htmx Quick Start
___________________________________________________________________
PrimateJS: Htmx Quick Start
Author : phaleth
Score : 51 points
Date : 2023-03-14 18:33 UTC (4 hours ago)
(HTM) web link (primatejs.com)
(TXT) w3m dump (primatejs.com)
| jmull wrote:
| It looks like "primate" is another javascript-based HTTP request
| handler, with a template language.
|
| I don't get the connection to htmx, though, which runs client-
| side. It looks like there's a separate template variant for
| "htmx" vs HTML, but why would you need a different server-side
| template handling for stuff that executes client-side?
|
| I don't understand the point of the domains either... it somehow
| wraps an ORM but an ORM is already a wrapper (not to mention a
| server-side ORM seems an awkward fit for htmx, which wants the
| server to be stateless).
| nawgz wrote:
| Speaking as a long-time UI guy... The only thing I can imagine
| being worse than HTMX's design philosophy is then writing another
| layer of JavaScript on top of it
|
| Phaleth, can you say more about what this is and why? The whole
| repo, org, and sub-repos don't talk even once about the
| motivation behind the project. Finding it hard to understand what
| this post is soliciting in terms of feedback.
| ZoomZoomZoom wrote:
| > The only thing I can imagine being worse than HTMX's design
| philosophy
|
| Could you explain your position on this? I'm far from front-
| end, but from the user experience, current stack seems
| excessive and bloated. A button/link which sends a request and
| gets a chunk of HTML back to replace without reloading the
| whole page seems like a logical workflow covering the needs of
| 90% pages. Looks like HTMX simulates this and thus looks
| attractive to me.
| ng12 wrote:
| > I'm far from front-end, but from the user experience,
| current stack seems excessive and bloated
|
| I see this flavor of opinion lot on HN and it always
| surprises me. How would you know? Kubernetes and Docker seem
| bloated to me, but I take good faith there's reasons to like
| them.
| worldsayshi wrote:
| As a front heavy full stack Dev I concur. The debate going
| on lately has maybe had some important points but also been
| quite lopsided.
|
| I think you make a good point. Reactive frameworks are
| quite comparable to Kubernetes. React addresses a number of
| issues but not without creating issues of its own.
| Kubernetes seems similar in this. It also seems quite
| "bloated" but it seems worth it.
|
| Name a solution that adds value that doesn't also add a
| bunch of complexity.
| nawgz wrote:
| Sure.
|
| > A button/link which sends a request and gets a chunk of
| HTML back to replace without reloading the whole page
|
| 1. My whole app is distributed now. To determine what will
| render after any given action, I need to go find my backend
| renderer for this specific endpoint, which itself seems
| likely to reference another piece of code that it uses as an
| endpoint, adding a fresh layer of indirection on every single
| UI interaction.
|
| Also, this HTML renderer logic needs to be aware of the rest
| of my app, so the reverse is true; when I'm going to write
| some new UI, I have to go put it somewhere random, associate
| it with a frontend route and backend endpoint it loads from,
| and then attach all the possible nested user-actions from
| this HTML.
|
| Have you heard of separation of concerns? This does the
| opposite: it joins my rendering concern with my loading
| concern, and distributes my User-facing concern.
|
| 2. Everything is async
|
| You know what I love as a user? When I have to wait for a
| network trip before the Button I clicked on does anything.
|
| How do you show a loader in HTMX?
|
| 3. Graceful async handling
|
| So, you read my complaint #2, and said to yourself: well,
| I'll simply make a custom Button which upon being clicked can
| disable further clicks until it is updated about the status
| of the action it just distributed!
|
| So, real quick: where are you going to put this button so
| that you can easily reuse it in your other backend renderers?
| Are you going to write JavaScript to do this? Does it need to
| communicate with other parts of the app dynamically?
|
| Wow, that sure sounds like it'd be nice if I could write it
| once in a 'client' folder and easily pass information from
| its parent to it... It would also be quite cool if I could
| make the network layer a pure abstraction so it could be
| mocked...
|
| I know some libraries that help with that outside of HTMX,
| does HTMX have the toolkit for this stuff?
|
| CONCLUSION
|
| HTMX is "good enough" in the sense that it can produce decent
| static pages and bolt on a small amount of interaction. But
| you can't seriously tell me that you want to use UIs that
| require constant network round trips, and you can't tell me
| that you seriously want to be writing UIs that constantly
| require you to eject from the framework to actually make the
| user interactions feel good.
|
| People who like HTMX dislike good UIs, it's that simple.
| dgb23 wrote:
| I came to similar conclusions as you at some point (minus
| your first point, which is more of an organizational or
| tooling/tech issue and not very interesting to me [0]):
|
| HTMX is great if you need "static website with forms and
| stuff"++ levels of interaction.
|
| Basically anything that is database heavy CRUD stuff
| _without_: interactive and rich visualizations, complex
| document / rich text editing, drag and drop stuff etc. So
| it has very glaring limitations.
|
| But I think it's very, very good within those constraints.
| It's very light and adds minimal overhead, it's very simple
| and it leans on _standards_, (HTTP/REST).
|
| But there's an opportunity to combine this with another,
| very light, minimal overhead, simple library/tech that
| leans on standards. Namely web components.
|
| I recently started a new project that we're going to ship
| as a JS bundle. It's basically just a UI that gets
| dynamically rendered on some site (that we don't control).
| So I gave lit/lit-html a go and it's been a breeze.
|
| What I'm thinking now is why not use those two things
| together, solving separate problems? They are like ying and
| yang. Web components integrate with or can wrap more heavy
| weight interactive things easily. HTMX gives you a
| sensible, simple way of talking to the server.
|
| [0] To say at least something about it, separating your UI
| layer is really more about sensible code organization and
| decoupling. If your tools/framework/libraries make this
| hard, kick them in the can.
| arcanemachiner wrote:
| I came up with the following client-side solutions to
| problems 2 and 3 after a few minutes of Googling and RTFM:
|
| - The `htmx-indicator` class can be used to show a loading
| spinner while an HTMX request is in progress.
|
| - The `htmx-request` class is added to a class that makes
| an HTMX request. You can customize this class to disable
| pointer events, etc.
|
| Example: https://codepen.io/arcanemachine/pen/ExeEzgG
|
| (Stolen mostly from
| https://codepen.io/davidadeneye/pen/eYVrpxg)
| ZoomZoomZoom wrote:
| 1. > adding a fresh layer of indirection on every single UI
| interaction.
|
| Well, if it's a web app, getting the data from the server
| is inevitable. If it somehow can work without it, maybe it
| shouldn't be a web app? Or, as a last resort, it should be
| able to communicate the same way with the executable
| payload you served with the UI. If it's pure UI interaction
| you have the whole html+css at hand, it's huge and is
| rumored to be so capable, that people want to layout
| desktop UI's with it now.
|
| 2. > You know what I love as a user? When I have to wait
| for a network trip before the Button I clicked on does
| anything.
|
| How can it do anything if it doesn't get a response from
| the server?
|
| > But you can't seriously tell me that you want to use UIs
| that require constant network round trips.
|
| Well, network roundtrips are often measured in ms, but a
| fat modern UI brings a netbook capable of compiling a
| kernel in less than half an hour to a crawl.
|
| Don't get me wrong, I get some of your reasoning, but the
| issue is that functionality necessary for all these
| requirements you mention bleeds into basic hypertext model
| of the web and we get a byzantine chaos of today. So, we
| get blogs showing blank pages if JS is turned off, pages
| that won't show you the content unless you scroll and hover
| for a few seconds over each chunk of the page and all that
| insanity.
|
| PS: It's easy to put people in boxes but it's never that
| simple.
| nawgz wrote:
| > 1. getting the data from the server is inevitable
|
| I don't think you really read what I wrote. It is the
| CODE angle that I am addressing here; there is
| indirection in every piece of UI code because of what I
| said. It never is a piece of markup that is conditionally
| displayed based on state; it is the result of another hx-
| request, so I can never escape walking thru a graph that
| includes my entire UI and my entire backend while trying
| to build my UI. Yuck.
|
| > 2. How can it do anything if it doesn't get a response
| from the server?
|
| First of all, let's hope we all agree that each user
| action needs to be acknowledged and represented well by
| the UI. HTMX supports the most bare-bones "request is in
| flight" type of logic, but I usually like optimistic app
| behaviors when on the happy path. For instance, an object
| you created can show up in a list instantly even though
| the list came from the server. It's really easy to do
| this kind of stuff in normal UI frameworks, but HTMX
| outlaws it entirely.
|
| On the flip side, I do want to acknowledge this point:
|
| > we get blogs showing blank pages if JS is turned off
|
| HTMX has a use-case, like I acknowledged: 'HTMX is "good
| enough" in the sense that it can produce decent static
| pages and bolt on a small amount of interaction'
|
| This use-case definitely applies to things like blogs,
| but we have to be honest with ourselves. Blogs and this
| entire class of website aren't really a "user interface"
| or application so much as they are user-facing markup.
| Static content. I wouldn't call myself a "long-time UI
| guy" if I was building blog templates for a living.
|
| HTMX falls apart the second you're building tools, if you
| care about the tool-user's experience as much as the tool
| developer's.
| ZoomZoomZoom wrote:
| Ok, thanks a lot for the detailed answers. I see we're
| coming at it from totally different angles. Can't say I'm
| 100% convinced but I'll be refining my understanding of
| the topic and my position further.
| infamia wrote:
| > You know what I love as a user? When I have to wait for a
| network trip before the Button I clicked on does anything.
|
| There is always so much cognitive dissonance for me when I
| read performance complaints like this from React/JS folks.
| They will complain that the user _might_ have to wait
| 60-100ms extra for an interaction (not ideal at all
| granted), but totally ignore the 20 seconds spent waiting
| for megs of JS to download and execute for a new visitor or
| cache eviction (which happens all too often).
| Scarbutt wrote:
| HTMX is not for highly interactive UIs where most user
| actions are local, it has its use case.
| nawgz wrote:
| I agree with this, do I not? I said: 'HTMX is "good
| enough" in the sense that it can produce decent static
| pages and bolt on a small amount of interaction.'
|
| This takes me back to the top-of-chain comment I made:
| HTMX has its spot, but I see no world where HTMX needs
| another layer of JS on top of it. HTMX is not meant for
| highly-interactive domains, which is almost the exclusive
| use of JS. Why are we combining these? HTMX is the escape
| hatch from JS for people who want to do a bit better than
| true hypermedia but not write JS.
| eterps wrote:
| Exactly, IMO a good rule of thumb would be:
|
| If a project is appropriate to be built as a multi-page
| application (MPA), then HTMX can be added to it to give
| it some SPA like qualities (without having to resort to
| JS coding).
|
| Moreover, you can implement HTMX along with support for
| graceful degradation, ensuring that the app continues to
| function even when JavaScript is disabled.
| earleybird wrote:
| Is there a connection to https://htmx.org/?
| epr wrote:
| The lack of mentioning the original htmx is incredibly
| confusing considering that it does support at least some of the
| exact same functionality, down to the hx- attribute prefix.
|
| Questions relating to this are probably going to dominate this
| thread, but I suppose that's what the author deserves.
| ytjohn wrote:
| It seems like they use some of the same syntax of hx-get and
| hx-post, but then some of the templating like you see in
| apline.js. But no mention of either project. This primatejs
| appears to be more of a node backend and provides some
| variation of the htmx library.
|
| They do reference upstream in this one issue:
| https://github.com/primatejs/primate-htmx/issues/1
|
| Definitely needs some explanation - at first glance this looked
| like someone trying to repackage htmx under their own name.
| rustyminnow wrote:
| It must be since the button sample code is the same on both
| pages. This sure needs more words explaining what it really is
| though
| pictur wrote:
| Using htmx is reminiscent of the dark times of web development
| directly over ftp without using a version control system. I don't
| understand why people do this to themselves. Just try harder
| guys. Maybe you can discover fire with a little more effort.
| sam_goody wrote:
| Or possibly, you are missing something?
|
| I have a lot of experience in JS - even contributed to MooTools
| back in the day, until the team left to create React.
|
| I run node on one server, Nginx with Php on another, and have
| plenty experience with many of the front end frameworks.
|
| Try designing a web page - say the product page of a shoe store
| - multiple times. First try as though you have React (or Vue,
| Svelte, Angular, etc.), but never heard of HTMX, then try with
| HTMX as though you never heard of React, etc.
|
| OK, its a bit of an apples to oranges comparison, especially if
| you would use hotwire or whatever.
|
| Now, test those pages for responsiveness and ease of
| maintenance.
|
| I did that, and the HTMX version won hands down. I was pretty
| surprised. You should try it; then comment again.
|
| I now use HTMX extensively, and avoid frameworks unless they
| would really save time and effort.
| robertoandred wrote:
| You're pretending that HTMX isn't a framework.
|
| You're also being vague on what this shoe page does. How is
| it handling color and size selections? Stock availability?
| Photo galleries? Cart status?
| vlunkr wrote:
| I think you need to elaborate on what a front-end framework has
| to do with version control and deployment strategies.
| pictur wrote:
| I understand that you are declining because I criticize your
| sacred. but I'm hopeful for you guys. One day you will manage
| to light the fire.
| ElectricalUnion wrote:
| > "Using htmx is reminiscent of the dark times of web
| development directly over ftp without using a version control
| system."
|
| Were those really the issues in the dark times?
|
| To me those times are back when very incompatible scripting
| languages, with very incompatible browser DOM implementations
| roamed the land.
|
| The simplicity of MPAs, the immediate feel of just writing to
| disk and refreshing the browser, without any slow transpilation
| process - this is how I remember the "dark times" of htmx.
| replwoacause wrote:
| I like HTMX. I just needed to put together a SPA and I have
| limited JS skills. HTMX was pretty easy to pick up and it was
| the easy bridge between my frontend and backend that I needed,
| while giving also allowing me to add some basic interactivity.
| I think its pretty cool.
| rodolphoarruda wrote:
| How did you learn it? What was your learning path like?
| [deleted]
| beepbooptheory wrote:
| Use js so you don't have deal with htmx which you are using so
| you don't have to deal with js?
___________________________________________________________________
(page generated 2023-03-14 23:02 UTC)