Pull to refresh

Comments 7

но, к счастью, есть и более хорошее решение: Webpack 5 Module Federation.

Зачем? Есть же нативные модули? есть import-maps, и полифил для него, которое позволит из внутреннего приложения загрузить и стили и ресурсы через import.meta.url. и зависимости разруливаются.

Процитирую разработчика Webpack — Tobias Sokra:


No billion or trillion dollar company will use that. Import maps will realistically take 5 years to gain enough browser support to be used. It's like depending on polyfills to things that do not exist. Production code depends on a shim ultimately worse perf. Even when import maps come out, so what. Something still needs to append them to the page. Who cares if its script or something else, webpack will still need to manage it at scale and you still need tree-shaking. Plus import maps only “share”code if the path is exactly the same. Making it still no good and not near a replacement.

Еще добавлю отсутствие версионирования зависимостей, поддержку только JS модулей (без CSS и тд), повышенную нагрузку на сеть по кол-ву запросов и худшее сжатие. У меня была статья https://habr.com/ru/post/474672/ — import maps еще очень далеко до реального применения.

Процитирую разработчика Webpack — Tobias Sokra:

цитата Tobias Sokra, если честно больше похожа на выкрик, импорты плохо, а вот наша штука лучше. С модулями, начиная с requirejs было примерно так же, каждый раз был, вот те модули плохие, а наши лучше, в итоге имеем AMD, SystemJs, CommonJs и вот еще модули от вебпака. Если к импортам относиться так же, что они не будут использованы. То к вебпак модулям наверное так же надо:). Только разница, что es модули поддерживаются(будут поддерживаться в полном мере) нативно. Полифилы всегда используются. А если полифил еще и следует какому-то стандарту. То ИМХО лучше идти этим путем.
Еще добавлю отсутствие версионирования зависимостей

import-map поддерживает scope

поддержку только JS модулей (без CSS и тд)

если использовать полифил то там не только css модули

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

Использование es модулей подразумевает под собой использование http2, server push и тому подобное. нужно корректно настроить кеш, сервер пуш, etc.
худшее сжатие, вы про tree shaking? если так, то получаеться вам нужно каждый раз пересобирать, базовое приложение чтоб добавить нужные вендор зависимости, выпилить то что не нужно(если я правильно понял как работает Module Federation). То какой профит от мини фронтенда, если при релизи вроде бы как атомарного мини приложения, которая не должна аффектить все остально, нужно запускать всю сборку?

habr.com/ru/post/474672 — import maps еще очень далеко до реального применения.

да читал, и решения засорять глобальную область видимость через сервисворкер так себе. Все можно было сделать проще используя тот же роллап с конфигом на несколько строк, и этот скрипт вызывать в postinstall. И будет реакт акктуальной версии с es модулями.

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

В вебе пытаются стандартизировать, модули, модуль-импорты, да, нет инструментов для разработки из коробки, но их и не будет, если идти по пути реакта который не может определиться как публиковать пакеты или вебпака, который в 4ой версии не умеет билдить в нативный es модуль. Раньше было куча браузеров который изобретал свой стандарт, сейчас браузеров меньше стандарт один, но тут разработчики, теперь каждый раз изобретают свой стандарт)
Tobias Sokra, если честно больше похожа на выкрик, импорты плохо, а вот наша штука лучше

Полифил непринятого стандарта — это стремно. Вебпак давно зарекомендовавший себя инструмент, так что автор прав, ни одна серьезная компания на импорт-мапы пока не подпишется.


Использование es модулей подразумевает под собой использование http2, server push и тому подобное

Про HTTP2 я еще у себя в статье писал.


худшее сжатие, вы про tree shaking?

Крупные куски сжимаются лучше чем много мелких.


если я правильно понял как работает Module Federation

Не правильно, см презентацию https://github.com/sokra/slides/blob/master/content/ModuleFederationWebpack5.md — это живая система, а не "хоровой деплоймент".


да читал, и решения засорять глобальную область видимость через сервисворкер так себе

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


в вашем случае получаеться аффектиться сборка основного приложения с зависимостями

Вовсе нет. Хост разглашает, что у него есть, приложения — что нужно им и что есть у них, все это максимально развязано. В крайнем случае скачается несколько раз.

Самая главная проблема с импорт-мапами, даже со скоупами, в том, что хост обязан все знать про все модули, приложения, по всей видимости, могут догружать свои импорт-мапы но кто будет следить за чистотой, чтоб не было коллизий, и за оптимальным использованием версий и тд. Федерация поддерживает семвер например.

Полифил непринятого стандарта — это стремно. Вебпак давно зарекомендовавший себя инструмент, так что автор прав, ни одна серьезная компания на импорт-мапы пока не подпишется.


Ну у Вас какие-то двойные стандарты:). В Вашем решении вы используете вебкомпоненты, которые, тоже не особо железобетонный стандарт. С теми же HTML импортами там много вопросов. Те вы используете полифил не принятого, до конца стандарта:)
Так же, когда не был принят стандарт es модулей, в коде его активно использовали, а потом пропускали через babel, и как то не особо, люди беспокоились, что это не принятый стандарт. По поводу поддержки импортов, буквально пол года назад, была только поддержка в Chrome canary с флагом, сейчас во всех Chrome'ах с флагом, так что думаю скоро будет работать и без флага. По поводу Webpack, он хорош себя зарекомендовал для сборки бандла приложения, когда все в одном. А вот для сборки модуля, тут вопрос, тк на данный момент(в 4ой версии) он не умеет выплевывать es модуль(или я так и не смог понять как настроить его на это%).

Крупные куски сжимаются лучше чем много мелких.

Честно, я в этом вопще не вижу какой либо проблемы, тк такого рода проекты, пишутся где количество кода, ресурсов, стилей измеряется мегобайтами, и экономия в несколько килобайт как не выглядит не очень. ИМХО Тут другой подход нужен, тот же HTTP2, сервер пуш, сервис воркер.

Вовсе нет. Хост разглашает, что у него есть, приложения — что нужно им и что есть у них, все это максимально развязано. В крайнем случае скачается несколько раз.

Ну тогда получаеться:
Module Federation — это набор утилит для вебпака которые включает в себя какое то описание модуля, со своими зависимостями, и сборка всего этого.
Тот же import map, это просто будущий стандарт который позволяет зарезолвить нейминг в импортах для es модулей. es модули это не только модули js кода, но в будущем это и html и css в тех же вебкомпонентах. Тогда получаеться, если были бы утилиты которые могли сгенерировать import map, предоставить информацию другим мини приложении о том что есть у них, все это вместе собрать, то получиться все тоже самое, только с поддержкой нативных технологий. И тогда, наверное, можно было сравнивать. Но чтоб все это реализовать, нужно сделать несколько больше, чем просто написать конфиг для вебпака.

В целом я понял вашу идею — это еще один вариант реализации микрофронтенда с таким же количеством вопросов к обсуждению, как и в десятке других решений, существующих на текущий момент. Спасибо за статью)

Прошу прощения, но это у вас неверные сведения. Web Components — это Living Standard, реализованный на уровне браузера. Import Maps — not a W3C Standard nor is it on the W3C Standards Track. На сайте красным написано Unofficial Draft. В Бабеле все вещи минимум в драфте.


Более того, использование WC опционально, фреймворк и без них работает.

Only those users with full accounts are able to leave comments. Log in, please.

Articles