The semantics of a programming language isn't determined by how you talk about it or even how the language specification talks about it.
The original statement was: "(I program in JavaScript where all values are immutable)" Its meaning depends on the semantics of 'values' and 'immutable'. If by 'values' you only mean primitive values (excluding objects and arrays) or by immutable you only mean immutable identity (excluding mutable state), you're comparing apples to oranges instead of Rust to JavaScript.
Immutable.js and PureScript exists for a reason: in JavaScript, not all values are immutable.
Object states are mutable, of course. But they are not values. You can't bind object states to variables. If you use objects as proxies for values that exist in your head but not in in JavaScript's semantics, that's fine, so long as you keep in mind the distinction between what you wish you were using and what you are actually using.
The original statement was: "(I program in JavaScript where all values are immutable)" Its meaning depends on the semantics of 'values' and 'immutable'. If by 'values' you only mean primitive values (excluding objects and arrays) or by immutable you only mean immutable identity (excluding mutable state), you're comparing apples to oranges instead of Rust to JavaScript.
Immutable.js and PureScript exists for a reason: in JavaScript, not all values are immutable.