Thread by @norswap

I've been immersing myself in web3 frontend dev for the past month and a half or so.

Quick rambly rant on things. 🧵

(Frontloaded with ranting but there is hope at the end :D)

It's crazy to me that it's more complicated (imho) than backend work (including smart contracts) but somehow gets much less airplay, hype and respect.

Frankly, proper frontend dev — making an app that is robust and does not randomly error-out and catch fire — is probably as hard as proper distributed system design.

Because, essentially, it is a distributed system, which in web3 also happens involve flaky components (wallets, RPC providers).

The state of practices is abysmal, or at least there is very low visibility into them.

I've asked how people handle errors ... looks like they don't?

There isn't a even a good way to find out what errors *can* happen other than reading source code.

I've asked for codebases that demonstrate best practices, and haven't really gotten anything usable back (maybe I should start spelunking).

Web3 tools are ... okay but not awesome.

I feel like I picked on wagmi a lot, but at least it exists and works pretty well.

It's not the greatest library if you want to understand exactly what goes on (docs are lacking details), and there are eldrich horrors of type-level programming.

But the default behaviour "just works"!

Still, if you want to master the stack, not sure if I can really recommend using it vs just writing your own thin chain interop layer that handles caching & retries.

The way ethers.js does errors is a big meme. Excited to switch to viem to replace that.

Ethers is also > 200kb, Jesus. And for that price, it can't encode Solidity callbacks :')

Oh, and no way to tell your event subscription to filter on an indexed field.

So in my game, everybody has to process every game event from every single game. Great for lining Alchemy & Infura's pocket, but not much else.

(Or create a contract per game, which is also expensive, but also wasteful.)

I kinda don't know anything about web3.js. I always assumed that it's worse than ethers.js because everybody seems to use ethers instead, but maybe everybody is wrong? idk

I didn't try thirdweb (because I didn't want to do a full rewrite) but I'm a bit skeptical of their react API. There are also zero details. e.g. "useContractRead" ... when does that thing refresh? And very few configuration options.

I've got some theories.

One is that maybe what makes this that way and why people talk about frontend less is that if you screw up your protocol people lose money. If you screw up your system design the chain goes down.

Frontend down? Just use etherscan brah.
If a refresh will fix it — nobody cares.

Theory two is that because 95%+ of web3 stuff is finance, maybe what we have works well enough for that?

Like if you just have a DEX, you just need to pull a bunch of numbers that are stored on-chain from the latest block, your app is not going to get devilishly complex.

But even just writing my damn game lobby logic, all the building blocks are woefully unadapted.

A player creates a game. Then players join it and once the required number of players has been met, the game starts.

Pretty simple? You've got to create the game, get its ID, use that to pull the game data, set up subscriptions for game events. Whenever an event happens, update the game data.

In the real world, people lose connection, and you might lose events for other reasons.

So you need to figure out if that happens and resynchronize in that happens.

You probably also want to store things in the browser's storage. If only so a game (which has private information!) can resume after a browser crash. So that too needs to be resynchronized.

Still, as I refactor all of this, I feel like it's not that complex. But I have to figure out all the patterns as I go.

Maybe this is the way.

Maybe this is how I know the things I already know also?

I do feel like in other domains you can literally read books about the common patterns though. Be that distributed design, or game programming.

I think a mistake I definitely made was thinking of the frontend as "oh, I'll just lookup data and send commands".

In reality, you are replicating the chain state!

This is why MUDv2 by @latticexyz is great (yes, I need to write a thread on that): it gives you full contract state replication for free! (though at the cost of needing an indexer)

It's not perfect yet: you still need to handle reconciliation with optimistic local updates (e.g. you make a game move and apply it to your local state/display before it lands on-chain)

It has a non-indexer mode where you essentially do in-browser indexing. That doesn't really scale though, because you need to index from the creation of the contract.

I'd love a hybrid mode where you could do an initial pull then process events from there onwards.

There is also the problem that if many "games" happen in the same contract, you're reproducing the state of every game. It would be great to be able to discriminate.

So yeah, state replication. In a sense, it's not a new problem. Every web2 app with collaborative edit has to deal with the same problem!

Do you know any writeup on that? (keeping in sync with the backend)

But truly, the key is to think of your frontend as a node that you're trying to keep in sync with your on-chain state.

It's not that different from a rollup =)

So yeah, web3 frontend hard, games hard.

But it's all fun though, figuring it out and all ;)