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

431–440 of 530 posts

Re: Please just try HTMX

#431

Post by ErroneousBosh »

leoedin wrote: post #197
ErroneousBosh wrote: post #123

Earlier quoted context omitted.

Okay, so what do you your servers actually serve stuff to? I kind of don't get why if you want to display something in a web browser you'd generate anything other than HTML.

I think the parent's point is that when you have a react front-end, your back-end basically just deals in structs of data. There's no HTML or templating to think about. It's just JSON-serialisable structs. That makes the code on the back end much simpler, which makes it easier to run in a resource-constrained environment. The only exposure the back-end has to HTML is streaming the static files to the browser. Which c…

What's the difference between rendering HTML and rendering JSON?

Why are you then offloading rendering HTML from JSON to a painfully slow scripting language on the client?

Re: Please just try HTMX

#432

Post by ErroneousBosh »

stefan_ wrote: post #349
bccdee wrote: post #344

Earlier quoted context omitted.

> It has to load HTML templates into memory and insert strings into them. In practice, I doubt this is much slower than serializing JSON. Keeping a couple kilobytes of HTML templates in memory is nothing. Conversely, running a whole vdom on the frontend (typically more resource-constrained than the server) is a much bigger performance issue.

Three levels down and people have entirely forgotten what my post was. My "server" is some anemic ARM core built into real physical hardware with 64M of read-only storage. I don't want it spending its time "hydrating" some DOM, I don't want to bring any of this frontend insanity on there at all. No code hosted on npm shall ever run on that processor or I can't go to sleep in peace. So how do we still get a fancy SPA…

What's npm got to do with it?

Why can't your code fill in the blanks in some HTML template instead of filling in the blanks in some JSON?

Re: Please just try HTMX

#433

Post by ErroneousBosh »

bccdee wrote: post #408
listenallyall wrote: post #404

Earlier quoted context omitted.

I agree that templating is very fast and efficient, probably faster than serializing to JSON. Read the OP's posts - he is talking about a "server" being an embedded device with 64mb of read-only storage. My assumption is that the data output format is basically hard-coded in the device's OS and doesn't even rely on JSON serialization.

Oh wait, oh my god > Three levels down and people have entirely forgotten what my post was. I missed this reply entirely. Whoops. That said, I do feel like you can do HTML templates on a tiny chip with 64 megs of memory. I've seen NASes with comparably tiny & terrible chips serve their web UIs this way: paper-thin html templates with s for interactivity and s for layout.

But that's the point of something like HTMX, though.

You draw a simple web page with very basic elements, tag them with an HTMX element, and let the client side javascript turn that into something that "does stuff".

I wrote a phone directory with find-as-you-type using Django (because it's what I had lying around) and HTMX (because I read somewhere that it was cool and fun and I should try it, and I bow easily to peer pressure), and then min.css to make it not look shit.

All totally vendored, just download the appropriate .js and .css file and check them into your source control.

When you type it hits an endpoint that returns a bit of HTML that contains a table, and swaps it into a div. The querying part and the drawing part is client-side and there's nothing stopping you passing a query string to the endpoint and getting just a bare table out.

Indeed there's nothing stopping you detecting if it's an HTMX request and only returning the fragment, or if it's "bare" returning a full valid page. You know what? I should do that, I'll log a feature request on my project for it.

I've gotten a little away from the original point.

You use HTMX on the client side, to turn a plain HTML page with no interactivity into something that will pull data from a backend and swap it into the DOM. If you want to return JSON and render that with yet another library you can, but you're probably already filling in the blanks in an HTML template as it is.

Re: Please just try HTMX

#434

Post by DANmode »

yomismoaqui wrote: post #310
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…

> Still prefer a chill vibe for htmx though. Said the horse with laser eyes (¬_¬)

No avatars here.

Re: Please just try HTMX

#435

Post by DANmode »

farmeroy wrote: post #268
mal-2 wrote: post #233

Earlier quoted context omitted.

This is what doesn't get discussed enough around htmx, in my opinion. So much of the difficult steps are left for the templating system, and template systems aren't great in general. You need to track a lot of identifiers for htmx to work properly, and your template and view logic needs to make that make sense. For the templating systems I've seen, that's not so simple to do.

1000% this. I actually am using htmx at ${JOB} and this is essentially the only downside to htmx. I want to know which template partial is getting swapped. My IDE doesn't know. I need to track countless html ids to know what will be swapped where... how? It hasn't been a big deal because I alone write the frontend code so I have all my hacks to navigate and my intimate knowledge of the code, but if we need more devs…

How does it feel to be one of 3 HTMX related jobs in the universe (according to the comments in this thread)? heh.

Re: Please just try HTMX

#436

Post by arethuza »

IgorPartola wrote: post #367
adamzwasserman wrote: post #181

Earlier quoted context omitted.

I was able to find architectural patters that work smooth as glass. Here is what my htmx apps have: - Single-purpose endpoints: Each endpoint returns ONE thing (a card list, a tag cloud, a form fragment) - Optimistic UI: Preferences like font/theme update the DOM immediately; the save is fire-and-forget with no response needed - Simple error handling: Most endpoints either succeed (return HTML) or fail (HTTP error co…

I have never loved the idea of the server rendering HTML which is probably why I have such a hard time with HTMX. In every other paradigm you clearly separate your server API and UI rendering/logic. Web apps are the only place where it seems common to have the server render UI components. Imagine if you had a Java or Swift application and had the server sending your phone UI screens. I don’t even know how you would p…

X (the Window System not the thing that was Twitter) explicitly allowed a remote machine to send rendering commands over a network to the local machine? (I'm avoiding using the term "server" as X has this round the other way - from the users perspective the server is local and the client can be remote).

Sun's NeWS also allowed something similar - but with a large amount of programmability using PostScript.

Re: Please just try HTMX

#437

Post by internet_points »

philipwhiuk wrote: post #4

The proselyting over frameworks is the worst bit of the web ecosystem. If your solution is actually good, it will get adopted eventually... Forget React, there's still stuff written in jQuery and JSP. Why the rush to convert everything - you're not a missionary on a mission, just build your stuff in stuff you like? The attack on npm is ridiculous, when (apart from introducing a permanent vulnerability in the form of…

https://www.monash.edu/business/marketing/marketing-dictiona...

Re: Please just try HTMX

#438

Post by internet_points »

jeffjeffbear wrote: post #353

I just don't like having to send HTML and have the backend deal with what are really frontend problems. Sending JSON is great since you can serialize most reasonable data types into it and then the backend has no responsibility for how it is rendered which helps for having mobile apps use the same backend as the website. Sending HTML just seems nuts since if you change your design you would have to change the backend…

if you require a backend/frontend split, you're maybe not in the htmx use case

if you can imagine having just one "end", maybe you can use htmx

Re: Please just try HTMX

#439

Post by hu3 »

Havoc wrote: post #389

Threads like these make me glad I’m not a frontend dev. Just looking at the comments it’s clear there is no cohesive view or vision or agreement. One giant Tower of Babel

I think it's because the ground in frontend dev is shaky.

Browsers keep changing along with people's expectation of what a website or app should be capable of.

Meanwhile on the backend land, the same MVC framework from 2 decades ago can still deliver acceptable results.

Re: Please just try HTMX

#440

Post by JodieBenitez »

jadbox wrote: post #73
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…

How does Unpoly and htmx differ?

HTMX is lower level. I think it would make a good web standard for libraries like Unpoly to build upon. Unpoly works best as progressive enhancement for frameworks like Rails or Django where most of the view logic is executed on the server. I love it, it's excellent. Just like Django (or rails), it's a practical tool refined after actual needs and experience, not a solution looking for a problem. And like Django it stood the test of time and is very well maintained.
Post reply on HN