Moving from React to htmx • Hacker News Board

Re: Moving from React to htmx

#181

Post by chris12321 » Sun, Oct 16, 2022, 9:34 AM UTC

nathanappere wrote: post #178

nine_k wrote: post #130

Earlier quoted context omitted.

Frankly, with yarn, typescript, and a packaging / compressing tools of your choice, web frontend development is pretty pleasant and efficient these days. (To say nothing of using Elm, if you can afford it.) Typescript is particular is nice compared to, say, Python, and even to Java (though modern Java is quite neat.) The only unpleasant part is dependency management, but you have the same, or worse, with Python or Ru…

Really curious, how is it worse with Ruby?

With bundler, Ruby dependency management is excellent. I don't think I've ever had a problem setting up an app where the Ruby dependencies are the issue. I certainly can't say the same for JavaScript apps.

Re: Moving from React to htmx

#182

Post by Winsaucerer » Sun, Oct 16, 2022, 10:01 AM UTC

wruza wrote: post #167

Winsaucerer wrote: post #155

Earlier quoted context omitted.

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…

Yep, I think there's wisdom in what you say here for good design. My point is (using a very simple example) that there are ways in which server side rendering offers some immediate security benefits that don't automatically come for an API+front end design.

I'm not sure about its performance, as I haven't done a great deal of testing, but another tool to achieve some of what you suggest (assuming I've understood you) is using RLS. E.g., using the obvious query, and relying on RLS rules to return only permitted data. You can similarly send the appropriate role with the query [1].

I also note with interest that Postgres 15 includes some improvements that might make this kind of approach even more viable:

"PostgreSQL 15 lets users create views that query data using the permissions of the caller, not the view creator. This option, called security_invoker, adds an additional layer of protection to ensure that view callers have the correct permissions for working with the underlying data."

[1] https://news.ycombinator.com/item?id=30706295

Re: Moving from React to htmx

#183

Post by nateberkopec » Sun, Oct 16, 2022, 10:03 AM UTC

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…

Preact is not a good comparison. If it "has the same API as React", then it's not solving any of the problems that the post talks about.

Bundle size is 1 problem of JS-heavy SPAs but the post goes into many other drawbacks not addressed by something like Preact.

Re: Moving from React to htmx

#184

Post by spion » Sun, Oct 16, 2022, 10:04 AM UTC

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…

The problem was there was no concept of reusable components. IMO htmx is not the headline here but django-components (https://pypi.org/project/django-components/) is. Managing html, css and JS in component-reusable chunks on the server used to be extremely awkward, especially when you begin to need lifecycle events (HTML appeared on the page, lets attach all the necessary event listeners, but only to the right element - even in a list of 5 elements; internal HTML changed, lets see which things need more events etc).

I would try this approach out in a typechecked language, if I'm certain a native mobile app isn't going to be needed.

Re: Moving from React to htmx

#185

Post by ksbrooksjr » Sun, Oct 16, 2022, 10:24 AM UTC

nateberkopec wrote: post #183

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…

Preact is not a good comparison. If it "has the same API as React", then it's not solving any of the problems that the post talks about. Bundle size is 1 problem of JS-heavy SPAs but the post goes into many other drawbacks not addressed by something like Preact.

Preact would solve most (if not all) of the performance problems listed in the executive summary of the post (build time, time to interactive, memory usage, and maximum data set size). It doesn't seem like a terrible comparison to mention a framework with the exact same api as the one the team in the post was using for 2 years before adopting htmx.

It's a pretty short post, but a lot of it boils down to the fact that the team is using a single language throughout the whole stack (Python), which allows everyone on the team to be a full stack developer. Like I said, if you're against writing js then htmx is probably a better solution for your team.

Re: Moving from React to htmx

#186

Post by lf-non » Sun, Oct 16, 2022, 10:29 AM UTC

wwweston wrote: post #146

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…

> you start making the assumption that the client's internet is fast. The most common trajectory for react and other SPA framework apps is to also make this assumption, waving away the weight of libraries and front-end business logic with talk of how build tools are stripping out unused code so it must be light, while frequently skipping affordances for outright network failure that the browser handles transparently,…

It may be common when starting out, but we do have paths to optimize out of it.

We can do code splitting, eager fetching js when page is idle, optimistic rendering when page is taking time etc. Unlike what a lot of people like to believe not every spa runs 20 megs of js on page load.

Also the initial load time being a few seconds and then the app being snappy and interactive is an acceptable compromise for a lot of apps (not everything is an ecommerce site).

When most fragments need to be server rendered it manifests as a general slowness throughout the interaction lifecycle that you can't do much about without adopting different paradigm. The hey-style service-worker based caching hits clear boundaries when the ui is not mostly read only and output of one step very closely depends on the previous interactions.

I joined a place working on larger rails+unpoly+stimulus app which started off as server rendered fragments with some js sprinkled in, but after two years had devolved into a spaghetti where to figure out any bug I'd typically need to hunt down what template was originally rendered, whether or not it was updated via unpoly, whether or not what unpoly swapped in used the same template as the original (often it was not), whether or not some js interacted with it before it was swapped, after it was swapped etc. .... all in all I felt like if you push this to use cases where lot of interactivity is needed on the client, it is better to opt for a framework that provides more structure and encapsulation on the client side.

I am sure good disciplined engineers will be able to build maintainable applications with these combinations, but in my experience incrementally optimizing a messy spa app is generally more straightforward than a server-rendered-client-enhanced mishmash. ymmv.

Re: Moving from React to htmx

#187

Post by hnbad » Sun, Oct 16, 2022, 10:30 AM UTC

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

If you are a Python team, sure, avoiding JS is a good idea and tools like htmx which let you pretend you're not working in multiple languages while having to memorize a massive API implemented in DSLs bolted onto DOM elements are fine. I've worked with these kinds of libraries in the past and once you can get over the knowledge gap, they can be amazing 80% solutions and solve most of your problems.

If you are either a "full-stack" JS (i.e. server + client written in JS) team or have more than one person specifically working on the frontend, this can just as likely be a massive footgun because you're trading a widely used, well-understood tool with a massive community for a somewhat niche one with a much smaller (but hopefully more dedicated and helpful) community.

Sorry if my assessment of htmx comes across as sarcastic but TINSTAAFL and my criticism would equally apply if the talk was about moving from Angular or Vue. If having to write JS is a drain on your team's resources and you can't change that, yes, try moving away from JS even if it means going down a less travelled path.

EDIT: To be clear: one of the early selling points of React was "it's just JavaScript", referring to how most comparable tools would require you to learn their DSLs to do basic things like a loop. React allowing you to actually use a JavaScript `forEach` or build an array in your render function instead of having a `data-react-foreach` attribute or something like that on an element was a breath of fresh air as tools like AngularJS or Knockout required you to use those and were extremely inflexible because of it (e.g. if they wanted to support filtering they'd have to bake it into the DSL whereas in React you could just do an `if` or `.filter`).

Re: Moving from React to htmx

#188

Post by 8organicbits » Sun, Oct 16, 2022, 10:34 AM UTC

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?

People certainly unify their stack on JS that way. For Contexte their team was one React/JS dev, two Django/python, and one full stack. So they had two and a half people writing python and one and a half writing Javascript before, then three python developers after.

Switching to JS would require a full backend rewrite. The backend devs may not do well with the switch, so they may have let go two developers and needed to hire a new JS dev. The presenter may have been let go with that approach, clearly not ideal for the person driving the project.

You'd also need to address the perf issues. htmx clearly sped things up. Is the alternative JS SSR?

Re: Moving from React to htmx

#189

Post by hnbad » Sun, Oct 16, 2022, 10:34 AM UTC

wwweston wrote: post #146

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…

> you start making the assumption that the client's internet is fast. The most common trajectory for react and other SPA framework apps is to also make this assumption, waving away the weight of libraries and front-end business logic with talk of how build tools are stripping out unused code so it must be light, while frequently skipping affordances for outright network failure that the browser handles transparently,…

I think you're talking past each other: the problem isn't assuming the client's internet is fast, the problem is assuming the client's internet is stable.

If you replace most interactions that could be resolved client-side with a network transaction, you're betting on the client's internet being not just reasonably fast but also very stable. When I'm on the go, my internet is more likely to be fast than stable.

Re: Moving from React to htmx

#190

Post by brodock » Sun, Oct 16, 2022, 10:38 AM UTC

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…

If the internet is slow it will be horrible for the user on first load to download a full blownup JS bundle. It will also not removr the fact that any resource change will require a roundtrip to the backend and back forth