Комментарии 11
Теряется возможность использовать такие инструменты как Typescript;
Нет возможности минифицировать код и использовать Tree-shaking;
Нет возможности использовать алиасы для импортов.
- все эти три пункта - не соответствуют действительности. Но, зато есть реклама ТГ-канала... конечно.
Советую всем не ориентироваться на устаревшие и поверхностные статьи, а самим лучше разобраться в вопросе. С ESM и TypeScript прекрасно работает (как и все остальные важные тулзы), нет проблем со сборкой/минификацией/тришейкингом, и вы можете использовать самый обычный резолвинг модулей node-стайл, со всеми плюшками + importmap.
ЗЫ: насчет "спирали" еще очень странная мысль, ибо как-то я упустил момент, когда скрипты к сайту можно было подключить как-то иначе, чем через тег script...
C ESM весь инструментарий действительно работает. Но посыл был про то, что ESM открывает дорогу для разработки вне зависимости от среды исполнения, опуская шаги транспиляции и компиляции. Для типизации в этом случае также можно использовать typescript, но уже в ручную описывая d.ts. Или же использовать jsDoc.
P.S. Очевидно, что все скрипты подключаются через тэг script, но мы используем сборщики для этих целей и не пишем это руками.
С ESM и TypeScript прекрасно работает
Юзать транспилятор TS прямо в браузере откровенно говоря не лучшая идея. Минификация кода и treeshaking без сборщика? 😂
насчет "спирали" еще очень странная мысль
Зачем вы передергиваете, прекрасно понятно что имел ввиду автор поста
Ничего не понимаю. У меня все пэт-проекты работают без сборщиков. В чём проблема-то?
А рабочий проект в dev-версии работает без сборщика, а в для prod - собирается и минифицируется.
Для небольших проектов это понятно.
Автор говорит, что большие проекты без сборщиков не делают. Ну, да, соглашусь. Проблема ли это? Я в этом проблемы не вижу. Огромное количество запросов к серверу на загрузку огромного количества модулей - это не лучшая идея для создания производительного сайта. А если не тришейкать, то объема скриптов будет ещё больше.
Вот что ещё не отражено в статье, так это использование протокола http/2 для загрузки пакета скриптов. Типа за один запрос можно сразу же скачать кучу файлов. И тут нам может ещё помочь механизм esm preload. Тоже можно было бы осветить.
Ну, ещё что-то молчат о том, что можно брать package.json и конвертировать его в importmap для веба. Разные среды - разные загрузчики модулей, это норм.
Чтобы иметь полный контроль, необходимо было скачать код библиотеки и хранить его в том же репозитории, что и приложение. Однако библиотек со временем становилось все больше, а управлять этим становилось все сложнее.
Я выскажу, возможно, не самую популярную точку зрения, но.
Год или два назад тут проскакивала статья, что средний размер статьи в Интернете неуклонно растёт. Включая сюда статьи, которые жалуются, что средний размер статьи в Интернете неуклонно растёт. Реклама, трекинги, телеметрия, набор кросс-платформенных компонентов, чтобы приложение одинаково собиралось под веб, Android, iPhone и ZX Spectrum, а также замечательная зависимость, которая вычисляет, является ли число чётным, и которую до сих пор скачивают 1-2 миллиона раз в месяц.
Так вот, если вы чувствуете, что при помощи файлов вы уже не можете эффективно управляться со всем этим хозяйством… ОСТОНОВИТЕСЬ, ДЕМОНЫ!!!!111
С похожей темой был доклад на Frontendconf. Автор в рамках эксперимента попытался использовать современные стандарты для разработки приложения без зависимостей и этапа сборки.
Хорошо было бы рассказать в такой статье про imports, exports поля в package.json. Тема рассказана не до конца
Управление зависимостями в Javascript заходит на новый виток? Работа с ES модулями без сборщиков