Современный веб (ES6+) как раз развивается в сторону SPA/PWA, которые уже на 90% обходят нативные приложения. У веба больше нет проблем с работой оффлайн, с доступом к устройству (камера, датчики, хранилище, фоновые процессы), с производительностью и т.д. А также у веба куча преимуществ: кроссплатформенность, не нужны магазины приложений (мгновенный доступ без установки, ленивая подгрузка модулей, малый вес, мгновенный релиз и т.д.).
Эпоха мобильных приложений уже движется к закату. С каждым днём всё больше компаний внедряют веб-технологии в свои продукты (больше всего этому способствует переход в облака - именно они кстати добьют десктопы, превратив их в "тонкие клиенты"). С каждым днём всё больше "нативных" мобильных приложений (в том числе и на iOS) полностью или частично состоят из WebView, либо вовсе являются PWA без нативной обёртки. Статистика это подтверждает - за последние 5 лет катастрофически падает кол-во установок приложений - люди перестали устанавливать приложения, рынок насыщен, а пользователи наигрались. Чаще всего, сами того не замечая, мы разово воспользуемся продуктом на веб-технологиях (в браузере), чем установим приложение, а PWA окончательно добьёт нативные приложения при многоразовом использовании.
И это я про wasm ещё молчу, вот он как раз-то может составить конкуренцию текущему вебу в сфере высокопроизводительных приложений (например игр), где JS увы проиграет.
Веб - это и есть "кислород", а нативные приложения - "анаэробные организмы", у них нет шансов :)
Мы прямо сейчас как раз делаем плагин для Jira + интеграционный сервис между Jira <-> GitLab, но акцент больше на тикет систему и пайплайны. На вашем опыте вижу, что и ревью тоже классно ложится на эти рельсы. Спасибо за статью!
Смотрите глубже. Я считаю, Microsoft пофиг на Electron, это тупиковая ветвь эволюции, которая сгинет через несколько лет. Но тем не менее, он показал что веб может тягаться с нативом на его территории. Microsoft хотят подмять под себя будущую нишу PWA, которая как раз и убьет нативные приложения, тем более на рынке браузеров не вышло. Переход Microsoft на Chromium позволит им контролировать экосистему веб-приложений, для которых не важен браузер, а только движок в котором они выполнятся.
Пример: открываете сайт в %вашем любимом браузере%, соглашаетесь на установку PWA, оно устанавливается и открывается как нативное приложение, но не через Chrome, а самой осью на движке Chromium (или тоже самое при установке из Microsoft Store).
И этим же путем скорее всего пойдет Apple, сохранив за собой полный контроль за экосистемой (это они любят), не допустив Google к возможности устанавливать и исполнять веб-приложения от своего имени. В противном случае они проиграют битву, т.к. дни нативных приложений с GUI сочтены, веб убьет их в любом случае. Тоже касается и мобильных нативных приложений, там это произойдет даже быстрее. Разумеется игры, утилиты и прочий софт, а также содержащий тяжелые вычисления останется нативным, на js/ts никто в здравом уме переписывать не будет А затем wasm и их добьет.
Попробовал Inbox, не понравилась концепция как в начале, так и спустя месяц использования. Возможно он был рассчитан на аудиторию, которая использует почту в качестве «быстрых сообщений», «передачи файлов» и «напоминаний/таск менеджера», но мессенджеры и google keep отлично справляются (с keep сейчас перехожу на собственную разработку).
Мой юзкейс для сравнения: пользуюсь gmail в основном с десктопа; мобильный клиент стоит только ради push и подтверждения входа/регистраций; около 30 ярлыков; кнопкой «отложить» не пользуюсь вовсе; письма всегда становятся прочитаны (выполнены) в течении 1-2 дней.
мы об этом очень хорошо подумали заранее и добавили версионирование этой зависимости
О, это круто, тогда ок.
Да, крупные модули в отдельных js-файлах со своими зависимостями, иначе бы SPA весило сотни мегабайт. А на счет проблем асинхронности и производительности, не совсем понял, не знаю, может в каких-то фреймворках есть какие-то трудности в этом?
Наш проект — это сложная система, состоящая из выделенных частей (микросервисов)
Значит ваш проект уникален и требует именно такого подхода, поэтому согласен с вами.
В целом у нас возникла путаница в терминах, если кратко, то меня лишь возмутило одновременное наличие различных технологий на странице, но как вы указали в последнем комментарии, что это специфика вашего проекта.
На мой взгляд это называется из «мухи — слона». Столько излишних абстракций, сложностей, костылей, правил для команд, правил для правил… Модули на 100% реализуют микросервисный подход во фронте.
Для каждого модуля лучше подходят свои технологии
два приложения, написанных на разных фреймворках, на одной странице
Значит выбран неподходящий для вашей задачи фреймфорк, но уж точно не позволять в одном проекте писать на разных. Либо выделить проблемный модуль (если он такой большой и пафосный) в отдельный проект. А ваш подход приемлем только для легаси.
компиляцию в единый бандл
Ни в коем случае, всё в модулях!
Кто-то не готов перейти на обновленный API зависимости
Вам всё равно придется при изменении глобальной зависимости (от которой зависят все фрагменты, а этих сервисов даже в статье перечислено много) править код во многих фрагментах, а так как они ещё и на разных технологиях, то это затронет все команды.
Содержимое каждой закладки мы можем сделать отдельным фрагментом
Всё независимое выкинуть в разные проекты (разные технологии/фреймворки), а что имеет связь в рамках одной страницы в рантайм должно быть одним проектом на одной технологии, и даже если он гипер-большой (тысячи модулей) — разделить на независимые глобальные модули, где каждая команда может отвечать за свой глобальный модуль.
Я в своё время нечто похожее делал, но больше были интересны мутации свойств, не прописанных явно в коде. Например, изначально не определено как может двигаться организм, что нужно идти к еде и т.д., а в процессе он сам тыкаясь получал ± запоминал результат и повторял его. Сейчас конечно это выглядит глупо, но когда учился было прикольно.
А не пробовали запускать симуляцию с уже созданными геномами (случайно и по паттерну сгенерированных)? Или например два (или более) бота с сильно разными геномами. В этом случае думаю что колонии могут радикально отличаться.
ссылка на аватарку пользователя не приходит сразу в ответе, а формируется на основе id пользователя
По хорошему, сервер должен отдавать готовую динамическую ссылку на любой статический контент подобного типа. В вашем случае придется заботиться о сбросе кеша, если она изменена и проверить есть ли она вообще; как реализовать приватность доступа к аватаркам; хранить пути к серверу и т.д. — и всё это не разрешимо на фронте. А нужно просто получить ссылку с сервера и всё ;-)
Можно вынести этот метод из компоненты в сервис.
Для этого существуют Пайпы.
мы переместили метод создания пользователя в UserService
Вместо решения проблемы, вы переложили её на плечи бедного сервиса. Ваша первая реализация класса User уже достаточна, далее не нужно было его замусоривать. Внедрив в него кучу сервисов, вы обрекли себя на муки поддержки в будущем (например, в другом месте приложения потребуется просто вывести имя, а у вас ещё вагон зависимостей).
Не бойтесь создавать модели и сервисы при первой необходимости. Вы сами того не замечая удивитесь, что сервис, о котором по началу не думали, уже используется в 10 местах. И рефакторинг в сторону упрощения и объединения всегда проще, чем расковыривать монстра с десятком зависимостей и сотней строк.
Такое ощущение, что статья опоздала лет на 10))
Современный веб (ES6+) как раз развивается в сторону SPA/PWA, которые уже на 90% обходят нативные приложения. У веба больше нет проблем с работой оффлайн, с доступом к устройству (камера, датчики, хранилище, фоновые процессы), с производительностью и т.д. А также у веба куча преимуществ: кроссплатформенность, не нужны магазины приложений (мгновенный доступ без установки, ленивая подгрузка модулей, малый вес, мгновенный релиз и т.д.).
Эпоха мобильных приложений уже движется к закату. С каждым днём всё больше компаний внедряют веб-технологии в свои продукты (больше всего этому способствует переход в облака - именно они кстати добьют десктопы, превратив их в "тонкие клиенты"). С каждым днём всё больше "нативных" мобильных приложений (в том числе и на iOS) полностью или частично состоят из WebView, либо вовсе являются PWA без нативной обёртки. Статистика это подтверждает - за последние 5 лет катастрофически падает кол-во установок приложений - люди перестали устанавливать приложения, рынок насыщен, а пользователи наигрались. Чаще всего, сами того не замечая, мы разово воспользуемся продуктом на веб-технологиях (в браузере), чем установим приложение, а PWA окончательно добьёт нативные приложения при многоразовом использовании.
И это я про wasm ещё молчу, вот он как раз-то может составить конкуренцию текущему вебу в сфере высокопроизводительных приложений (например игр), где JS увы проиграет.
Веб - это и есть "кислород", а нативные приложения - "анаэробные организмы", у них нет шансов :)
Подарочный сертификат на участие в трек-дне Moscow Raceway на личном авто: 3600 руб. С арендой спорткара: от 9000 руб.
Пример: открываете сайт в %вашем любимом браузере%, соглашаетесь на установку PWA, оно устанавливается и открывается как нативное приложение, но не через Chrome, а самой осью на движке Chromium (или тоже самое при установке из Microsoft Store).
И этим же путем скорее всего пойдет Apple, сохранив за собой полный контроль за экосистемой (это они любят), не допустив Google к возможности устанавливать и исполнять веб-приложения от своего имени. В противном случае они проиграют битву, т.к. дни нативных приложений с GUI сочтены, веб убьет их в любом случае. Тоже касается и мобильных нативных приложений, там это произойдет даже быстрее. Разумеется игры, утилиты и прочий софт, а также содержащий тяжелые вычисления останется нативным, на js/ts никто в здравом уме переписывать не будет А затем wasm и их добьет.
Мой юзкейс для сравнения: пользуюсь gmail в основном с десктопа; мобильный клиент стоит только ради push и подтверждения входа/регистраций; около 30 ярлыков; кнопкой «отложить» не пользуюсь вовсе; письма всегда становятся прочитаны (выполнены) в течении 1-2 дней.
О, это круто, тогда ок.
Да, крупные модули в отдельных js-файлах со своими зависимостями, иначе бы SPA весило сотни мегабайт. А на счет проблем асинхронности и производительности, не совсем понял, не знаю, может в каких-то фреймворках есть какие-то трудности в этом?
Значит ваш проект уникален и требует именно такого подхода, поэтому согласен с вами.
В целом у нас возникла путаница в терминах, если кратко, то меня лишь возмутило одновременное наличие различных технологий на странице, но как вы указали в последнем комментарии, что это специфика вашего проекта.
Значит выбран неподходящий для вашей задачи фреймфорк, но уж точно не позволять в одном проекте писать на разных. Либо выделить проблемный модуль (если он такой большой и пафосный) в отдельный проект. А ваш подход приемлем только для легаси.
Ни в коем случае, всё в модулях!
Вам всё равно придется при изменении глобальной зависимости (от которой зависят все фрагменты, а этих сервисов даже в статье перечислено много) править код во многих фрагментах, а так как они ещё и на разных технологиях, то это затронет все команды.
Всё независимое выкинуть в разные проекты (разные технологии/фреймворки), а что имеет связь в рамках одной страницы в рантайм должно быть одним проектом на одной технологии, и даже если он гипер-большой (тысячи модулей) — разделить на независимые глобальные модули, где каждая команда может отвечать за свой глобальный модуль.
Я в своё время нечто похожее делал, но больше были интересны мутации свойств, не прописанных явно в коде. Например, изначально не определено как может двигаться организм, что нужно идти к еде и т.д., а в процессе он сам тыкаясь получал ± запоминал результат и повторял его. Сейчас конечно это выглядит глупо, но когда учился было прикольно.
А не пробовали запускать симуляцию с уже созданными геномами (случайно и по паттерну сгенерированных)? Или например два (или более) бота с сильно разными геномами. В этом случае думаю что колонии могут радикально отличаться.
По хорошему, сервер должен отдавать готовую динамическую ссылку на любой статический контент подобного типа. В вашем случае придется заботиться о сбросе кеша, если она изменена и проверить есть ли она вообще; как реализовать приватность доступа к аватаркам; хранить пути к серверу и т.д. — и всё это не разрешимо на фронте. А нужно просто получить ссылку с сервера и всё ;-)
Для этого существуют Пайпы.
Вместо решения проблемы, вы переложили её на плечи бедного сервиса. Ваша первая реализация класса User уже достаточна, далее не нужно было его замусоривать. Внедрив в него кучу сервисов, вы обрекли себя на муки поддержки в будущем (например, в другом месте приложения потребуется просто вывести имя, а у вас ещё вагон зависимостей).
Не бойтесь создавать модели и сервисы при первой необходимости. Вы сами того не замечая удивитесь, что сервис, о котором по началу не думали, уже используется в 10 местах. И рефакторинг в сторону упрощения и объединения всегда проще, чем расковыривать монстра с десятком зависимостей и сотней строк.
А на счет бойлерплейта уже выше вам написали.