Pull to refresh

Comments 23

Идея неплоха, но, как мне кажется, она для сайтов с ограниченной аудиторией где потеря трёх с половиной человек со старыми браузерами не скажется на сайте, либо для тех, которые не зарабатывают на своей посещаемости (есть ли такие вообще, кроме вики?).
Причем тут потеря аудитории? Пользователи с новыми браузерами получат новый экспириенс, тогда как для пользователей на динозаврах всё останется неизменным.
ES5 (main-legacy.js) 175K

У него там там babel-polyfill подключен, если чё.

Как этот подход будет работать при работе с React, Vue и тд?
Не исключено, что в скором времени этот подход будет реализован в create-react-app. Обсуждение здесь.
Описанный в статье способ (указание в html-е двух тэгов script — одного с type=«module», второго — с атрибутом nomodule) работает, но все быстро проверенные мной браузеры (ie11, opera 12.18, chrome 61, ff 55 в обоих режимах dom.moduleScripts.enabled) загружают оба скрипта.
По всей видимости, наиболее правильным будет использовать подход, подобный этому: определять возможности браузера и инжектить соответствующим образом сформированный тэг script.
Проверял на Firefox и Chrome тех же версий — работает. Единственное, включил флаги поддержки ES модулей. Подробнее здесь.
Закладку «network» в DevTool-зах смотрели?
Да, только один файл приходит. При выключенных флагах main-legacy.js, при включенных — main.js
Хром грузит только один из скриптов, файрфокс — оба.
А у вас этот пример сколько скриптов грузит?
Firefox — грузит оба, исполняет один. Chrome грузит один скрипт.
Хм, похоже, по поводу хрома я не прав: сейчас перепроверил, да, грузит один.
А вот остальные (ff, opera 12, ie11) — грузят оба. Исполняют да, один.
Эм. Но если они грузят оба, то какой профит от всего этого? :)
Тогда все же надо программно определять возможности и подключать только один скрипт.
Так и я про то же.
Раз всё равно для Safari нужен отдельный js-сниппет, то лучше уж его заменить на js-загрузчик с детекцией возможностей текущего браузера.
Пришло время собирать наши модули как ES2015

Ох, как раз недавно столкнулись с такой бедой, когда «скрипя сердцем» решили дропнуть ES5-транспилирование в нашем проекте — и выяснили, что в популярных фронтенд фреймворках, типа Nuxt, в конфиге babel-loader тупо захардкодено исключение node_modules из сборки. И включить это назад там не так-то просто бывает. Разработчики же этого Nuxt вообще не понимают, зачем кому-то может понадобиться импортировать ES6 модуль — мол, «я ни разу не видел не пред-транспилированного модуля, а значит, этого не бывает».


Причём ломается это все в итоге даже не в браузере пользователя — слава богу, основные браузеры уже умеют в ES6 — а на таких замечательных и непременных штуках в тулчейнах девелоперов, как Uglify или Google Closure Compiler. Которые в 2017 году до сих пор не умеют даже в классы, какое там async/await...


К счастью, нашу либу в основном юзают из Node, поэтому это оказалось не так страшно. Но и там нашлись свои приколы: поле engine в package.json, судя по всему, не работает так, как многие думают. С его помощью вы не сможете запретить устанавливать ваш пакет в ранние версии Node (где ещё не появился, скажем, async/await). Раньше в NPM был флаг engineStrict, но теперь его убрали. И, убрав поддержку ES5 в своем проекте, мы столкнулись с тем, что многие юзеры до сих пор сидят на доисторических версиях Node и совсем не понимают, почему после npm update у них всё вдруг перестало работать...


В целом многие JS девелоперы вообще не понимают что такое Babel и как его настраивать. Вот например тут человек целый день провозился с настройкой вебпака, в итоге обматерил меня и мой проект, и написал свой собственный аналог :)


Транспилирование библиотек должно умереть, конечно же — т.к. ES модули позволяют импортировать только ту часть кода, которая реально используется (tree shaking). В ином случае, чтобы достичь подобного, приходится разбивать большие модули на миллион маленьких микромодулей (в пределе — до уровня отдельных функций), что крайне неудобно в плане поддержки...

Да, я советовал тому челу его попробовать, но он сказал что тот валится с out-of-memory-error, т.к. он запускает свой проект на amazon tiny instance, а там памяти как на калькуляторе...

Ещё есть бранч в uglify, называется uglify-es, тот тоже якобы может ES6, но я сам не пробовал..

И про поддержку доисторических Node.js. Уже давно было заявлено, что версии ниже Node 4 больше не поддерживаются. То есть они не получают вообще никаких обновлений, в том числе критических. Поддерживать их в своих библиотеках смысла нет, их уже не поддерживают множество популярных npm-модулей, например: https://github.com/request/request/issues/2772#issuecomment-330879495


А Node.js 4 много чего из ES6 понимает. Я использую ESlint с плагином node/no-unsupported-features, который понимает секцию engines из package.json и предупреждает об использовании неподдерживаемых ES6-фич

Интересное решение, спасибо! Обязательно попробуем. Сейчас в изоморфных (универсальных) аппах юзаем инъекцию скриптов после чека возможностей браузера. Работает норм именно потому что с сервера изначально приходит готовый html и есть время в фоне подгрузить скрипты. Для чистых SPA не очень-то хорошо, ваш способ определено лучше, если реально работает.
Это означает, что если авторы модулей начнут публиковать исходный код на ES2015+ в npm, то они, вероятно, сломают некоторые сборки пользователей и просто вызовут путаницу.

Было предложение добавить поле module в package.json, чтоб решить эту проблему, но пока воз и ныне там.
Sign up to leave a comment.

Articles