Absolutely! I am killing a huge React app step by step and replacing it with HTMX.

Best thing I did in many years for that project.

I often read these threads on HN and they make me feel like that I am perhaps a horrible software engineer or just weird…

I _like_ building things with React.

I think it's really context dependent. If you've been banging your head against the wall working on a poorly architected React codebase for years, anything else probably feels like a breath of fresh air.

If you have a nice codebase with good separation of concerns (that everybody adheres to) and reasonable library choices, you'll be happy regardless of what framework you're using.

as long as you like it, keep using it! I wouldn't try to make generalizations from the HN or reddit bubbles.

I dislike all the warts of React, all the rules that fail at runtime... If hooks and the rules of them would be enforced at compile time, it could be great.

I prefer solid

Honest question - have you ever tried to use the actual web components API? It very much feels like a set of primitives to build a framework on top of. I can't imagine the amount of boiler plate you would need to write to just use web components.

With a simple 500-line lib you can write Web Components just like React, here's an example: https://github.com/wisercoder/uibuilder/blob/master/WebCompo...

Right and Lit is that exact framework and it’s amazing.

State management for smaller vanilla JS projects that works 9/10 times for me:

    const state = new Proxy(
      {},
      {
        set(target, property, value) {
          target[property] = value;
          renderUpdate();
          return true;
        },
      }
    );

I'm only 1/4(.0000000004) serious here. That said, I've been doing this for almost 30 years, I was a kid when I picked up Netscape, I have gone through every mainstream and many niche libraries/languages replacing libraries. Now, in my late 30s I finally can grow a moustache (a big achievement in my family gene pool) but the analysis paralysis is still making me anxious every time I pick up a new project.

- preact w. signals or Svelte are still my libraries of choice if I need to spike something, but that's partially because of signals and vite. The development experience is good, there isn't much magic you need to deal with on a daily basis.

- Web Components are great in many ways, but they don't solve the problems I usually have with bigger projects (scaling state, orchestration for the lack of a better phrase). Lit makes it a bit better though.

- JSX is actually not that bad, as long as you treat it as a DSL around functional composition. Native JSX + signals would probably make most of my node_modules redundant.

(please don't overthink this, I didn't)

What most people need is good routing solution but it’s hard to make it with SSR. Seems like frameworks are somewhat converging now on this app router concept.

Agree that JSX is great (but styles like in Svelte also).

> Agree that JSX is great (but styles like in Svelte also).

Oh yeah, 100%. One of the reasons I like Svelte are colocated CSS modules.

> seems like frameworks are somewhat converging now on this app router concept.

That for sure, and signals in one way or another. It took us 10+ years, Solid.js then preact to bring back a pattern from 2010s (IIRC) implemented in Knockout.js.

People are talking about declarative signals in HTML. I don't have a formed opinion about them yet.

If you want your own Web Components, you're going to build an entire framework around the creation and management of them because making proper 'web components' for your project is in effect a whole other project

I really have not liked htmx at all. Anything dynamic with it is a big, big pain...

IME a lot of the pain comes from picking the wrong tool for the layer.

By that I mean saying everything has to be a JS framework or everything has to be server-delivered-HTML.

For very dynamic & interactive things maybe it makes sense to write it just in JS without a framework?

For full pages for data-powered applications (that heavily benefit from types & Typescript), maybe it makes sense to use something like Golang on the server.

And then you can embed those interactive dynamic islands inside the data-intensive application, with a thin layer of communication between the two.

Just my 2c - I've found that pattern to be super compelling

I agree but the dominant view is that everything has to be a SPA and having some html delivered by the server is considered bad.

I agree. I really wanted to like it, I do think a lot of what it purports to try to do would be better for the web and development in general, but my experience is that HTMX (even with Alpine) fails to succeed in practice.

Use Alpine for dynamic client-side. Htmx is focused on talking with the server.

I should have clarified that yes, I used Alpine with htmx.

How is Blazor not a JS framework?

Using blazor as an example of sane web development is so odd to me. Have you actually used it? Not only is it a mess in terms of development (live reloading basically does not work, you either depend on SignalR and your website becomes unusable the second you lose connection, or use wasm and have a terrible mess of a canvas based frontend that barely works), but it's also terrible for users.

I know hating on frontend dev is trendy, and I guess blazor is the logical end to that aversion to actually using frontend tools, but if anything it's the perfect example to show how much worse web dev would be without JavaScript frameworks. There's a reason it's only used for internal tools.

I'd take any react+JavaScript "bloated" websites over this. Especially on mobile. https://bootstrap5demo.blazorise.com/

That last one is a big stretch. Blazor is uhh.. not pleasant to use