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

Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

misago-project.org

Post reply on HN
Print view View original

201–210 of 224 posts

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#201

Post by robertlagrant »

throwaway7783 wrote: post #125
robertlagrant wrote: post #63

Earlier quoted context omitted.

> That's the definition, I didn't made it up. Your prior claim was that they only solve one problem, not about a definition. They solve several problems: - less data can move over the wire compared to sending a full page every time (this is in your definition, and is definitely not always true, as sometimes REST APIs can return far more data than what's needed to render the screen) - the same REST/data API can serve…

That second point is almost never true " the same REST/data API can serve your website and other consumers, e.g. any native mobile apps or third party API consumers" In a reasonably complex application, each interface ends up needing its own shape of optimized APIs. Otherwise the clients become very complex munging/reshaping data or making too many API calls, throwing away a lot of data etc.

Fair point, yes.

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#202

Post by HackerThemAll »

james2doyle wrote: post #91

I actually tried to use HTMX on a site recently. I used the 4.0 beta. The site needed an interactive filterable product-listing-page-type experience to list out all their vendors. Form filters on the left and the list of results "cards" on the right. The problem I had was that the entire experience became really slow when I had it all working together as one "response". Sending back all that HTML for an entire form w…

You can bring anything to its knees when requesting too much data at once. There's always another bottleneck. Getting all data in a single request is an antipattern to me. Fetching a lot of data unless absolutely necessary with no other option is an antipattern to me. But that of course is relative to a specific purpose.

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#204

Post by Elzair »

james2doyle wrote: post #91

I actually tried to use HTMX on a site recently. I used the 4.0 beta. The site needed an interactive filterable product-listing-page-type experience to list out all their vendors. Form filters on the left and the list of results "cards" on the right. The problem I had was that the entire experience became really slow when I had it all working together as one "response". Sending back all that HTML for an entire form w…

For some reason this subthread reminds me of the old joke about how to get Linux tech support. https://www.reddit.com/r/ProgrammerHumor/comments/7p88zj/ask...

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#205

Post by sjoedev »

foxygen wrote: post #171
sjoedev wrote: post #160

Earlier quoted context omitted.

Sure. I personally think SPAs/React have better DX than HTMX. IMO, the most compelling reasons to use HTMX instead (for building dynamic/interactive web applications) are to reduce the amount of JavaScript sent to the client and make pages become interactive faster. These are UX concerns: how much the user has to download (waiting) and how long before the page becomes interactive (waiting). With HTMX, you get these b…

> the most compelling reasons to use HTMX instead (for building dynamic/interactive web applications) are to reduce the amount of JavaScript sent to the client and make pages become interactive faster Next.js and TanStack Start don't send any JavaScript to the client if you decide to server-render everything. The upside is that you can opt-in into client-side components, and have all the interactivity benefits of Rea…

> Next.js and TanStack Start don't send any JavaScript to the client if you decide to server-render everything.

AFAIK, this isn’t true. And you still get more JS per interactive element than with HTMX.

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#206

Post by asdfsa32 »

sgt wrote: post #199
asdf88990 wrote: post #151

Earlier quoted context omitted.

What is the main difference?

The main difference is that htmx is server driven, and it's HATEOAS (hypermedia driven). Angular was always client side only with data binding and state management. So as far as frameworks go, they are pretty much as different as they come.

Where code runs is a small, albeit important, part. Whatever you use "Hypermedia" or JSON to communicate the state is only part of the story. What makes HTMX a second attempt at Angular 1.0 is in how it handles mutating the HTML, you know, the key aspect of a web app. Splitting some of the FE to backend to allow room for the spaghetti we had back in the CGI/PHP day isn't a win.

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#207

Post by asdfsa32 »

wild_egg wrote: post #169
wredcoll wrote: post #127

Earlier quoted context omitted.

> If you have separate state on the client that needs to be managed, you are going to have a bad time regardless of framework. Yeah, because clients never need to keep track of state like which block is expanded or which tab is selected or that the previous page was or what the user is currently typing...

Every one of those are things that the browser manages for you if you are using semantic markup and embracing web standards.

This is a pipe dream. Browsers have come a long way but they're largely still broken in many many ways.

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#208

Post by asdfsa32 »

gulugawa wrote: post #186
asdfsa32 wrote: post #46

Earlier quoted context omitted.

The only nonsense here is ignoring that React.hydrate have existed since React 0.4 (2013, that is over 13 years ago) and Gatsbyjs was released over a decade ago around 2015. The gist of it continuously seems to be that people who think HTMX Great, know very little about good frontend engineering.

One key part of good frontend engineering is picking tools to effectively solve current challenges your product is facing. Thinking about theoretical problems that may not apply to you is a waste of time. I don't currently use use HTMX. However, that doesn't invalidate the use of htmx by others when it is a better fit for their experience and use cases.

htmx is no more invalid than Visual Basic, and the parallels goes deeper than that.

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#209

Post by wild_egg »

asdfsa32 wrote: post #207
wild_egg wrote: post #169

Earlier quoted context omitted.

Every one of those are things that the browser manages for you if you are using semantic markup and embracing web standards.

This is a pipe dream. Browsers have come a long way but they're largely still broken in many many ways.

Would love to hear about which of those listed examples does not currently have native browser support.

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#210

Post by asdfsa32 »

monooso wrote: post #78
asdfsa32 wrote: post #40

Earlier quoted context omitted.

> You may have stabilised on JSX, "we" have not. Just about any reputable sources puts the combined market share of React, Vue, Angular 2+, and Solid well above 80%. So I am not sure what "we" you are talking about.

> Just about any reputable sources puts the combined market share of React, Vue, Angular 2+, and Solid well above 80%. I have no idea if that's accurate, but let's assume for a moment that it is. - Vue supports JSX, but it is not the default. - Angular does not support JSX. - Svelte, which you neglected to mention, does not support JSX. - Solid does indeed use JSX, as of course does React. So two out of the five main…

I listed frameworks that makes majority of the market share that are based on JSX and react-like reconciliation loop. This architecture is also now dominate in the mobile apps space via React Native and Flutter as well.

So I am not sure what you're talking about. The industry has largely stabilised on this architecture because it works. So I don't know who this "we" you're talking about or what you're even talking about anymore.

Post reply on HN