Речь об этом:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules

You need to pay attention to local testing — if you try to load the HTML file locally (i.e. with a file:// URL), you'll run into CORS errors due to JavaScript module security requirements. You need to do your testing through a server.

В чём смысл? Кроме, конечно, как заставить разрабов разрабатывать всё в облаках. Он вообще есть, этот смысл?

Вот, например, если делать Chromium-based приложения. По ряду причин мне удобно всю разметку, стили, скрипты и прочие РЕСУРСЫ включать в дистрибутив. В частности, чтобы обновлять вместе с версией приложения, а не качать всё это каждый раз, когда система кеширования решит, что пора. При первом запуске, например )) А на сервер ходить только с запросами на получение и изменение данных. Есть и другая причина: обновление версии должно быть личным делом юзера. Не нравится новый UI — сиди на старом, пока формат данных не изменится, всё ОК.

Однако, выходит, если хочешь при разработке иметь удобства модульности (ремаппинги, например, для тестовых билдов), то обязан качать все ресурсы с сервера. Это заговор злых корпораций?

Здравствуйте, Alekzander, Вы писали:

A>Однако, выходит, если хочешь при разработке иметь удобства модульности (ремаппинги, например, для тестовых билдов), то обязан качать все ресурсы с сервера. Это заговор злых корпораций?

Гиви! Нам тут сказали, что все твои однокурсники ездят в институт на автобусе, я ты один — на такси. Не выпендривайся, Гиви. Будь, как все. Купи себе автобус и езди на автобусе!

А что мешает личный сервер для отладки завести, если облачный не устраивает?

Ограничения CORS придуманы, чтобы в релизе пользователя не взломали.

Здравствуйте, Pzz, Вы писали:

Pzz>А что мешает личный сервер для отладки завести, если облачный не устраивает?

Так я, вроде, объяснил, что мешает. Мешает желание запаковать скрипты в ресурсы приложения. И не для отладки, а для продакшена.

Pzz>Ограничения CORS придуманы, чтобы в релизе пользователя не взломали.

А локальные файлы тут с какого боку? Если у меня уже есть доступ на запись к ФС юзера, про какую безопасность вообще можно говорить?

Здравствуйте, Alekzander, Вы писали:

Pzz>>Ограничения CORS придуманы, чтобы в релизе пользователя не взломали.

A>А локальные файлы тут с какого боку? Если у меня уже есть доступ на запись к ФС юзера, про какую безопасность вообще можно говорить?

Чтобы неизвестно откуда взявшийся JS не шарил по локальным файлам? В т.ч., не пытался их исполнять...

Здравствуйте, Alekzander, Вы писали:

A>Однако, выходит, если хочешь при разработке иметь удобства модульности (ремаппинги, например, для тестовых билдов), то обязан качать все ресурсы с сервера. Это заговор злых корпораций?
Не понял, причем тут облака и качать с сервера? Мозила говорит, что открытие в браузере локального хтмл-файла будет сыпать ошибками. Запусти свое приложение как положено или открой файл в liveserver (расширение для vscode) и тестируй/правь. Или речь о чем-то другом?

Здравствуйте, Alekzander, Вы писали:

A>Однако, выходит, если хочешь при разработке иметь удобства модульности (ремаппинги, например, для тестовых билдов), то обязан качать все ресурсы с сервера. Это заговор злых корпораций?

Вообще это сделано чтобы javascript не мог читать локальные файлы, если он вдруг это захочет. И это IMHO есть хорошо.

Для оффлайн-приложений (которые не требуют интернета) есть стандартное решение — PWA/web workers, можно все хранить в кэше браузера,
хоть десятки гигабайтов (увидел тут недавно — народ LLM хранит, лол — образы виртуалок, по сути)

Для встраиваемых браузеров (типа electron или edge web view) это отключается через параметры.
Также у всех браузеров есть ключ настройки, позволяющий блокировку file:/// отключить (для FF была кнопка-плагин AFAIR)

В самом тупом случае разработки удобно пользоваться live-server (встроенный в vs code)

Здравствуйте, Pzz, Вы писали:

Pzz>>>Ограничения CORS придуманы, чтобы в релизе пользователя не взломали.

A>>А локальные файлы тут с какого боку? Если у меня уже есть доступ на запись к ФС юзера, про какую безопасность вообще можно говорить?

Pzz>Чтобы неизвестно откуда взявшийся JS не шарил по локальным файлам? В т.ч., не пытался их исполнять...

Выполнять код, разбитый на два неизвестно откуда взявшихся скрипта JS — безопасно, птички летают, солнышко светит, благорастворение воздусей.

Выполнять код, разбитый на два неизвестно откуда взявшихся модуля JS — голактего опасносте, повторяю, голактего опасносте!!!

Если разобраться, модули-то побезопаснее будут (из-за strict).

Кроме того, наличие "неизвестно откуда взявшегося JS" намекает на права доступа к ФС юзера. Если они у меня будут, я не стану размениваться на вызов скриптов браузера юзера, а спижжу сразу всю юзерскую директорию с куками и другими личными данными.

Наконец, что мешает ограничить допустимое пространство одним локальным скоупом? Ну, Хромиум не поддерживает res://, так что речь могла бы идти об одной папке. В рамках одной папки разбивай js на модули сколько хочешь.

Здравствуйте, rFLY, Вы писали:

A>>Однако, выходит, если хочешь при разработке иметь удобства модульности (ремаппинги, например, для тестовых билдов), то обязан качать все ресурсы с сервера. Это заговор злых корпораций?
FLY>Не понял, причем тут облака и качать с сервера?

Гугл последовательно ведёт атаку на файлы, а Мозиллу давно уже пора переименовать в Киваллу, им бы больше подошло. Логично предположить, что за этим стоит интерес перетащить всех в свои облака.

>Мозила говорит, что открытие в браузере локального хтмл-файла будет сыпать ошибками. Запусти свое приложение как положено или открой файл в liveserver (расширение для vscode) и тестируй/правь. Или речь о чем-то другом?

Речь идёт о приложениях типа Steam. С чего ты решил, что ресурсы для таких приложений это не "как положено"? А расширение для vscode ты в продакшен не отдашь, лицензия не позволит, гы-гы.

Здравствуйте, bnk, Вы писали:

A>>Однако, выходит, если хочешь при разработке иметь удобства модульности (ремаппинги, например, для тестовых билдов), то обязан качать все ресурсы с сервера. Это заговор злых корпораций?
bnk>Вообще это сделано чтобы javascript не мог читать локальные файлы, если он вдруг это захочет. И это IMHO есть хорошо.

Javascript при импорте модулей может читать только код, и только куски, помеченные на экспорт. И чтобы он выполнился, на него надо сослаться в разметке (в <script>'е или опосредованно — подменой в карте импорта). Если ты можешь в разметке создавать <script>'ы, ты можешь с тем же успехом подтянуть любой js-файл. Но только не страшный js-файл, оформленный как модуль! Хотя модули даже чуточку безопаснее, из-за запрета на некоторые трюки в strict'е. В этом и вопрос, где тут логика. Логика, ау! Нет тебя, и бога нет. На головы корпораций зла.

bnk>Для оффлайн-приложений (которые не требуют интернета) есть стандартное решение — PWA/web workers, можно все хранить в кэше браузера,
bnk>хоть десятки гигабайтов (увидел тут недавно — народ LLM хранит, лол — образы виртуалок, по сути)

Извращенцы. Есть золотой стандарт — файлы, поддерживаются везде, но нет, надо залезть к чёрту в зубы, привязаться к кэшу браузера. Ссаных npm-зумеров хлебом не корми, дай продуктовый пайплайн завязать на как можно большее число сторонних решений.

bnk>Для встраиваемых браузеров (типа electron или edge web view) это отключается через параметры.
bnk>Также у всех браузеров есть ключ настройки, позволяющий блокировку file:/// отключить (для FF была кнопка-плагин AFAIR)

А вот это уже тема. Спасибо! Действительно, должно же это поведение отключаться.

bnk>В самом тупом случае разработки удобно пользоваться live-server (встроенный в vs code)

В продакшене?

Здравствуйте, Alekzander, Вы писали:

A>Здравствуйте, bnk, Вы писали:

A>>>Однако, выходит, если хочешь при разработке иметь удобства модульности (ремаппинги, например, для тестовых билдов), то обязан качать все ресурсы с сервера. Это заговор злых корпораций?
bnk>>Вообще это сделано чтобы javascript не мог читать локальные файлы, если он вдруг это захочет. И это IMHO есть хорошо.

A>Javascript при импорте модулей может читать только код, и только куски, помеченные на экспорт. И чтобы он выполнился, на него надо сослаться в разметке (в <script>'е или опосредованно — подменой в карте импорта). Если ты можешь в разметке создавать <script>'ы, ты можешь с тем же успехом подтянуть любой js-файл. Но только не страшный js-файл, оформленный как модуль! Хотя модули даже чуточку безопаснее, из-за запрета на некоторые трюки в strict'е. В этом и вопрос, где тут логика. Логика, ау! Нет тебя, и бога нет. На головы корпораций зла.

Не лучше блокировать опасности сразу на входе?
Для доступа к локальным файлам есть JavaScript API — File system API, которое позволяет нормально явно запросить доступ к файлам или папкам у пользователя, а потом их писать-читать (в пределах разрешенной папки) через File API
См. например как работает VS Code в браузере (https://vscode.dev/)

bnk>>Для оффлайн-приложений (которые не требуют интернета) есть стандартное решение — PWA/web workers, можно все хранить в кэше браузера,
bnk>>хоть десятки гигабайтов (увидел тут недавно — народ LLM хранит, лол — образы виртуалок, по сути)

A>Извращенцы. Есть золотой стандарт — файлы, поддерживаются везде, но нет, надо залезть к чёрту в зубы, привязаться к кэшу браузера. Ссаных npm-зумеров хлебом не корми, дай продуктовый пайплайн завязать на как можно большее число сторонних решений.

Вовсе нет, IMHO крутейшая вещь. Получаешь что можно запускать штуки типа ChatGPT (ну попроще конечно, опенсорсные Llama например 4GB) или Stable Diffusion (websd) без привязки к сторонним сервисам, прямо в браузере (отключенном от интернета)
По сути же можно запускать скачанную "виртуалку" прямо в браузере (WebGPU, WebNN). Браузер постепенно превращается в операционку.
демка https://chat.webllm.ai/

bnk>>Для встраиваемых браузеров (типа electron или edge web view) это отключается через параметры.
bnk>>Также у всех браузеров есть ключ настройки, позволяющий блокировку file:/// отключить (для FF была кнопка-плагин AFAIR)

A>А вот это уже тема. Спасибо! Действительно, должно же это поведение отключаться.

Это какой-то ключ командной строке запуска браузера, насколько я помню.
Возможно есть в chrome://flags

bnk>>В самом тупом случае разработки удобно пользоваться live-server (встроенный в vs code)

A>В продакшене?

Ну зависит от того что нужно. Я если честно твою цель не очень понял?

Здравствуйте, bnk, Вы писали:

bnk>Не лучше блокировать опасности сразу на входе?
bnk>Для доступа к локальным файлам есть JavaScript API — File system API, которое позволяет нормально явно запросить доступ к файлам или папкам у пользователя, а потом их писать-читать (в пределах разрешенной папки) через File API
bnk>См. например как работает VS Code в браузере (https://vscode.dev/)

Так давай для безопасности сразу все скрипты запретим. На входе.

Почему один из двух видов локальных скриптов разрешён, а другой (более безопасный) — нет?

bnk>Браузер постепенно превращается в операционку.

Ну так, я сразу и сказал: чувствуется, что за всем этим стоит Гугл.

bnk>Это какой-то ключ командной строке запуска браузера, насколько я помню.
bnk>Возможно есть в chrome://flags

Спасибо ещё раз, но это делается не так. Это или параметр в конфиге, либо вызов нативной функции (на C++). Возможно даже, что это по дефолту сделано в CEF'е.

Я просто подумал: жизнь проходит мимо, люди юзают модули, а я всё по старинке. Стал читать спеки, а там такое. Но если подумать, то ну их нахер, эти модули. Если ещё надо что-то там для них отключать. Завтра, когда все перейдут на модули, Гугл запретит их отключение, и привет.

Что такого мегаполезного они несут?

bnk>>>В самом тупом случае разработки удобно пользоваться live-server (встроенный в vs code)
A>>В продакшене?

bnk>Ну зависит от того что нужно. Я если честно твою цель не очень понял?

C++ приложение с интерфейсом на HTML.

Здравствуйте, Alekzander, Вы писали:

bnk>>Ну зависит от того что нужно. Я если честно твою цель не очень понял?

A>C++ приложение с интерфейсом на HTML.

Для встраиваемого да, эта "безопасность" не имеет смысла, поскольку все скрипты ты сам контролируешь
У CEF должна быть настройка.

Здравствуйте, bnk, Вы писали:

bnk>По сути же можно запускать скачанную "виртуалку" прямо в браузере (WebGPU, WebNN). Браузер постепенно превращается в операционку.

Потом в браузере появится централизованная конфигурация прав доступа, которая всё запрещает по умолчанию, никто её не будет настраивать, людей это задолбает, и они сделают браузер-в-браузере, где всё просто работает.

Здравствуйте, Alekzander, Вы писали:

A>Речь идёт о приложениях типа Steam.
Стим всегда тормозил. Во всяком случае я ощущаю задержки в его интерфейсе. У тебя отзывчивей получится?

A>С чего ты решил, что ресурсы для таких приложений это не "как положено"? А расширение для vscode ты в продакшен не отдашь, лицензия не позволит, гы-гы.
Ты так изложил суть проблемы, что я (и судя по следующему ответу не один) предположил, буд-то проблема в разработке. Мол я запускаю файл, а оно ругается и заставляет все на сервак переносить.

Смысл в том, что браузерами так никто не пользуется. Поэтому проще натянуть модель из HTTP, чем пытаться что-то изобретать для неиспользуемого юз-кейса. Безопасно и ладно. А разработчики всегда пользуются локальными серверами, это банально удобней, там и live reload есть и прочие удобства.

Если тебе очень хочется всё в виде файла распространять — сделай бандл из одного файла и всё.

А приложения обычно встраивают HTML движок или используют готовый и там опять же никаких проблем нет его сконфигурировать как душе угодно.

Здравствуйте, vsb, Вы писали:

vsb>А приложения обычно встраивают HTML движок или используют готовый и там опять же никаких проблем нет его сконфигурировать как душе угодно.

Надолго ли...

Но всё равно спасибо! Сам я в эту сторону не подумал.

Здравствуйте, rFLY, Вы писали:

A>>Речь идёт о приложениях типа Steam.
FLY>Стим всегда тормозил. Во всяком случае я ощущаю задержки в его интерфейсе. У тебя отзывчивей получится?

Да. Я как раз специализируюсь на этом. Когда, например, я столкнулся с тормозами на слабых Андроид-девайсах вебвьюшной медиа-подсистемы, я написал и прикрутил свою. Причём, как доктор Франкенштейн — пришил её нитками наживую, не пересобирая webview. Если хочешь писать хорошие интерфейсы, надо не бояться испачкать руки в грязных хаках низкоуровневых деталях.

А в случае Стима там ошибка в системе размером во всю систему, я б сказал

A>>С чего ты решил, что ресурсы для таких приложений это не "как положено"? А расширение для vscode ты в продакшен не отдашь, лицензия не позволит, гы-гы.
FLY>Ты так изложил суть проблемы, что я (и судя по следующему ответу не один) предположил, буд-то проблема в разработке. Мол я запускаю файл, а оно ругается и заставляет все на сервак переносить.

Проблема в том, куда всё идёт. Но не все её видят. Выше мне говорят, мол, все збс, просто редкий юз-кейс