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

161–170 of 326 posts

Re: Moving from React to htmx

#161

Post by galaxyLogic »

gspencley wrote: post #69
MatthiasPortzel wrote: post #41

Earlier quoted context omitted.

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…

As someone who has been writing code for 30 years and has been developing "web apps" since the late 90s, it's really funny to me how things come full circle. You just described the entire point of client-side rendering as it was originally pitched. Computation on the server is expensive and mobile networks were slow and limited in terms of bandwidth (with oppressive overage charges) just a few years ago. Client-side…

> we used to call them "Single Page Web Applications" because avoiding page refreshes was the point

I wonder if the problem was really that the whole page was reloaded into the browser which caused a big "flash" because all of the page was-re-rendered. The problem maybe was not reloading the page from the server but re-rendering all of it. Whereas if you can load just parts of the page from the server the situation changes. It's ok if it takes some time for parts of the page to change because nothing gets "broken" while they are refreshing. Whereas if you reload the whole page everything is broken until all of it has been updated.

Re: Moving from React to htmx

#162

Post by galaxyLogic »

P5fRxh5kUvp2th wrote: post #93
gspencley wrote: post #69

Earlier quoted context omitted.

As someone who has been writing code for 30 years and has been developing "web apps" since the late 90s, it's really funny to me how things come full circle. You just described the entire point of client-side rendering as it was originally pitched. Computation on the server is expensive and mobile networks were slow and limited in terms of bandwidth (with oppressive overage charges) just a few years ago. Client-side…

People always take a good idea to far. There's nothing wrong with loading a page and then everything on that page loads data from the server and renders it. Where the issues come in is that modern SPA claims loading a new page is unacceptable and that somehow doing so means you can't fetch data and render anymore. It's just not true.

I think the term SPA is somewhat confusing. Why can't an SPA, or parts of it be rendered on the server as well.

Re: Moving from React to htmx

#163

Post by galaxyLogic »

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…

> Why have HTML elements react to changes in data or state, rather than just insert new HTML elements already updated with the new state?

But what's the big difference? Something somewhere must react to change. Either modify the DOM by client-side code, or modify/replace it by loading content-fragments from the server.

I would (perhaps naively) think that doing more on the client is faster than both re-rendering on the server and reloading from the server. Maybe it's just that React is too big and complicated and therefore slow.

Re: Moving from React to htmx

#164

Post by jcparkyn »

Winsaucerer wrote: post #155
hsbauauvhabzb wrote: post #57

Earlier quoted context omitted.

What security issues does server rendering solve? I resent that every website needs to be an SPA, but from a security perspective I’ve concluded that the clearer line in the sand that SPA application architectures creates is better than the security challenges that can result from server side rendering. Navigating the risks around the NPM supply chain is another story, but I suspect it will be solved by large / popul…

Here's one I've experienced. Suppose you have a table of customers, and you want to show an extra column of data on that page showing total orders, if and only if the viewer of that table has the manager role. With an SPA, you'll be building an API (perhaps a 'REST' one, or GraphQL) to expose all the data required, such as customer name, email, etc, as well as the extra 'total orders' field iff they have the manager…

As a slight counterpoint to that scenario, the front-end can often just get away with just checking whether the data exists in the response, rather than checking roles. This isn't quite as simple as the SSR alternative, but it at least removes most of the hassle with making sure the permissions match on server and client.

However, this doesn't help much when the restricted data is on a separate endpoint, since the app needs to decide whether to make the request in the first place.

Re: Moving from React to htmx

#165

Post by [deleted] »

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…

[deleted]

Re: Moving from React to htmx

#166

Post by personalidea »

yawaramin wrote: post #68
ksbrooksjr wrote: post #60

Earlier quoted context omitted.

According to the article we're commenting on, the programming model is not the sole reason for switching from React to Htmx. Look at the executive summary's bullet points. Four of them are related to performance (build time, time to interactive, data set size, and memory usage). Performance might not be the reason you personally use Htmx, but it's certainly put forward as an advantage in the article which we're comme…

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?

Re: Moving from React to htmx

#167

Post by wruza »

Winsaucerer wrote: post #155
hsbauauvhabzb wrote: post #57

Earlier quoted context omitted.

What security issues does server rendering solve? I resent that every website needs to be an SPA, but from a security perspective I’ve concluded that the clearer line in the sand that SPA application architectures creates is better than the security challenges that can result from server side rendering. Navigating the risks around the NPM supply chain is another story, but I suspect it will be solved by large / popul…

Here's one I've experienced. Suppose you have a table of customers, and you want to show an extra column of data on that page showing total orders, if and only if the viewer of that table has the manager role. With an SPA, you'll be building an API (perhaps a 'REST' one, or GraphQL) to expose all the data required, such as customer name, email, etc, as well as the extra 'total orders' field iff they have the manager…

manager role column

Tbh, I’d prefer a runtime which would be itself aware of such metadata, knew the role out of a request/session context and could build a ui table based on all-columns-ever template, from a query automatically built for this specific case, because querying and throwing away totals may be expensive. This manual “do here, do there” is a sign of a poor platform (not that we have a better one) and code-driven rather than data-driven access control in it. Painting walls and installing doors every time you want a meeting should not be a part of a business logic, regardless of which-end and its implications.

Re: Moving from React to htmx

#168

Post by capn_duck »

Winsaucerer wrote: post #155
hsbauauvhabzb wrote: post #57

Earlier quoted context omitted.

What security issues does server rendering solve? I resent that every website needs to be an SPA, but from a security perspective I’ve concluded that the clearer line in the sand that SPA application architectures creates is better than the security challenges that can result from server side rendering. Navigating the risks around the NPM supply chain is another story, but I suspect it will be solved by large / popul…

Here's one I've experienced. Suppose you have a table of customers, and you want to show an extra column of data on that page showing total orders, if and only if the viewer of that table has the manager role. With an SPA, you'll be building an API (perhaps a 'REST' one, or GraphQL) to expose all the data required, such as customer name, email, etc, as well as the extra 'total orders' field iff they have the manager…

Yes yes yes. You're not going to get much appreciation of this from newer devs. They've only known one thing. I shudder at all the human-hours spent on duplicative tasks related to the artificial frontend/backend separation.

Re: Moving from React to htmx

#169

Post by jpe90 »

singularity2001 wrote: post #156
mediumdeviation wrote: post #56

Earlier quoted context omitted.

For a real world example of this, GitHub uses server-side rendered fragments. Working with low latency and fast internet in the office, the experience is excellent. Trying to do the same outside with mobile internet, and even with a 5G connection, the increased latency makes the application frustrating to use. Every click is delayed, even for simple actions like opening menus on comments, filtering files or expanding…

Github does? Maybe that's the reason why I often get the error message: "page took too long to render" after ten seconds of waiting. example: https://github.com/pannous/hieros/wiki/%F0%93%83%80 this is admittedly a complicated markdown file, however it often fails on much simpler files.

that's a good reason to invest in self hosting! https://git.jeskin.net/hiero-wiki/file/%F0%93%83%80.md.html

Re: Moving from React to htmx

#170

Post by aidos »

galaxyLogic wrote: post #161
gspencley wrote: post #69

Earlier quoted context omitted.

As someone who has been writing code for 30 years and has been developing "web apps" since the late 90s, it's really funny to me how things come full circle. You just described the entire point of client-side rendering as it was originally pitched. Computation on the server is expensive and mobile networks were slow and limited in terms of bandwidth (with oppressive overage charges) just a few years ago. Client-side…

> we used to call them "Single Page Web Applications" because avoiding page refreshes was the point I wonder if the problem was really that the whole page was reloaded into the browser which caused a big "flash" because all of the page was-re-rendered. The problem maybe was not reloading the page from the server but re-rendering all of it. Whereas if you can load just parts of the page from the server the situation c…

We had this middle ground of returning html fragments and updating subsections of the page. For posting a comment, for example.

There were plenty of sites doing that in the mid 2000s.

Post reply on HN