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

21–30 of 224 posts

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

#21

Post by snorremd »

I think HTMX is a great fit for forum software. Forum websites mostly deliver non-interactive content in the form of text and maybe some audio, video, or image content. All of this can be represented as HTML and CSS.

With HTMX you can do partial rendering and live updates via server-sent events. This gets you most of the way to the "client side" feel where things load dynamically based on user actions.

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.

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

#22

Post by asdfsa32 »

wild_egg wrote: post #19
asdfsa32 wrote: post #15

Earlier quoted context omitted.

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…

As someone who wrote a lot of angular back in the day, and who writes a lot of htmx in the current day... That comparison makes absolutely no sense. The only thing the 2 have in common is the use of HTML attributes for functionality. Completely different on every other axis that matters.

It is different in that some of what happened on the frontend now happens in the backend, but overall, it is the exact same approach, so as I said in a sibling comment, it, it is just a second attempt at angular 1.0 with even more naive assumptions about web.

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

#23

Post by prologic »

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.

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

#24

Post by prologic »

skeptic_ai wrote: post #17
sgt wrote: post #6

Happy they did this. Htmx is a great fit for server rendering - which in many or most cases is what you should do in any case. You can always put a mini VueJS or ReactJS app inside of a template for a very custom interactivity.

That’s basically a massive hack. Every real world app will need enough js that htmx will require you to put js on front end and you’ll need to hack it together. Just like we did php+js 15 years ago.

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).

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

#25

Post by ifwinterco »

xutopia wrote: post #12
asdfsa32 wrote: post #5

Great, now you can't offload your FE to a CDN. But on serious note, htmx is basically a solution in the search of a problem. It is the new hype. Or rather, a solution that overlooks 2 decades of learnings. Yes, for a small set of projects htmx is okay, but even then, where htmx is ideal, static is king, and once static is not good enough, htmx sooner or later starts to feel like the XAML and BPEL soap. The fundamenta…

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.

Why would react fail for higher traffic pages?

If it's a traditional React SPA, you can use a versioned bundle with immutable caching and each user only has to download your bundle when you release an update or they use a new browser. You will need to think about how you handle spikes in traffic when you do a release, but even then users won't all load your page immediately after you bump the version.

Most of the time (existing user using the same browser, no update) there will be precisely zero traffic to your servers to load the React app except for the initial HTML skeleton.

For an app using SSR it's more complicated and I'll admit I don't know how that works at very high load

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

#27

Post by officialchicken »

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…

Being a curmudgeon is not good engineering leadership. "Seeing everything" is just old people being wistful, not actually contributing or doing in the now. I deployed (via ftp) my first site before Netscape so I do understand where you're coming. There isn't at present a valid or detailed criticism of why X won't Y based on all of that supposed XP - so why mention it? Educate us - why will it fail? Is it because you never mastered CDN's or the exact opposite? It certainly doesn't lead any credibility the assertion that A will become Z because they look similar or embrace similar ethos.

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

#28

Post by asdfsa32 »

officialchicken wrote: post #27
asdfsa32 wrote: post #15

Earlier quoted context omitted.

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…

Being a curmudgeon is not good engineering leadership. "Seeing everything" is just old people being wistful, not actually contributing or doing in the now. I deployed (via ftp) my first site before Netscape so I do understand where you're coming. There isn't at present a valid or detailed criticism of why X won't Y based on all of that supposed XP - so why mention it? Educate us - why will it fail? Is it because you…

You need to read things in the context, Chicken.

But I will answer your main questions since your comment seems to be in good faith.

Just like angular 1 choked on complex, high-frequency UIs, HTMX is going to follow the same faith. Github uses a similar approach to HTMX and you will find that even for such a simple system, their notification indicator elements on the same page are often out of sync.

The reasons for this is that State Management is hard, which is why the reconciliation loop of React-like frameworks and shadow-dom does away with pushing complex state management to user application and handles it systematically.

Of course, this doesn't mean htmx is useless, for a specific case of web apps, it is good enough, but the problem is that often times, you start with "specific cases" and your application grows overtime.

So when you consider that and the cost of doing htmx vs React or any react-like framework, picking htmx is only reasonable if it is the only option you're comfortable with and rarely on merit.

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

#29

Post by monooso »

asdfsa32 wrote: post #14
dajonker wrote: post #8

Earlier quoted context omitted.

This feels like an uninformed, generalized opinion from someone with zero experience on the topic. Have you even used HTMX or a similar approach? Besides the memes, it is absolutely not hype-driven, but hypermedia driven. It asks the question: could HTML be even more powerful than it already is? The creators of HTMX even want to standardize core ideas of HTMX into the official HTML specification: https://triptychproj…

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. Hypermedia is what to web apps what XML is to programming languages. We have tried HTMX as a concept many times over, there is nothing new here, and like everything declarative, sooner or later it will fall short and you're going to reach for escape hatch…

> Hypermedia is what to web apps what XML is to programming languages.

I have no idea what this means. The World Wide Web itself is quite literally hypermedia.

The fact that a lot of front-end frameworks appear hell bent on ignoring this fact doesn't make it any less true.

> Again, the reason we have finally stabilised on JSX is because you can't really "Declare" away HTML or sophisticated data and event management...

You may have stabilised on JSX, "we" have not. React is one way of building web applications. It's appropriate for a certain subset of highly interactive SPAs, and completely inappropriate for many other things.

Post reply on HN