Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Please just try HTMX

pleasejusttryhtmx.com

Post reply on HN
Print view View original

241–250 of 530 posts

Re: Please just try HTMX

#241

Post by yawaramin »

ChocolateGod wrote: post #178
mrinterweb wrote: post #166

HTML over the wire frameworks like HTMX, Hotwire (rails), LiveView (phoenix), Livewire (laravel), LiveView (django), etc. They all have the same basic idea with differences in how they achieve it. I feel this approach is overlooked, and it drives me crazy. There is a huge complexity cost attached with JS frontend app + backend that everyone seems to have accepted as reality. HTML over the wire (really need a catchy a…

Using JSON over the wire means you can re-use your backend between multiple frontends (like with mobile apps).

You can also reuse your backend if you server HTML, thanks to content negotiation. The frontend sends a header that indicates what type of content it accepts, and the backend serves the according type.

Also, mobile apps often have different API needs than webapps, so they end up getting different APIs anyway.

Re: Please just try HTMX

#242

Post by yawaramin »

nicole_express wrote: post #28

The big problem I have with HTMX is the same one I have with React server components and similar concepts; I really like being able to just serve static files. Plus the clear separation of server and client really makes reasoning about a lot of different problem cases a lot easier, that's not something to dismiss lightly. (It's a bit of a 'ship your org chart' case, though)

Htmx has very clear separation between server and client. The server is in your backend language and framework. The frontend is HTML.

Re: Please just try HTMX

#243

Post by merely-unlikely »

alfonsodev wrote: post #128
chrisweekly wrote: post #97

Earlier quoted context omitted.

This is where I think Astro shines, with its "islands of interactivity" approach. Keep things as simple as reasonably possible, and provide an idiomatic, first-class mechanism for supporting more complexity where appropriate.

I overlooked Astro for a long time, I didn't really get it, and my journey back to it went something like this: - 1 Getting burned out by Nextjs slowness in a complex production project that shouldn't be that complex or slow on the dev side, (this was 2022 approx) - 2 Taking a break from React - 3 Moving back to classic server side rendering with python and Go and dealing now with template engines. Hyped with HTMX an…

> 5 Wondering would be a way to use JSX with HTMX server side, I miss components, I don't want partial templates.

I'm playing with JSX, Hono, and Bun right now to do just that. It's early but will see how it goes.

Re: Please just try HTMX

#244

Post by yawaramin »

DaSHacka wrote: post #9
purerandomness wrote: post #3

Please install a TLS certificate to the site so people can view the content.

There is a cert, it's just not signed by a CA.

What are you guys talking about. It automatically redirects to the HTTPS version and the cert is signed by Let's Encrypt.

Re: Please just try HTMX

#245

Post by yawaramin »

karmakaze wrote: post #84

> Any HTML element can make an HTTP request > The server just returns HTML (not JSON, actual HTML) I like to separate presentation HTML from the data (returned from HTTP request). Some like to make backends that do nothing but serve the (singular) frontend, even running templates to make the HTML they return for easy consumption. That's not where I draw the line.

You know, there was a time when returning Hypertext Markup Language over Hypertext Transfer Protocol was considered a normal thing.

Re: Please just try HTMX

#246

Post by irq-1 »

dpifke wrote: post #217
recursivedoubts wrote: post #29

Hey, I created htmx and while I appreciate the publicity, I’m not a huge fan of these types of hyperbolic articles. There are lots of different ways to build web apps with their own strengths and weaknesses. I try to assess htmx’s strengths and weaknesses here: https://htmx.org/essays/when-to-use-hypermedia/ Also, please try unpoly: https://unpoly.com/ It’s another excellent hypermedia oriented library Edit: the arti…

https://unpoly.com touts "progressive enhancement." Third link on the page ("read the long story") points to https://triskweline.de/unpoly-rugb/ , which renders as a blank page with NoScript enabled. Sigh.

It's because of the demo wrapper/layers. Try just the raw demo: https://unpoly.com/examples/modal/preview.html

Still not perfect -- the demos should work too. I love the idea of a progressive framework and am willing to work around a few things to get it.

Re: Please just try HTMX

#247

Post by yawaramin »

fassssst wrote: post #190

Latest iOS Safari: the viewport jumps around on all those demos. Really hurts your case.

iOS Safara user here. The viewport jumped for me only on the active search demo and only the first time when the result content was initially loaded. This can be easily fixed by having a fixed-size results box loaded from the beginning.

Re: Please just try HTMX

#248

Post by yawaramin »

recursivedoubts wrote: post #170
athrowaway3z wrote: post #36

I'm a big fan of returning html instead of json when possible and I've been htmx curious for a bit. With all the examples people keep using, I assumed it would be way smaller. 16kb minified is a lot. Looking at the docs just now the core api seems reasonable, but it a lot larger than I'd assumed.

our minimalist version of htmx is fixi.js: https://github.com/bigskysoftware/fixi 1181kb brotli'd (no minification)

I think you mean 1181b, not kb

Re: Please just try HTMX

#249

Post by yawaramin »

athrowaway3z wrote: post #36

I'm a big fan of returning html instead of json when possible and I've been htmx curious for a bit. With all the examples people keep using, I assumed it would be way smaller. 16kb minified is a lot. Looking at the docs just now the core api seems reasonable, but it a lot larger than I'd assumed.

It's much smaller than the final bundle size that most sites will end up loading.

Re: Please just try HTMX

#250

Post by adamzwasserman »

johnfn wrote: post #227
adamzwasserman wrote: post #200

Earlier quoted context omitted.

The state encapsulation concern is exactly what DATAOS addresses: dataos.software The premise is that React's "UI=f(state)" creates a synchronization problem that doesn't need to exist. If the DOM is the authority on state (not a projection of state held elsewhere), there's nothing to sync. You read state from where it already lives. I built multicardz on this: 1M+ cards, sub-500ms searches, 100/100 Lighthouse scores…

I would be happy to discuss more. I am genuinely curious (though I do hold a pretty strong belief that React is a good abstraction). When you say that the DOM is the authority on state, I’m not sure if that addresses my concern. Let’s revisit my example of the button. Image I look at the DOM and see that it’s in a “Submitted” state, and I think that’s a bug. How can I determine how it got into this buggy state? The D…

The debugging question has a direct answer: when you capture User State from the DOM (via manifest) and send it to pure functions on the backend, you get a perfect event source pattern.

Not only can I can tell you exactly who and what triggered any piece of HTML being sent to screen, I can rewind and replay it like a tape recorder.

The broader philosophical difference: I don't treat "state" as one thing. User State (what the user sees and expects to persist across refresh) lives in the DOM.

Auth state, db cursors, cache: backend concerns. Pure functions on the backend are deterministic; same input, same output, trivially testable.

I have no hate for React; I was a core member of the React Studio team. But for my use cases, this model gives me better debuggability, not worse.

Post reply on HN