Although its strange ive adapted quite well to shallow cloning w/o issues for a long time.
Makes me question the real need for immutable data structures in day to day front end.
On a tangent ive wondered if the problem of shared mutable state could be solved by build tools, like if a rust like mechanism were just a linter for JavaScript. Going further you could hover a variable & see all the read & write references with a warning for multiple writers or some more useful rules. Some nuances are required to do this correctly but for me this is more desirable than putting it in the language either at runtime (immutable data structures) or compile time feature like lifetimes, at least for front end where I value a rapid dev cycle.
Yes, I that could be helpful, TypeScript already has the readonly modifier. I found it frustrating to use though - I think as it is, there’s a tension between being guaranteed that this thing won’t change under me vs the guarantee that I’m able to mutate it. Not sure if the both caller and callee need to annotate appropriately or something (which is basically true in Rust) or whether this can be solved more ergonomically?
Yea I don’t want to enforce readonly necessarily, I just want to know when its happening.
For example in a language like svelte it would be nice how many times my variable is 2-way bound using bind:. Ideally this is only on form elements directly instead of custom components. Having powerful linting rules/warnings like that wouldn’t get in the way of local development but should still prevent difficult to debug bugs in production.
I was more referencing putting something like that in the compiler. I don’t want my hot reloading to stop working because some rule was violated - typescript bothers me enough with this.
In terms of immutable data structures at runtime like Immutable.js, it just depends on the environment you’re in. ClojureScript or Elm obviously its a benefit if you buy into the language & ecosystem. But in plain js I find its hard to inspect & often needs to be converted to regular js & back. On top of that I really deeply value plain javascript syntax of spreading & destructing, so for me it slows things down, but maybe that’s not true for others.
Finally!
Although its strange ive adapted quite well to shallow cloning w/o issues for a long time.
Makes me question the real need for immutable data structures in day to day front end.
On a tangent ive wondered if the problem of shared mutable state could be solved by build tools, like if a rust like mechanism were just a linter for JavaScript. Going further you could hover a variable & see all the read & write references with a warning for multiple writers or some more useful rules. Some nuances are required to do this correctly but for me this is more desirable than putting it in the language either at runtime (immutable data structures) or compile time feature like lifetimes, at least for front end where I value a rapid dev cycle.
As luck would have me, I just had a shallow clone bug shortly after writing this :)
Yes, I that could be helpful, TypeScript already has the readonly modifier. I found it frustrating to use though - I think as it is, there’s a tension between being guaranteed that this thing won’t change under me vs the guarantee that I’m able to mutate it. Not sure if the both caller and callee need to annotate appropriately or something (which is basically true in Rust) or whether this can be solved more ergonomically?
Yea I don’t want to enforce readonly necessarily, I just want to know when its happening.
For example in a language like svelte it would be nice how many times my variable is 2-way bound using
bind:. Ideally this is only on form elements directly instead of custom components. Having powerful linting rules/warnings like that wouldn’t get in the way of local development but should still prevent difficult to debug bugs in production.How does the presence of immutable data structures adversely affect a rapid dev cycle?
I was more referencing putting something like that in the compiler. I don’t want my hot reloading to stop working because some rule was violated - typescript bothers me enough with this.
In terms of immutable data structures at runtime like Immutable.js, it just depends on the environment you’re in. ClojureScript or Elm obviously its a benefit if you buy into the language & ecosystem. But in plain js I find its hard to inspect & often needs to be converted to regular js & back. On top of that I really deeply value plain javascript syntax of spreading & destructing, so for me it slows things down, but maybe that’s not true for others.
I come from ClojureScript where native data structures are immutable. It makes deep clone completely superfluous.