Нативные EcmaScript модули: новые возможности и отличия от webpack

[jankovsky]

Круто что script src пробелы можно использовать!

[madkite]

А что тут такого крутого? Есть реальный use case? Не удивлюсь, если linter-ы начнут в ближайшем будущем warning-и за такие проблы показывать.

[mogaika]

Нативный… на js
*TIGGERED*

[Memfisrain]

В хроме вообще без шансов затестить?

[nialvi]

С недавнего времени теперь доступно в Chrome Canary под флагом.
Нужно открыть страницу chrome://flags/#enable-experimental-web-platform-features.
Включить флаг и перезагрузить браузер.
Проверить, что нативные модули работают, можно тут: https://codepen.io/malyw/project/full/DkddeZ/

[dreammaster19]

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

[jankovsky]

Давно уже паттерн «Модуль» в js существует, так нет, наворачивают ерунду.

[SuperPaintman]

Вероятнее всего опечатка, не exports, а export. (exports — это объект экспотра из commonjs / node.js).

const modulesSupported = typeof exports !== undefined;

// =>

const modulesSupported = typeof export !== undefined;

[SuperPaintman]

https://tc39.github.io/ecma262/#prod-Keyword
https://tc39.github.io/ecma262/#prod-ExportDeclaration

typeof exports; // => "undefined"

typeof export; // => SyntaxError: Unexpected token export

Т.е. typeof exports — это не SyntaxError, это валидный синтаксис.

[SuperPaintman]

Теперь вы знаете, что можно перейти с Webpack-а на нативные модули и даже знаете о существовании lodash-es.

Не совсем понимаю в чем реальный профит:

• 600 запросов, пусть и HTTP/2. Почему бы этот файл не склеить и не закешировать, ведь библиотеки не так часто обновляют в уже работающем проекте.
• Если используется не чистый JS, а Flow или TypeScript, все равно придется их чем-то транспилить / компиллить. Это же относится и к минификации.
• Хоть современны браузеры и быстро обновляются, но всегда будет IE или Safari. А значит нужны полифилы или фолбэки. А раз стоит такой выбор, то почему бы сразу не доунгрейднуть код транспилятором до ES5 и уже отточенных require.js / webpack модулей.

Я люблю модульную систему ESNext, и мне нравится ее спецификация (и строгость этой спеки), но мне кажется что ее миссия уже выполнена, она стандартизировала модули, и окончательно внесла ясность. А вот зачем использовать их нативную реализацию, для меня пока загадка. Или я что-то не понимаю?

[PsyHaSTe]

Хоть современны браузеры и быстро обновляются, но всегда будет IE или Safari. А значит нужны полифилы или фолбэки. А раз стоит такой выбор, то почему бы сразу не доунгрейднуть код транспилятором до ES5 и уже отточенных require.js / webpack модулей.

Но откуда возьмется поддержка в IE и Safari, если её туда не добавят разработчики? Замкнутый круг. Поддержки нет, потому что нет пользователей. Пользователей нет, потому что нет поддержки.

[MrDaedra]

Тем не менее, у webpack есть ряд преимуществ, таких как сокращение количества запросов и tree shaking.

[merrick_krg]

Но это и не должно входить в спеку по модулям. HTTP/2 решает проблему с кол-вом запросов, а tree shaking всегда может существовать отдельно вне контекста спеки(неважно commonjs или ESNext модули), в виде инструмента. И это только если мы говорим о браузере, а если еще посмотреть в сторону nodejs?