jypie

Oh, I failed to remember there was Object.freeze().

This is something the interpreter(Just-in-time compiler, to be more exact) would utilize as hints. but does this mean Immutable.js does Object.freeze()? and if so, why do we need a new library that does the same thing?

I'm afraid I don't get your point.

So deep copy is expensive, and if the variable is immutable and has to be changed, it would have to be deep copied. so immutable is bad?

Or are you trying to say even if it's expensive, the original variable not being corrupted is more important? I know there would be some variables that shouldn't be changed in some programs. but for this need I don't think immutable variables are necessary.

Shouldn't we focus more on the aspect of performance? Thanks for the input! Please enlighten me.

What is the benefit of having immutable variables that are just fake-built at runtime? At compile time, knowing some variables are constant and will not change would give the interpreter/compiler a lot of optimization chances but does this apply the same at runtime as well?

the website says "efficiency" because immutable variables wouldn't need to be deep copied but would the deep copy operations be that frequent in JS?

This.

I was thinking the same.