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

61–70 of 224 posts

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

#61

Post by Izkata »

bbg2401 wrote: post #58
ko27 wrote: post #52

Earlier quoted context omitted.

> the average device and connection is insanely faster than 10-15 years ago Using the same reasoning, I’d come to the opposite conclusion. Devices are much faster than they were 10-15 years ago, but network latency is still roughly the same because physics limits how much it can improve. So reducing network round trips matters more than ever, which favors SPAs over MPAs.

I’m not sure I follow. SPA’s tend to require more network round trips, sometimes significantly more based on the architecture.

But a lot of the time they can happen in the background where the user doesn't see them, or on a part of the page the user isn't currently interacting with, preventing it from being a stop-the-world interruption.

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

#63

Post by robertlagrant »

epolanski wrote: post #56
shooly wrote: post #54

Earlier quoted context omitted.

> React/Vue/etc solve a specific problem: single-page application That's not true. They solve the problem of requiring separate code paths for interactive elements - one for initial render and another for updates. Previously the server rendered the initial HTML and then client JS updated it after e.g. user clicks a button, but with React/Vue/etc., it's merged into one code path because HTML is derived from the curren…

> A Single-Page Application (SPA) is a web application or website that loads a single HTML page and dynamically updates its content as users interact with it, rather than loading entire new pages from the server. That's the definition, I didn't made it up. And those libraries solve that. Your other definition, can be fully implemented server side, Elixir's Phoenix does that. But it's not the only one.

> 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 your website and other consumers, e.g. any native mobile apps or third party API consumers

- you can write tests for your frontend, e.g. you can unit test components' behaviour and style in isolation

- the frontend can also work, or at least respond usefully to the user, when the network or the backend are not working

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

#64

Post by shooly »

epolanski wrote: post #56
shooly wrote: post #54

Earlier quoted context omitted.

> React/Vue/etc solve a specific problem: single-page application That's not true. They solve the problem of requiring separate code paths for interactive elements - one for initial render and another for updates. Previously the server rendered the initial HTML and then client JS updated it after e.g. user clicks a button, but with React/Vue/etc., it's merged into one code path because HTML is derived from the curren…

> A Single-Page Application (SPA) is a web application or website that loads a single HTML page and dynamically updates its content as users interact with it, rather than loading entire new pages from the server. That's the definition, I didn't made it up. And those libraries solve that. Your other definition, can be fully implemented server side, Elixir's Phoenix does that. But it's not the only one.

You said, that React/Vue/etc. solve a specific problem: SPAs - that's not accurate. That's not the problem they solve.

According to what you said, CSS also solves the problem of making an SPA because you could "switch pages" by changing CSS class names on `body`. But if someone asked what CSS is you're not gonna answer "you use CSS to make an SPA", even though _technically_ you can use it to make an SPA.

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

#65

Post by wwweston »

prologic wrote: post #23

I basically use HTMX for all my Web Apps, including PWA(s) that run as ~near native apps on iOS/Android. It's great! I aso pair this with DaisyUI+TailwindCSS. YOu really can't go wrong, there is something quite pleasant about writing your web apps in ordinary HTML with partials and the extensions that HTMX adds to the browser for SPA-like interactivity.

How does the PWA work offline with HTMX? The “hit the server for fresh markup fragments” approach seems like it has to be abandoned here, however simplifying it is for online apps.

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

#66

Post by [deleted] »

ko27 wrote: post #52
epolanski wrote: post #48

Earlier quoted context omitted.

> The only properly dynamic SPA-like feature in a forum I can think of is a WYSIWYG editor, but that you can build as a web component. Maybe a flexible highlight and quote system would be a bit difficult in pure HTMX (think of the comment functionality in Medium posts). So you'd want to build a few things in client side JS. But the main experience could very well be built with HTMX. That's how interactivity has alway…

> the average device and connection is insanely faster than 10-15 years ago Using the same reasoning, I’d come to the opposite conclusion. Devices are much faster than they were 10-15 years ago, but network latency is still roughly the same because physics limits how much it can improve. So reducing network round trips matters more than ever, which favors SPAs over MPAs.

[deleted]

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

#67

Post by ko27 »

bbg2401 wrote: post #58
ko27 wrote: post #52

Earlier quoted context omitted.

> the average device and connection is insanely faster than 10-15 years ago Using the same reasoning, I’d come to the opposite conclusion. Devices are much faster than they were 10-15 years ago, but network latency is still roughly the same because physics limits how much it can improve. So reducing network round trips matters more than ever, which favors SPAs over MPAs.

I’m not sure I follow. SPA’s tend to require more network round trips, sometimes significantly more based on the architecture.

It’s in the name: an MPA requires a page roundtrip for every navigation, while SPA requires a single page roundtrip. Any subsequent requests are part of the application itself and can be handled without disrupting UX.

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

#68

Post by infamia »

asdfsa32 wrote: post #32
prologic wrote: post #24

Earlier quoted context omitted.

I've found this to not be true at all. You can do quite a lot with just HTMX. Any client-side Javascript™ you strictly need can often be done fairly minimally with Locality of Behaviour (LoB).

LoB isn't going to reconcile Chat Messages rendering state and Notifications. Their dependent state by nature. HTMX largely seems to ignore this reality. In fact, the complexity of Chat Messages and Notifications synchronisation is one of the prime reasons why React exists.

> In fact, the complexity of Chat Messages and Notifications synchronisation is one of the prime reasons why React exists.

SSE is perfect for chat/notifications and is a lot simpler than syncing. The server pushes updates to the client doesn't require a sync. SSE is also more performant since it can keep the connection open. The example below is on a $10 vps last I heard.

https://data-star.dev/examples/dbmon

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

#69

Post by JSR_FDED »

asdfsa32 wrote: post #15
xutopia wrote: post #12

Earlier quoted context omitted.

Sounds like you never worked on complex HTMX systems. They're easier to maintain, allow for easy caching of HTML fragments in a page. For higher traffic pages React just fails spectacularly.

How does React fail for high traffic pages? It is amazing that you would suggest I don't understand HTMX "systems" and then go make such assertion. I have been writing frontends since early 2000. So I have seen it all, from activex being shinny to jquery, mootools, backbonejs, angular 1.0, php, Java Spring, Go. I looked into htmx and it is very much a second attempt at angular 1.0, which I did use for some good half…

If you really think HTMX and Angular 1.0 are equivalent then…actually I don’t even know where to begin.

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

#70

Post by hazrmard »

Using Django w/ frontend frameworks has been a struggle for me. (I only dabble as a hobbyist.) I think splitting the backend off into a restful API makes the marriage work. I've looked at django-rest-framework (https://www.django-rest-framework.org/) and django-ninja (https://django-ninja.dev/). Of course,, then you're discarding a lot of batteries that come with the django framework. Perhaps using Django templates for admin / internal facing work only, and React for customer-facing sites can be a healthy compromise?
Post reply on HN