Ну и нет совместимости у федерализации с остальными сборщиками. Что привязывает консьюмеров к вебпаку.
а должна быть? Сборщик запилил такую вещь и логично, что завязывает на себя, чтобы пополнить комьюнити. Почему это не делают другие - вопрос. Хотя, судя по настроениям - не вопрос, ведь большинству либо страшно браться, либо "фу-фу, нафиг надо" . Для сборки приложенек - вебпак, для сборки либ - роллап. Для меня ну вот вообще не проблема привязки к сборщику. Можно, конечно, приплести сюда snowpack, vite и все остальное, но для меня скорости стало достаточно, отказавшись от babel в пользу esbuild, а если надо будет собрать все лучшее - там где-то еще должен жить gulp, можно велосипед из сборщиков вокруг него построить, только зачем?
дык, при потреблении федерализации откуда типы брать?
я уже выше писал, что из коммон либы я в своем случае складывал. Неудобно, но не смертельно, либо подцепить кастомную types в tsconfig (что, видимо, вы и сделали).
Например, все модули лежат по номерными ключами в глобальном объекте. Не знаю, как в пятой версии
Лежат точно так же в объекте, но не глобальном, если не указывать scope default. Каждый микрофронт может искать в отдельном скопе себе зависимости и выбрасывать туда, если нет зависимостей
У каждого выбора есть свои сильные и слабые стороны. В случае моем, все сильные стороны перекрыли слабые. И я в целом остался доволен, а предупредить про неприятные моменты - вот цель статьи, потому что нигде это не освещается практически
Нет, просто в хост приложении загружается uikit и шарится в микрофронт. Сответственно, инжектятся стили с хешами версии ядра. В микрофронте приложении uikit потребляется из хоста, но если версия будет, например, младше хоста и меняли, допустим, инпут или таблицу - стили отлетали, т.к. в дочернем приложении ожидаются другие хеши для css классов (использовались scss modules). Это как раз случай, когда, вероятно, использовать singleton для библиотеки не лучшее решение, но у нас uikit непонятным образом весит больше 2мб (точнее понятным - некоторую графику загнали в base64 в css и еще куча других проблем) и это мрак полный. Пришлось смириться и быть внимательным, чтобы обновлять единомоментно
Проблема тут еще в том, что uikit нам поставляли со стороны и информациооная поддержка была не лучшего качества - очень долго выбивали ченджлоги, в итоге пришли к тому, переодически высалаются PDF (!!!!) с описанием изменений, про сторибук молчу, больше выглядел как лишняя примочка не понятно для кого
А с чем конкретно возникла сложность в типизации? У нас были проблемы в типизации бутстрапа (устали костылить и влепили мужицкий ts-ignore) и точку входа в дочь, если меняется стор ядра (приходится генерировать .d.ts и перекладывать руками в common), а так в остальном проблем не было
Сейчас собираемся перейти на NX, так как в других проектах он себя хорошо показывает
Я видел, что NX не поддерживает отдельные релизы подсистем, это дейтсвительно так и насколько больнно делать свои workaround'ы для этого? У нас каждый фронт релизится отдельно, интересно попробовать спроецировать этот опыт на будущее и подготовиться :)
я так понял вы и сами с этим частично столкнулись
Да, но не сказал бы, что сильно было критично. Самая большая проблема с шарингом состояния и передачей из дочери в ядро. Например, пагинация у нас в шапке ядра, еще и хитровыдуманная, поэтому пришел к выводу, что нужно делать DI и выводить методы в стейт ядра, чтобы дочки их дергали. Отсюда и думаю, что в следующий раз попробовать общаться через воркеры, оценить затраты и плюсы/минусы
начал смотреть на NX, но слишком поздно, под конец проекта. На другом проекте обкатывают коллеги лерну и она им больше не нравится, чем нравится. Думаю, NX будет следующим. Но это история не про module federation
Сам module federation выбрал по нескольким причинам: 1) Шаринг зависимостей. Не нужно писать костыли для определения инстансов бибилиотек. 2) Подкупили утверждения автора технологии по поводу экономии сетевого трафика и это на самом деле оказалось правдой 3) По сути, конфигурация простая, но выглядит заковыристо. Пару строк в конфиг вебпака, бутстрап для энтиропоинта - и микрофронтенды готовы к работе 4) Я слишком буквально воспринял фразу "подключить любое приложение в любой момент". Никто другой не мог на тот момент предложить, что можно встроить без костылей и лишних библиотек/фреймоврков механизм работы с приложениями. Да, было что-то уже в вебпаке плагинчик (не помню как называется), который позволял делать схожее, но причина ниже. Я ориентировался на то, что завтра/полгода/год с бухты-барахты заказчик притащит команду ангулярщиков, а мы все пишем на реакте (реакт был в требованиях тз). И нам как-то придется всем месте жить, а бизнес слышит про микрофронты и думает, что все просто. 5) У меня была абсолютная свобода действий. Я люблю работать с новыми библиотеками, и тут подвернулся такой шанс. Хотя, возможно, сейчас бы я не стал так рисковать как год назад. А тогда я увидел новую хайповую фичу и решил попробовать.
Да и возможно выбор module federation был yolo-решением и, слава богу, оно сыграло и опрадалось. Но, опять же, впредь я вряд-ли рисковать буду таким образом
Вы совершенно правы, но, как говорится, кто платит - тот и музыку заказывает :)
Заказчик в будущем своими силами хочет расширять функционал системы и не хочет копаться в фронтовых делах. Ведь на самом деле дествительно легко поднять любое приложение на любом стеке и "вклинить" его в существующую систему, чем копаться в архитектуре и т.д., тем более, в какой-то момент это станет легаси и бизнес не захочет слышать просьбы на выделение средств на рефактор :) Но, это уже совсем другая история
остальное через feature modules можно решить
Если я не ошибаюсь, feature modules предполагает нахождение на одном сервере, а module federation позволяет тянуть части системы из любого места. Поправьте, если не прав.
Я всей ситуации не обладаю и не участвовал в проектирований всей системы, мне донесли как данность. Да и если бы хотел, всего рассказать не могу, сами понимаете. Но, постараюсь ответить, исходя из того, что получается в итоге.
Микрофроненды нашли хорошее применение в организации ролевого доступ к АРМ. Как я говорил в статье, у каждого приложения есть манифест и сервер о них знает. В зависимости от привелегий пользака, север формирует пул манифестов и отправляет его клиенту. Не обладая нужными правами, пользак при всем своем желании не попадет туда, куда не следует, просто потому, что ему этот микрофронт не доступен с домашней страницы. Конечно, он может попытаться по прямой ссылке пойти, но и там его ждет облом, но это уже немного другое
Целевая аудитория - системные администраторы, и у них есть разные уровни доступа. По требованиям ТЗ предполагается, что могут быть как локальные админы (администраторы структурной единицы в предприятия), так и супер админы (админ всего предприятия/нескольких предприятий, хоть всей РФ). Одни должны настраивать пул доменов, NTP, DNS и т.д., другим же достаточно предоставить доступ к управлению машинами, пользователям, принтерам. При этом, объем системы большой и изменение в функционале точечно затрагивают модули, снижая время на CI/CD и вывод в релиз отдельных элементов системы или выноса функционала в отдельный домен. К сожалению, были моменты корректировки ТЗ и на одной из крупных подсистем было очень много стихийных изменений, и мы бы уперлись в конфликты в репозитории и ожидании развертывания без микрофронтов, dev-стенд вообще по несколько раз в час обновлялся.
Так же, сильно ускорилась работа, были сформированы несколько команд/одиночных разработчиков, работающих абсолютно независимо друг от друга, без ожиданий очередей сборки с минимальными конфликтами в git
Более конкретно рассказать не могу, чтобы не получить по голове за разглашение :)
Надеюсь, ответил на Ваш вопрос, если нет, то уточните, где я свернул не туда
3) как-то странно, по сути статья сводится к тому, что кто-то изменил руками либу в node_modules и рассуждения вокруг этого? Это не то, что костыль, на это нормативной лексики недостаточно
Когда в моем проекте пришёл момент этот, я переписал роты на статичные и все остальное перенёс в query. Жить стало значительно легче
Самый несущественный. Лишние пересоздания кокомпонентове
Если у вас такая проблема, то наверняка вы неверно, особенно с шапкой, организовали роутинг. Как уже сказали выше, ту же шапку можно вынести из роута и всё, а все остальное можно проверить в одном месте, где роутинг конфигурируется, даже тот же location.
В первой части переизобрели бутстрап 4, во второй части в css уже видны проблемы отсутствия следования методологии какой либо
Для новичков материал суперский, но автору посоветовал бы пересмотреть подход к организации css, начиная с нейминга и раз вы используете scss - использовать миксины чаще и placeholder-классы. Даже "улучшенный" код можно ещё сократить, используя все выше, а спагетти из card-* упаковать в 3-5 строчек, используя map
я надеюсь, в проде вы так не делаете, как написали на примере. Разворачивать массив еще раз, да еще и по результирующей переменной вместо использования предыдущего состояния может вам очень больших проблем подкинуть
да как угодно, только то что указано в примере - явно указание на то, что ваш разработчик обладает крайне низкой компетенцией
надеются на помощь html-webpack-plugin и т.п.
потому что html-webpack-plugin имеет inject: 'body' опцию и сам вставит все скрипты в конец.
Если же так хочется контролировать инжекты, то вот, в порядке бреда:
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title><%= htmlWebpackPlugin.options.title %></title>
<% for (var css in htmlWebpackPlugin.files.css) { %>
<link rel="preload" as="style" type="text/css" crossorigin="anonymous" href="<%= htmlWebpackPlugin.files.css[css] %>" onload="this.rel='stylesheet'"/>
<% } %>
</head>
<body>
<!-- какой-то код -->
<% for (var js in htmlWebpackPlugin.files.js) { %>
<script async src="<%= htmlWebpackPlugin.files.js[js] %>"></script>
<% } %>
</body>
надеяться не надо на инструменты, а читать нормально доку и пользоваться.
История #3: корень всех зол
ну... не знаю, муху можно и мухобойкой прибить, можно и из базуки выстрелить. Результат будет один и тот же, вопрос только в целесообразности использования средства умерщвления.
Вы берете оптимизацию в разрезе отдельно, а смотреть надо в целом. Если у вас рендер меньше 16 мсек на страницу, то и бог с ней с мемоизацией. А если у вас 100+ объектов (а вы мап в мапе делаете), да и рендер уже выходит, допустим в 75 мсек? Не надо отвечать, это очередной холиварный вопрос, тут вопрос целесообразности, как я и говорил чуть выше
я предпочитаю не тратить время на то, что не дает профита
Следуя ваше логике: - я могу пойти к питонщикам и сказать, что их_такой_синаксисис полное говно - могу пойти к сишникам/джавистам и сказать, что их синтаксис и типизация слишком сложна, а работу с памятью я не понимаю и нафига оно вообще надо, в JS есть свой сборщик мусора и работает все прекрасно без обращений к нему - пойти в любой ООП и сказать, что прототипное наследование - отстой, потому что схема не прозрачна, а композиция - лучше! Зачем классы, когда можно процедурно набахать функций, вон с jQuery так все делали! - пойти в любую команию и сказать, нафига вы делаете микросервисные архитектуры и т.д. и т.п., возьмите ВордПресс, у него пыха не беке и работа с бд уже есть! А еще поставьте плагинчик, он вам и сваггер сам нарисует! - зачем CI/CD если есть FTP - зачем GIT если есть архиваторы
и т.д. и т.п.
И когда я скажу, что "я пришел к вам из JS, там все иначе, но я хочу узнать что-то новое", но все мне не будет нравиться, просто потому, что я так не привык...
Наблюдая за вашими комментариями под статьями, складывается впечатление, что вы не понимаете, зачем вам TS
Вы жили в других парадигмах, пришли в JS со "своим уставом" и удивляетесь, почему это не работает. Вам говорят, как принято в комьюнити сейчас, но вы упорно отказываетесь. На любой аргумент в пользу TS у вас 10 против, это нормально. Не нормально то, что вас должны все убедить перейти на TS под соусом вашей, якобы, открытости к новому.
На все вопросы даже в этой статье есть ответ. Бандлеры (роллап, вебпак, даже тот же гальп как таскраннер), плагины к ним делают те вещи, которые вы хотите, но не так, как вы хотите.
Давайте не будем лукавить: вы не собираетесь переходить на TS, вас не нужно убеждать, потому что кроме вас никто этого сделать не может. Вы не хотите принимать правила игры, потому что они вам не по вкусу, вы заложник своих привычек. С вашей точки зрения импорты не те, то не то, это не так...
а должна быть? Сборщик запилил такую вещь и логично, что завязывает на себя, чтобы пополнить комьюнити. Почему это не делают другие - вопрос. Хотя, судя по настроениям - не вопрос, ведь большинству либо страшно браться, либо "фу-фу, нафиг надо" .
Для сборки приложенек - вебпак, для сборки либ - роллап. Для меня ну вот вообще не проблема привязки к сборщику. Можно, конечно, приплести сюда snowpack, vite и все остальное, но для меня скорости стало достаточно, отказавшись от babel в пользу esbuild, а если надо будет собрать все лучшее - там где-то еще должен жить gulp, можно велосипед из сборщиков вокруг него построить, только зачем?
я уже выше писал, что из коммон либы я в своем случае складывал. Неудобно, но не смертельно, либо подцепить кастомную types в tsconfig (что, видимо, вы и сделали).
Лежат точно так же в объекте, но не глобальном, если не указывать scope default. Каждый микрофронт может искать в отдельном скопе себе зависимости и выбрасывать туда, если нет зависимостей
У каждого выбора есть свои сильные и слабые стороны. В случае моем, все сильные стороны перекрыли слабые. И я в целом остался доволен, а предупредить про неприятные моменты - вот цель статьи, потому что нигде это не освещается практически
К сожалению, такое случается :)
Когда заказчик узнал, что от MVP ничего не осталось, его удивлению не было предела :)
Нет, просто в хост приложении загружается uikit и шарится в микрофронт. Сответственно, инжектятся стили с хешами версии ядра.
В микрофронте приложении uikit потребляется из хоста, но если версия будет, например, младше хоста и меняли, допустим, инпут или таблицу - стили отлетали, т.к. в дочернем приложении ожидаются другие хеши для css классов (использовались scss modules). Это как раз случай, когда, вероятно, использовать singleton для библиотеки не лучшее решение, но у нас uikit непонятным образом весит больше 2мб (точнее понятным - некоторую графику загнали в base64 в css и еще куча других проблем) и это мрак полный. Пришлось смириться и быть внимательным, чтобы обновлять единомоментно
Проблема тут еще в том, что uikit нам поставляли со стороны и информациооная поддержка была не лучшего качества - очень долго выбивали ченджлоги, в итоге пришли к тому, переодически высалаются PDF (!!!!) с описанием изменений, про сторибук молчу, больше выглядел как лишняя примочка не понятно для кого
Тут ничего сказать не могу, но по отзывам куча issue на гитхабе открытых, которые никак не решаются, так что я лично не хочу с лерной связываться
А с чем конкретно возникла сложность в типизации? У нас были проблемы в типизации бутстрапа (устали костылить и влепили мужицкий ts-ignore) и точку входа в дочь, если меняется стор ядра (приходится генерировать .d.ts и перекладывать руками в common), а так в остальном проблем не было
@movlпромахнулся веткой, извините
Я видел, что NX не поддерживает отдельные релизы подсистем, это дейтсвительно так и насколько больнно делать свои workaround'ы для этого?
У нас каждый фронт релизится отдельно, интересно попробовать спроецировать этот опыт на будущее и подготовиться :)
Да, но не сказал бы, что сильно было критично. Самая большая проблема с шарингом состояния и передачей из дочери в ядро. Например, пагинация у нас в шапке ядра, еще и хитровыдуманная, поэтому пришел к выводу, что нужно делать DI и выводить методы в стейт ядра, чтобы дочки их дергали. Отсюда и думаю, что в следующий раз попробовать общаться через воркеры, оценить затраты и плюсы/минусы
Спасибо за ваш отзыв!
начал смотреть на NX, но слишком поздно, под конец проекта. На другом проекте обкатывают коллеги лерну и она им больше не нравится, чем нравится. Думаю, NX будет следующим. Но это история не про module federation
Сам module federation выбрал по нескольким причинам:
1) Шаринг зависимостей. Не нужно писать костыли для определения инстансов бибилиотек.
2) Подкупили утверждения автора технологии по поводу экономии сетевого трафика и это на самом деле оказалось правдой
3) По сути, конфигурация простая, но выглядит заковыристо. Пару строк в конфиг вебпака, бутстрап для энтиропоинта - и микрофронтенды готовы к работе
4) Я слишком буквально воспринял фразу "подключить любое приложение в любой момент". Никто другой не мог на тот момент предложить, что можно встроить без костылей и лишних библиотек/фреймоврков механизм работы с приложениями. Да, было что-то уже в вебпаке плагинчик (не помню как называется), который позволял делать схожее, но причина ниже. Я ориентировался на то, что завтра/полгода/год с бухты-барахты заказчик притащит команду ангулярщиков, а мы все пишем на реакте (реакт был в требованиях тз). И нам как-то придется всем месте жить, а бизнес слышит про микрофронты и думает, что все просто.
5) У меня была абсолютная свобода действий. Я люблю работать с новыми библиотеками, и тут подвернулся такой шанс. Хотя, возможно, сейчас бы я не стал так рисковать как год назад. А тогда я увидел новую хайповую фичу и решил попробовать.
Да и возможно выбор module federation был yolo-решением и, слава богу, оно сыграло и опрадалось. Но, опять же, впредь я вряд-ли рисковать буду таким образом
Вы совершенно правы, но, как говорится, кто платит - тот и музыку заказывает :)
Заказчик в будущем своими силами хочет расширять функционал системы и не хочет копаться в фронтовых делах. Ведь на самом деле дествительно легко поднять любое приложение на любом стеке и "вклинить" его в существующую систему, чем копаться в архитектуре и т.д., тем более, в какой-то момент это станет легаси и бизнес не захочет слышать просьбы на выделение средств на рефактор :) Но, это уже совсем другая история
Если я не ошибаюсь, feature modules предполагает нахождение на одном сервере, а module federation позволяет тянуть части системы из любого места. Поправьте, если не прав.
Я всей ситуации не обладаю и не участвовал в проектирований всей системы, мне донесли как данность. Да и если бы хотел, всего рассказать не могу, сами понимаете. Но, постараюсь ответить, исходя из того, что получается в итоге.
Микрофроненды нашли хорошее применение в организации ролевого доступ к АРМ. Как я говорил в статье, у каждого приложения есть манифест и сервер о них знает. В зависимости от привелегий пользака, север формирует пул манифестов и отправляет его клиенту. Не обладая нужными правами, пользак при всем своем желании не попадет туда, куда не следует, просто потому, что ему этот микрофронт не доступен с домашней страницы. Конечно, он может попытаться по прямой ссылке пойти, но и там его ждет облом, но это уже немного другое
Целевая аудитория - системные администраторы, и у них есть разные уровни доступа. По требованиям ТЗ предполагается, что могут быть как локальные админы (администраторы структурной единицы в предприятия), так и супер админы (админ всего предприятия/нескольких предприятий, хоть всей РФ). Одни должны настраивать пул доменов, NTP, DNS и т.д., другим же достаточно предоставить доступ к управлению машинами, пользователям, принтерам.
При этом, объем системы большой и изменение в функционале точечно затрагивают модули, снижая время на CI/CD и вывод в релиз отдельных элементов системы или выноса функционала в отдельный домен.
К сожалению, были моменты корректировки ТЗ и на одной из крупных подсистем было очень много стихийных изменений, и мы бы уперлись в конфликты в репозитории и ожидании развертывания без микрофронтов, dev-стенд вообще по несколько раз в час обновлялся.
Так же, сильно ускорилась работа, были сформированы несколько команд/одиночных разработчиков, работающих абсолютно независимо друг от друга, без ожиданий очередей сборки с минимальными конфликтами в git
Более конкретно рассказать не могу, чтобы не получить по голове за разглашение :)
Надеюсь, ответил на Ваш вопрос, если нет, то уточните, где я свернул не туда
почему нет совета использовать querySelector вместо ref? :) такое же тоже бывает
1) 1k скачиваний крайне мало
2) почему не https://www.npmjs.com/package/react-leaflet ? Тут хотя-бы ~200к скачиваний
3) как-то странно, по сути статья сводится к тому, что кто-то изменил руками либу в node_modules и рассуждения вокруг этого? Это не то, что костыль, на это нормативной лексики недостаточно
Когда в моем проекте пришёл момент этот, я переписал роты на статичные и все остальное перенёс в query. Жить стало значительно легче
Если у вас такая проблема, то наверняка вы неверно, особенно с шапкой, организовали роутинг. Как уже сказали выше, ту же шапку можно вынести из роута и всё, а все остальное можно проверить в одном месте, где роутинг конфигурируется, даже тот же location.
В первой части переизобрели бутстрап 4, во второй части в css уже видны проблемы отсутствия следования методологии какой либо
Для новичков материал суперский, но автору посоветовал бы пересмотреть подход к организации css, начиная с нейминга и раз вы используете scss - использовать миксины чаще и placeholder-классы. Даже "улучшенный" код можно ещё сократить, используя все выше, а спагетти из card-* упаковать в 3-5 строчек, используя map
я надеюсь, в проде вы так не делаете, как написали на примере. Разворачивать массив еще раз, да еще и по результирующей переменной вместо использования предыдущего состояния может вам очень больших проблем подкинуть
Не знаю, что за решение использует автор, но лично я смотрю в сторону Loki.
По поводу удобства не знаю, можете предварительно оценить по этому докладу (где-то в середине будет демонстрация Loki)
Это справедливо для работы в команде.
Иногда команда может состоять из одного тебя, или таких же как и ты и руководства сверху нет. Такое я встречал
заканчивается на выводе футера. Из того, что представлено это явно не футер для контейнера, а отдельная сущность и за такое надо бить по рукам
а может этот код будет работать каждый кадр?
да как угодно, только то что указано в примере - явно указание на то, что ваш разработчик обладает крайне низкой компетенцией
потому что html-webpack-plugin имеет inject: 'body' опцию и сам вставит все скрипты в конец.
Если же так хочется контролировать инжекты, то вот, в порядке бреда:
надеяться не надо на инструменты, а читать нормально доку и пользоваться.
ну... не знаю, муху можно и мухобойкой прибить, можно и из базуки выстрелить. Результат будет один и тот же, вопрос только в целесообразности использования средства умерщвления.
Вы берете оптимизацию в разрезе отдельно, а смотреть надо в целом. Если у вас рендер меньше 16 мсек на страницу, то и бог с ней с мемоизацией. А если у вас 100+ объектов (а вы мап в мапе делаете), да и рендер уже выходит, допустим в 75 мсек? Не надо отвечать, это очередной холиварный вопрос, тут вопрос целесообразности, как я и говорил чуть выше
я предпочитаю не тратить время на то, что не дает профита
Следуя ваше логике:
- я могу пойти к питонщикам и сказать, что их_такой_синаксисис полное говно
- могу пойти к сишникам/джавистам и сказать, что их синтаксис и типизация слишком сложна, а работу с памятью я не понимаю и нафига оно вообще надо, в JS есть свой сборщик мусора и работает все прекрасно без обращений к нему
- пойти в любой ООП и сказать, что прототипное наследование - отстой, потому что схема не прозрачна, а композиция - лучше! Зачем классы, когда можно процедурно набахать функций, вон с jQuery так все делали!
- пойти в любую команию и сказать, нафига вы делаете микросервисные архитектуры и т.д. и т.п., возьмите ВордПресс, у него пыха не беке и работа с бд уже есть! А еще поставьте плагинчик, он вам и сваггер сам нарисует!
- зачем CI/CD если есть FTP
- зачем GIT если есть архиваторы
и т.д. и т.п.
И когда я скажу, что "я пришел к вам из JS, там все иначе, но я хочу узнать что-то новое", но все мне не будет нравиться, просто потому, что я так не привык...
Короче, глупо все это...
Наблюдая за вашими комментариями под статьями, складывается впечатление, что вы не понимаете, зачем вам TS
Вы жили в других парадигмах, пришли в JS со "своим уставом" и удивляетесь, почему это не работает. Вам говорят, как принято в комьюнити сейчас, но вы упорно отказываетесь. На любой аргумент в пользу TS у вас 10 против, это нормально. Не нормально то, что вас должны все убедить перейти на TS под соусом вашей, якобы, открытости к новому.
На все вопросы даже в этой статье есть ответ. Бандлеры (роллап, вебпак, даже тот же гальп как таскраннер), плагины к ним делают те вещи, которые вы хотите, но не так, как вы хотите.
Давайте не будем лукавить: вы не собираетесь переходить на TS, вас не нужно убеждать, потому что кроме вас никто этого сделать не может. Вы не хотите принимать правила игры, потому что они вам не по вкусу, вы заложник своих привычек. С вашей точки зрения импорты не те, то не то, это не так...
К чему эта демагогия?