4 ms·

I'm a big fan of immutable data structures, but I will caution people to blindly adopting them just because they've heard they are "fast" and it's something tha

I'm a big fan of immutable data structures, but I will caution people to blindly adopting them just because they've heard they are "fast" and it's something that has been popularized by companies like Facebook. The vast majority of apps, when properly designed (and using things such as paginated datasets, and properly managing memory/cleaning up after themselves), do not need immutability. You should first ask yourself, is this a problem that can be solved with immutable data structures, or why do I need to have huge data structures in the browser for my frontend? Unless it's a very special case, you can do more for frontend performance with lazy loading, and some good old fashioned performance analysis (take inventory of event listeners, look at a heap dump from Chrome dev tools, etc) than you can from adding the significant developer and cognitive overhead of immutable.js or its ilk. It may seem nice to say if obj === obj2 and if any deeply nested things have changed it's just a pointer, but as others have mentioned this is not the primary use case for many UI's that are constantly recomposing and creating different kinds of data structures from other data structures (think map, creating a hash from an array, etc). There is no silver bullet and premature optimization with a highly specific design pattern is the root of all evil. Don't worry about performance until there is a legitimate performance problem that needs to be worried about.

spion 11y ago
If "fast" is what makes people adopt immutable data structures, awesome. I'm glad even if its for the wrong reasons as they come with many other benefits. We've all been using immutable strings in JS for quite a while without much troubles - why not use immutable objects and lists too?
- deleted 11y ago
  [deleted]
Scramblejams 11y ago
I don't use immutable structures for speed (they're often slower), I use them because they can eliminate entire classes of bugs.
- matwood 11y ago
  This. By making everything immutable by default, a program becomes much easier to reason about. If I can quickly see this variable is set here and since it is immutable it will never change, I can now quickly reason about other parts of the function.
- kentor 11y ago
  Same here. People are missing the point.
ScottBurson 11y ago
I've been pushing functional collections for years (with implementations for Common Lisp and Java: http://www.ergy.com/FSet.html http://www.ergy.com/FSet.html) and I have to say this post amuses me greatly. For most of this time, I've had to deal with people being skeptical about them because they were afraid they would be too slow -- and now the word is spreading that they're actually faster! I think that's probably wrong. Well-implemented mutable collections are faster than functional collections, if for no other reason than that they allocate less. As others here have said, the argument for functional collections has almost always been on style and clarity grounds. In some cases there's a stronger argument because you need to have many slightly different versions of a collection existing in memory simultaneously; I have written a piece of code like that, but such situations are pretty rare. I don't want to sound like I'm laughing at your argument, which is all true. It's just funny to see someone putting it that way.
- jlongster 11y ago
  The posts here are missing context: I'm talking about immutable data structures specifically in the context of UIs. It's common knowledge in the React world that there is quite a performance improvement using them, because as you change data you no longer have to do expensive checks to figure out exactly what has changed. You just rerender from the top-down and only update specifically what has changed (which just requires pointer checks now). See http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/ http://swannodette.github.io/2013/12/17/the-future-of-javasc.... In general, sure, if you can't take advantage of these semantics then there is going to be overhead and you just gain simplicity. But in certain domains we can take advantage of this simplicity for big performance wins.

spion 11y ago

If "fast" is what makes people adopt immutable data structures, awesome. I'm glad even if its for the wrong reasons as they come with many other benefits. We've all been using immutable strings in JS for quite a while without much troubles - why not use immutable objects and lists too?

deleted 11y ago
[deleted]

Scramblejams 11y ago

I don't use immutable structures for speed (they're often slower), I use them because they can eliminate entire classes of bugs.

matwood 11y ago
This. By making everything immutable by default, a program becomes much easier to reason about. If I can quickly see this variable is set here and since it is immutable it will never change, I can now quickly reason about other parts of the function.
kentor 11y ago
Same here. People are missing the point.

ScottBurson 11y ago

I've been pushing functional collections for years (with implementations for Common Lisp and Java: http://www.ergy.com/FSet.html http://www.ergy.com/FSet.html) and I have to say this post amuses me greatly. For most of this time, I've had to deal with people being skeptical about them because they were afraid they would be too slow -- and now the word is spreading that they're actually faster! I think that's probably wrong. Well-implemented mutable collections are faster than functional collections, if for no other reason than that they allocate less. As others here have said, the argument for functional collections has almost always been on style and clarity grounds. In some cases there's a stronger argument because you need to have many slightly different versions of a collection existing in memory simultaneously; I have written a piece of code like that, but such situations are pretty rare. I don't want to sound like I'm laughing at your argument, which is all true. It's just funny to see someone putting it that way.

jlongster 11y ago
The posts here are missing context: I'm talking about immutable data structures specifically in the context of UIs. It's common knowledge in the React world that there is quite a performance improvement using them, because as you change data you no longer have to do expensive checks to figure out exactly what has changed. You just rerender from the top-down and only update specifically what has changed (which just requires pointer checks now). See http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/ http://swannodette.github.io/2013/12/17/the-future-of-javasc.... In general, sure, if you can't take advantage of these semantics then there is going to be overhead and you just gain simplicity. But in certain domains we can take advantage of this simplicity for big performance wins.