8 ms·

PrimateJS: Htmx Quick Start

77 points by phaleth 4y ago

deleted 4y ago
[deleted]
earleybird 4y ago
Is there a connection to https://htmx.org/ https://htmx.org/?
- rustyminnow 4y ago
  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
- ytjohn 4y ago
  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 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.
- epr 4y ago
  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.
pictur 4y ago
[flagged]
- pictur 4y ago
  [flagged]
- replwoacause 4y ago
  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 4y ago
    How did you learn it? What was your learning path like?
    - replwoacause 4y ago
      I used the documentation and Bing Chat AI.
  - vgb2k18 4y ago
    I like it too for now. Htmx + Caddy (goodbye nginx), Bulma (css) and Fastapi (python backend). All this for a student management SPA. My day job as a school teacher means (A) I have to deal with outdated monolithic webapps daily, and (B) I don't exactly have all the time in the word to write software. This stack has been a godsend.
- sam_goody 4y ago
  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.
beepbooptheory 4y ago
Use js so you don't have deal with htmx which you are using so you don't have to deal with js?
nawgz 4y ago
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 4y ago
  > 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.
  - nawgz 4y ago
    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.
jmull 4y ago
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).
ithkuil 4y ago
Tried the demo app, followed the instructions, didn't work, filed a ticked, moving on, will evaluate again

77 points by phaleth 4y ago

deleted 4y ago

[deleted]

earleybird 4y ago

Is there a connection to https://htmx.org/ https://htmx.org/?

rustyminnow 4y ago
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
ytjohn 4y ago
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 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.
epr 4y ago
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.

pictur 4y ago

[flagged]

pictur 4y ago
[flagged]
replwoacause 4y ago
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 4y ago
  How did you learn it? What was your learning path like?
  - replwoacause 4y ago
    I used the documentation and Bing Chat AI.
- vgb2k18 4y ago
  I like it too for now. Htmx + Caddy (goodbye nginx), Bulma (css) and Fastapi (python backend). All this for a student management SPA. My day job as a school teacher means (A) I have to deal with outdated monolithic webapps daily, and (B) I don't exactly have all the time in the word to write software. This stack has been a godsend.
sam_goody 4y ago
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.

beepbooptheory 4y ago

Use js so you don't have deal with htmx which you are using so you don't have to deal with js?

nawgz 4y ago

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 4y ago
> 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.
- nawgz 4y ago
  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.

jmull 4y ago

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).

ithkuil 4y ago

Tried the demo app, followed the instructions, didn't work, filed a ticked, moving on, will evaluate again