Hacker News Reader

Comment by 0x3f | Hacker News Reader

The thing is React is usually fine, and even if you don't have to build _this_ thing in React due to simplicity, why bother learning two paradigms when you can just use the heavier one for everything and most likely never encounter any real practical showstopping issue?

View on HN

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. proprietary IDEs and text editors.

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.

My current app is a boring SPA. SSR, RSC wouldn’t make sense for it. My previous app was a video player with UI drawn in React: couldn’t SSR that.

> you can just use the heavier one for everything

Because people don't like using heavyweight solutions needlessly. That's the logic that begat C++ and Ada and Multics and ASN.1 and CORBA. All of which were good solutions useful for "everything" in their domain. But people hate them, mostly.

Historically big "everything" solutuions end up losing in the market to lighter weight paradigms with more agility and flexibility. Almost every time. React[1] was such a solution once!

[1] Which really is a shorthand for "modern node-based web development with tens of thousands of npm dependencies and thirteen separately-documented API and deployment environemnts to learn".

The thing is most of us have jobs where we can't unilaterally switch to the 'cooler' solution, and I value my own context-switching overhead much more than I value a slightly smaller bundle or dep tree. I'll much sooner optimize the former than the latter and so the general purpose solution that will solve both my own projects and the work ones typically wins.

> The thing is most of us have jobs where we can't unilaterally switch to the 'cooler' solution, and I value my own context-switching overhead much more than I value a slightly smaller bundle or dep tree.

And this is how your company ultimately loses in the market. For every bloated incumbent you will get a snappy new competitor. Keep saying 'it's not worth it to try new stuff', right until you finally realize you never learned anything new and now your company made you redundant.

> most of us have jobs where we can't unilaterally switch to the 'cooler' solution

Which is exactly why the uncool solutions persist in the market. They're useful and practical! If they weren't they never would have been successful at all. I'm just saying that that this is fundamentally the logic of the frumpy old curmudgeon, and the kids will always have something better to offer along with their confusing new ideas.

And to be clear, I'm also just saying that as someone looking in from the outside (I do firmware!) the front end webdev developer onboarding story has long since jumped the complexity shark and things are quite frankly an impenetrable disaster ripe for disruption.

> why bother learning two paradigms

Objection. Your React is ultimately turning into HTML so you DO have to learn HTML + CSS. You just have an abstraction over it.

That's like saying my C# is getting turned into CLR bytecode, so I do have to learn CLR bytecode because I have an abstraction over it.

Yet I know roughly what it is, but I couldn't begin to actually write the stuff myself.

Good abstractions mean you don't have to worry about the layer below.

Now of course it's not really the case that React holds up to being a good abstraction, especially when it comes to CSS and styling, but I don't think it's a forgone conclusion that abstractions force you to learn the level below.

Otherwise we'd all spend half our time learning assembly.

I do have sympathy though for a developer who just wants to focus on the higher level paradigm and let the library maintainers worry about the innards.

React is an abstraction over UI state, not the platform (ie HTML/CSS). This is by design and non-parallel to C#/CLR case. If you want something akin to this, then Flutter is what you should be looking at.

> That's like saying my C# is getting turned into CLR bytecode, so I do have to learn CLR bytecode because I have an abstraction over it.

For a good part of your career this is true, but eventually you will need to justify your senior salary by being able to debug react via looking at library code itself, or understanding the event bubbling under the hood, or figure out why the output css isn't working.

Saw a video, wish I could remember who, someone developing a game in c-something. There was some bug they couldn't figure out so they jumped into I guess the assembly for that block of higher abstracted code, and was able to find some kind of memory issue. Vague, sorry, but point is I remember being really impressed, thinking oh shit yeah if I really want to be an expert in my field I better be able to really understand my stack all the way to the bones.

> That's like saying my C# is getting turned into CLR bytecode, so I do have to learn CLR bytecode because I have an abstraction over it.

That's not a valid analogy, 99.99% of C# developers never see or touch CLR bytecode, where every React developer is still working with HTML+CSS.

That's possibly true, but I wonder why react as an abstraction fails to deliver that kind of independence.

In theory, react developers ought to be able to code against the react API in typescript, without seeing the "raw" HTML+JS that gets delivered to the browser.

So what's failing those developers? Is it the tooling, the abstraction itself, or something else?

> So what's failing

You're failing to understand the difference between react and react-dom.

> be able to code against the react API in typescript

https://github.com/chentsulin/awesome-react-renderer

Off the top of my head, C# is both the language & the runtime. React only throws things over the fence to browsers.

Probably helps a lot to keep abstractions from leaking.

That seems like an odd take. I don’t know that anyone ever intended React to completely insulate you from the actual UI framework (HTML/CSS in this case). You’d have to reinvent a whole new set of layout and styling features. Why would you bother? React is for orchestrating your use of the UI framework, not for replacing it.

That just makes HTML/CSS part of the React paradigm though. You can still use all those features in a React app, after all. The 'new paradigm' to learn with HTMX is how it does reactivity/interactivity.

This featured article is about HTMX not HTML. Ofc everyone working in the FE should know HTML/CSS

honestly both the react haters & the htmx haters are wrong on this

if you care about have a solid UI, you should learn everything

you should learn css, react, svelte, vue, rails, tailwind, html

if you don't and you say you actually care about your UI, your opinion is actually irrelevant

React (and Angular) is an MVC framework pushed on top of a MVC framework in the backend. Why make things so complex?

Performance

Reply on news.ycombinator.com