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

Please just try HTMX

pleasejusttryhtmx.com

Post reply on HN
Print view View original

291–300 of 530 posts

Re: Please just try HTMX

#291

Post by ramon156 »

> Option B: React (or Vue, or Svelte, or Angular if you're being punished for something).

> And suddenly you've got:

> A package.json with 847 dependencies

> A build step that takes 45 seconds (if the CI gods are merciful)

> State management debates polluting your pull requests

> Junior devs losing their minds over why useEffect runs twice

> A bundle size that would make a 56k modem weep

No? React is surprisingly small, and if you're in dependency hell then fix that. The alternative is another idiom.

Re: Please just try HTMX

#293

Post by Ciunkos »

There is inherent risk of such low level frameworks over React, that is they allow you to easily blow your foot off, by injecting raw unsanitized HTML back for dynamic execution. A thing that would not work in React apps by default. Even on those demos, you can XSS yourself with the simplest payload, confirming my point.

Re: Please just try HTMX

#294

Post by H1Supreme »

0x3f wrote: post #100
purerandomness wrote: post #40

Earlier quoted context omitted.

The reality of React is that you have to keep re-learning and un-learning stuff if you want to keep up with React's ecosystem, because the surface area of the libraries is so large. (see "JavaScript fatigue") Whereas with HTMX you learn a very, very basic concept in 15mins, and you're good to go for the next decade(s), and it will be more than enough for 80% of your projects. Same as with vim and Emacs vs. proprietar…

I agree that people often do this but I don't think you _have_ to. You could have freely ignored SSR, RSC, etc. and kept on making boring old React SPAs. The churn is largely opt-in.

> The churn is largely opt-in.

It is not. React 18 changed damn near everything. You can't create a new React 17 project without jumping through serious hoops. React 19.5 introduced the compiler, so you can stop using useCallback and useMemo. Except for "common scenarios" where you still need it. Which are about as clear as mud.

I can only imagine what React 20 is going to introduce.

Re: Please just try HTMX

#296

Post by recursivedoubts »

didip wrote: post #285

I love HTMX. It felt like a rebirth of PJAX. Server side template rendering is simply the best. Too bad that the world insists on going nuts with JS everything. Oh as a plus, AI agents are a lot more productive when dealing with server side logic.

huge fan of pjax, interviewed @defunkt here:

https://htmx.org/essays/interviews/chris-wanstrath/

Re: Please just try HTMX

#297

Post by hu3 »

ramon156 wrote: post #291

> Option B: React (or Vue, or Svelte, or Angular if you're being punished for something). > And suddenly you've got: > A package.json with 847 dependencies > A build step that takes 45 seconds (if the CI gods are merciful) > State management debates polluting your pull requests > Junior devs losing their minds over why useEffect runs twice > A bundle size that would make a 56k modem weep No? React is surprisingly sma…

React only renders. You need a lot more than that for an app.

And if you glue packages together you're basically reinventing frameworks. This can be a good thing or a bad thing.

Regardless of your choice between glueing libs or a framework, you'll end up with tons of dependencies for most non-trivial projects anyway.

Re: Please just try HTMX

#298

Post by recursivedoubts »

lynndotpy wrote: post #176
azangru wrote: post #162

Earlier quoted context omitted.

> No Jobs > Another practical reason not to use htmx is that there are, rounding off, zero htmx jobs. > I just did a search for htmx jobs on indeed and found a grand total of two: one at Microsoft and one at Oak Ridge National Laboratory. > A search for “react”, on the other hand, gives 13,758 jobs. > Seriously, developer, which of these two technologies do you want to hitch your career to? I do not advocated for htm…

The evidence is so damning that htmx.org even opted to host it. That's not all- the author of the document is the one who developed HTMX! (In all seriousness, this entire article is facetious and is highlighting the strengths of HTMX. They are not sincerely advocating for 'resume driven development'.)

while the article is tounge-in-cheek, i do think a lot of the criticisms are legitimate

Re: Please just try HTMX

#299

Post by adamzwasserman »

davidhariri wrote: post #155

HTMX is a great choice for an app that only needs forms, validation and partial template rendering, though CSS view transitions are making partials less relevant for server side web applications. For things with heavy interaction (drag and drop, chat etc.), I find the code to make it work with HTMX is just too clumsy to work with as a mental model.

multicardz is heavy drag-drop ui. totally based on htmx (I still need to get data from a backend, I use htmx to do it for a number of reasons.)

Re: Please just try HTMX

#300

Post by ViewTrick1002 »

alfonsodev wrote: post #128
chrisweekly wrote: post #97

Earlier quoted context omitted.

This is where I think Astro shines, with its "islands of interactivity" approach. Keep things as simple as reasonably possible, and provide an idiomatic, first-class mechanism for supporting more complexity where appropriate.

I overlooked Astro for a long time, I didn't really get it, and my journey back to it went something like this: - 1 Getting burned out by Nextjs slowness in a complex production project that shouldn't be that complex or slow on the dev side, (this was 2022 approx) - 2 Taking a break from React - 3 Moving back to classic server side rendering with python and Go and dealing now with template engines. Hyped with HTMX an…

Last time I dabbled in a front-end I tried out Astro but felt like it just added another layer of complexity without much gain when all my components were just wrapping React in different ways. I went with react router instead.

I can see the value of the "islands" concept when you have a huge front-end that's grown over generations of people working on it.

For my constrained front-end debugging Astro errors on top of React errors on top of whatever all the turtles down felt a like a step too far.

Am I in my Rust centered back-end driven brain missing something?

Post reply on HN