Hacker News Reader

Comment by solatic | Hacker News Reader

> 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.

View on HN

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.

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

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.

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.

Reply on news.ycombinator.com