Второй вариант — пример будущих тормозов. Каждое изменение observable свойств будет вызывать autorun. action и runInAction — откладывают вызов autorun до завершения. Автор mobx сам рекомендует все изменения выполнять в рамках action
И да и нет. Фреймворк позволяет всей команде мыслить в одном русле, проще взаимодействовать с сторонними разработчиками. Когда у вас свой велосипед, приходиться постоянно обучать персонал. Что усложняет привлекать сторонних разработчиков, ведь они не в курсе вашего велосипеда. Даже вроде такие ит гиганты РФ как yandex, mail, стараются использовать популярные готовые решения, а не пилить свое
Все дело в том, что ангулар предлагает архитектуру с коробки, которая устраивает минимум на 80%. Реакт по своей сути ничего не предлагает. Причина в фейсбуке. Они развивают реакт как им надо, а не сообществу. Сообщество соответственно начинает развивать свое. Сообщество огромна и по своей сути без явного лидера и костяка. Отсюда и весь этот зоопарк
Реакт сам по себе проще, чем ангулар. Отсюда и больше поклонников. Ангулар больше заточен на крупные приложения, а реакт нет. Чем больше проект, тем структура на Ангулар не сильно усложняется. Тогда как на реакте все зависит от архитектора проекта и скилов команды разработки. Т.е. кашу наварить очень легко.
Вам повезло видимо). Проходил как-то перед пандемией собеседованиям, так меня гоняли по особенностям языка, которые не то, что нужны, а вредны. Js: [] ==![]
Полностью согласен. iframe для B2C проектов можно сказать зло). Хочу сказать то, что текущие возможности не дают реализовать микрофронтенд. Возьмем для примера angular проекты — они используют фишки оптимизации при компиляции. Сюда также можно добавить и Svelte. Их сложно рассматривать в контексте микрофронтенд, описанный в статье. Грубо говоря они не рантаймные библиотеки и фреймворки. Нюансов много. Почему упомянул iframe, потому что сейчас это единственное, что гарантирует независимость частей. Микрофронтенд необходимость, но его надо развивать совместно с разработчиками браузеров и вводить новые методологии и технологии. Все что описывает статья это обычный модульный подход
У меня был опыт разработки независимых веб частей на SharePoint. Независимое в полном объеме. Это была кабала. Конфликты версий и прочее). В итоге начали внедрять глобальные общие библиотеки одной загрузкой, веб части подтягивали лишь локальные зависимости. Но как-то сильно легче не стало. Далее iframe начали активно использовать. Вот тогда стало намного легче. Проекты были корпоративные и SEO нас не волновало. Много что перепробовали, того, что в просторах интернета и не найти.
SPA проекты пробовали делить на dll(angular тема). Тоже попа). В итоге пришли снова на монолит). Единственное, что части проекта планируем выносить в отдельные репы и npm пакеты, чтобы разделить зону ответственности и снизить нагрузку при сборке основного проекта. Не стоит забывать и про фишки сборки, которые оптимизируют общий финальный код. По поводу мгновенной заливки изменения части общего проекта я против, пахнет отсутствием контроля и рисками грубых ошибок, сложно контролировать объемы кода. А так можно и эту часть автоматизировать.
Не могу понять, чем описанные подходы отличаются от модуля, плагина, библиотеки? Как по мне, ничем. Аналог микросервисов на фронте — это iframe. Пиши на любом фремворке или библиотеке. Текущие движения микрофронтенда создание нового хайпа, попытка назвать колбасу нечто новым и красивым именем)
Не очень понимаю направление ваших мыслей. Директивы представляют собой методы расширения. По своей сути они несут в себе все те же правила создания и использования. Это не плохо и не хорошо
В варианте с кнопками столь же изящного варианта нет, как минимум из коробки. Самый простой вариант из коробки и возможно наиболее правильный — это объявить шаблоны. Далее использовать NgTemplateOutlet для вывода нужного шаблона в зависимости от условия. Даю + за react).
Так к слову mat-raised-button — это не директива, а компонент. Просто она хостится не на новый тип тэга, а на существующую
В angular есть шаблоны(ng-template). Которые позволяют отрендерить нужный шаблон в зависимости от условия, передавать через инпуты и многое другое. Для ряда случаев можно использовать ng-container. Вариации использования много. Ваши претензии исходят из отсутствия глубокого понимания возможностей фреймворка или привычки писать под react.
Можно долго холиварить по поводу что лучше, что хуже. Тут надо исходить из требований и объема. Лично для меня уже сложилось мнение, что для чего-то простого, небольшого сайта — лучше svelte. Для чего-то посложнее, но не более — react. Если требуется сделать сложную, большую систему — лучше angular. Одним из простых причин выбора для последнего DI, без него сложно строить сложную систему максимально просто.
Насчет vue ничего не могу сказать толкового, не изучал особо, честно и желания нет.
Спасибо за статью! Раньше думал, что закинуть побольше вещей в DI, круто и правильно, то сейчас скажу нет. Стандартные вещи как window, document — считаю излишеством закидывать в DI. Ваша зависимость либо эмулирует поведение стандартной фичи, либо возвращает null(undefined). В целом сказал бы бесполезная процедура. Да и лишние затраты на создание провайдеров. Из опыта SSR, также добавлю, что в node.js чаще всего придется эмулировать браузерные объекты. Редко проекты обходятся без плагинов, которые заточены только под браузер
Blazor/C# — платформа, упрощающая разработку фронтенда, разработчикам бэкэнда. Все это напоминает разработку мобильного приложения: писать нативно или гибридный вариант. Часть ниши закроет, но скорее небольшую. Typescript актуален пока актуален js
Я в курсе таких нюансов. Основной посыл моего комментария был в том, что все это не дает явного плюса, а может и минуса больше. Фреймворки развиваются быстрее и поэтапно, упрощая разработку. А подобные технологии могут годами не обновляться, сильно зависимы от платформы(т.е. браузера). Если были бы более низкоуровневые технологии, позволящие получать заметно производительные варианты, то другой вопрос. А так нет
Чутье подсказывает, что развитие данного направления не имеет особого смысла. Как понимаю подобные компоненты работают примерно также(производительность), как и написанные на чистом js или с использованием фреймворка
Полностью согласен с комментариями выше о целесообразности использования микросервисов. Тоже ломали голову переходить или нет, в итоге не перешли). Оставили монолит, единственное думаем над тем, чтобы можно было разворачивать множество копий монолита на чтение для снижения нагрузки на один сервер и оставить один на изменение(консистентность данных в приоритете), разделив отправку запросов через какую нибудь проксю. Не было у кого-то подобного опыта?
Такие же проблемы проходили — грузить все или кусками. Второй подход у нас нельзя было реализовать. Решили подмену токенов на сервере делать. Т.е сервер генерировал скрипты на каждый язык и возвращал в готовом виде
SPA проекты пробовали делить на dll(angular тема). Тоже попа). В итоге пришли снова на монолит). Единственное, что части проекта планируем выносить в отдельные репы и npm пакеты, чтобы разделить зону ответственности и снизить нагрузку при сборке основного проекта. Не стоит забывать и про фишки сборки, которые оптимизируют общий финальный код. По поводу мгновенной заливки изменения части общего проекта я против, пахнет отсутствием контроля и рисками грубых ошибок, сложно контролировать объемы кода. А так можно и эту часть автоматизировать.
Не могу понять, чем описанные подходы отличаются от модуля, плагина, библиотеки? Как по мне, ничем. Аналог микросервисов на фронте — это iframe. Пиши на любом фремворке или библиотеке. Текущие движения микрофронтенда создание нового хайпа, попытка назвать колбасу нечто новым и красивым именем)
Так к слову mat-raised-button — это не директива, а компонент. Просто она хостится не на новый тип тэга, а на существующую
Можно долго холиварить по поводу что лучше, что хуже. Тут надо исходить из требований и объема. Лично для меня уже сложилось мнение, что для чего-то простого, небольшого сайта — лучше svelte. Для чего-то посложнее, но не более — react. Если требуется сделать сложную, большую систему — лучше angular. Одним из простых причин выбора для последнего DI, без него сложно строить сложную систему максимально просто.
Насчет vue ничего не могу сказать толкового, не изучал особо, честно и желания нет.
Полностью согласен с комментариями выше о целесообразности использования микросервисов. Тоже ломали голову переходить или нет, в итоге не перешли). Оставили монолит, единственное думаем над тем, чтобы можно было разворачивать множество копий монолита на чтение для снижения нагрузки на один сервер и оставить один на изменение(консистентность данных в приоритете), разделив отправку запросов через какую нибудь проксю. Не было у кого-то подобного опыта?
Такие же проблемы проходили — грузить все или кусками. Второй подход у нас нельзя было реализовать. Решили подмену токенов на сервере делать. Т.е сервер генерировал скрипты на каждый язык и возвращал в готовом виде