Личное предпочтение - это ориентироваться на библиотеки. Каждую страницу из примеров можно формировать как библиотеку. Библиотеки упрощают поддержку и управление версиями, используемых сторонних библиотек и фреймворков. Пример: используются разные версии angular в разных конечных продуктах, приложениях. Без обсуждения почему). Сборка монолита из кусков позволяет проконтролировать ошибки взаимодействий, провести оптимизацию сборки и многое другое. Среда исполнения в браузере единое. Не стоит забывать об этом, когда делаются аналогии с микросервисами. Не знаю как сделано в сбербанке, не смотрел код, похоже применяется что-то схожее с микрофронтедом. Бесит, что стилистика и взаимодействие с ui отличается от места к месту. Хотя не скажу,что там что-то сложное
Большинство используют такой подход, это позволяет проще подбирать стороннюю библиотеку под проект. Ваш же подход ломает сложившийся подход. Ничто не мешает релизить под несколько мажорных версий).
Явно потери будут. Вопрос на сколько сильны. Из опыта использования переменных в css думаю 99% современных пользователей и не заметят разницы. Также вопрос производительности отнимает много ресурсов, т. е. денег. Если заказчик готов тратить на это ресурсы, то это одно дело, если нет, то оно надо париться за 0.5 сек первичной отрисовки). Как по мне лучше выбрать более комфортные механизмы разработки. Классы, по 1000 раз переопределяющие свойства элемента, тоже могут снижать производительность
Время - течение процессов. На течение процессов влияет гравитация. Гравитация замедляет процессы. Чёрная дыра для примера. Соответственно изменяется и время относительно объекта. При движении (не ускорение, а скорость), увеличивается масса. И чем ближе к скорости света, тем выше масса. Чем больше масса, тем больше гравитационные взаимодействия. Природу этого пока не могут объяснить. Почему скорость фотонов ограничена этой скоростью?
Отличный коммент! Видя внешне базовые хуки, их производные, эти непонятные механизмы сторов, вызывает глубокое отвращение. И самое главное на серьёзных щах восхищаются этим)
Ваше мнение сводится к привычке. Для примера мне удобнее вводить номер банковской карты там, где есть автоматическое разделение пробелом между цифрами аналогичной той схеме, что и на самой карточке. К хорошему привыкаешь быстро)
Из своего опыта: лучше сводить архитектуру к библиотеко-ориентированному подходу. Каждая библиотека представляет собой независимый модуль, требует соответствующего подхода разработки. Т. Е. мы имеем дело с чёрным ящиком. Пользователь библиотеки не заботится о внутреннем устройстве, качество руки програмиста, что писал код. Его заботит лишь интерфейс и гибкость управления им. Ещё неоспоримым преимуществом этого подхода - максимальная готовность кода. Сборка проекта внутренних компонентов может съедать много времени. У меня есть пример холодной сборки в dev режиме angular-cli 5 минут. На prod 20 минут. А так, архитектуру подбирают под требования.
Личное предпочтение - это ориентироваться на библиотеки. Каждую страницу из примеров можно формировать как библиотеку. Библиотеки упрощают поддержку и управление версиями, используемых сторонних библиотек и фреймворков. Пример: используются разные версии angular в разных конечных продуктах, приложениях. Без обсуждения почему). Сборка монолита из кусков позволяет проконтролировать ошибки взаимодействий, провести оптимизацию сборки и многое другое. Среда исполнения в браузере единое. Не стоит забывать об этом, когда делаются аналогии с микросервисами. Не знаю как сделано в сбербанке, не смотрел код, похоже применяется что-то схожее с микрофронтедом. Бесит, что стилистика и взаимодействие с ui отличается от места к месту. Хотя не скажу,что там что-то сложное
В первом вопросе подумал про парня за дверью, показывающего двойку через большой палец. У немцев вроде так принято. С самоваром плохо видно
Большинство используют такой подход, это позволяет проще подбирать стороннюю библиотеку под проект. Ваш же подход ломает сложившийся подход. Ничто не мешает релизить под несколько мажорных версий).
Я бы связал мажорную версию библиотеки с мажорной версией angular
Явно потери будут. Вопрос на сколько сильны. Из опыта использования переменных в css думаю 99% современных пользователей и не заметят разницы. Также вопрос производительности отнимает много ресурсов, т. е. денег. Если заказчик готов тратить на это ресурсы, то это одно дело, если нет, то оно надо париться за 0.5 сек первичной отрисовки). Как по мне лучше выбрать более комфортные механизмы разработки. Классы, по 1000 раз переопределяющие свойства элемента, тоже могут снижать производительность
В точку!
Интернет в руки и почитайте о зависимости массы от скорости. Почему фотон способен достичь максимальной скорости света, а вы нет
Время - течение процессов. На течение процессов влияет гравитация. Гравитация замедляет процессы. Чёрная дыра для примера. Соответственно изменяется и время относительно объекта. При движении (не ускорение, а скорость), увеличивается масса. И чем ближе к скорости света, тем выше масса. Чем больше масса, тем больше гравитационные взаимодействия. Природу этого пока не могут объяснить. Почему скорость фотонов ограничена этой скоростью?
Подобных статей писать не надо. Однозначно минус. Название не соответствует содержанию.
Отличный коммент! Видя внешне базовые хуки, их производные, эти непонятные механизмы сторов, вызывает глубокое отвращение. И самое главное на серьёзных щах восхищаются этим)
Также). Думаю что причина в наметанном глазе и опыте. Уже просто сложно удивить
Находить чужие ошибки проще, чем свои). Вывод: необходимо либо тестирование отдельным сотрудником, либо взаимный обмен с коллегами
да)
Ваше мнение сводится к привычке. Для примера мне удобнее вводить номер банковской карты там, где есть автоматическое разделение пробелом между цифрами аналогичной той схеме, что и на самой карточке. К хорошему привыкаешь быстро)
Мне больше по душе mobx в связке с angular.
Из своего опыта: лучше сводить архитектуру к библиотеко-ориентированному подходу. Каждая библиотека представляет собой независимый модуль, требует соответствующего подхода разработки. Т. Е. мы имеем дело с чёрным ящиком. Пользователь библиотеки не заботится о внутреннем устройстве, качество руки програмиста, что писал код. Его заботит лишь интерфейс и гибкость управления им. Ещё неоспоримым преимуществом этого подхода - максимальная готовность кода. Сборка проекта внутренних компонентов может съедать много времени. У меня есть пример холодной сборки в dev режиме angular-cli 5 минут. На prod 20 минут. А так, архитектуру подбирают под требования.
Великооепный ответ). Все просто забывают про бизнес составляющую и много философствуют). В начале самая лучшая архитектура - это чёрный ящик)
На обычном блокноте делал
Типичная пропаганда react. Статья не раскрывает сильные и слабые стороны
Хорошо что у нас не php)