That for-loop design is a really interesting way of achieving "executional transparency", which is a good name for something I've found lacking in many reactive frameworks. Trying to work with Svelte, I was annoyed by how much magic was going on behind the scenes, and how it would attempt to automagically dice up code between the client and server, only to end up in arcane errors that were painful just to understand. I've found React a fair bit better on that front, in that component code will always run exactly as written (the main question being when it is run), but it doesn't have the greatest story w.r.t. expensive derived state that you may want to compute lazily, which ends up in useEffect() and careful dependency tracking.
In contrast, this design lets you know precisely what is recomputed on each refresh, even if it comes at the cost of explicitness. Any and all timing errors will be present in the code as written.
Yes. I worry that “executional transparency” doesn’t have a formal, objective definition, and referential transparency is actually boolean, code either is referentially transparent or it’s not. But there are some formal objective measures for executional transparency, like cyclomatic complexity, and I find it helpful to think of the “transparencies” on a sliding scale.
That for-loop design is a really interesting way of achieving "executional transparency", which is a good name for something I've found lacking in many reactive frameworks. Trying to work with Svelte, I was annoyed by how much magic was going on behind the scenes, and how it would attempt to automagically dice up code between the client and server, only to end up in arcane errors that were painful just to understand. I've found React a fair bit better on that front, in that component code will always run exactly as written (the main question being when it is run), but it doesn't have the greatest story w.r.t. expensive derived state that you may want to compute lazily, which ends up in useEffect() and careful dependency tracking.
In contrast, this design lets you know precisely what is recomputed on each refresh, even if it comes at the cost of explicitness. Any and all timing errors will be present in the code as written.
Yes. I worry that “executional transparency” doesn’t have a formal, objective definition, and referential transparency is actually boolean, code either is referentially transparent or it’s not. But there are some formal objective measures for executional transparency, like cyclomatic complexity, and I find it helpful to think of the “transparencies” on a sliding scale.