Hacker News Reader

Comment by erikpukinskis | Hacker News Reader

Tanner builds libraries with a huge amount of functionality. But IMO he is not great at API design. His packages often have leaky abstractions which need to be patched over time.

React Table and React Query are powerful but end up simultaneously doing too much and not doing enough, because their boundaries are in the wrong place.

What’s wonderful about React is that it’s _not_ a framework. It does one thing well, and then stops at a well thought out, well documented, well tested boundary.

I try to only adopt libraries that also meet that standard. It means you have a lot fewer libraries you can lean on, but it means the API surface you build on will be more stable for longer.

View on HN

> It does one thing well

I'd love to know what that is and I'm a long term React user myself.

It maps state to a set of reasonably efficient DOM updates that you generally don't have to manage or think about.

Go play around with Angular 1, or BackboneJS, or try building a working SPA with jQuery, and you'll get a sense of the breakthrough that react represented in 2013.

I worked with AngularJS back in 2014-15 and it was hell. We used to regularly have accidental performance dips because of the way it reacted to changes in values. IIRC it used to do two scans of all variables in all the controllers on many browser events, one for checking if something had changed and updating everything else and one for checking if the previous check changed anything that would require further updates. I don't remember the specifics now cause it's been so long but it got really costly really fast for complex applications (we were building real time WebRTC telephony interfaces). React was so much better because it came with restrictions on what changes were being checked and Angular was a total rewrite in Typescript with heavy performance improvements over AngularJS. The virtual DOM stuff truly was a revelation over everything everyone else was doing at the time.

> Go play around with Angular 1, or BackboneJS, or try building a working SPA with jQuery

I have used these in production (and mootools, prototype, and many more) and when these came out they were novel / a breakthrough as well at the time.

My point being is React is no longer a simple transform from state -> UI. Since fibers and concurrent rendering and suspense and server components and hooks and actions it is a much wider framework than you are remembering from 2012.

>I'm a long term React user myself.

Clearly not long enough.

The point being that it has gotten too complicated and no longer does any one thing well.

Hooks, actions, server vs client components, the switch from class components to functional, the fad of HOC and render functions.

React today is not the same React I started with.

>I try to only adopt libraries that also meet that standard.

Can you share what those libraries are? Not to critique your choice but to actually use.

A few that come to mind:

React Laag

Apollo client+server

Vanilla Extract

Visx

Downshift

React Router

Thank you very much.

Not really, React doesn't do "one thing [well]", it's responsible for:

- UI rendering

- State management

- Component lifecycle

- Event handling

- Data flow

- JSX templating

In that sense React truly is a comprehensive UI framework, not a single-purpose library. Counter-examples of "do one thing well" are Lodash and Axios.

I’d say all of those bullets fall under the umbrella of “rendering” in an asynchronous execution environment like browsers, where code often depends on a consistent and predictable view of the DOM.

I’m willing to hear arguments about the merits of how React approaches these issues, but I would want any frontend UI library for generating and updating DOM trees to address them in some way.

lodash is a utility library (so chock-full of functionality) how can you say it "does one thing well"?

He actually says it is a counter-example of “does one thing well”.

Oops, misread that.

State management is typically handled by other libraries. React can do it, but it's not great for a full app. Maybe "data flow" too, not really sure what makes that different from "state management".

Lodash does a hundred different things and then people start using it in place of super simple code or native capabilities ballooning the third party API you need to learn

Disagree. State management is an anti feature in react and you don’t need JSX to use react.

It’s only true feature is the view = func(state), everything else should be outsourced to something else.

Yup. Don't use react for state or some hook spaghetti like react query. Use mobx and live happily ever after :)

Exactly. Although I would go with starfx instead

Didn't know about starfx. Interesting.

To anyone reading, mobx is a more generic tool for any type of state management.

And starfx seems like a data fetching + holding state and providing hooks for that data kind of library. Very unique and looks someone cared to make something nice for that kind of problem

starfx looks interesting and innovative ! thanks for sharing

This. Lean on less. I use react and a SQL driver. I have many massive react projects in production.

Query's boundaries are in the wrong place? Can you elaborate?

Who is Tanner?

The developer making react-query (one of the libraries mentioned in the article).

https://tanstack.com/query/latest/docs

Also react-router, which I found to be way too overcomplicated and would duplicate functionality I was handling in other ways. IIRC last major release was also not backwards compatible, and made some odd decisions in the design. Funny enough I went with wouter (which the post also complains about) instead: Simple, focused, does one thing well, doesn't try to be multiple things. I don't recall anything about its major updates though.

Tanner never worked on react-router: https://github.com/remix-run/react-router/commits/main/?auth...

Sorry yeah, I got the names mixed up. I recognized the documentation, and I do mean tanstack router with my description above. I don't remember why I didn't use react-router, but skimming over its documentation I think it may have been the focus on the odd non-React-y way of doing things ( https://reactrouter.com/start/framework/routing ).

Reply on news.ycombinator.com