Неизменяемым (англ. immutable) называется объект, состояние которого не может быть изменено после создания. Результатом любой модификации такого объекта всегда будет новый объект, при этом старый объект не изменится.  Речь не идет о глубоком копировании: если объект имеет вложенную структуру, то все вложенные объекты, не подвергшиеся модификации, будут переиспользованы. В памяти объекты будут представлены следующим образом:  Эту возможность активно используют в связке с популярным нынче VirtualDOM (React, Mithril, Riot) для ускорения перерисовки web-страниц. Возьмем пример с state, приведенный чуть выше. После модификации объекта state нужно сравнить его с объектом nextState и узнать, что конкретно в нем изменилось. Иммутабельность сильно упрощает нам задачу: вместо того, чтобы сравнивать значение каждого поля каждого вложенного в state объекта с соответствующим значением из nextState, можно просто сравнивать ссылки на соответствующие объекты и отсеивать таким образом целые вложенные ветки сравнений. Внутри объектов bounds и style.font операции сравнения производить не нужно, так как они иммутабельны, и ссылки на них не изменились. Нередки случаи, когда переданные в функцию данные могут быть случайно испорчены, и отследить такие ситуации очень сложно. Здесь иммутабельные данные спасли бы ситуацию. Функция sort была бы запрещена. Или вернула бы новый отсортированный массив, не меняя старый: Каждый раз при модификации иммутабельного объекта создается его копия с необходимыми изменениями. Это приводит к большему расходу памяти, чем при работе с обычным объектом. Но поскольку иммутабельные объекты никогда не меняются, они могут быть реализованы с помощью стратегии, называемой «общие структуры» (structural sharing), которая порождает гораздо меньшую издержку в затратах на память, чем можно было бы ожидать. В сравнении со встроенными массивами и объектами издержка все еще будет существовать, но она будет иметь фиксированную величину и обычно может компенсироваться другим преимуществами, доступными благодаря неизменяемости. В большинстве случаев кешировать легче не станет. Этот пример прояснит ситуацию: Несмотря на то, что data.value из первого шага не отличается от data.value из последнего шага, сам объект data уже другой, и ссылка на него тоже изменилась. Это тоже неправда: Гарантий того, что функция станет чистой, или что у нее будут отсутствовать побочные эффекты — нет. Здесь не все так очевидно, и производительность зависит от конкретной реализации иммутабельных структур данных, с которой приходится работать. Но если взять и просто заморозить объект при помощи Object.freeze, то обращение к нему и его свойствам быстрее не станет, а в некоторых браузерах станет даже медленее. JavaScript — однопоточный, и говорить тут особо не о чем. Многие путают асинхронность и многопоточность — это не одно и тоже.
По умолчанию есть только один поток, который асинхронно обслуживает очередь сообщений.
В браузере для многопоточности есть WebWorkers, но единственное возможное общение между потоками осуществляется через отправку строк или сериализованного JSON; к одним и тем же переменным из разных воркеров обратиться нельзя. Использование const вместо var или let не говорит от том, что значение является константой или что оно иммутабельно (неизменяемо). Ключевое слово const просто указывает компилятору следить за тем, что переменной больше не будет присвоено никаких других значений. В случае использования const современные JavaScript-движки могут выполнить ряд дополнительных оптимизаций. Пример: Метод Object.freeze замораживает объект. Это значит, что он предотвращает добавление новых свойств к объекту, удаление старых свойств из объекта и изменение существующих свойств или значения их атрибутов перечисляемости, настраиваемости и записываемости. В сущности, объект становится эффективно неизменным. Метод возвращает замороженный объект. Библиотека предлагает иммутабельные структуры данных, обратно совместимые с обычными массивами и объектами. То есть доступ к значениям по ключу или по индексу не будет отличаться от привычного, будут работать стандартные циклы, а также все это можно использовать в связке со специализированными высокопроизводительными библиотеками для манипуляций с данными, вроде Lodash или Underscore. Для работы эта библиотека использует Object.freeze, а также запрещает использование методов, которые могут изменить данные. Некоторые браузеры, например Safari, имеют проблемы с производительностью при работе с замороженными при помощи Object.freeze объектами, так что в production сборке это отключено для увеличения производительности. Благодаря продвижению со стороны Facebook эта библиотека для работы с иммутабельными данными стала самой распространенной и популярной среди web-разработчиков. Она предоставляет следующие неизменяемые структуры данных: Библиотека, которая привносит персистентные структуры данных из ClojureScript (Lists, Vectors, Maps и т.д.) в JavaScript. Отличия от Immutable.js: Пример использования: Речь пойдет об использовании Immutable.js (с Mori все примерно также). В случае работы с Seamless-Immutable таких проблем у вас не возникнет из-за обратной совместимости с нативными структурами JavaScript. Дело в том, что в большинстве случаев серверное API принимает и возвращает данные в формате JSON, который соответствует стандартным объектам и массивам из JavaScript. Это значит, что нужно будет каким-то образом преобразовывать Immutable-данные в обычные и наоборот. Immutable.js для конвертации обычных данных в иммутабельные предлагает следующую функцию: где с помощью функции reviver можно добавлять собственные правила преобразования и управлять существующими. Предположим, серверное API вернуло нам следующий объект: Удобнее всего такой объект будет представить как OrderedMap. Напишем соответствующий reviver: Предположим, нам нужно изменить данные и отправить их обратно на сервер: Immutable.js для конвертации иммутабельных данных в обычные предлагает следующую функцию: Как вы видите, reviver отсутствует, а это значит, что придется писать собственный внешний immutableHelper. И он каким-то образом должен уметь отличать обычный OrderMap от того, который соответствует структуре ваших исходных данных. Унаследоваться от OrderMap вы тоже не можете. В настоящем приложении структуры, скорее всего, окажутся вложенными, что добавит вам дополнительных сложностей. Можно, конечно, использовать при разработке только List и Map, но тогда зачем же все остальное? И в чем плюсы использования конкретно Immutable.js? Если проект раньше работал с нативными структурами данных, то легко перейти на иммутабельные не получится. Придется переписывать весь код, который хоть как-то взаимодействует с данными. Immutable.js не предлагает нам ничего кроме функций fromJS, toJS, которые работают следующим образом: То есть абсолютно бесполезны для сериализации/десериализации. Существует сторонняя библиотека transit-immutable-js. Пример ее использования: Для тестирования производительности были написаны бенчмарки. Чтобы запустить их у себя, выполните команды: Результаты бенчмарков можно увидеть на графиках (repeats / ms). Чем больше время выполнения, тем хуже результат. При чтении самыми быстрыми оказались нативные структуры данных и Seamless-immutable.  При записи самым быстрым оказался Mori. Seamless-immutable показал наихудший результат.  Эта статья будет полезна JavaScript-разработчикам, столкнувшимся с необходимостью использовать иммутабельные данные в своих приложениях для повышения производительности. В частности, это касается frontend-разработчиков, которые работают с фреймворками, использующими VirtualDOM (React, Mithril, Riot), а также Flux/Redux решения. Подводя итоги, можно сказать, что среди рассмотренных библиотек для иммутабельности в JavaScript самая быстрая, удобная и простая в использовании это Seamless-immutable. Самая стабильная и распространенная — Immutable.js. Самая быстрая на запись и самая необычная — Mori. Надеюсь данное исследование поможет выбрать вам решение для своего проекта. Удачи. Full-Stack JS, React, Node.JS, AWS, Serverless