3 ms·
Essentially the reactive state model - which imo is 'fast' to code in - currently has a horrendous limitation on how many components can be reactive. A naive m
by Normal_gaussian 7y ago
Essentially the reactive state model - which imo is 'fast' to code in - currently has a horrendous limitation on how many components can be reactive.
A naive minesweeper implementation (that is state-connected) will get upset at a hundred cells, and terribly laggy at 900 (a standard 30x30 super expert board).
This means devs have to abandon reactive programming for parts of their code with a non trivial component count.
The demo is showing 'smooth' perf on these kinds of "state-connected" workloads.
The graphics side of things is a partial distraction, mainly it will mean web devs won't have to make the current performance vs ease of development tradeoff in webapps (think boring saas stuff).
The way in which it isn't a distraction is it will make it possible to get past CSS limitations inside of react in a very intuitive way.
As this raises the low bar react had for game perf, we will no doubt see more react games.
But have no doubt - this is about what the current state of reactive programming is capable of off the shelf.
- abcpassword 7y agoI’d like to see a laggy react implementation of minesweeper. I build apps with more complex component graphs than this without performance issue.
- gdxhyrd 7y agoI am amazed at the fact that even going the slow path gets laggy with a mere 900 elements... What are they doing?!