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

191–200 of 326 posts

Re: Moving from React to htmx

#191

Post by recursivedoubts »

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

Re: Moving from React to htmx

#192

Post by nickjj »

MatthiasPortzel wrote: post #41
andy800 wrote: post #12

Earlier quoted context omitted.

> as you reach a more “app like” experience with multiple layers of state control on the front end you need to reach for a front end JS framework I think that if you fully embrace HTMX's model, you can go far further than anticipated without a JS framework. Do you really need to be managing state on the client? Is it really faster to communicate via JSON, or protobuf, whatever, rather than atomic data and returning j…

The slippery slope that scares me (as a React developer) about htmx (or Hotwire.dev, in particular is the one I was looking at), is that you start making the assumption that the client's internet is fast. There was demo that showed it normally takes ~100ms to click a mouse, and if you attach to the on-mouse-down, then by the time the mouse has been released (100ms later), you can have already fetched an updated rende…

> There was demo that showed it normally takes ~100ms to click a mouse, and if you attach to the on-mouse-down, then by the time the mouse has been released (100ms later), you can have already fetched an updated rendered component from the server.

I think what you're describing is a form of preloading content but it's not limited to React.

For example:

The baseline is: You click a link, a 100ms round trip happens and you show the result when the data arrives.

In htmx, Hotwire or React you could execute the baseline as is and everyone notices the 100ms round trip latency.

In React you could fetch the content on either mouse-down or mouse-over so that by the time the user releases the mouse it insta-loads.

But what's stopping you from implementing the same workflow with htmx or Hotwire? htmx or Hotwire could implement a "prefetch" feature too. In fact htmx already has it with https://htmx.org/extensions/preload/. I haven't used it personally but it describes your scenario. The API looks friendly too, it's one of those things where it feels like zero effort to use it.

Hotwire looks like it's still fleshing out the APIs for that, it has https://turbo.hotwired.dev/handbook/drive#preload-links-into... for pre-loading entire pages. There's also https://turbo.hotwired.dev/reference/frames#eager-loaded-fra... and https://turbo.hotwired.dev/reference/frames#lazy-loaded-fram... which aren't quite the same thing but given there's functionality to load things on specific events it'll probably only be a matter of time before there's something for preloading tiny snippets of content in a general way.

Re: Moving from React to htmx

#193

Post by recursivedoubts »

personalidea wrote: post #166
yawaramin wrote: post #68

Earlier quoted context omitted.

The article we're commenting on dedicates an entire section to talking about the dev team makeup and how it completely changed and unified the team approach to being fullstack. That's how thoroughly htmx changed the programming model.

Wouldn’t that also work the other way around? Move to a JS backend and now every dev on the team can write client and server side code?

"We are fond of talking about the HOWL stack: Hypermedia On Whatever you'd Like. The idea is that, by returning to a (more powerful) Hypermedia Architecture, you can use whatever backend language you'd like: python, lisp, haskell, go, java, c#, whatever. Even javascript, if you like.

Since you are using hypermedia & HTML for your server interactions, you don't feel that pressure to adopt javascript on the backend that a huge javascript front end produces. You can still use javascript, of course, (perhaps in the form of alpine.js) but you use it in the manner it was originally intended: as a light, front end scripting language for enhancing your application. Or, if you are brave, perhaps you can try hyperscript for these needs.

This is a world we would prefer to live in: many programming language options, each with their own strengths, technical cultures and thriving communities, all able to participate in the web development world through the magic of more powerful hypermedia, rather than a monolith of SPAs-talking-to-Node-in-JSON.

Diversity, after all, is our strength."

https://htmx.org/essays/a-response-to-rich-harris/

Re: Moving from React to htmx

#194

Post by tuukkah »

richbell wrote: post #139
stickfigure wrote: post #125

Earlier quoted context omitted.

From a security perspective, the client is 100% irrelevant. You might prefer to offer a good UX in the face of authorization failure, but that doesn't affect the security of your app one way or another. Good APIs look like simple functions; they take certain very structured inputs (path, query params, headers, body) and produce a simple structured output (usually a json blob). They're usually well defined, limited in…

The operative word being good , which most APIs unfortunately aren't. You could make the exact same argument about APIs that you made about HTML endpoints, and vice versa. The problem, imo, is that writing a fronted is a lot harder for many people than writing a backend and they tend to spend more time on the front-end. Security is hard, especially when most developers are ignorant or negligent about basic best pract…

> The problem, imo, is that writing a fronted is a lot harder for many people than writing a backend and they tend to spend more time on the front-end.

The question then is whether the API is more part of the frontend or the backend.

If your backends are relatively easy and small, I think you should try to keep your APIs in that space and e.g. return JSON from a simple REST API with endpoint-level security.

On the other hand, if an API threatens to bloat and complicate your backend, use an API framework like Postgraphile or Hasura that gives you the tools to build powerful and secure APIs by writing some simple code or even no code at all.

Re: Moving from React to htmx

#195

Post by criddell »

ksbrooksjr wrote: post #25

Htmx is great for developers who need client side interactivity, but would rather not write any js. If you don't mind writing a bit of js however, you can't go wrong with Preact. Same api as React, but at a fraction of react-dom's bundle size. It looks like the minified source is even smaller than htmx (which is already very minimal) [1][2]. They've also packaged Preact in such a way that you don't need to add a buil…

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

Re: Moving from React to htmx

#197

Post by hsbauauvhabzb »

nine_k wrote: post #133
throwawaymoddle wrote: post #119

Earlier quoted context omitted.

> Only the API needs to be secure. If users type passwords, sensitive data, anything into the frontend then any javascript, plugins etc pulled in by that page is an attack vector.

Unless you do something extremely silly with the login page, like sending it as a GET parameter, or storing it locally, or not having a CSRF token, or not using HTTPS, I don't see what special measures are required!

If POST content type is application/json and is enforced, csrf is not possible. You cannot csrf put and delete unless you modify cors policies, all of which are server side vulnerabilities and not related to you using SPA vs server side rendering.

Re: Moving from React to htmx

#198

Post by hsbauauvhabzb »

throwawaymoddle wrote: post #148
nine_k wrote: post #133

Earlier quoted context omitted.

Unless you do something extremely silly with the login page, like sending it as a GET parameter, or storing it locally, or not having a CSRF token, or not using HTTPS, I don't see what special measures are required!

Sensitive data is not restricted to logins. If you are pulling in third party JS like for analytics, tracking, social, whatever then that is an attack vector. Marketing and business teams aren't responsible for security but they have the muscle to pull in dangerous code to the frontend that can be swapped out. It is naive to think that the API is the only thing to focus on.

The likelihood of a vulnerability in serverside logic is far higher and more impactful than a large marketing player like google analytics stealing PII.

Re: Moving from React to htmx

#199

Post by beebeepka »

Glyptodon wrote: post #120

Expected this to be more interesting than a maybe fancier version of turbolinks. Am I missing something?

The htmx guys self promote here all the time. Their selling point is "no js" for slightly interactive demo apps.

10/10 times is just them openly bashing the rest of us for not using their tech.

Re: Moving from React to htmx

#200

Post by branko_d »

andy800 wrote: post #12
samwillis wrote: post #7

Love htmx and this talk is a brilliant run down of where it works well. But as always it’s about choosing the right tool for the job. Server rendered pages/fragments solve so many issues around security and time to develop a product, however it only gets you so far. Ultimately I think the decision when choosing a stack comes down to how much state you need to managed in browser. The vast majority of sites needs very…

> as you reach a more “app like” experience with multiple layers of state control on the front end you need to reach for a front end JS framework I think that if you fully embrace HTMX's model, you can go far further than anticipated without a JS framework. Do you really need to be managing state on the client? Is it really faster to communicate via JSON, or protobuf, whatever, rather than atomic data and returning j…

I think the point of a SPA is not how to refresh the screen when you have to do the round-trip to the server. The point is that you can do more things without making the round-trip in the first place.
Post reply on HN