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