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

81–90 of 224 posts

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

#81

Post by egeozcan »

toddmorey wrote: post #73
Pxtl wrote: post #71

Earlier quoted context omitted.

> Forum websites mostly deliver non-interactive content I'd say that "Endless Scroll" is a good example of something that is... well maybe not interactive but still breaks the "just an HTML document" page metaphor that plays nice with such things. Now, personally I find the UI compromises it takes to make endless scrolling happen are abhorrent (like not being able to ctrl-F or export the page content). But other peop…

Nope, HTMX could power endless scroll features if you want them

Yes but then you're doing HTMX not HTML and at that point why not use something that's more flexible. I'm saying this as a person who still maintains a small application done with Intercooler.js and is perfectly happy with it.

If you want basic interactivity, HTMX is fine.

If you want something more (like sortable) I'd reach for lit instead of adding the Sortable.js dependency, something the HTMX docs suggest ( https://htmx.org/examples/sortable/ )

And yes there are also some scenarios that you want to control the whole routing and rendering stuff, then go for Solid, React, Angular, Vue, whatever.

There is no golden rule to all of this but finding out what makes sense is a fun exercise.

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

#83

Post by jimberlage »

Pxtl wrote: post #71
snorremd wrote: post #21

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 prope…

> Forum websites mostly deliver non-interactive content I'd say that "Endless Scroll" is a good example of something that is... well maybe not interactive but still breaks the "just an HTML document" page metaphor that plays nice with such things. Now, personally I find the UI compromises it takes to make endless scrolling happen are abhorrent (like not being able to ctrl-F or export the page content). But other peop…

I first learned about endless scroll in a Ruby on Rails meetup, where the presenter was showing how to craft snippets of HTML with ERB and using a bit of JS to insert them below the existing entries. It's definitely possible.

Maintaining a code path with a snippet for each possible viewing experience, back when REST was all the rage, was a bit obnoxious though.

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

#84

Post by pelagicAustral »

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…

> hot take > 70-day old account > relentless contrarianism

steer clear.

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

#85

Post by zuzululu »

butz wrote: post #50
thrownaway561 wrote: post #35

This happened 3 years ago... wondering what makes it news worthy today?

We need a follow up, how this change panned out, how much did performance improve?

most people i know that bought into htmx went back to react after they couldn't manage the spaghettification

although i wonder if LLM changes things

i am interested in moving away from React but its also what LLMs know infinitely more of than HTMX

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

#87

Post by ErroneousBosh »

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.

What I've found in practice is that HTMX is extensible enough that I can write a small amount of javascript to "put a funny plug on the end of HTMX" to talk to say Leafletjs if I'm drawing maps, and want things dynamically updated.

It works quite well, and saves me an awful lot of tedious mucking about with other stuff.

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

#88

Post by jfengel »

monooso wrote: post #29
asdfsa32 wrote: post #14

Earlier quoted context omitted.

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

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

I think he's saying that the Web is hypermedia plus Javascript, rather than just hypermedia. Which means, from the standpoint of the power of hierarchy, that it's Javascript, which also happens to use some hypermedia. Even if you use only a tiny bit of a Turing-complete language, Turing-completeness defines what your system actually can do.

This makes the Web fundamentally awkward, because most of the behavior is defined by the hypermedia part, and users have inconsistent expectations for what happens when you break the illusion.

HTMX works by extending the illusion. JSX works by breaking the illusion earlier rather than later.

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

#89

Post by shooly »

recursive wrote: post #80
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…

Only react "solves" that. In vue component setup only runs during mount. Update is not a thing in the way react has it.

The point is that there's only one template and DOM is derived from that template. This concept is the same in both Vue, React and other popular component-based UI frameworks.

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

#90

Post by snorremd »

egeozcan wrote: post #81
toddmorey wrote: post #73

Earlier quoted context omitted.

Nope, HTMX could power endless scroll features if you want them

Yes but then you're doing HTMX not HTML and at that point why not use something that's more flexible. I'm saying this as a person who still maintains a small application done with Intercooler.js and is perfectly happy with it. If you want basic interactivity, HTMX is fine. If you want something more (like sortable) I'd reach for lit instead of adding the Sortable.js dependency, something the HTMX docs suggest ( https…

I don't necessarily disagree that there comes a point at which you are working more against HTMX than with it. I think rather than measuring that contention point between HTMX and SPA/MPA in terms of interactivity I'd measure it in the amount of client side state and logic needed. If you need a bunch of client side state and logic, for example a digital audio workstation, then a SPA would definitely be the appropriate pattern.

But interactivity in largely content-driven sites doesn't necessarily preclude HTMX. You can do a bunch of fancy interactive stuff with HTMX and some minimal JS. Drag and drop sort is a tiny drop-in JS snippet. Skeleton loaders and spinners are supported out of the box in HTMX as is infinite scroll as others pointed out.

I'm not saying Next.js, Solid Start, Remix, Nuxt or some other hybrid server and client rendered model doesn't work for forum software. Or that even client only rendering can be a valid approach if you accept the trade-offs (no curl-ability). People should use whatever they feel productive building with.

But if your backend is already a non-JavaScript server rendered framework like Django then HTMX makes a ton of sense to add some interactivity.

Post reply on HN