4 ms·

What do you think about vanilla `Object.freeze`? Any drawbacks? Here my considerations at the moment: Pros: - you can use native data structures instead of co

by gcanti 12y ago

What do you think about vanilla `Object.freeze`? Any drawbacks? Here my considerations at the moment: Pros: - you can use native data structures instead of continually wrap / unwrap - you can use native methods on them (map, filter, ...) - hence (almost) no interoperability problems with other libraries - overall your coding style doesn't change so much - (possible perf gains since the js engine knows the object is frozen? - I really don't know) - EDIT: 0KB dependency Cons: - you must find / write a way to update efficiently

swannodette 12y ago
Lack of update is a show stopper. In general I would expect Immutable JS to trounce anything via Object.freeze with respect to performance. Real hash maps and sets are useful to organize programs - the semantics of Object.freeze on ES6 Map and Set are unclear and still suffer from above problems. Again Immutable JS has a big advantage. In the context of building real applications with immutable data structures and a library like React that makes them easy to integrate - many of your concerns don't apply at all.
- gcanti 12y ago
  > Lack of update is a show stopper Well, it's quite easy to write something like Facebook Immutability Helpers [1]. As you correctly stated, it really depends on your own use case and performance issues. I'll try some perf experiment with [1] or something similar to see what comes out. [1]: http://facebook.github.io/react/docs/update.html http://facebook.github.io/react/docs/update.html
Too 12y ago
Last time i checked Object.freeze actually made things slower, alot slower. Sounds counter intuitive and it might eventually change but that's the current state in most popular browsers.
- leebyron 12y ago
  This is pretty unfortunate. At Facebook we use Object.freeze in a number of places to express POJSO immutability. A technique we've used to deal with the performance hit is to make most of these Object.freeze calls a no-op in a production environment. Most FB employees (incl non-devs) load the site in development mode, so we still get the stricter error messages.

by gcanti 12y ago

swannodette 12y ago

Lack of update is a show stopper. In general I would expect Immutable JS to trounce anything via Object.freeze with respect to performance. Real hash maps and sets are useful to organize programs - the semantics of Object.freeze on ES6 Map and Set are unclear and still suffer from above problems. Again Immutable JS has a big advantage. In the context of building real applications with immutable data structures and a library like React that makes them easy to integrate - many of your concerns don't apply at all.

gcanti 12y ago
> Lack of update is a show stopper Well, it's quite easy to write something like Facebook Immutability Helpers [1]. As you correctly stated, it really depends on your own use case and performance issues. I'll try some perf experiment with [1] or something similar to see what comes out. [1]: http://facebook.github.io/react/docs/update.html http://facebook.github.io/react/docs/update.html

Too 12y ago

Last time i checked Object.freeze actually made things slower, alot slower. Sounds counter intuitive and it might eventually change but that's the current state in most popular browsers.

leebyron 12y ago
This is pretty unfortunate. At Facebook we use Object.freeze in a number of places to express POJSO immutability. A technique we've used to deal with the performance hit is to make most of these Object.freeze calls a no-op in a production environment. Most FB employees (incl non-devs) load the site in development mode, so we still get the stricter error messages.