В какой-то момент может понадобится полифил для браузера который поддерживает esmodules. Либо этот момент уже настал у какого-нибудь браузера две версии назад.
Мне кажется как-то жирно для ошибок, которые могут ни когда не произойти, держать постоянно открытое вебсокет соединение и тянуть не маленькую библиотеку socket.io.
Тот же механизм есть в google closure library в методе registerDisposable или addChild. Если сделать dispose родителя, то все потомки уничтожатся. Но там еще ко всему можно переместить ребенка не уничтожая его. В этой реализации я так понимаю нельзя будет сделать.
Расскажите, какие есть слабые места в существующих тактических решениях и как ваше решение поможет их обойти.
При первом приближении кажется, что это вариация Async.js.
В каком случае не спасет проверка на аякс?
Злоумышленник же не может отправить CSRF запрос AJAXом с другого домена (если не стоят разрешающие заголовки на сервере). Но может отправить форму.
За это время плюсы светодиодов перевесили минусы (Эффективность ограничена, спектр далеко не «солнечный», цена кусачая и серьёзные проблемы с охлаждением)?
Сейчас используем как у Google Closure Library. JS иклудит js, scss иклудит scss, html рендерится яваскриптом. Еще полгода назад блоки бились по мотивам БЭМ. Html блоки инклудили js и scss, а последние сами подтягивали нужные зависимости. Подробности есть в статье Фронт-энд Островка изнутри.
Проще оказалась как раз не думать о сборщиках, а пофиксить браузером. Потери производительности можно потерпеть, ради редких моментов дебага в IE.
И такой код легче переносить из проекта в проект.
или
При первом приближении кажется, что это вариация Async.js.
Злоумышленник же не может отправить CSRF запрос AJAXом с другого домена (если не стоят разрешающие заголовки на сервере). Но может отправить форму.
И такой код легче переносить из проекта в проект.