Hacker News Reader

I started webdev in 2007, CodeIgniter, jQuery etc. Things were fun to build and fast to iterate. Deployment was a faff but you dealt with it.

I was late to React (like 2020 late!) but have worked on three large (code base and requests) projects in React since then. Development was not fun, iteration was slow, but deployments were fast, yay for DevOps.

I am now building an in house platform in HTMX and it’s wonderful. I get the fun and speed of the early days with the CI/CD we have now.

The project I’ve built would already be a pain to deal with in React, instead it’s fast to load, has snappy interactions, has less code and is easy to extend.

It feels like cheating, but only because React projects get so hard to work on.

Just out of curiosity, what makes the development with React slow for you? Is it amount of code required to do something? The actual latency between change and visible output? The time it takes to get something running? The app itself being too slow (maybe from weight)?

Because of primeagen I've been bit buy the curiosity bug, so I wanna try it, but till I try it I am trying to figure out why the day-to-day experience is better. Because for me the biggest win is the idea of having thinner client logic. But I think I would use a React Server Component today to ease that issue.

But yea, genuinely curious. Thanks!

Two big things in React from the projects I’ve worked on:

1. Horrible project structure because it’s so unopinionated. Angular has its problems but it’s so much easier to navigate around (one of the reasons I like NestJS is it uses a similar structure). I once worked on a React project where every component was a folder with an index.tsx file in it and default export so tracing issues was hell since the folder name was the best clue you had but people renamed components on import. Not soley a React issue, but made worse by its lack of opinions. 2. State management in React becomes a nightmare for: a: keeping server and client state in sync, thunk/the other one b: everyone eventually puts it all in a global store so you’ve got the faff of dispatching, reducing, whatevering each and every update, adding a single toggle can involve updating half a dozen files.

On the performance side I have a table in my htmx app showing a few thousand bits of data. In React this would need to be paginated, with HTMX I just send the fully hydrated table to the browser and it loads it in a fraction of a second. Then when it updates I just rerun the SQL query, rerender the table on the server, send it back to the browser and HTMX swaps it in.

For me SPA + API always felt like building an application twice. With htmx I build it once.

Hope that helps.

React isn’t the problem. Bad architecture is the problem, eg, making everything a reducer, no separation of concerns, etc.

But yes, the generalized and popular React ecosystem is a mess.

Agree that React isn’t the problem, I worked on an equally large Angular project that was also a pain, just slightly less of a pain.

React makes it easy to create a big mess.

Because I only spent 3 years in SPA land I feel quite comfortable with only shipping what the browser needs to display what the user wants. Getting JS to render everything always felt a bit odd to me.

React has abstracted everything that works so that you can wrap every bit of code in the 'React way of doing things' e.g. styled components, hooks, stores... so much so that we've forgotten architecture and what programming languages can do. I think if you draw a good architecture you won't need most of its fluff

  > making everything a reducer

just curiosity from someone whos not very experienced in react, but what are the problems with that?

It is unnecessarily complex for many problems. You can blast away state in many instances. Sure, use it for multithreaded real-time chat, but don’t use it for simple CRUD.

Instead of living the basic react way and gathering state in one component and passing it down as a prop to a child, you feed it into a global "state store". The child component then requests the exact state they need from the state store. This also works reversed, instead of passing "setX" as a function to a child, you just rely on them to gather the state and pass it to the store.

The thought behind this is that components live in pyramids, and state and props ideally only go down and rarely up by setters-> parents and their immediate children can easily share state and props.

This gets more complicated the larger your family line gets. Many grandchildren down, you have since passed the respective props via prop drilling through a lot of components that perhaps don't care for them. It also gets complicated if you want to share state not in an immediate family line, but in a neighborhood.

Overdoing it is almost like hoarding. You think "eh, maybe I need this later somewhere else) and suddenly, your entire application basically lives in the global store.

Redux, and later useContext, were invented specifically to eliminate prop drilling.

Right. And I think the point is that Redux is a godsend for some small percentage of products but for the vast majority the cure is worse than the disease. Simple and slightly verbose is just "better" as a general solution than the powerful but complex solutions you get with Redux.

Prop drilling wouldn’t be an issue in a functional language as partial application could solve this problem.

I think a lot of the issues with React in general has to do with attempting to contort JS into a functional language.

useContext can lead to some gnarly code.

> contort JS into a functional language

I made something last year in a functional style as I was fresh off the back of a few React jobs and projects. I got a proof of concept working but the code was awful to work with.

I took a couple of days to start over and rewrite it with OOP principles and it was in a much better state afterwards.

The major issue, IMO, is that the DOM is just markup with an API grafted on, and so any framework attempting to add the slightest bit of composability or state management has to twist and turn itself to be compatible in all browsers.

And that's how we got here, because everyone wants to make their applications available on as many platforms as possible, without having to maintain five or six separate teams that have to coordinate a roadmap, and the browser is the only somewhat consistent way to do this.

This is untrue. You can observe this in scalas implicits, which generate an insane mess in any medium to large codebase.

A global store isn’t necessarily a bad thing… in a functional language!

Components are a good idea, don’t throw the baby out with the bathwater!

Just don’t make me develop a production site with a dev environment that falls over due to CORS for my first semester at my fancy new job ;)

(And why do you call state management in stateless design “hooks?” And, and!)

Web components are great, let’s build a framework around them! /sarcasm probably referencing an XKCD

This sounds grossly like a skill issue, for lack of a better shibboleth.

I have seen people arguing that you shouldn't be using the same API endpoints for front-ends and for integration. I can see arguments both ways though...

https://max.engineer/server-informed-ui

I mean, I’ve built both ways. The least productive thing I have seen from the debate involves two teams doing the same thing, but one team are python nerds making an API and the other are node nerds making an API. N’er the twain shall meet, right?

I don’t mean to exaggerate, but your code will tend to mirror your organization structure. I have worked at companies where I thought our product was great because the API rocked.

Then in my last 3 months I got to meet the frontend (definitely a jobsmell: not seeing the frontend every day.)

Definitely misjudged the quality of our product, because apparently we wrote two different products (shrug) ;)

Pretty strong argument for htmx, actually. But again, in a weird way where we fire the frontend and become actual full-stack engineers for everrrrything.

https://en.wikipedia.org/wiki/Conway%27s_law

Didn't GraphQL solve this issue already anyway?

Have you implemented it? The orm aspect is actually pretty weak. You end up implementing an RPC api anyway. And then you wonder how this was sold to you as declarative and idempotent.

I exaggerate here because graphql does not solve the datalake problem. And it doesn’t do graphs (you can). The curb appeal looked super promising, but then it was just rpc with a bespoke ORM syntax.

How? GraphQL is just another way to make query API with structured output, almost always JSON in practice. If you wanted server-side rendering, you still need another endpoint even if it happens to use GraphQL internally, just like you could made a rendered endpoint using another form of API internally.

> doubling my endpoints

yep, and that's a good thing:

https://htmx.org/essays/splitting-your-apis/

https://htmx.org/essays/mvc/

Plus, if you’re writing the front end in react or something else, that’s essentially the “other endpoint”. You’re just moving that back closer to the source of the origin.

>My projects all depend on an API for automation. So by buying into this doctrine, and rejecting even content negotiation, I am at least doubling my endpoints.

If you can query that client-side, you don't need an hypermedia client, you need an RPC client.