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

В настоящее время я пишу веб-приложение, используя MEAN Stack, и пытаюсь написать код в 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

ОТВЕТЫ

Ответ 1

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

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

Ответ 2

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

  • Safari 10.1
  • Chrome 60 - за флагом экспериментальной веб-платформы в хром: флаги.
  • Firefox 54 - за настройкой dom.moduleScripts.enabled примерно: config.
  • Edge 15 - за настройками экспериментальных JavaScript в около: flags.

Ответ 4

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

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

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

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

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

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

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

import { sum } from './math';

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

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