Defront — про фронтенд-разработку и не только
23.7K subscribers
21 photos
1.09K links
Ламповый канал про фронтенд и не только. Всё самое полезное для опытных web-разработчиков

Обсуждение постов @defrontchat

Также советую канал @webnya
Download Telegram
Майлз Боринз три дня назад открыл пулл-реквест в Node.js с обновлённой имплементацией поддержки ES2015 Modules.

Самое значимое изменение – возможность использовать новые модули в файлах с расширением *.js. Теперь в Node.js есть три возможности работать с новыми модулями:
1) используя расширение *.mjs;
2) используя расширение *.js и type: module в package.json;
3) используя расширение *.js и флаги командной строки --type=module / -m.

Причиной изменения подхода стала критика со стороны сообщества предыдущего механизма, когда работа с ES модулями была доступна только в файлах *.mjs. Для сохранения совместимости с CommonJS было добавлено специальное расширение *.cjs.

Разработчики Node.js пока не рекомендуют использовать ES модули в публикуемых пакетах. Релиз поддержки новых модулей без флага запланирован до выхода LTS версии Node.js 12 (октябрь 2019).

#nodejs #modules #esm #es2015

https://github.com/nodejs/node/pull/26745
Николас Закас – автор нескольких книг по JS и оригинальный автор eslint – в январе написал статью про то, почему он решил не использовать дефолтные экспорты в своих модулях. Статья называется "Why I've stopped exporting defaults from my JavaScript modules".

Для меня самое полезное в статье (как это ни странно) не причины, из-за которых автор отказался от дефолтных экспортов, а принципы, которыми он руководствуется при разработке и которые ценно вспоминать время от времени:
1. явное лучше неявного;
2. имена должны быть консистентны во всех файлах;
3. выкидывайте исключений как можно раньше и чаще;
4. меньшее количество решений - более быстрая разработка;
5. необходимость переключать контекст (side trips) замедляет разработку;
6. избыточная когнитивная нагрузка замедляет разработку.

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

#javascript #modules #esm #musings

https://humanwhocodes.com/blog/2019/01/stop-using-default-exports-javascript-module/
Надо уже написать что-нибудь про свои проекты. Недавно доделал бенчмарк скорости загрузки нативных JavaScript-модулей в браузерах — esmtest.

В бенчмарке измеряется скорость загрузки 100 модулей через HTTP/1.1 и HTTP/2. В каждом модуле находится код, который добавляет на страницу одну букву из первых предложений "Преступления и наказания" Ф.М. Достоевского. Скорость загрузки модулей через HTTP/2 в моих тестах в четыре-пять раз быстрее HTTP/1.1. Возникает резонный вопрос, достаточно ли этой разницы, для того чтобы полностью отказаться от бандлинга приложений? Всё зависит от ситуации. Если у вас Electron-приложение или приложение не очень большое, то от бандлинга можно отказаться. С другой стороны, если нужна максимальная скорость загрузки большого приложения, то тут надо действовать по обстоятельствам и делать эксперименты. В любом случае бандлинг можно оставить только для production-сборки и использовать нативную загрузку во время разработки, таким образом от source maps, с которыми иногда бывают проблемы, можно будет отказаться.

По каким-то причинам при троттлинге сети Chrome в пять раз уступает Firefox. Возможно, что на это влияют какие-то оптимизации в Firefox, или просто есть баг в одном из браузеров. В общем, всё это очень интересно, и пока непонятно из-за чего возникает проблема.

P.S. Сайт бенчмарка попал под ковровые бомбардировки Роскомнадзора, поэтому он может быть недоступен у некоторых российских интернет-провайдеров...

#js #modules #esm #performance

https://twitter.com/myshov/status/1139611892652105730
Пару дней назад Джейсон Миллер из Google написал статью про несколько стратегий загрузки js-бандлов с современным синтаксисом — "Modern Script Loading".

Отдача скриптов с современным синтаксисом для актуальных браузеров может очень положительно отразиться на производительности. При этом нельзя забывать о старых браузерах, которые могут не поддерживать новый синтаксис. Для условной загрузки скриптов в стандарте предусмотрен специальный аттрибут nomodule у тега script. Если вставить на страницу два тега скрипт один с современным синтаксисом, а другой со старым и с атрибутом nomodule, тогда последний не будет загружаться в современных браузерах. Но есть проблема — этот трюк будет вызывать лишний фетчинг файлов в Edge и Safari.

Джейсон предлагает четыре решения возникшей проблемы:
1. Определение поддержки браузером современных модулей и вставка на страницу нужного бандла в рантайме
2. При формировании страницы на сервере определять User-Agent и вставлять в код страницы нужный скрипт
3. Использовать описанный выше паттерн nomodule/module, понимая, что у какой-то части пользователей будет происходить лишняя загрузка кода
4. Использование полифиллов в теге с аттрибутом nomodule

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

#js #esm #modules #performance

https://jasonformat.com/modern-script-loading/