Микрофронтенды раздувают приложение дублированным кодом, делая его медленно грузящимся и неповоротливым. В результате комфорт и повышенная модность процесса разработки превращаются в ад для пользователя, который должен мириться с долгой загрузкой и постоянными провисаниями. Уверен, мода на дутые библиотеки/фреймворки, а также вот такие странные (для фронтенда) технологии уже подходит к концу, и маятник начинает двигаться в сторону производительности и комфорта для пользователя, этим упрощая фронтенд и перенося необходимую сложность назад, в сторону бекенда.
Я не говорил, что проблема версий уйдет, если не использовать микросервисы — я говорил, что эту проблему придется решать для каждого сервиса отдельно. Это создает дополнительную сложность и нивелирует плюсы микросервисов как параллельной разработки.
Дублирование кода — это уже как вы решите
В который раз говорю, это не так. Микросервисы как подход очень способствуют дублированию кода. Это неизбежно. Идея не нова (https://micro-frontends.org/), и то, что это добавляет абстракций и дубликатов, предполагается прямо в самом подходе микросервисов.
Производительность зависит не от данного фреймворка
Производительность зависит не от вашего фреймворка, а от самого решения использовать микросервисы, так как это всегда новые абстракции + дублированный код
Данный фремворк не работает с DOM деревом
Подлючаемые модули будут работать с дом-деревом. Но даже это не столь важно. Ресурсы, блокирующие рендеринг, не обязательно работают с DOM-деревом.
Еще раз — каждый модуль собирается в отдельный бандл и подгружается только тогда когда пользователь этот модуль использует.
Еще раз — в каждом модуле будет дублированный код, это неизбежно при использовании микросервисов
Если вам нужно поменять версию библиотеки, в любом случае вам нужно рефачить весь проект
Посмотрите на свою папку node_modules, загляните в файл package-lock. Каждый плагин имеет версию. Есть громадное количество причин, почему нужно сделать апгрейд того или иного плагина. Часто это происходит автоматически, в зависимости от проекта. Ну и если это будет общая библиотека для всех микросервисов, то внесение любого нового плагина / неизбежные изменения в существующих все равно нужно будет согласовывать с каждым сервисом в отдельности.
> Если вам нужно что-то простое и быстрое,
Нет, я имел в виду вообще любые веб-проекты. Любой проект, как бы он сложно не выглядел, во фронтенде он должен быть как можно более производительным, а значит как можно более простым.
> Это делается для того, чтобы ваше приложение можно было легко масштабировать, легко добавлять новый функционал, проверять бизнес теории
Когда на первом месте стоит пользователь этого приложения, а не модные идеи/удобная работа в команде/повышенная легкость масштабирования/принесенный опыт архитектур из java/желание вписать в резюме новый стек и так далее, то идея использовать микросервисы во фронтенде просто не возникнет.
> Чтобы избежать дублирование кода, можно вынести свои ui компоненты (инпуты таблицы модальные окна ...) в отдельную библиотеку.
Во фронтенде каждый микросервис будет иметь свои зависимости, у каждой зависимости будет своя версия и так далее. Если выносить общие зависимости в отдельную библиотеку, то каждая команда должна будет постоянно это обсуждать — например, перед апдейтом какого-то плагина из общей библиотеки с версии 1.0.17 до 1.0.18, и соотвественно вносить изменения в каждый из своих сервисов. Это нивелирует идею микросервисов (параллельная разработка и уменьшение зависимостей между командами), и в итоге только добавляет излишнюю сложность.
Статья ведь о микросервисах во фронтенде. Микросервисы предполагают, что часть функционала дублируется в каждом сервисе, и при загрузке грузятся сразу несколько сервисов, пусть даже в одном бандле. Это делает проект тяжеловесным.
По моему опыту во фронтенде, любые дополнительные уровни абстракции никогда не являются полностью «плюсом». Это всегда компромисс. И чем больше этих абстракций, тем более этот компромис в сторону минуса, чем плюса. Как бы красиво что-то не выглядело с точки зрения архитектуры или креативных идей, во фронтенде они все в конечном счете проходят проверку вопросами производительности. В общем все, что выполняется у пользователя в браузере, должно быть с технической точки зрения как можно более простым — если вы хотите, чтобы он заходил на ваш сайт часто. А тяжеловесные абстракции и новейшие архитектурные идеи лучше оставить там, откуда они пришли и где хорошо работают — в бекенде.
Использование нескольких фреймворков резко увеличит размер render-blocking resources. Также породит много дубликатов кода. Это сделает первоначальную загрузку сайта намного более долгой, что для современного проекта недопустимо. www.scientiamobile.com/mobile-site-visitors-abandon-more-than-3-seconds
Я тоже полгода жил в Висбадене, и все это время очень хотел оттуда уехать, так как там очень монотонно и скучно. При первой же возможности переехал в Кёльн и всё резко улучшилось) Так что, возможно, вам нужно было попробовать какой-то город в Германии, который бы был поживее Висбадена.
Другими словами, данное исследование показывает возможность создания искусственных атомов нового типа, электронные конфигурации которых можно будет настраивать по собственному желанию
Похоже, мечты алхимиков по созданию золота, наконец, начали осуществляться.
Это так. При меньшем техпроцессе потребляемая мощность, варьируемая или нет, будет меньше. При прочих равных условиях меньший техпроцесс позволяет уменьшить потребляемую мощность. Это очевидный факт.
Как насчёт третьих пентиумов на трёх техпроцессах?
Не знаю, не интересовался. Мы говорим о большинстве, а не о частных случаях. Очевидных примеров абсолютное большинство, даже лень гуглить.
основные затраты энергии — переключение между состояниями
Под «силой тока через транзистор» я имел в виду вообще трату энергии на работу транзистора, на переключение между состояниями в том числе. Суть остается прежней: меньше техпроцесс — меньше энергии тратится на работу транзистора.
Так же и число транзисторов не влияет на производительность чипа.
Тогда было бы странно постоянно увеличивать количество транзисторов при уменьшении техпроцесса — это, получается, действие себе в убыток? Но это всегда происходит — при уменьшении техпроцесса производитель почему-то сразу же наращивает количество транзисторов. И производительность улучшается. Влияние нелинейное и сильно зависит от архитектуры, но то, что зависимость присутствует, очевидно.
что-то вроде психологической длины зазора в условном транзисторе.
Если это влияет на силу тока через транзистор — это то, что нужно. Ведь именно это влияет на энергопотребление в результате. Энергопотребление нельзя увеличивать бесконечно — оно ограничено, например, батареей ноутбука, или установленными границами для десктопа. Поэтому и уменьшают техпроцесс — чтобы увеличить количество транзисторов при сохранении / уменьшении энергопотребления.
По моему опыту, этот «маркетинговый» техпроцесс вполне соответствует ожиданиям — то есть те же маркетинговые 14нм и 7нм заметно отличаются по своим характеристикам — производительности и энергопотреблению.
Филипп, занимайтесь тем, что у вас хорошо получается. Техпроцесс именно так и работает, характеризует размер транзисторов и других элементов на плате. Размер транзисторов влияет на энергопотребление.
Не количество ядер, а техпроцесс — это основное, чем сейчас АМД выделяется на фоне Интела. Чем меньше размер транзистора, тем больше их можно впихнуть под стандартное энергопотребление. Больше транзисторов — выше производительность. Но Интел вот собирается тоже печатать на 7нм у Тсмс, так что вполне возможно, что Интел снова вырвется вперед. А пока что АМД объективно впереди.
Да просто будет печататься у tsms, как уже делают все остальные (когда амд и эппл отдали печать на аутсорс, у них наоборот все вверх пошло). И параллельно ресёрчить свою печать, выяснять, что было не так с фабрикой на 10нм.
Я не говорил, что проблема версий уйдет, если не использовать микросервисы — я говорил, что эту проблему придется решать для каждого сервиса отдельно. Это создает дополнительную сложность и нивелирует плюсы микросервисов как параллельной разработки.
В который раз говорю, это не так. Микросервисы как подход очень способствуют дублированию кода. Это неизбежно. Идея не нова (https://micro-frontends.org/), и то, что это добавляет абстракций и дубликатов, предполагается прямо в самом подходе микросервисов.
Производительность зависит не от вашего фреймворка, а от самого решения использовать микросервисы, так как это всегда новые абстракции + дублированный код
Подлючаемые модули будут работать с дом-деревом. Но даже это не столь важно. Ресурсы, блокирующие рендеринг, не обязательно работают с DOM-деревом.
Еще раз — в каждом модуле будет дублированный код, это неизбежно при использовании микросервисов
Посмотрите на свою папку node_modules, загляните в файл package-lock. Каждый плагин имеет версию. Есть громадное количество причин, почему нужно сделать апгрейд того или иного плагина. Часто это происходит автоматически, в зависимости от проекта. Ну и если это будет общая библиотека для всех микросервисов, то внесение любого нового плагина / неизбежные изменения в существующих все равно нужно будет согласовывать с каждым сервисом в отдельности.
Нет, я имел в виду вообще любые веб-проекты. Любой проект, как бы он сложно не выглядел, во фронтенде он должен быть как можно более производительным, а значит как можно более простым.
> Это делается для того, чтобы ваше приложение можно было легко масштабировать, легко добавлять новый функционал, проверять бизнес теории
Когда на первом месте стоит пользователь этого приложения, а не модные идеи/удобная работа в команде/повышенная легкость масштабирования/принесенный опыт архитектур из java/желание вписать в резюме новый стек и так далее, то идея использовать микросервисы во фронтенде просто не возникнет.
> Чтобы избежать дублирование кода, можно вынести свои ui компоненты (инпуты таблицы модальные окна ...) в отдельную библиотеку.
Во фронтенде каждый микросервис будет иметь свои зависимости, у каждой зависимости будет своя версия и так далее. Если выносить общие зависимости в отдельную библиотеку, то каждая команда должна будет постоянно это обсуждать — например, перед апдейтом какого-то плагина из общей библиотеки с версии 1.0.17 до 1.0.18, и соотвественно вносить изменения в каждый из своих сервисов. Это нивелирует идею микросервисов (параллельная разработка и уменьшение зависимостей между командами), и в итоге только добавляет излишнюю сложность.
По моему опыту во фронтенде, любые дополнительные уровни абстракции никогда не являются полностью «плюсом». Это всегда компромисс. И чем больше этих абстракций, тем более этот компромис в сторону минуса, чем плюса. Как бы красиво что-то не выглядело с точки зрения архитектуры или креативных идей, во фронтенде они все в конечном счете проходят проверку вопросами производительности. В общем все, что выполняется у пользователя в браузере, должно быть с технической точки зрения как можно более простым — если вы хотите, чтобы он заходил на ваш сайт часто. А тяжеловесные абстракции и новейшие архитектурные идеи лучше оставить там, откуда они пришли и где хорошо работают — в бекенде.
www.scientiamobile.com/mobile-site-visitors-abandon-more-than-3-seconds
Похоже, мечты алхимиков по созданию золота, наконец, начали осуществляться.
Не знаю, не интересовался. Мы говорим о большинстве, а не о частных случаях. Очевидных примеров абсолютное большинство, даже лень гуглить.
Под «силой тока через транзистор» я имел в виду вообще трату энергии на работу транзистора, на переключение между состояниями в том числе. Суть остается прежней: меньше техпроцесс — меньше энергии тратится на работу транзистора.
Тогда было бы странно постоянно увеличивать количество транзисторов при уменьшении техпроцесса — это, получается, действие себе в убыток? Но это всегда происходит — при уменьшении техпроцесса производитель почему-то сразу же наращивает количество транзисторов. И производительность улучшается. Влияние нелинейное и сильно зависит от архитектуры, но то, что зависимость присутствует, очевидно.
Если это влияет на силу тока через транзистор — это то, что нужно. Ведь именно это влияет на энергопотребление в результате. Энергопотребление нельзя увеличивать бесконечно — оно ограничено, например, батареей ноутбука, или установленными границами для десктопа. Поэтому и уменьшают техпроцесс — чтобы увеличить количество транзисторов при сохранении / уменьшении энергопотребления.