wotamRobin

Principal eng working with 3 teams on a ~500k loc React site here. After lots of experimentation, we’re just using React contexts.

- Redux is cool but there’s so much decoupling that it gets hard to read the code. New hires would take too long to start, TS types got crazy, it was too much.

- XState is very good for state machines… but you barely ever need that level of control. Most of the time understanding it ends up being overhead. We’ve had maybe one good case for using it in about 10 years.

- React’s contexts are minimum overhead and work very well with “jump to definition” functionality and TS types. You can choose to use a reducer if you want, or skip it if it isn’t appropriate.

YMMV of course. This is just us.

What do topologists have for breakfast?

Donuts filled with coffee.

I’ve seen the same at several different companies. There seems to be just too much that can go wrong during an e2e test like this: network failures, slow CPU causing timeouts, etc. At one company, the entire suite of 700 tests was re-run 3 times nightly, taking 5+ hours, and some tests still failed randomly.

I have found that the majority of errors can be caught by unit and integration tests on a single service, and that the extra burden of maintaining Cypress just isn’t worth the small amount of coverage.

This is a great article! It’s surprising how much tech debt pops up in games like these.

Another game much like this is Satisfactory, which is basically the 3D version of Factorio. I actually wrote a very similar article about it here, though more focused on architecture instead of process: https://medium.com/@wotamRobin/what-satisfactory-and-website...

I really like the UI and seeming wealth of different units. It doesn't look like it supports fluid ounces though.

I tried "4 tbsp to oz" and it interprets oz as mass instead of volume. Google correctly gives me 2 as the answer.

To make an analogy, right now it's possible to write and include C++ modules in your Python scripts, just like it's possible to do with WASM/JS. But people still use Python, because it's a much faster/easier way to get a specific kind of thing done.

So WASM is a great tool, but not a good choice for building something like HN, where perf isn't an issue. Iteration speed, debuggability, and the GC make HTML/CSS/JS a better choice here.

At the very least, browsers are the new JRE.