Какие браузеры поддерживают синтаксис импорта и экспорта для ECMAScript 6?

в настоящее время я пишу веб-приложение, используя средний стек, и пытаюсь написать код в ECMAScript 6 JavaScript; однако я получаю ошибки как в Chrome, так и в Firefox при использовании синтаксиса импорта и экспорта. Есть ли в настоящее время какие-либо браузеры, которые полностью поддерживают ECMAScript 6?

обратите внимание: я не спрашиваю, когда ECMAScript 6 будет поддерживаться браузерами. Я спрашиваю, какие браузеры поддерживают синтаксис импорта и экспорта ECMAScript 6. Видеть https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/ECMAScript_6_support_in_Mozilla#Features_not_yet_supported_by_Firefox

35
browser-support ecmascript-6 es6-module-loader es6-modules javascript

5 ответов

поддержка Chrome и Firefox import и export синтаксис (существуют тесты для правильный анализ).

не поддерживается загрузка модуля - вы не можете загрузить модуль любыми средствами, потому что спецификация для него не завершена. Для этого вы должны использовать какой-то модуль bundler. Я не front-end разработчик, но я слышал хорошие мнения о свернуть из моих коллег.

10

Он поддерживается в:

  • Safari 10.1
  • хром 61
  • Firefox 54 – за дом.moduleScripts.включен параметр в about:config для.
  • края 16
28

вот тут pollyfill который вы можете использовать для импорта модуля ES6.

Я успешно протестировал его на Chrome.

вот ссылка:http://github.com/ModuleLoader/browser-es-module-loader

Он также реализован изначально в Edge 14:

https://blogs.windows.com/msedgedev/2016/05/17/es6-modules-and-beyond

4

как уже говорили другие, поддержка по-прежнему очень ограничено. Но даже при полной поддержке.... будет ли разумно использовать его? Как мы это сделаем?

подумайте об этом. Типичное приложение JS, написанное с модулями Node JS, легко содержит десятки, даже сотни (очень маленьких) пакетов. Нам действительно нужно так много запросов?

Browserify, Webpack, Rollup и т. д. настолько популярны, потому что они позволяют нам связывать много небольших пакетов в одну быструю загрузку. С разделение кода мы можем позволить модулю bundler решить во время транспиляции, основываясь на коде, который наши страницы фактически используют, и на некоторых настройках конфигурации, сколько пакетов создать и что поместить в каждый из них. Таким образом, мы можем написать много маленький пакеты и служат им в качестве (нескольких) больших пакетов.

Я считаю, что мы должны разделить наш код на пакеты, которые хорошо работают на концептуальном уровне, а затем объединить эти пакеты в пакеты, которые хорошо работать на техническом (сетевом) уровне. Если мы напишем наш код на основе оптимального размера сетевого пакета, мы в конечном итоге пожертвуем модульностью в этом процессе.

тем временем, использование его, вероятно, только добавит путаницы. Например, посмотрите пример в блоге Edge:

import { sum } from './math.js';

обратите внимание, как они добавить расширение .js до from строку? В узле JS мы обычно пишем это как:

import { sum } from './math';

таким образом, приведенный выше код также будет работать на Edge? А насчет именованные пакеты? Я боюсь, что мы увидим много несовместимости здесь, прежде чем мы поймем, как заставить эти пути работать по всем направлениям.

Я бы рискнул предположить, что для большинства разработчиков, System.import останется в основном невидимым в браузерах, и только само программное обеспечение начнет использовать его (для целей эффективности), когда оно станет основным.

4

по данным руководство Google по стилю Javascript:

пока не используйте модули ES6 (т. е. export и import ключевые слова), как их семантика еще не завершена. Обратите внимание, что эта политика будет Повторите, как только семантика будет полностью стандартной.

// Don't do this kind of thing yet:
//------ lib.js ------
export function square(x) {
    return x * x;
}
export function diag(x, y) {
    return sqrt(square(x) + square(y));
}

//------ main.js ------
import { square, diag } from 'lib';

однако, import и export реализованы во многих транспилерах, таких как компилятор Traceur, Babel или Rollup.

0