Htmx in a Nutshell • Hacker News Board

Re: Htmx in a Nutshell

#211

Post by rgrieselhuber » Wed, Dec 14, 2022, 9:32 PM UTC

czx4f4bd wrote: post #198

codegeek wrote: post #158

Earlier quoted context omitted.

Can I ask you how long you have been using this stack for and what are your findings ? Do you have a complex UI heavy application and can you deterministically say that this stack can replace frameworks like React/Vue for JS heavy frontend ? Is HTMX really mature and stable for production and massive UI heavy apps ? I am asking because we are starting a big project in Django, Postgres, Tailwind and for frontend, stil…

https://htmx.org/essays/when-to-use-hypermedia/ addresses your first question. The tl;dr is "probably not" as htmx is not really designed to handle complex browser-based UIs, but I have seen people in this thread and elsewhere discuss more complex use cases, so YMMV. https://htmx.org/essays/a-real-world-react-to-htmx-port/ is about porting a serious production Django application from React to htmx. If you hate SPAs a…

After going through a fever swamp project involving React, I am definitely in the camp of getting back to basics.

Re: Htmx in a Nutshell

#212

Post by fatboy » Wed, Dec 14, 2022, 9:36 PM UTC

Quekid5 wrote: post #209

fatboy wrote: post #202

Earlier quoted context omitted.

Can you speak of your experience with liveviewjs? I've been looking at it, and htmx, and everything else, over the past few months for a heavily-interactive frontend project I need to start. I'm an experienced ios dev, but in at the deepens with all this js frontend stuff. There are so many options! The one thing I'm sure of is I don't want to use react.

The only real advice I can offer is: Try to implement an example of the most complicated UI interaction that you have in your (conceptual) application in both and then decide. Development-by-random-recommendation is usually a recipe for disaster.

That is sound advice and I take it to heart. I was mainly wondering if you'd hit any roadblocks whose existence might not have been obvious from the outset?

Re: Htmx in a Nutshell

#213

Post by infogulch » Wed, Dec 14, 2022, 9:37 PM UTC

nop_slide wrote: post #104

Relevant talk from the creator of HTMX https://www.youtube.com/watch?v=LRrrxQXWdhI

This is the best of various talks presented by the author imo

Re: Htmx in a Nutshell

#214

Post by taolegal » Wed, Dec 14, 2022, 9:39 PM UTC

t8sr wrote: post #97

t8sr wrote: post #75

I'm confused about what value this adds. The introductory example is certainly not helpful, as it takes an ` Blog ` and turns into 7 lines of markup to accomplish the same thing. (And then it says a bunch of things that are arguably not desirable, like "any element can now trigger requests".) Like: what's the point of using this over HTML5+js? I've spent 15 minutes reading the website and I still don't understand why…

Replying to myself: I guess the main point of this library is to use HTML as the protocol payload between serve and client, instead of JSON. I can see the benefit of doing that, although I have a bone to pick with the condemnation of all data APIs because JSON is awful. Protocol buffers, for example, are trivially forward and backward compatible and mostly self-describing. Also if you build stuff on top of hypermedia…

> I guess the main point of this library is to use HTML as the protocol payload between serve and client, instead of JSON

HTTP is named Hypertext Transfer Protocol after all. Exchanging schema-less JSONs is conceptually pretty lame. It's plain old RPC architecture. That's why we end up needing to write API docs to line up the frontend and backend, or otherwise inspect backend code to figure out what's being handed over.

Browsers are built to understand HTML. Whereas in the modern world we largely ignore that and write double the code we'd have to write otherwise passing arbitrary messages and it introduces a whole new set of problems making sure those codebases line up properly. Whereas HTML produced by the backend (properly) contains all the information someone could need.

Re: Htmx in a Nutshell

#215

Post by harryvederci » Wed, Dec 14, 2022, 9:40 PM UTC

bnert wrote: post #50

silver-arrow wrote: post #30

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 l…

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.

Same here, also using Janet + htmx!

Re: Htmx in a Nutshell

#216

Post by pvorb » Wed, Dec 14, 2022, 9:42 PM UTC

This looks very similar to Hotwire. Does anyone have experience in both libraries and give a few hints about pros and cons of both libraries?

Re: Htmx in a Nutshell

#217

Post by megaman821 » Wed, Dec 14, 2022, 9:42 PM UTC

hedgehog wrote: post #197

jonesnc wrote: post #126

We're migrating our apps from Vue.js to HTMX, and it has been a great experience. The size of our codebase has consistently gone down as we move things to HTMX, and it feels like the level of complexity goes down as well. I highly recommend using HTMX.

What kind of apps? I used Intercooler (sort of a predecessor to HTMX) for a personal project and it worked well but I didn't get a good feel for what it would be like to build more complicated UI.

I don't think UI is part of HTMX's concerns. It is a library for submitting data and loading HTML fragments. For general UI components, I like https://shoelace.style/.

Re: Htmx in a Nutshell

#218

Post by hexmiles » Wed, Dec 14, 2022, 9:44 PM UTC

recursivedoubts wrote: post #2

howdy, I'm the creator of htmx, happy to talk about it

Hi, on the subject of hypermedia: I recently saw your talk when you showed hyperview.org as an alternative to HTML for mobile use case.

As someone who is very interested in the space, are there other hypermedia implementation (if is the right word) that you found interesting? Or do you have some pointer for those who want to explore this space?

Personally I really want some kind of hypermedia framework for terminal application, since I often need to work with hardware (or bandwidth) where the only interface is a terminal, and I never feel productive with manually writing the application code, having to reimplement a new client every time.

Also thank you for htmx, I started using for a couple of project, and it really is refreshing. Especially kudos for the various example, that really helped making it "click".

Re: Htmx in a Nutshell

#219

Post by bitterblotter » Wed, Dec 14, 2022, 9:45 PM UTC

I've been working on a HTMX Playground!

https://lassebomh.github.io/htmx-sandbox/

It runs a small mock server inside the browser which is very Django inspired, so it should be very familiar if you have experience with it.

The mock server runs using PollyJS and Nunjucks as the templating engine. There is sadly no mobile support or the ability to save yet, but it's still a great place to start tinkering without needing a full setup.

Repo: https://github.com/lassebomh/htmx-sandbox

Re: Htmx in a Nutshell

#220

Post by airstrike » Wed, Dec 14, 2022, 9:46 PM UTC

taolegal wrote: post #214

t8sr wrote: post #97

Earlier quoted context omitted.

Replying to myself: I guess the main point of this library is to use HTML as the protocol payload between serve and client, instead of JSON. I can see the benefit of doing that, although I have a bone to pick with the condemnation of all data APIs because JSON is awful. Protocol buffers, for example, are trivially forward and backward compatible and mostly self-describing. Also if you build stuff on top of hypermedia…

> I guess the main point of this library is to use HTML as the protocol payload between serve and client, instead of JSON HTTP is named Hypertext Transfer Protocol after all. Exchanging schema-less JSONs is conceptually pretty lame. It's plain old RPC architecture. That's why we end up needing to write API docs to line up the frontend and backend, or otherwise inspect backend code to figure out what's being handed ov…

This hits the nail on the head so hard that reading it feels like waking up from a bad dream.

> Browsers are built to understand HTML. Whereas in the modern world we largely ignore that and write double the code we'd have to write otherwise passing arbitrary messages and it introduces a whole new set of problems making sure those codebases line up properly.

This belongs in a manifesto. Put it on a shirt and I'll gladly wear it