Hacker News Reader

One thing I learnt going from frontend development, to distributed system database, development, and then back:

These neanderthal grade tools have the same problem: attempting to abstract away unabstractible problems. The MO of said tools are to limit expressiveness rather than provide context or knowledge.

Take the multi-tab syncing you mentioned. Syncing will always take a loop and a buffer, assuming a channel of communication is not a problem. Those can be in a library, in a browser's built-in API, abstracted away, or you can write it by yourself. But when you don't write it, you don't have control over it (e.g. when to sync, how to interlace the syncing with other operations).

A better toolings work in the level of paradigm. Instead of simply abstracting, bring complexity to clarity and provide the learning ramp.

This is the problem that most JavaScript frontend frameworks are trying to solve. Most of them just connect JS and renderer event loops, but some are approaching data fetching and background jobs as well (like React with the experimental `use` hook, or Svelte Query).

They do however come with significant complexity for new users, and if you write React code without understanding the underlying event loops, you'll write code with weird edge cases (eg. overreliance on useEffect). But I do think that they solve the problem pretty well once you got past that initial burden of learning them.

> they solve the problem pretty well once you got past that initial burden of learning them.

Please do share how the canary `use` hook solves: remote data syncing, proper data sharing across the UI, real-time remote syncing, incremental updates, optimistic updates, realtime collaboration, offline only, etc

These are table stakes for good rich apps now. Now your answer is probably going to be to 'use other tools for this' and the lack of cohesion between those tools is what I'm saying is crappy glue. The atoms aren't good.

That’s… not react’s job?

React is all about efficiently taking state and rendering it.

We use mobx for managing state. We use Hasura for syncing. We use react for display. That works well for us and our requirements.

> React is all about efficiently taking state and rendering it.

You sure about that? https://github.com/facebook/react/blob/main/packages/react/s...

I’m searching for ReactFetch and not finding anything. My 10 years in React tell me that react isn’t a library focused on data fetching, maybe I’m missing something and I would happily discuss it if you point me towards some more information.

packages/react/src/ReactServer.js imports it.

I don’t know what reactsever is either. Was looking more for some documentation to show what it is and how it’s used.

That's just patching fetch for suspense stuff, and suspense is literally about rendering state.

Sure, not a pretty workaround, but nah react isn't trying to be in charge of fetching here.

I've never mentioned React, nor really alluded to it (though it is one piece of the complicated problem).

I didn’t quite understand what you meant by “canary `use` hook solves” but you’ll have to excuse me for assuming you were talking about react.

My mention of the use hook (which was first mentioned in a reply to me) was to point out how silly a response it is to offer a random react hook and as the solution to the complex problem I initially discussed. Do read the thread and my initial comment again.

Hasura + React is the dream. https://github.com/Vetd-Inc/vetd-app

react-query's useQuery hook makes the proper data sharing and optimistic updates a breeze.

react-query (or @tanstack/query as its now called) has a few things which make it a little awkward to use beyond very basic fetches:

1. No concept of normalization. Fetching a list of entity type vs fetching a detail of one of those entities means you end up fetching the same data twice since the cache is only per query, not entity. And good luck trying to mutate its cache yourself to force it to cache by entity.

2. No good way to get the data out of react-query and into, say, my mobx/redux store.

3. Its query cache is global, but the `select` cache is per component/subscriber.

I think your question is valid! React does have solutions for most of these, but remember that even in Canary, its job is just to sync state between renderer<->DOM events<->data fetching, not to replace your backend.

- Proper data sharing across the UI: Contexts

- Optimistic updates: `useOptimistic`

- Offline only: Can you clarify? React by default is offline only

- Remote syncing, realtime remote syncing, realtime collaboration: `useSyncExternalStore` with a subscribe function that connects to your backend

- Incremental updates: What do you want to update incrementally? You can render the site component for component as they are loaded with Server Components. Otherwise, I don't think React has anything built-in for that.

I have experienced the same. I am a backend person with 30 years experience who spent 2 years doing only frontend (mostly react) and the tooling is depressingly bad. What is worse though is that (even in this thread) most (all?) libraries scream ‘not our job’, so now it’s no-one’s job then as we don’t have ‘in between’ or ‘frontend/backend sync’ (I avoid middleware on purpose here as that’s already a thing) devs.

Phoenix and other attempts are the future here imho. We have, for our saas with a few 100k users, rolled out a phoenix like (we use mostly go server side) next to our initial react/next frontend and a) our devs prefer it massively (write mostly only go and not typescript!) b) our users prefer it because it’s just more natural. With ssr you can accomplish the same but it takes more pain because we still have to think about state syncing etc; with liveview likes we are back to cgi on steroids: just handle it on the server and forget the client. You still have to do state but it’s much easier to reason about if it’s in one place.

I've recently been writing a Chrome Extension.

It becomes harder when any one of your distributed event loops can be closed/shut down at any time (e.g: content script, service worker, options page).

Chrome Extensions with the newest "manifest v3" do not have persistent "background pages" any more, but have "service workers" that Chrome will terminate every 30s.

Maybe Phoenix Liveviews?

This is a fundamental problem with the standard approach of shipping serialized state and rendering logic to the browser. It simply doesn't scale, and frankly its an asinine approach.

Rendering should live inside the same system as the state being used. In most cases that state lives on a server somewhere, though there are plenty of cases where (usually small bits of) state live in the client exclusively and are never sent back to the server.

The current approach of leveraging build systems and bundlers to generate RPC calls is only going to make it worse. The goal is to effectively hide obscure the split between backend and frontend, in reality all this will do is lead to a terrible debugging process and countless bugs cause by a misunderstanding of the complex DX required. Worse still, given that any piece of state has to either be the responsibility of the backend or the frontend, we can't blur that line completely and will be stuck papering over it with more and more complex solutions.

HTMX has been getting more attention recently. I have no idea if its really the "right" answer for the next few years of web development, but it seems to strike a chord with devs precisely because it goes the way of leaving rendering of server state where it belongs...on the server.