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

401–410 of 530 posts

Re: Please just try HTMX

#401

Post by lbreakjai »

adamzwasserman wrote: post #395
lbreakjai wrote: post #333

Earlier quoted context omitted.

So now you have presentation logic, tightly coupled, spread over two places. You need to jump between two codebases to even have a clue about what is rendering on the page. There's an example on their website where the header of a table is defined in the frontend, and the body is returned by the backend. If I wanted something as simple as switching the order of the columns, I'd actually need to create a new version o…

I use nested templates the same way React uses nested components. The key is cascading the context (like props) down the hierarchy. Column order change? One edit in the table template; everything that includes it gets the update. The "header frontend / body backend" split is a choice, not a requirement. I wouldn't make that choice.

> The "header frontend / body backend" split is a choice, not a requirement. I wouldn't make that choice.

I mention it because that's the first example on the official website, so I'd assume this is the right way.

Re: Please just try HTMX

#402

Post by swyx »

i tried it, its great if you want a jquery replacement, but if you are AT ALL used to react svelte etc you are going to be SORELY disappointed at how much ui manipulation and state management coordination you are going to need to reinvent from scratch. not worth it

Re: Please just try HTMX

#403

Post by lbreakjai »

adamzwasserman wrote: post #200
johnfn wrote: post #83

> When you click it, HTMX POSTs to /clicked, and whatever HTML the server returns replaces the button. No fetch(). No setState(). No npm install. No fucking webpack config. Can someone explain something to me? To my view, the single best idea React has is that it forces you to encapsulate the full set of states in your component - not anywhere else. For instance, if you have a "Comment" button that becomes "Submitted…

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…

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

But it's not, is it? The state lives in the server. If I open a page, and let it open for 2 hours, then there's no guarantee it actually represents the current state.

Re: Please just try HTMX

#404

Post by listenallyall »

bccdee wrote: post #377
listenallyall wrote: post #369

Earlier quoted context omitted.

Yes, if your server is a weak, limited processor, you want to keep the demands on it as low and lean as possible, and let the client do the heavy lifting. HTMX is not a good fit for this scenario, just like PostgreSQL is not a good database to embed on your devices. This isn't a controversial idea and nobody would try to sell you on HTMX for your use case.

1. No, templating strings is actually quite cheap. I'm doubtful that you could benchmark any substantial difference between templating html and serializing json. 2. Who has a server with a weak, limited processor? HTML templates power Django, Rails, and PHP. This paradigm worked fine on the servers of 20 years ago, in the slowest languages we use. I could serve a Django app on my phone and see reasonable performance.

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.

Re: Please just try HTMX

#405

Post by zeroq »

Call me grumpy but 20 years ago we were making fun of smarty - a template engine made in a template engine - and now everything looks like a solution looking for a problem.

Re: Please just try HTMX

#406

Post by nchmy »

naasking wrote: post #396
nchmy wrote: post #354

Earlier quoted context omitted.

To clarify, there's nothing React or SPA about datastar. Moreover, HTMX v4 is essentially Datastar-lite (but heavier, and less capable)

There is, Datastar has client-side rendering based on signals [1]. Datastar is also very explicitly designed to be modular and extensible, so you can extend the client-side with more features, as they've done with Web Components. [1] https://data-star.dev/guide/reactive_signals

Signals aren't even really "rendering". And react and spas dont have a monopoly on doing things on the client - that's just javascript. I dare you to go to the datastar discord and tell them that they're React-adjacent, and SPA-like

Re: Please just try HTMX

#407

Post by intrasight »

Octoth0rpe wrote: post #275
azangru wrote: post #162

Earlier quoted context omitted.

> No Jobs > Another practical reason not to use htmx is that there are, rounding off, zero htmx jobs. > I just did a search for htmx jobs on indeed and found a grand total of two: one at Microsoft and one at Oak Ridge National Laboratory. > A search for “react”, on the other hand, gives 13,758 jobs. > Seriously, developer, which of these two technologies do you want to hitch your career to? I do not advocated for htm…

> Resume-driven development should not be a thing. Pretend this is not about library choice, but rather about language choice. One language has 2 jobs, and the other language 13k jobs. I doubt you'd think for more than a second.

One language - JSX - has 10 jobs.

The other language - HTML - has over 30,000 jobs

Re: Please just try HTMX

#408

Post by bccdee »

listenallyall wrote: post #404
bccdee wrote: post #377

Earlier quoted context omitted.

1. No, templating strings is actually quite cheap. I'm doubtful that you could benchmark any substantial difference between templating html and serializing json. 2. Who has a server with a weak, limited processor? HTML templates power Django, Rails, and PHP. This paradigm worked fine on the servers of 20 years ago, in the slowest languages we use. I could serve a Django app on my phone and see reasonable performance.

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.

Re: Please just try HTMX

#409

Post by codedokode »

I looked at the code examples and instantly saw something familiar. I remember, there was a library that intercepted link clicks, made AJAX requests and updated DOM with response, so that the page would update without reloading. If for any reason the code failed, there was just standard link navigation so you could access the content any way. I think it was pjax library.

It made the site look like a SPA without having to write any extra code. How cool is that.

HTMX resembled me this library. But it seems very narrow cased, there are only so many attributes and their values and you cannot implement anything else. While pjax is generic: you can attach it to any site which has links.

Also you cannot replace Vue (don't use React) with HTMX. For example, if you are making a diagram editor, HTMX won't be useful.

Re: Please just try HTMX

#410

Post by johnnyanmac »

azangru wrote: post #162
librasteve wrote: post #103

Earlier quoted context omitted.

HTMX Sucks https://htmx.org/essays/htmx-sucks/

> No Jobs > Another practical reason not to use htmx is that there are, rounding off, zero htmx jobs. > I just did a search for htmx jobs on indeed and found a grand total of two: one at Microsoft and one at Oak Ridge National Laboratory. > A search for “react”, on the other hand, gives 13,758 jobs. > Seriously, developer, which of these two technologies do you want to hitch your career to? I do not advocated for htm…

>Resume-driven development should not be a thing

Reality is often disappointing. I'd love to be working deep in my Vulkan rendering knowledge, but it's clear right now with my lack of job that I need to grind leetcode instead and work on personal projects first. Graphics programming is already such a stiff bar to get into and it's only gotten stiffer as I go along.

I'm going a little bit on a limb by also cultivating Rust, so I'm not optimizing my RDD. But I still looked for a compromise of what I like and what's in demand.

Post reply on HN