7 ms·

Have been using htmx for a little over a year now, and I am so thankful for this library. It has simplified our development tremendously from ClojureScript / Re

Have been using htmx for a little over a year now, and I am so thankful for this library. It has simplified our development tremendously from ClojureScript / React to vanilla Clojure on the backend doing SSR of HTML with htmx HTML element attributes. All with 1 script tag that includes this wonderful library. Kudos to the creator of htmx! This is what hypermedia architecture with true HATEOAS is all about. It feels like we took a wrong turn a decade ago, and we have been trying to reinvent rich clients with JSON RPC designs from the 90s. It has resulted in too much churn and complexity IMO.

bnert 4y ago
Doing something similar with janet. Really does simplify so much, and being able to not have to worry about always translating json -> html via { insert SPA framework here } is a breath of fresh air.
- silver-arrow 4y ago
  Agreed that it is a breath of fresh air. It totally eliminates heavy complexity in the development environment and networking protocol layers. What makes me happy is that it completely reinvigorates the server side language you prefer to use.
- harryvederci 4y ago
  Same here, also using Janet + htmx!
  - hipjiveguy 4y ago
    Do you mean this? https://janet-lang.org/ https://janet-lang.org/
    - bnert 4y ago
      Yes!
mrits 4y ago
I've done a few years of solid frontend dev in the last decade and became efficient in a few different modern frameworks. For personal projects I just pull in a bootstrap and jquery framework from a CDN. I think htmx is going to replace this practice.
0x6c6f6c 4y ago
I would love to see some example projects of stacks like this
eduction 4y ago
Do you know off hand how much JavaScript your pages are including now versus when you were using ClojureScript/React? I ask because I know ClojureScript is built on Google Closure which has pretty advanced dead code elimination (and typically for React functionality people use libraries like reagant that take advantage of this - I think?). Presumably with htmx users are having to download the whole htmx lib.
- silver-arrow 4y ago
  The JavaScript we use is now much, much less. Actually, most times we just sprinkle in a bit of hyperscript for the times we need something a bit more dynamic than plain htmx. _hyperscript is a separate library by the same author that provides an HTML type of scripting in the attribute tags. Still, in general, because we are generating fragments of hypermedia (HTML) on the server and returning that to target elements in the browser directly, the need for JavaScript directly in our code lessens dramatically. As you mentioned, though, you do need to include the hmtx JavaScript libary with a script tag. That library is very small though when min - something like 12k. Amazingly, you can build some pretty dynamic web apps using htmx and sprinkling in a little vanilla JavaScript or _hyperscript if you are daring! The main key for us though is thinking from a hypermedia point of view with SSR; that coupled with the elimination of the complicated development configurations, is a huge win in simplicity and productivity. No more versioning our endpoints too!
  - sandGorgon 4y ago
    why hyperscript and not alpine.js ? just asking. alpine.js seems to be a lot more popular generally (even without htmx)
    - silver-arrow 4y ago
      Hmmm. alpine.js does complement htmx very well and is pretty popular, so it is a great choice. I liked _hyperscript when I saw it when assessing htmx so thought they might play better together since the author is the same for both. But I don't know if that is even really true actually, and alpine.js seems to be just fine. Honestly, it may be because I used AppleScript back in the day and _hyperscript reminded me of it!
sandGorgon 4y ago
here's a question to you...since ur like, almost from the Java world! Why not clj-thymeleaf ? or even clojurescript ? this is very interesting that you find HTMX better than clojurescript - typically clojure devs prefer to stay within the lisp world for any markup. ive been getting pushback in a java team against htmx. cos the value prop is unclear vs jsp or thymeleaf. Would love to hear ur perspective.
- bnert 4y ago
  After a quick glance, it seems like htmx would complement thymeleaf, if the web page/app you're writing doesn't need any sort of eager client (eager as in, treat and interaction with a remote service as "successful" and resolve the error in the background somehow). W/ htmx + clojure, you can define your ui like so: (def counter (atom 0)) (defn partial-count-markup [c] [:span (str "Pressed: " c)]) ; Handler for /partial/count (defn partial-count [] (swap! counter inc) (partial-count-markup @counter)) ; Handler for index.html (defn handler [] [:button {:hx-put "/partial/count" :hx-swap "innerHtml"} (partial-count-markup @counter)]) And like that you have a page with a button that tracks a counter and updates the ui (I haven't tested this, YMMV). Also if it isn't clear, you can also keep all your markup as Clojure data structures, which means you can write an `html` function which has the common styles/scripts/etc.. necessary so you get a ton of re-use with an already similar syntax vs needing to learn a new templating syntax w/ its own conventions. W/ clojurescript, to get the same behavior you need: - clojurescript toolchain w/ some configuration of how you'll bundle/package it - an idea of how you'll distribute your application (serve spa from same API service? S3/Object store? another web service? How to reconcile state?) - an idea of how you'll reconcile state between local/server, if you want to go that route. If only local, nbd. If server, you add a handler and fetch data once SPA or cljs has loaded. - and idea of what format you want to consume (JSON, HTML, XML,text) and then write the translation between that format and your markup. etc... I hope the above answers your question, or at the very least offers another perspective. As a quick postscript, I think it is underestimated how convoluted templates/templating engines are, given they have the tendency to implement their own language/semantics outside of the PL you're using. I have much respect for the authors of template engines/spec, the engineering that goes into them is impressive, however, most I have come across tend to be a leaky abstraction. Once I experienced writing markup as Clojure data structures, it ruined me for templates permanently. I don't want to go back to writing templates, and doing an assessment of "what language does this template engine implement, and is it simple/easy to learn?" is an exercise I do not miss. Note: I've been Clojure/ClojureScript developing professionally for almost two years now and have debated most of the above internally during that time. Done some templating w/ JS, Go.

bnert 4y ago

Doing something similar with janet. Really does simplify so much, and being able to not have to worry about always translating json -> html via { insert SPA framework here } is a breath of fresh air.

silver-arrow 4y ago
Agreed that it is a breath of fresh air. It totally eliminates heavy complexity in the development environment and networking protocol layers. What makes me happy is that it completely reinvigorates the server side language you prefer to use.
harryvederci 4y ago
Same here, also using Janet + htmx!
- hipjiveguy 4y ago
  Do you mean this? https://janet-lang.org/ https://janet-lang.org/
  - bnert 4y ago
    Yes!

mrits 4y ago

I've done a few years of solid frontend dev in the last decade and became efficient in a few different modern frameworks. For personal projects I just pull in a bootstrap and jquery framework from a CDN. I think htmx is going to replace this practice.

0x6c6f6c 4y ago

I would love to see some example projects of stacks like this

eduction 4y ago

Do you know off hand how much JavaScript your pages are including now versus when you were using ClojureScript/React? I ask because I know ClojureScript is built on Google Closure which has pretty advanced dead code elimination (and typically for React functionality people use libraries like reagant that take advantage of this - I think?). Presumably with htmx users are having to download the whole htmx lib.

silver-arrow 4y ago
The JavaScript we use is now much, much less. Actually, most times we just sprinkle in a bit of hyperscript for the times we need something a bit more dynamic than plain htmx. _hyperscript is a separate library by the same author that provides an HTML type of scripting in the attribute tags. Still, in general, because we are generating fragments of hypermedia (HTML) on the server and returning that to target elements in the browser directly, the need for JavaScript directly in our code lessens dramatically. As you mentioned, though, you do need to include the hmtx JavaScript libary with a script tag. That library is very small though when min - something like 12k. Amazingly, you can build some pretty dynamic web apps using htmx and sprinkling in a little vanilla JavaScript or _hyperscript if you are daring! The main key for us though is thinking from a hypermedia point of view with SSR; that coupled with the elimination of the complicated development configurations, is a huge win in simplicity and productivity. No more versioning our endpoints too!
- sandGorgon 4y ago
  why hyperscript and not alpine.js ? just asking. alpine.js seems to be a lot more popular generally (even without htmx)
  - silver-arrow 4y ago
    Hmmm. alpine.js does complement htmx very well and is pretty popular, so it is a great choice. I liked _hyperscript when I saw it when assessing htmx so thought they might play better together since the author is the same for both. But I don't know if that is even really true actually, and alpine.js seems to be just fine. Honestly, it may be because I used AppleScript back in the day and _hyperscript reminded me of it!

sandGorgon 4y ago

here's a question to you...since ur like, almost from the Java world! Why not clj-thymeleaf ? or even clojurescript ? this is very interesting that you find HTMX better than clojurescript - typically clojure devs prefer to stay within the lisp world for any markup. ive been getting pushback in a java team against htmx. cos the value prop is unclear vs jsp or thymeleaf. Would love to hear ur perspective.

bnert 4y ago
After a quick glance, it seems like htmx would complement thymeleaf, if the web page/app you're writing doesn't need any sort of eager client (eager as in, treat and interaction with a remote service as "successful" and resolve the error in the background somehow). W/ htmx + clojure, you can define your ui like so: (def counter (atom 0)) (defn partial-count-markup [c] [:span (str "Pressed: " c)]) ; Handler for /partial/count (defn partial-count [] (swap! counter inc) (partial-count-markup @counter)) ; Handler for index.html (defn handler [] [:button {:hx-put "/partial/count" :hx-swap "innerHtml"} (partial-count-markup @counter)]) And like that you have a page with a button that tracks a counter and updates the ui (I haven't tested this, YMMV). Also if it isn't clear, you can also keep all your markup as Clojure data structures, which means you can write an `html` function which has the common styles/scripts/etc.. necessary so you get a ton of re-use with an already similar syntax vs needing to learn a new templating syntax w/ its own conventions. W/ clojurescript, to get the same behavior you need: - clojurescript toolchain w/ some configuration of how you'll bundle/package it - an idea of how you'll distribute your application (serve spa from same API service? S3/Object store? another web service? How to reconcile state?) - an idea of how you'll reconcile state between local/server, if you want to go that route. If only local, nbd. If server, you add a handler and fetch data once SPA or cljs has loaded. - and idea of what format you want to consume (JSON, HTML, XML,text) and then write the translation between that format and your markup. etc... I hope the above answers your question, or at the very least offers another perspective. As a quick postscript, I think it is underestimated how convoluted templates/templating engines are, given they have the tendency to implement their own language/semantics outside of the PL you're using. I have much respect for the authors of template engines/spec, the engineering that goes into them is impressive, however, most I have come across tend to be a leaky abstraction. Once I experienced writing markup as Clojure data structures, it ruined me for templates permanently. I don't want to go back to writing templates, and doing an assessment of "what language does this template engine implement, and is it simple/easy to learn?" is an exercise I do not miss. Note: I've been Clojure/ClojureScript developing professionally for almost two years now and have debated most of the above internally during that time. Done some templating w/ JS, Go.