Разница в производительности: тут тест (без смс и регистрации) — преобразование в JSON и обратно — медленнее в 10 раз.

let originalObject = {a: 1, b: 2, c: {d: 3, e: 4}};
let clonedObject = JSON.parse(JSON.stringify(originalObject));

clonedObject.c.d = 7;

console.dir(originalObject); // {"a":1,"b":2,"c":{"d":3,"e":4}}
console.dir(clonedObject); // {"a":1,"b":2,"c":{"d":7,"e":4}}

И зачем огород городить? :)

Другая тема — копирование методов…

Спасибо за статью!

Даже про мою поделку четырёхлетней давности вспомнили (__SE__), про которую тогда писал на хабре.

Сейчас глянул исходники:

 // It is not obvious, but the next line it is a point, where the application execution starts... :-)
__SE__.Sync = __SE__.Sync;

… всплакнул %)

Я потому про связку с WebPack и упомянул, что это (для JS, в частности), уверенный и стабильный +1 запрос (в подавляющем большинстве случаев возвращающий в респонсе только заголовки — это сущие байты).

А в варианте автора, при несовпадении версий нескольких файлов, вероятна ситуация, когда клиенты сгенерируют гору запросов по каждому отдельно обновлённому компоненту приложения.

WebPack + If-Modified-Since

Не проще ли?

Справедливости ради, стоит отметить, что с документацией у Битрикса далеко не всё гладко. В частности, если уж и говорить про его родную библиотеку BX.js, то на тот момент когда мои нервы сдали и я отвернулся от этой системы, вся документация по этой жирнющей библиотеке сводилась к вордовскому файлику из двух страниц с содержанием в духе «смотрите, у нас есть такая библиотека». Но это было пару лет назад.

Да, кстати, на тот момент, если мне не изменяет память, они ещё не придумали включить в дистрибутив кастомизированный jquery. Но если это действительно так, то у меня возникают вопросы об обоснованности решения о кастомизации библиотеки, которая успешно используется на многих миллионах сайтов в неизменном виде.

В силу своего знакомства с принципами работы jquery и её исходниками, я просто не могу представить, честно говоря, для каких целей её необходимо было модифицировать, потому как задачи, для которых она создана, она выполняет на все 100, а все прочие задачи можно решить на её основе путём создания плагинов.

Если просветите по этому вопросу — буду благодарен. Просто интересно.

Вот именно поэтому я с Битриксом больше не работаю. Потому что каждая такая «смена прелоадера» требует реверс-инженеринга его собственной JS библиотеки на пол-метра, суток бомбардировки Гугла, переписки с ТП, а потом переосмысления сущности бытия и написания ~80 строк кода.

Опыт работы под Битрикс — 3 года (включая собственные компоненты). За это время разучился «программировать», зато научился «сношаться с Битриксом». И статья на тему «как сменить прелоадер» с листингом кода на три экрана — хороший тому пример.

В общем:
— Если вместо решения задачи при помощи системы приходится бороться с самой системой — это плохая система.

Боюсь, что с их-то ресурсами, китайцы могут запретить Америку… )

Рекомендуйте смело! Эта книга не только новичкам подойдёт, но и тем, кто хочет «освежить знания».

Пожалуйста, расскажите ещё этих замечательных историй про JavaScript. Только на этот раз бездарям из Epic Games, начинавшим верстальщиками с самого дна. Ведь они, к сожалению, не выучив ничего, кроме убогого и тормозного JavaScript, из-за нехватки ума и чувства вселенской несправедливости теперь транслируют в него игры на Unreal Engine 4.7. [/sarcasm]

Писал об подобном на хабре год назад: вот здесь.

На тему коммуникаций между вкладками просто оставлю ссылку на свой пост почти годичной давности: Библиотека для обмена событиями, данными и задачами между вкладками браузера.

别担心，我们理解你。我们不认为这是不尊重的。

Я за Вас поправил. :-) [/offtopic]

По теме: статья и алгоритм очень вовремя! Как раз сейчас в рамках работы стоит задача по классификации множества пар ключ->множество_значений, заодно испытаю.

А вот в таком виде смысл есть… Хмм…

Как там происходит процедура внесения предложений Мозилле? =)

Предложение Mozilla сделать, думаю, стоит, но… что-то мне подсказывает, что это будет уже далеко не первое предложение о внедрении подобного функционала. Потому что судя по опросу в конце топика, почти половина программистов сталкивается с необходимостью внедрять подобную коммуникацию. Плюс на том же stackoverflow видел кучу вопросов по этой теме ещё с бородатых годов (когда народ ещё через Cookies и setInterval это всё пытался сделать).

Стало быть вопрос стар, как мир. Почему не внедрили до сих пор? — Вероятно, есть какие-то причины.

И первое, что приходит на ум — это вероятные проблемы с безопасностью. Потому что тут, как минимум, существует серьезная дыра, когда при наличии банального XSS лишь на одной из страниц, удар может прийтись уже по любой части сайта через другие открытые вкладки.

А теперь представим ситуацию, что на такую XSS попался админ, у которого в данный момент в соседней вкладке открыта админка. Даже если на сайте реализованы все возможные системы нивелирования угроз со стороны данных, которые можно вытянуть через XSS, или реализованы даже какие-нибудь одноразовые ключи на каждое действие в админке (аля, «скрытая капча», чтоб только напрямую с админки можно было выполнять системные скрипты), то все эти средства защиты идут прахом, потому что по факту получается, что через XSS в какой-нибудь подписи на форуме, злоумышленник напрямую действует «руками админа» через админский браузер в админке сайта, а админ этого даже не заметит, потому как все действия будут происходить в неактивной вкладке.

Так что, всё же, палка о двух концах, как мне кажется, и внедрять это на нативном уровне — опасно.

Shared Workers вообще бы решили всё и не пришлось бы городить огород. Но на тот момент, когда писалась библиотека, их поддержка была чуть менее, чем никакая. Сейчас положение, конечно, лучше, но всё ещё где-то на уровне «м-да»… :)

И как раз для борьбы с заморозками неактивных вкладок (и отсутствием реакции на события хранилища) я и использовал обычный Worker, который, работая фоном, банально пингует вкладку изнутри. Такая беда не только в мобильном сафари.

Кидаем тут в консоль:

var WindowHandler = window.open( 'http://google.com' , '_blank' );

В открывшемся окошке гугла кидаем в консоль:

function listener( Event ) {
    console.log( Event.data );
}
 
if ( window.addEventListener ){
  window.addEventListener( "message" , listener , false );
} else {
  window.attachEvent( "onmessage" , listener );
}

Снова возвращаемся сюда и кидаем в консоль:

WindowHandler.postMessage( 'MyEvilMessage' , '*' );

В консоли гуглового окошка наблюдаем надпись «MyEvilMessage».

Про это подробнее написано вот тут.

А мне хотелось адресации и было время…

Если мне память не изменяет, то postMessage требует указатель на объект окна, которому передается сообщение. Потому этот метод и используется, как правило, для коммуникации с iframe или окнами/вкладками, которые были открыты скриптами (когда получаем указатель из метода window.open()) — в этом случае всё гладко.

А как нам получить указатель на вкладку/окно, если, например, пользователь руками дважды набрал адрес нужной страницы в разных окнах, но в одном браузере?