> As you can see, the most updated PHP wouldn't be able to serve JavaScript modules with an extension only NodeJS recognizes. Чё?

https://github.com/nodejs/node/pull/16170#issuecomment-336318420

Да он вообще ахинею несет

чет вообще не понял зачем отдельное расширение

Аргумент против m.js очень простые - ломает обратную совместимость

По поводу обратной совместимости — это допустимо если *.m.js никто больше не использует.

По поводу обратной совместимости — это допустимо если *.m.js никто больше не использует.

Да, но это все равно ломает обратную совместимость, а mjs - нет

Зачем кому то запускать mjs в браузере не понятно

Да, но это все равно ломает обратную совместимость, а mjs - нет

Не совсем. Всё в какой-то мере ломает обратную совместимость.

CommonJS не запускается в браузере и никто не умер

Зачем кому то запускать mjs в браузере не понятно

тем не менее, это будет возможно

Не совсем. Всё в какой-то мере ломает обратную совместимость.

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

а вебрефлекшн тупенький

он там полчаса назад очередной шитсторм в твиттере поднял

В том чтобы использовать file.m.js нет ничего не разумного, поэтому ломать нельзя

В том чтобы использовать file.m.js нет ничего не разумного, поэтому ломать нельзя

Я не спорю с выводами, но твоя логика неверна.

да все верно

.м.жс ломает намного больше, чем .мжс

.м.жс ломает намного больше, чем .мжс

Это выводы. А логика неверна.

В том чтобы использовать file.m.js нет ничего не разумного, поэтому ломать нельзя

По ней, в том, чтобы использовать file.m2076527k.js нет ничего не разумного, поэтому ломать совместимость с *.m2076527k.js нельзя.

Ну да

Но я думаю, что если сломать совместимость с *.m2076527k.js — это не сделает плохо никому.

Ты не согласен?

Да, это маловероятно. Но если этого можно избежать, то лучше этого избежать

Я честно скажу, я лично предпочел бы флаг в CLI

Но и с mjs особых проблем не вижу

с флагом не будет интеропа

а с mjs он есть

Да и ладно

в этом и суть

ну как ладно

Я знаю

ты думаешь весь нпм перепишут в момент релиза 9 ноды на мжс?

Но на мой взгляд без интеропа норм

Нет, зачем

Нужен cjs модуль - делаешь require

так кстати в 9 будет оно?

я чот так и не понял

Пока не ясно

Думаю, что нет

Я честно скажу, я лично предпочел бы флаг в CLI

Я бы предпочёл 'use module'; везде.

Ну для этого нужно чтобы tc39 это принял

И я готов это аргументировать, кмк это было бы единственным разумным решением для всех.

в ecma262 и так юз модуль имплицитный

Ну для этого нужно чтобы tc39 это принял

Да, очевидно. Он был бы разумным только в случае если бы ему следовали все.

в стрикте

А браузеры это заблокировали.

браузеры тут ни при чем

А без браузеров следующий вариант — *.mjs.

браузеры тут ни при чем

Как не при чём? Они сказали что не будут следовать 'use module'; даже если его кто-то введёт, и будут его игнорить.

они не говорили ничего такого

их не спрашивали

в es только одни модули есть

require - самодеятельность ноды

так что этот use module и так бай дефолт

так что этот use module и так бай дефолт

Нет же!

Он включается из хтмл.

они не говорили ничего такого

Ок, это то, что сказали отдельные разрабы браузеров.

Сами браузеры молчали, да.

Он включается из хтмл.

кто "он"?

кто "он"?

ESM же

https://developer.mozilla.org/ru/docs/Web/HTML/Element/script#attr-type

так что этот use module и так бай дефолт

Если бы так было, проблем бы не было вообще.

это для обратной совместимости

Модули и скрипты несовместимы в обе стороны.

ERROR: S client not available

это для обратной совместимости

Нет же!

а для чего?

Для того, чтобы включить режим esm для этого скрипта. Чтобы там делать export/import.

Аналог *.mjs в ноде и 'use module'; если бы он был.

По умолчанию это всё выключено, иначе бы была сломана обратная совместимость.

это нужно чтобы статически разрешать зависимости

а не динамически

это — что?

type=module

явно указывает браузеру, что надо до исполнения их разрешить

Эм. То есть ты утверждаешь, что без type=module ключевые слова import/export в браузерах будут работать?

они будут парситься (и давно парсятся)

но будет поздно разрешать зависимости

поэтому будет какая-то ошибка, но не из js

а от энва

который не нашел их

с т.з. js там все легально

они будут парситься (и давно парсятся)

Эм. Но модули/скрипты — это таргет на этапе парсинга, и его надо указать _до_ парсинга. Иначе не спарсится.

Хотя дабл парс можно, он не сильно медленный в реале.

я и говорю type=module как раз для того, чтобы после парсинга и до выполнения сделать статический резолв

хотя может там и дважды парсят, я не знаю как в разных браузерах это сделано

и позволяют ли движки после парсинга выполнить что-то внешнее

наверняка да

Скрипты и модули это синтаксически разные штуки. До парсинга надо понять под что мы парсим.

На пальцах: «спарсиСкрипт(текст)» и «спарсиМодуль(текст)» которые выдают дерево.

https://tc39.github.io/ecma262/#sec-ecmascript-language-scripts-and-modules

Дабл парс никто не хотел делать, и я сомневаюсь что браузеры его таки делают.

нет, синтаксически это одно и то же

семантически они разные

Нет

они будут парситься (и давно парсятся)

Можешь проверить в хроме и посмотреть, какая конкретно будет ошибка?

нет, синтаксически это одно и то же

Я ссылку на спеку дал!