Hacker News Reader

I guess it's continuing the trend of patching over hacks with more hacks to try to work around fundamental design errors.

useMemo has the problem of having to specify dependencies manually and making fine grained updates difficult. Letting go of the unworkable pretension of effect-free components would solve these self-inflicted wounds, like is done in e.g. SolidJS.

> a whole paragraph on the cognitive load of an extra compilation step... IMO you don't even come CLOSE to explaining why this trade off is worth it

You're missing the whole context about how React is a library with a huge enterprise sponsor (Meta) who uses it to build some of the biggest web frontends in the world (Facebook etc.) where most of their engineering talent, like most enterprises, will trend to be juniors in order to save money.

Juniors will not naively get the dependency array for useMemo correct, period. With enough juniors banging away on enough PRs, especially if PRs are not reviewed by the most senior talent to save time, this becomes a problem at scale. The need to introduce extra compilation steps, especially when a codebase the size of Facebook already has (I'm sure) distributed build caching, is more or less immaterial compared to the savings of getting more PRs to be correct when first raised for review.

It's rather amazing and telling of our economic system that over a trillion dollar company can't make their main product work properly.

And that people tell mom-and-pop shops to use too, because Facebook uses it

People probably tell the shops to use it because they don't know anything else and lack fundamental understanding of programming which makes switching frameworks quite hard. I.e. job security for "React programmers".

Show me a better one... And please don't say Vue or svelte because these are just the same thing a little differently.

Depends on the use case. For a lot of cases you may not need a framework at all. A library like jQuery to smooth out DOM API horrors is probably a good idea anyway.

I'm not too thrilled about Vue or svelte either. But there are differences. Vue is more "relaxed" with state and effects, and svelte (and Vue 3) go the compilation route to keep the illusion a bit better. Both can get nasty quickly, with complilation hacks playing significant part.

For a current small project I started with Vue (mainly for Quasar) but switched to React due to Vue magic starting to break. Now useMemo is starting to get unwieldly, so probably switching to SolidJS or Preact/signals.

I was a web developer before jQuery, during jQuery and still am after jQuery. You really want react/similar even for very small apps. I went and tried to implement a simple calculator app without any dependencies just to see if it got better with Web components, but not really, way too limited to be useful for anything other than purely design tokens if you don't want to reimplement React. jQuery is not really necessary any more, the problems it used to fix are solved - but there is still no support to make a reasonably organized and performant reactive application.

BTW not sure what you mean with the useMemo - I built very large applications in React (hundreds of complex dynamic financial analysis pages) and didn't have much problems with it - could you go into detail please?

I was a web developer before XMLHttpRequest. JQuery is just a convenient way of using the DOM, and this has not been fixed (especially addEventListener is a horrid API, but many others too). If you're coding for browser, there's no escaping the DOM. Web components are an orthogonal thing. You don't necessarily need components at all to do web frontend.

React is a fundamentally different paradigm from the event-based DOM, but it tries to do a (leaky) stateless abstraction on it. You can have event-based APIs with different kinds of organizations. E.g. SolidJS is an event-based framework with component organization.

useMemo requires explicit tracking of dependencies, and it requires a lot of handholding to update just what is needed. Of course you can do practically anything with it, but it can get tedious and error prone.

The problem is more with us than them.

We lap up all the open source and ideas that the FAANGs of the world put out and presume they are awesome because...it is hard to get hired there? People've heard of them? They pay a lot?

It's all political bullshit instead of actually doing the hard work of evaluating the idea and implementation.

The problem is network effects (everybody else is using it), anticompetitive behavior (e.g. buying out competition) and corruption (e.g. lobbying).

What's this we shit? I've been saying this since all this garbage started dropping way the hell back in the days of yore. I fucking hate all of these stupid frameworks with the burning passion of a dying star. We know how to build websites, we know how to build software. I have never learned these stupid frameworks and I have no intention of doing so, if you want a website, I'll build you a great damn website and no maybe it won't be web scale or able to handle sixty quadrillion connections, but it'll work, it'll be on time, it'll be under budget and you won't need a comp-sci graduate with 12 years of industry experience if you want to change what color the fucking buttons are.

what do you propose they do instead to reduce bugs?

By mandating that people can access their data so less incompetent organizations can create less buggy systems with it.

Studies have shown that number of lines of code is directly proportional to the number of bugs produced in that code, regardless of language or framework. Would it stand to reason then that a framework (yes, I said it) like React with its boilerplate is suboptimal, even with the new compiler?

As an old school web dev, to this day I cannot understand how multi-megabyte JavaScript code blobs (after gzipping!) became "normal" and acceptable.

React with several big libraries is still only 100k or so gzipped. I'd say it has less boilerplate than most other frameworks too, especially when compared to something like angular.

1. React doesn't have less boilerplate than the average let alone most.

2. You haven't seen Angular lately, have you? It's on 18 now. 15 and 16 really trimmed things down.

A basic React app is 3 lines of code with an optional but recommended compilation step. You can get a very complex app with 20% of the code compared to Angular. Nothing else of the big ones (React, Vue, Angular, Svelte) comes close. Just don't use bloat like create-react-app, instead make an empty folder and install react and react-dom yourself.

What's the smallest "Hello ${name}" hooked up to an input field you can make deployable in React?

Svelte's is about 2.1KB last I checked. Can React get below 40KB?

Nope, ReactDOM is 132K min, 42K gzipped:

- https://unpkg.com/browse/react-dom@18.2.0/cjs/

- https://bundlephobia.com/package/react-dom@18.2.0

Note that this is the full package, and that it's normal to use a bundler that will treeshake things you don't use away. For example react-dom includes server-side rendering functions that are not necessary on browser side.

Afraid that's not accurate.

The package size I linked is specifically the `react-dom.production.min.js` bundle that is used on the client side. The `react-dom` package does include _separate_ bundles used for server rendering, but that whole React client bundle will get included in your app, and it does _not_ tree-shake at all.

(To be clear I _like_ React, but it's best to be accurate about what happens here.)

So this package is not the actual react-dom package I get when I npm install react-dom? Thanks for the correction!

The `react-dom` NPM package includes multiple different JS bundles that are used for different purposes. See that `unpkg` link I pasted in the parent comment.

There's 3 different flavors of `react-dom` for use in the client (dev, prod, profiling), and then several variations of `react-dom` for use _on the server_.

The client bundles don't include any of the server functionality.

_None_ of the bundles are treeshakeable at all, because A) they're shipped as CommonJS modules and not ESM, and B) the way the React library is written and architectured as a whole. All of the reconciler logic is intertwined and unshakeable, so even if React did suddenly switch to shipping ESM modules instead of CJS, it would still end up as the exact same bundle size.

So how small can you get for a hello world page with a single "hello $name" component, spending an hour or less on it?

That bundle size + the size of your component.

Just created a fresh Vite+React app and rendered a "hello world" component, and the resulting output is:

    dist/assets/index-uoOveHrm.js   142.66 kB │ gzip: 45.76 kB

Go for Preact if bundle size is your concern.

I'd rather go to Svelte for lower bundle size than Preact, better performance than Preact, and clearer code with fewer lines written than Preact.

Sure, I'd lose access to the React ecosystem, but I'd also gain access to the vast ecosystem of vanilla JS libraries without having to write/use a wrapper, so that's a wash. (bind:this is awesome!)

Yep, sure! Personally I don't like the Svelte programming model, and I like Preact signals a lot, and hooks are fine to me. But Svelte is definitely a good way overall.

The big time/cognitive savings is in not having to manually keep track of what should be in the dependency array, which is what you have to do with useMemo.

I don't explain why the trade off is worth it because I'm not convinced the trade off is worth it. I'm explaining because devs using React will need to know, I'm not trying to convince that it's the right choice.

How does this compare with ubiquitous lint rules that require hook dependency arrays to be exhaustive?

Personally, I semi-regularly encounter instances where this rule must be ignored else I achieve an infinite re-render loop. Other times, it can be ignored, like when you use a stable value in the body of the memo or effect, like state setters from `useState`.

In practice this leads to ignoring the rule, disabling the rule with a comment (and potentially forgetting to add vital dependencies when the function is updated), or adding a bunch of unnecessary noise to the dep array.

Can you give an example? In my experience these cases are often trivial to fix, and React provides some solid documentation on how to solve these: https://react.dev/learn/removing-effect-dependencies

There absolutely might be cases that can’t be solved, so I’m hoping to break out of my bubble and learn what they are!

Fairly common: triggering a side-effect that uses some state value, only when a different piece of state changes.

useEffect(() => { doSomething(someState) }, [otherState])

Sorry, there might be a misunderstanding —- I’m looking for an example of when the dependency array needs to be [], is that what you posted?

The example supplied is what I was trying to get at.

An empty dependency array means that the effect runs only once on mount. Same with memos and callbacks -- the value should remain stable. Here's a real world example of how I populate some state based on url query params:

https://github.com/Naught0/combinator/blob/master/frontend/s...

I may end up using a more robust routing solution to keep in sync with query params if I ever want to spend the effort, but this is a naive solution that works alright.

A more simplified, generic example could be:

  const [foo, setFoo] = useState();
  useEffect(() => {
    setFoo("bar");
  }, []); // The eslint rule wants setFoo here despite the value being stable

Yeah maybe I didn’t follow exactly, I meant this as a common example of when the hook dependencies rules must be ignored.

To me the big winning is that you don't have to memoize transitively. Occasionally someone asks me for help to optimize some react code, and then the dependency array contains some object/callback that has a dependency which has a dependency which wasn't memoized.

> de-inlining (or whatever the proper word is)

The phrase you are looking for is "loop-invariant code motion". https://en.wikipedia.org/wiki/Loop-invariant_code_motion

The big problem is that

- memoization sometimes crucial for performance.

- passing objects and functions around is common.

- you cannot compare objects and functions for semantic equality

If you wrote larger react apps you almost certainly had to useCallback at some point so that memoization worked, the compiler fixes that.

Whenever you construct an object or function the react compiler memoizes on their free variables so pointer equality is sufficient.

Though I do think the compiler caches too aggressively, even if there are no free variables and hoisting is sufficient or escape analysis shows it is unnecessary for semantics.

>It looks to me like we're just throwing that all in the bin for absolutely fuck all.

Welcome to the last 5 years of React development. React was "finished" with 17, but it's now a zombie project being filled with increasingly absurd feature sets serving as a promotion tool for bored Meta devs.

For me the start of the decline was actually React 16.8 with hooks.

No accounting for taste, I suppose. For me, hooks were when React got amazing.

No accounting for taste, I suppose. For me, class components were absolutely horrid and hooks simply made it less horrid by comparison. I guess anything can seem amazing after you've been stuck in knee-deep mud.

Hooks were how they re-added necessary functionality to function components that class components already had. They definitely didn't think it through.

I mean, if you don't understand how specialized inlined code could be faster than a generic function, or how not creating temporary arrays could be faster than creating them, then it's clear that you can't see that there could be any benefit.

I can't judge the React compiler yet, but in general, compilation steps don't cause cognitive load if they work. How many different levels of interpretation and compilation does V8 do? And do you care? Do you have to? No, and that's the point. Whether React Compiler reaches the same level of "it just works", we'll have to see.

> How many different levels of interpretation and compilation does V8 do?

This part is key to the OPs objection. They’re saying that V8 is a very capable optimizer (which it is), so why can’t it optimize the things React Compiler optimizes? It’s a fair question.

> compilation steps don't cause cognitive load if they work

Personally I disagree. Any source code transformation adds cognitive load because my original source code now doesn’t match the source in the browser. Source maps are the traditional answer to that but if React is rewriting logic (like getting rid of arrays) you’re not going to be able to maintain a 1:1 source map.

> They’re saying that V8 is a very capable optimizer (which it is), so why can’t it optimize the things React Compiler optimizes?

Because capable != exhaustive? All compiled languages can benefit from further optimizations. I genuinely don't understand the issue here. Help!

I think OP is questioning whether these are optimizations or whether they are just redundant.

I don't know the answer - I don't use React personally.