Popular posts

Speaking personally, I am a big fan of Immutable. The reason I haven't used it more is that it's a bit awkward to navigate a codebase that mixes immutable and non-immutable values. It's also awkward having to use .get() to unwrap an immutable value. To fully experience the benefits of immutable data, you'd need first-class language support so that it's possible to use it seamlessly everywhere.

I think it's a great fit for both Redux and React. One problem, though, is that it makes things like serialization and debugging a bit of a pain—again, because it's not a feature of the language.

So while I don't use Immutable everywhere in my apps, it's great for those areas in which it does work.

I would add that Immutable also has its own pitfalls. Like when people hope it improves performance but call toJS() before rendering which completely defeats its purpose, as toJS() allocates a ton of objects with different identities every time. Or when people try to set fields on Immutable objects, or try to use it with the spread operator.

I would say that if plain objects and arrays work well for you, stick with them. Don't use Immutable just because somebody else does. If you want to introduce it for performance, make sure to measure your changes so that you don't regress by using it incorrectly.