Hacker News new | ask | show | jobs
by asdfsa32 5 days ago
Putting ReactJS or VueJS for a little interactivity is hardly the correct approach. It makes no sense to bring them in for "a little". What made React and React-like (Angular v2, Vue.js) frameworks stabilise is that they're about the right abstractions and everything else for managing dynamic html converges to about the same thing.
3 comments

Why not? You can have server side routing that returns the page and then react then takes over and hydrates a small part within the page or the complete page. A similar approach is used for the islands architecture, and you can even combine different frontend frameworks for maximum flexibility, e.g. developer preference. You can decide to load your frontend libraries lazily or as shared scripts so they are cached and only take up some bandwidth on initial load (a couple of kB minified and zipped).
An islands architecture can be implemented with web components when hydration is needed.

Writing vanilla JS to manage state and backend data loading can be done with a script that is less than 2kB zipped. The script can then be reused.

At that point, gzipped Preact is only 1k larger (and 10k smaller than htmx) and provides a pretty comprehensive and common set of solutions to the majority of front end problems compared to hand rolling everything.
In principle I agree that putting React or Vue in for a little interactivity is a bad approach, if the same can be achieved with Htmx, which it usually can.

However for some really complex mini apps, that's another story. But for the rest of those CRUD pages, you can go simple server side rendered.

"Complex mini app" is one hell of a concept.
It can be. Think something like a file viewer or a text editor, or a music players. You can probably make do with vanilla javascript, but there’s some threshold where using react to take care of the state<=>ui relationship is worth it.
A text editor or music player is hardly "mini".

Again, the issue with htmx is that it pretends like it is not a framework, when in fact, it is just a second attempt at angular 1.0, with even more naive assumptions about web apps.

> A text editor or music player is hardly "mini".

If it's a sub-function of a bigger ensemble that mostly dies something else then it's fine to call them “mini apps”.

For instance a bank app may contain a text editor for the internal messaging feature of the app, that would count as a min-app in that context.

Having adopted Angular 1 back when it was new, I can promise you it's completely different than Htmx.
What is the main difference?
Astro then.