Hacker News Reader

Comment by OtomotO | Hacker News Reader

My tip: you start by avoiding React altogether.

It sounds bad, but if you can, do oldschool SSR with HTMX or the like.

It's sooooo much better. I was paid to develop frontends in React for 4 years, I wrote my first website in 2005... I am currently migrating one client project from React to HMTX and it's sooooooooo incredibly much better.

There are less bugs, less footguns with wrongly applied hooks...

If you need to do CSR, use Solid or Vue, but don't do React.

If you have no say in it: good luck!

View on HN

The problem I have with many of such advice: 1) what do you precisely mean and 2) why do you think so.

Do you mean the whole field, so from B2B SPA apps to personal blogs? "If you want to replace jquery, use Vue!" would be more helpful to understand.

The problem is that we don´t know if the advice comes from a "bootcamper" that has only learned Javascript. You know, some people manage to build low-interaction sites that will render a blank page when Javascript is disabled.

The "why" is also of interest to see if the advice is applicable. If not react, then why not preact for instance?

My main dislike for React is that I'm constantly learning React, its intricacies and idiosyncracies.

Disproportionate amount of energy I would rather spend learning JavaScript, something that would last.

Using React since 2013. Each release is an excitement, until I realise some chunk of concepts which altogether took months to fully grasp, are gone. Some even needed to be unlearned.

A lot of abstractions.

React doesn't make you a better developer, it makes you a better React developer.

I don't feel that with Vue. I don't feel that with most libraries I use.

> React doesn't make you a better developer, it makes you a better React developer.

React's pure component functional style translates really well to nearly every other type of software development.

It doesn't necessarily mean that React does it right. When building React apps, developers spend too much time on designing architecture for many things that should have been taken care of by the tools they are using. The more I am in web development, be it backend or frontend, the more I'm disappointed that declarative programming is still not a thing. One too many hours wasted on reducing boilerplate, replacing big boilerplate with smaller boilerplate, optimizing boilerplate and writing that boilerplate. While still being far from perfect, other frameworks like Vue and Svelte do great job at making the developer write less boilerplate and more business logic.

I agree with that, that's not so specific to react. So I kept it to narrating the main problem I and others have with react, which is that feeling that I keep learning the framework for a variety of reasons that I believe are frustrating developers, those who want to be more than react developers.

The non declarative aspect is a problem though, with v19 it now means unbelievably large PRs and time spent to refactor will take place for migrators. Declarative would at least reduce reduce that pain.

Practically every frontend framework uses components. The problem with React is that so many of its abstractions are leaky and forces a lot of accidental complexity on the developer.

Which abstractions are leaky? State is complex. There’s not really a way to get around that.

Dependency arrays are leaky.

How do they leak? Are they even an abstraction?

One example where it's leaky is when you want to memoize something, and now you need to memoize all its dependencies, recursively, and you end up with a 30 file PR.

I say this as a big fan of React, and I'm hoping the compiler turns out a success.

Well, they're part of the effects abstraction. And they are leaking because you have to manually track them. You are already using the dependency variables inside the hook function. And now you need to duplicate them into an array and keep the array updated as your effect hook changes. This is leaky.

There are better deaigned frameworks than React. Solid for example, the api surface area is smaller, there are less things to learn and less chance for bugs.

If I look at an article like this, I have the impression that Solid is in the early process of discovering their own gotchas:

https://vladislav-lipatov.medium.com/solidjs-pain-points-and...

It's nowhere close to pure, in the FP sense. Everything in React is an act around side effects of rendering.

So it's gotta be something else that makes it so popular.

Hooks do a nice job of encapsulating the impurity. Not the only way to do it, but it’s pretty slick.

React keeps changing its abstractions, idioms and best-practices every 2 years. The bootcamps and consultancies LOVE it - it keeps the churn going and the $$ coming in.

> React doesn't make you a better developer, it makes you a better React developer.

React's goal isn't to make you a better developer though. It's goal is to make it easier to build non trivial, stateful applications

which you can also do easily without react and 16Gb node_modules folder :)

Developers' goal is to become better developers.

I think most people arguing against react are against "advanced" ui libs at all. simple dom + a thin porcelain like htmx does help you finish most work duties without having to add a whole paradigme over.

And anecdotally, if your team is not ready/willing to dig in react, all its benefits will fail to materialize, you'll have a bunch of patched up libs and components trying to do what htmx or similar seem to offer (async actions over REST) for just a few lines in your html template.

No bootcamp, university, albeit only a BSc, because I didn't feel like academia afterwards with a full time job and now I've moved on.

9 years of professional experience.

Having worked and paid to do so with Java, Scala, Kotlin, Python, JavaScript, Typescript, Python

Been working with Rust since 2015, have prior experience with C++, had to work with C, Haskell and logic programming (not prolog) at University.

Also did C#, Golang, Lua, Zig and many more.

Does that give more authority to my statement? I sincerely hope not!

Why is this attitude so pervasive? It's akin to writing backend and saying you should avoid Postgres altogether and use text files saved on the hard disk.

How are these two scenarios comparable?

Because both are ubiquitous to the point they basically dominate a large part of a usecase's toolspace.

Sql syntax does not change every month

JSX syntax doesn't change every month either. React itself, as a library, has a great deal of backwards compatibility.

What does churn is the tooling (e.g. abandoning Webpack for Vite). But the actual API and syntax has remained virtually unchanged. You can still write and use class components today. Hooks themselves are nearly 7 years old at this point, with no sign of changing. You are not required to use "server components" or any of the new features in React.

Meanwhile people in this thread recommend "simple" alternatives like Vue that produce breaking changes so massive it splits their ecosystem in half.

I stopped writing React for probably 2 years and now the whole framework is different and I have to relearn the entire thing. Defining a component is completely changed, changing state is completely changed, and the component lifecycle is completely replaced and it feels like the complexity of the framework has gone through the roof. At least for me this is the type of churn that makes me not want to do it anymore.

React is 11 years old (older now than jQuery was when React was first released).

For whatever reason, backend devs can be incredibly precious about their tech stack and rightly or wrongly believe that frontend devs make "silly" choices by not using their preferred stack.

It's a form of technical smugness that pervades this site for any frontend JS thread.

You rarely see frontend devs criticise backend devs on their tech stack.

No it's because I have to maintain the frontend stack and it rots faster than raspberries left on the counter. If you write your frontend like it's 2008 it will continue to function unmodified until the heat death of the universe. And you wouldn't believe how many apps fit into that feature-set.

If you use just React I'll support you until the end of time but haven't seen a shop yet that does. I'm not saying use HTMX, if you have the choice go with just React over HTMX because it's still in flux.

Just React << HTMX < React with Friends.

It's the advice from POODR that's stuck with me forever, an objects dependencies should change less often than the object itself.

There you go, claiming another silly choice by frontend for using something built in the last 15 years will rot.

It's just not true in my experience.

It's not a silly choice, it's a trade-off. One which becomes frustrating the moment the code isn't being actively developed anymore. People choose to use unstable technology all the time for various reasons, it's valid for evergreen codebases where you're continuously updating deps. I argue it's bad if you expect your codebase to be "done."

An unmodified frontend will also function the same exact way until the heat death of the universe.

This isn't really much of an argument. The defining characteristic of a non-rotting codebase is one in which you can update your dependencies and language version every six months or on CVEs with only minor changes.

If you think rotting sounds too negative how about "maintenance unfriendly."

Your argument was about unmodified code, not mine.

If you only want minor changes, don’t install new major versions.

How does that work in an ecosystem which is constantly releasing new major versions and not backporting security fixes to old majors?

For one big reason that complex JS interfaces in the browser aren't needed nearly as much as they are used. Probably only about 10% of the time people reach for React. While databases solve a predictable problem (up to a certain scale).

FE tooling is never a one-size fits all thing like Postgres, but people want it to be (god help you if you have 2 different FE libraries that serve different usecases, even though 90% of the time you just need simple tooltips or a multi-select box that play nice with static server HTML) and the cost is giant, unmanageable, extremely expensive piles of JS where the entire frontend is pushed inside of it.

Definitely agree that a good database solves far more problems than it introduces.

I think the web technology and the kits that sit on it are rather obtuse because they really are swimming against the tide. I commented about VB a few weeks ago and how much better the paradigm was some 30 years ago. But that was a purpose-built tool for programming a purpose-built GUI API. React et al. are still contending with turning typesetting into general purpose software. Despite that, react does a pretty good job.

It's also about know-how. I can go get a programmer literally anywhere that can built something with react, so even problems that can be solved without are going to be solved with it.

No complaints from me, really. Everything is a little excessive. I just came across an app to order ice. I can't imagine that's really making anyone's life easier, except for maybe its developer.

I have 3 complementing theories:

1. Beyond self-learning, there's two types of education. Formal, college education that delves deep to both the CPU level and mathematical proofs of correctness, and coding bootcamps which teach how to do things, but little about how things work.

Frontend isn't taught in formal college education, so there's a big void in industry knowledge. Some people learn about compilers, interpreters, have used GDB and implemented malloc for school, but they aren't the ones doing frontend. Others are doing frontend but never think about memory usage, closure scopes, or garbage collection.

This leads to bad frontend code, that misuses resources.

2. JavaScript long had fame for being a "toy" or "joke" language. I noticed the tide slowly change by the mid 2010s— that's not that long ago.

Proportionally and compared to other technologies, how many engineers have had time to develop long careers, learn from mistakes, and become that serious, dress-shirt wearing, super-senior engineer sitting at the back of the room making sure young developers don't get too unhinged? This proportion is probably especially stark if you consider just how in-demand web development is.

This leads to bad frontend code, that misuses resources.

3. Finally, with the two above in mind, re-writes. Unexperienced teams are the first to opt for re-writes. It's a story as old as time; "we don't know how to fix A, so let's instead build a brand new thing B, which works differently to A and thus won't have its problems".

Re-writes always go well at first, because the fresh codebase will be smaller, faster, nicer and because everyone is especially cognisant of the problems A had, which are very much not present in B since it works differently.

Eventually of course, B grows bigger, and gets permanent hot-fixes, its requirements change, and bugs start to surface that nobody bothers understanding. A is also far enough in the past that nobody is thing about the problems A had anymore, and has more mind-space to notice the problems that are unique to B.

But before that happens, you get this sort of comments.

One of the major mistakes that are made in re-writes is that the developers writing the new code are not always the ones who created the original code. They see complexity, but don't know if it is accidental complexity ("tech debt"), or necessary complexity.

One example from my own experience was a team that inherited a service that had already seen a major rewrite/refactoring to be prepared for requirements that the old team knew with certainty was coming. The new team created a new service that barely covered the needs that the company had at the time, and claimed that the new architecture was flexible to cover any future need (without actually investigating the needs that were already known). When they were tasked with supporting the new requirements, the end result was more complicated and less capable than the old service.

indeed you should avoid postgres if all you need is saving files on a disk. that's exactly the point. people reach for complex client side frameworks when all they need is to render some markup.

If postgres were worse than the alternatives I wouldn't use it.

And React is worse than the alternatives. All it has going for it is the huge ecosystem.

I've avoided React as much as possible. Dabbled (positive experiences) with Vue. What's your recommendation w.r.t. "Components"? I've tried doing web-components from scratch (frameworkless) but nested web components have nasty gotchas.

eg: <todo-list><%for...><todo-item .../></for%></todo-list>

I've poked at `lit`, read through `htmx`, but really what I want is "custom elements" (including visual styling) on the front-end that I can map back to JSON on the backend.

The CSS side nudges towards tailwind (or similar), and modern (raw) CSS has undergone so many feature extensions and new capabilities, it's tough to find a good "modern" guide for building with it.

It just feels like there's a missing piece in-between: `let contact = new LdapContact(...)` and `<contact-summary .../> ; <contact-detail .../> ; <contact-search-result .../>`.

Vue has come closest, and setting aside a super-complicated "WebApp/SPA" with a ton of interactivity... what's a comfortable, modern, low-ceremony way to get to that?

> If you need to do CSR, use Solid or Vue, but don't do React.

Easier said than done.

There're still many high quality libs for React that are not available for vanilla JS or other frameworks. E.g. https://reactflow.dev/ (yes, they have a Svelte version, but not as feature rich).

Vue comes very close, though.

Still no good component or UI libraries for HTMX.

This is the sticking point for me. I get so many gains in Rails but I quickly sink into time-consuming component research/building. My eyes are always open for HTML/JS component libraries along the lines of react-aria.

I've had a great experience using Golang + HTMX + DaisyUI using the tailwind-cli-extra standalone tool, negating the requirement for npm at all.

Can webcomponents be trivially used with HTMX?

Like for example: https://shoelace.style/

Shoelace is great, but not robust. No data table, no date/time picker, no pagination, no sidebar.

Anything that can be loaded as a stylesheet or a script tag works great with htmx. These are not htmx-branded libraries... because they're just web libraries.

Right, but then you are glueing things together and mixing and trying to match CSS so they all play together. AirDatepicker here, tomselect there, datatables here, popper there. All of sudden you lost a lot of time trying to make things look like one cohesive unit, when you should be doing your app.

Meanwhile, I have v0 generate the whole skeleton for me, with composable reusable components, and just got the API done.

Interestingly I did something similar with Claude, asking it to generate tailwind/HTML components instead. And copy/pasting them as Thymeleaf fragments for a java/springboot + htmx project.

Yeah maybe, if you are using all these ready-made components. But with htmx...maybe you won't need to. Maybe you'll just end up using basic HTML widgets and the result will be simple and fast.

That is exactly the point of HTMX. Use your backend stack and sprinkle some hx tags.

Excuse me - do you understand what a component library is? It's a whole framework from element wrappers, styling, animations to pre-made pages, filtering and sorting functions on tables etc. Think MUI, Bootstrap or PrimeNG.

HTMX is just "replace this with response", you'll still have to write all the CSS classes, manually add them to all the elements, do animations yourself etc. I like HTMX, but I am tired of backend and hobby programmers shilling it at every opportunity. Try to write a reasonably complex website with it and give it your friend to maintain and improve. You'll understand why frontend frameworks exist. HTMX sends you back to the HTML-in-PHP ages with homebrew ORMs and what not, because there's no unified way of doing things.

Then something like DaisyUI/HyperUI + HTMX? And depending on the backend you can do components (eg: For Django there is django-cotton and others that help).

Yes, I could use those. But I gotta ask myself:

- will my client have problems finding someone that speaks Czech/Slovak and also knows DaisyUI/HyperUI/HTMX/Django? - are those techs gonna be maintained in 5 years? - what's the bus factor on the techs? Is it several people's project or a one (wo)man show?

All while there's React+<one of the big component libraries> right at your disposal...

Yes, there is a 'unified' way of doing things. In a single backend stack at least. And that way is...make a component library. Using your backend stack. It doesn't have to be HTML-in-PHP era. There are embedded HTML generation libraries for every mainstream language nowadays. You can just use whatever CSS you like and write any components you need. Eg I used Bulma, copy-pasted their HTML examples, and just wrapped them up as components.

If you are bemoaning the lack of prefab component libraries, well that's how backend development goes. Everybody and their dog has a backend stack and HTML generation system they like, and then eventually maybe some component libraries will emerge for the popular ones. That's the tradeoff for the freedom htmx gives you to work in any backend. You write some components yourself. Not the end of the world.

Your first paragraph highlights the issue perfectly. You mentioned Bulma—how many developers have even heard of it, let alone use it regularly? It’s even worse when one app uses Bulma because someone wanted to try it out, another uses Tailwind because it came along a year later, and then there’s a 10-year-old PHP project still stuck on Bootstrap 3.

With something like MUI, everything is where I expect it to be. That consistency lets me focus on learning the business logic, addressing critical bugs, and thus making meaningful contributions.

Sure, you use MUI, someone else uses Ant Design, yet another person uses Tailwind UI, where does it end?! Sheer insanity. So of course, this is a problem only when it happens in the server-driven approach, but not in the client-driven approach :shrug:

Weeeeell debating whether to use one of those 3 UI component libraries you mentioned is IMO pointless, you are gonna be fine with any of them. I was thinking more along the lines of Django vs Rails vs ASP.NET and someone suddenly coming in and yelling "LET'S DO CLOJURE".

In that case someone is gonna come in and yell 'LET'S DO ELM WITH ELM-UI'? No?

True :D

Probably there will never be, that's like saying "Still no good component or UI libraries for HTML".

HTMX philosophy is to be timeless and agnostic as HTML is, is just a nice extension on top.

Is discussing React vs. HTMX like comparing apples to oranges?

Maybe, but it may be reasonable to do that sometimes. What fruit should we bring to the picnic?

Or what goes well with milk.

Yes, my comment was not pedantic at all it is great to discuss intersections and symmetric differences. In this specific case. Just I thought that the intersection was small while the symmetric difference is much bigger.

The picnic example would be more like mixing them up though ;-)

Yes. Something HTMX evangelists always forget to mention is that HTMX is not a replacement for React -- HTMX + a backend is. This introduces a whole new layer of complexity; it's a total tradeoff. That is to say there are probably React apps that would be better as HTMX apps.

Also, does that currently mean that the backend will be Javascript?

In the browser we have no choice, but I prefer to prevent that accident from spreading to my servers.

No. Backend can be anything.

> HTMX is not a replacement for React -- HTMX + a backend is

Most React apps need a backend too.

Wouldn't the equivalent be more like server components in react? Or do people literally let their backend render presentational html (including tailwind css or whatever)? Like do htmlx people render html from database resultsets in their backends?

Why is it surprising that a backend returns HTML when it receives an HTTP request? That is the web

> Why is it surprising that a backend returns HTML when it receives an HTTP request? That is the web

We did that for a long time with Perl/PHP/ASP/JSP

I wonder why we stopped doing that? I'll just wait a few decades of your FE with this until you figure it out scnr

I don't understand what you are trying to say here. Serving HTML directly from the backend works wonderfully for almost all websites and web apps. The growing popularity of solutions like HTMX, Hotwire, and Phoenix LiveView is proof that React is not the panacea that was promised. Why prepare JSON on the backend, send it over the wire, and have the frontend transform that data into HTML when the backend could just send HTML in the first place?

> The growing popularity of solutions like HTMX, Hotwire, and Phoenix LiveView is proof that React is not the panacea that was promised.

Does it? To me, it seems more proof that software development trends are cyclical. It's also just not all that apparent that things like HTMX are all that popular. React is much more popular than any of them, and then JQuery remains even more popular than React, at least in terms of finding it on the web.

Working with XHR sending full HTML responses, it's pretty clear to me that there's some major tradeoffs to this approach. The payload sizes are larger and interactivity is dependent on round trips to the server. so you're increasing server load and are increasing payload sizes to save on client side processing.

If your views are data driven, then there's plenty of cases where you may want to have interactivity. filtering or sorting results, for example. So you click a column header, then you're sending another request to the server, asking for a new table with the newly sorted rows, it renders it, sends it back to the client, and then replaced the entirety of the table contents with the new contents. and then htmx does some magic to make it behave closer to native HTML (like enabling css transitions on replaced elements, for example).

Storing the state client side, you can perform a lot of these transformations without talking to the server again until you want to actually change data.

I'm all for sending plain html from the server. If your views are static and largely unchanging, then sure, by all means, send it over. You don't need a JSON response to render a blog post on the frontend. But as soon as you want any sort of interactivity in your forms or data views, then you probably don't want to make every interaction a round trip to the server and then you're back at having to think about state on the client, at which point objects in JS are just going to facilitate your needs better than html elements.

> If your views are data driven, then there's plenty of cases where you may want to have interactivity. filtering or sorting results

> Storing the state client side, you can perform a lot of these transformations without talking to the server again until you want to actually change data.

Only if you're only working with a tiny amount of data...

For example, say you have a dataset with 10k records. You're not going to want to send that all to the client so it can sort it locally. Much more efficient to send just the first 100 or whatever results. Then when the user clicks the sort button, ask the backend to re-sort it and give you the first 100 results again.

Bonus: those 100 results are already formatted as html table rows and htmx easily slots them right into the correct spot on the page.

It depends on the sort of data you're looking at, but definitely agree that you will need to hit the server sometimes, depending on the number of records you're looking at. Though even 10k row dataset can actually be handled quite easily with modest computers/phones. I'm not saying you should be doing that, but that would have more to do with usability than the client not being able to handle it.

But even with a modest 100 rows being retrieved, the payload size of fully rendered HTML is generally going to be substantially larger than JSON. These add up quickly when you're making round trip requests to the server for interactivity, especially if it's something like reordering tables.

This is a clear tradeoff and it's why we see trends like this oscillate between client-side and server-side.

I think React is seeing the downsides of being entirely client-side, which is why there's so much development into server side components. Conversely, things like HTMX are tackling problems of handling local state, client/server side caching, and well, payload sizes.

That's true but if you're concerned about payload sizes then 10k records is way too much to pre-send, and in general I think it's safer to depend on the server sending a known max size of html than it is to pre-send all the json every time.

Unless you're using tailwind or some other variation of inline styles, I don't think a typical formatted <tr> is going to be much bigger than a json record anyway. It might even be smaller if the json includes extra attributes that don't make it out to the html.

But I agree that if you know you have a tiny amount of data and you don't want to involve a server then it would be better to do the entire interaction client side. But nothing prevents you from plugging in a small client side lib (not react) and using server-side for everything you can.

> the payload size of fully rendered HTML is generally going to be substantially larger than JSON.

Substantially larger? No, I don't think so. Maybe slightly larger, but if you are compressing your responses (a best practice), there should not be a significant difference between them. And, while in a theoretical perfect world you send exactly the JSON needed for each response, in real-world conditions JSON APIs are quite often overfetching and making too many calls in the first place. Evidence: just look at any typical React-based webapp accessible to the public.

Meanwhile with htmx you can render and send the exact HTML you need for the response, and any overfetching is immediately obvious because it's all shown on the page.

> No, I don't think so. Maybe slightly larger, but if you are compressing your responses (a best practice), there should not be a significant difference between them.

Are we talking about this in an absolute sense? because an html payload whether you compress it or not is generally going to be larger. It obviously depends on what your html looks like, but even if you only are using minimal class names and aria properties, it's still going to be larger than JSON in almost all cases. As in conservatively 50% larger but realistically even more than that, just based on admittedly rudimentary experiments. That's after minification/gzipping and tabulated data is best case scenario for HTML with the small element names (tr, td).

Does that actually matter? Maybe, maybe not. As you said, plenty of real world cases of JSON APIs that are sending excessive data or making calls to the server too much.

...but with things like HTMX, you're either hitting the server or you're using client-side processing of some sort (at which point we're back at why aren't we using something that effectively handles other frontend problems?). I also still think there's rather large downsides to having part of your frontend being handled by the responses from the backend, even if you're using only using full stack developers.

See for yourself: https://github.com/1cg/html-json-size-comparison

False equivalence, and a disingenous one at that.

You can build single-page applications with React, you cannot with HTMX.

> You can build single-page applications with React, you cannot with HTMX.

Irrelevant to the conversation.

GP said:

HTMX is not a replacement for React -- HTMX + a backend is

So if you think that's not true because React can build SPAs and HTMX cannot, take it up with them (maybe you replied to the wrong comment?).

GP was from me :)

You stated: "Most React apps need a backend too."

But in reality this is irrelevant to the conversation, because the top post was asking if comparing HTMX to React is like apples to oranges, which it is, because both tools accomplish different things with completely different feature-sets.

A good example of this is the implementation of TodoMVC. [1] React's implementation can live completely in the browser, and even be stateful. [2] An implementation with HTMX requires a server to handle templating/rendering. [3]

[1] https://todomvc.com/

[2] https://github.com/tastejs/todomvc/tree/master/examples/reac...

[3] https://github.com/rajasegar/todomvc-htmx

the vast majority of (non-native) react applications require a back-end, at the very least to deliver them to users

htmx-powered applications can be local-only via service workers[1]

i think there is a sense in which htmx vs. react is apples to apples, in that in the common case they are used to build web applications that talk in some manner to a back-end system. On the other hand, it is true that react does require additional support code in order to do that communication.

Regardless of that latter fact, and the fact that htmx does not require a server, there is a large overlap in practical applications that might be built with either, so it is good to know the strengths and weaknesses of both for comparison.

[1] - https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...

> the vast majority of (non-native) react applications require a back-end, at the very least to deliver them to users

I mean, I guess if you consider me opening an index.html file in my browser requiring a backend in that my desktop operating system is the "backend server", then yes, but that's not what I was referring to. I don't think most folks would consider a CDN to serve static assets to mean "your React app requires a backend" in the traditional sense -- but that's a game of semantics.

> htmx-powered applications can be local-only via service workers

Do you have any examples of an HTMX app running completely client-side using service workers? Funny enough, the only example I found online ends up using Preact to render templates in the SW, but as a whole, this looks less ergonomic than simply using <insert JS library here> to build a SPA: https://joshi.monster/posts/serverless-htmx/

> there is a large overlap in practical applications that might be built with either, so it is good to know the strengths and weaknesses of both for comparison.

I could agree with this. I only care that people understand there are tradeoffs.

Correct. HTMX doesn’t deal with client-side state and updating UI in response to client-side interactions. React, on the other hand, is all about that stuff.

HTMX is certainly easier, but it's the worse if you want to actually learn FE

As someone who isn't a web developer, what do you mean by that?

HTMX abstracts functionality into pseudo-HTML attributes, allowing you to handle tasks like event binding and DOM/content manipulation that would typically require JavaScript. By using HTMX, you primarily focus on learning HTML and its attributes, with minimal need to learn JavaScript.

Not sure how to interpret what you're saying.

HTMX allows you to learn the very basics: the HTML which is almost verbatim turned into DOM which the browser renders. It's the FE. Everything else is layers upon layers of abstraction which ultimately compile down to the DOM representation of HTML.

...or to put it differently, quoting HTMX's author: using HTTP to transfer HTML? How queer!

Sounds like you don't know anything about FE except htmx...

He has a point though

Strong disagree, it would be a great way to learn vanilla html/CSS/js without kneecapping yourself.

How do you learn JS by using htmx exactly ?

Because htmx is limited in scope. And it's encouraged to use JS for the parts of your app that would benefit from it. But it's encouraged to do so in a way that fits with web standards. Eg https://dev.to/yawaramin/handling-form-errors-in-htmx-3ncg

Couldn't one say the same thing about using any framework that provides capabilities that otherwise would have to be learned?

React/NextJS user here. I can easily make a case that you should avoid HTMX and go with Elixir LiveView because it’s sooooooo incredibly much better. What you’re not understanding is that “better” is contextual.

> My tip: you start by avoiding React altogether.

Avoiding the most popular front-end tech (or any tech) is a good tip for those who want to play Finding a Job in hard mode.

on a flip side, you have an opening for a high 6-figure front end position with an amazing team doing amazing shit - and you see CVs of “React Developers” and you go “uf tough luck, these gals/guys would be PERFECT here except of course we don’t use React” (speaking from personal experiences…)

I'm saying knowledge of React is a good to have, even when you prefer something else. In the sense, avoiding it is not a good idea - know the enemy.

In my experience React (only) devs make very shitty everything-else devs, because they try to squeeze the broken React patterns in places where they don't make sense and don't work. And since every single React codebase does its own thing, with its own set of libraries and state management and routing and even CSS management, 2 React devs will try squeezing 2 completely different broken solutions into a Vue codebase where they could've accomplished the same thing with a single `v-model` in a single 20-line component.

yup, exactly same experience here...

Just use Vue lol.

Reply on news.ycombinator.com