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

Moving from React to htmx

htmx.org

Post reply on HN
Print view View original

281–290 of 326 posts

Re: Moving from React to htmx

#281

Post by hunterb123 »

adamckay wrote: post #215
pier25 wrote: post #114

Earlier quoted context omitted.

Use the right tool for the job. Obviously Gmail is a much better fit for React/Vue/etc than HTMX. Gmail is the perfect use case for an SPA but most web apps don't need to be an SPA.

> Gmail is the perfect use case for an SPA Is it really, though? It's a paginated list of emails, some drag-and-drop functionality, buttons for some ajax functionality. It works reasonably well, but it doesn't need to be so high Javascript compared to Google Docs or maps.

Viewing your emails offline is pretty important.

Re: Moving from React to htmx

#282

Post by hnbad »

samwillis wrote: post #205
hnbad wrote: post #187

This again? From the first page of the documentation: With that in mind, consider the following bit of HTML: Click Me! We've been through this back in the Angular days (and even before that: remember Knockout?). Implementing your template language as DOM attributes does not make it HTML. Not to mention the examples using "hyperscript", aka a "human readable" DSL for DOM manipulation and event handling also stuck in H…

The other reply (I think by the creator of HTMX) is right, HTMX is not a DSL for DOM template manipulation, but I want to address your main point about DSLs for DOM templating. I completely see the appeal of a "it's just JS" approach that JSX and React take. But there is a massive advantage that a DSL has, the compiler can statically analyse the template and compile it in such a way that it has an understanding of wh…

I know, this isn't a novel concept. There was a good talk about the spectrum of abstractions and the tradeoffs of template languages vs React's approach at React Europe a couple of years ago (in fact, he goes into that this means there are some optimizations that are simply unavailable to React): https://www.youtube.com/watch?v=mVVNJKv9esE

The question isn't whether DSLs or "just JS" are more powerful, the question is which tradeoffs they represent and which tradeoffs you prefer. It seems that HTMX is primarily based in the Python ecosystem and as a former Pythonista I see the advantage of having a DSL over having to write JS, especially that the former is much narrower, which is what you want in this situation.

Re: Moving from React to htmx

#283

Post by hnbad »

germandiago wrote: post #211
hnbad wrote: post #187

This again? From the first page of the documentation: With that in mind, consider the following bit of HTML: Click Me! We've been through this back in the Angular days (and even before that: remember Knockout?). Implementing your template language as DOM attributes does not make it HTML. Not to mention the examples using "hyperscript", aka a "human readable" DSL for DOM manipulation and event handling also stuck in H…

You are right about changingsupport for niche but... if the tool is easier to understand probably it is also less massive and easier to interact/find workarounds when needed than if you work on top of several layers + huge dependencies. At least that is my experience and why, in the face of choice and when it makes sense, I would choose htmx over React. It is easy to understand and a thin layer you can figure out eve…

Yes, it's a tradeoff. Picking up a DSL is probably faster and easier than learning an entire new language. But knowledge about that DSL is also not as readily transferrable and it's much harder to hire for someone already familiar with a DSL than one of the most widely used languages. Of course in turn you probably want a much higher level of expertise in that language than would be necessary in a DSL you can learn (and, to some degree, master) in a fraction of the time.

Re: Moving from React to htmx

#284

Post by hnbad »

recursivedoubts wrote: post #191
hnbad wrote: post #187

This again? From the first page of the documentation: With that in mind, consider the following bit of HTML: Click Me! We've been through this back in the Angular days (and even before that: remember Knockout?). Implementing your template language as DOM attributes does not make it HTML. Not to mention the examples using "hyperscript", aka a "human readable" DSL for DOM manipulation and event handling also stuck in H…

Htmx is not simply angular-style directives with client-side templates again. it is, rather, an extension of HTML as hypermedia. That's the big difference between htmx and most other front end libraries. There are a number of essays here on this difference and the ramifications of it here: https://htmx.org/essays

Frankly, that page in itself is the reason my comment's tone is so hostile.

There are fewer "essays" on that page than "memes" which just seem to exist to ridicule frontend frameworks or smear JS in general (which is ironic given that JS itself is a "twenty years old technology", which at least one of the memes frames as superior). I put "essays" in scare quotes as the first "essay" is literally the OP article, which is primarily a video of a conference talk. The rest of the collection mostly makes philosophical arguments that wax poetical about web architecture and mostly don't reference htmx by name so I can't be bothered to dig through all of them to figure out what you're trying to tell me.

"An extension of HTML as hypermedia" is not a description of what it does, it's a grandiose sales pitch. I'm familiar with the original REST paper and a lot of the philosophizing around HATEOAS and hypermedia.

It's not an "extension of HTML", it's a browser runtime implemented as a JavaScript library (assuming they didn't use WASM) that executes a declarative DSL in the form of non-standard HTML attributes (like Knockout, AngularJS 1, etc) and performs XHR requests to substitute fragments (like PJAX).

I'm genuinely trying to understand what makes this novel or interesting but it's hard to tell between all the obnoxious dismissiveness towards frontend frameworks (and JS) and the grandiose use of academic buzzwords.

EDIT: Thank you for pointing to that page though because at least it demonstrates that HTMX is the successor to Intercooler.js, a JS framework, which has a much less grandiose description of itself that doesn't need to appeal to philosophical blog posts or shitting on JavaScript to make its point: https://intercoolerjs.org/docs.html#philosophy

In fact, this Intercooler essay explicitly names PJAX as one of the examples of the tradition it tries to build on (while trying to stay true to the principles of HATEOAS and REST).

Re: Moving from React to htmx

#285

Post by criddell »

devoutsalsa wrote: post #278
criddell wrote: post #223

Earlier quoted context omitted.

Have you ever tried writing a native client? I think the native client path is something that a lot of developers don't even consider these days. I think it's an area of great opportunity.

What do you mean? Like writing one's own framework, such as devoutsalsa.js?

I have no idea what that is, but since it's javascript I assume it's still running in the browser.

I'm suggesting getting out of the browser all together and writing a native client. Before Evernote moved to Electron, it's what they did. Their Windows client was written in C++ and their Mac client was Objective C.

Re: Moving from React to htmx

#286

Post by criddell »

lliamander wrote: post #280
criddell wrote: post #195

Earlier quoted context omitted.

If you want a non-JavaScript client, ditch the browser all together and build a native client.

I think you have it backwards. If you want to build a client using HTML, then targeting the browser is exactly the right choice. Javascript-heavy SPAs are much closer to traditional native apps - and lose some of the benefits of running on the web/ in the browser as a result. There's a lot more reason to consider native app if you are building an SPA than if you are building an MPA/SSR app.

I'm suggesting not using HTML for the client. Anything running in a browser is heavy and slow compared to well written native code.

Re: Moving from React to htmx

#287

Post by jlokier »

jiggawatts wrote: post #29
keizo wrote: post #4

Earlier quoted context omitted.

Speed is the big one for me. 2-6+ seconds is insanity for anything.

I would argue that 1-2 seconds is not impressive either. It's like seeing people breaking rocks with hand tools being impressed with a bigger mallet. I used to aim for 15 millisecond cold load times, which is apparently unheard of these days even for front pages with entirely static content.

I'm with you on what's impressive and what isn't. I've done considerable work on page load performance engineering in the past, getting times down to the low single-digit milliseconds as you would like while maintaining high traffic levels. I know how to make every part of the system work together to minimise response and rendering latency, which is nice for people with suitably low-latency connections, and for APIs that respond nicely in client-side applications.

Unfortunately, for myself I can't even get a ping response from the ISP upstream router in 15ms, let alone a static page over HTTPS.

None of my internet connections has sufficiently low latency - neither home nor office.

HN takes 400-600ms to load, but that's understandable due to physics. Wrong country.

I just loaded news.bbc.co.uk, which is in my country and is also well connected, and saw that DNS resolution took up to 400ms, and TLS setup took up to 650ms (though not both at the same time in a single request). Total page load time was about 2s.

Those numbers seem unnecessarily high on this connection. But 15ms is too optimistic: the network latency isn't low enough, even for a small static page.

There are a lot of people in a similar situation, living with connection latencies you would consider high, but it's all we can get.

Re: Moving from React to htmx

#288

Post by pwdisswordfish0 »

spion wrote: post #274
pwdisswordfish0 wrote: post #263

Earlier quoted context omitted.

There is no client-side state, that’s the whole point.

There is always client-side state. The dropdowns, for example, have selection that affects the entire app. That selection must be stored in a state which will affect the reloads triggered by changes in the dropdowns.

Well, sure, the value of an input is in its value property, but you build your stuff in such a way that you don’t access it unless you absolutely have to.

Re: Moving from React to htmx

#289

Post by recursivedoubts »

hnbad wrote: post #284
recursivedoubts wrote: post #191

Earlier quoted context omitted.

Htmx is not simply angular-style directives with client-side templates again. it is, rather, an extension of HTML as hypermedia. That's the big difference between htmx and most other front end libraries. There are a number of essays here on this difference and the ramifications of it here: https://htmx.org/essays

Frankly, that page in itself is the reason my comment's tone is so hostile. There are fewer "essays" on that page than "memes" which just seem to exist to ridicule frontend frameworks or smear JS in general (which is ironic given that JS itself is a "twenty years old technology", which at least one of the memes frames as superior). I put "essays" in scare quotes as the first "essay" is literally the OP article, which…

it's always a tough balance: the reality is that htmx is hostile (or at least passive agressive :) towards JavaScript, as it is being used today.

in general, I try to keep things positive and emphasize hypermedia over htmx, since it's the conceptual idea that I think is more important than htmx's implementation of it (libraries like unpoly or hotwire are also great options.) I do think htmx is more of an "extension of HTML" than those two, in that it is lower level and requires more work (or, if you prefer, has less magic) than them.

the memes are what they are: it's the internet and i've gotten plenty of shit over the last decade from SPA partisans, so, at times, they are going to be a little punchy. I try not to take things personally and laugh about it all: the situation is hopeless, but not serious.

the philosophical turn after I created htmx (really, intercooler 2.0) reflects that I have, over the last decade, developed a better understanding of hypermedia/REST/HATEOAS and why intercooler.js/htmx is different than SPA-talking-to-JSON-APIs. The essays certainly aren't for everyone, but I enjoy writing them and giving an alternative (and, I would argue, originalist) view of how web development can be done.

tone is always hard on the internet and, broadly, I like Churchill's take: "I like a man who grins when he fights."

Re: Moving from React to htmx

#290

Post by recursivedoubts »

haolez wrote: post #64
recursivedoubts wrote: post #34

Earlier quoted context omitted.

If the hypermedia approach really grabs you, you could pair an htmx-based web application with a HyperView-based mobile application: https://hyperview.org/

I can't decide if this is awesome or terrifying. Will try it out :)

:) why not both?
Post reply on HN