Кстати, согласен с вами. Высокоуровневые фреймворки - это следующий шаг в будущее. Ведь когда экосистема надстроек нарастает, то зачастую теряется изящность низкоуровневых парадигм и производительность. И $mol очень хорошо себя показывает, при этом выполняя достаточный для приложений объем задач.
Вы все правильно говорите. Технология здесь ни при чем. Тут вопрос в том, что подобные сервисы пытаются в интерфейс напихать максимальное количество функций, требующих памяти. ВК не исключение, это не интерфейс, а калейдоскоп требующих оперативной памяти различных скриптов. Chromium тем и прославился, что он все пихает в оперативку , отнимая ее у других приложений. И конечно же, громоздкие интерфейсы не будут работать быстро в современных реалиях на любом фреймворке. Просто сервисам нужно пересмотреть принципы реализации "идей" в интерфейсах в сторону производительности и удобства. Но это не за горами. Они вынуждены будут это сделать, так как мощности уже не поспевают за "гением" идеологов, маркетологов и разработчиков сервисов. Один GSAP, понапихнутый во все статические лендинги и многие страницы сервисов под давлением "дизайнеров" - это уже показатель.
Как превратить статью в профанационную помойку. Разбираем по пунктам. Различия в производительности заметны были на старых версиях vue и react, но при условии более 10 миллионов активных пользователей интерфейса. И то, и другое - создано для работы с динамическими данными, а никак не со статикой. SSR - это костыль для того, чтобы не отделять статику от динамики. Фреймворки вроде next - инвалидная коляска для торопливых или зажатых в сроки разработчиков с низкой квалификацией. SSR в проектах вроде вашего съедает немного ресурсов, но уже требует постоянного scaling up при увеличении количества пользователей. Как только вы столкнулись бы с более 100 млн посещений, расходы на масштабирование превысили бы экономическую выгоду проектов. SSR хорош для небольших систем. Redis - костыль для динамических данных, но он хорош там, где вычисляемые данные статистически однотипны. Немного удешевляет масштабирование. Разницы в react и vue нет никакой, если это не проект масштабов vk и прочих многопользовательских систем. Но порог входа в Vue гораздо ниже, чем у React. У вас скорее вопрос управления кадрами. Так как вы не обучаете кадры, а пытаетесь найти готовых. Что в результате приводит к изменению парадигмы. Если говорить о рендеринге данных для магазинов, то даже в этом случае применение SSR не всегда оправдано. Намного дешевле и практичнее передать вычисления клиенту - для чего и создавались js-фреймворки, как раз для удешевления масштабирования. По-хорошему, у сервера должна быть одна функция - обрабатывать и отдавать данные. А представление - это дело браузера. Но рендерить на сервере статику - это кощунство, если речь про статьи и журналы. Я не очень понимаю, зачем там вообще динамика, кроме как для комментов. Итог: в любом проекте надо выбирать оптимальный стек технологий, обучать junior до нужного скила, минимизировать расходы на масштабирование, а главное - микросервисная архитектура проектов, тогда и не будет помойки!
Кстати, согласен с вами. Высокоуровневые фреймворки - это следующий шаг в будущее. Ведь когда экосистема надстроек нарастает, то зачастую теряется изящность низкоуровневых парадигм и производительность. И $mol очень хорошо себя показывает, при этом выполняя достаточный для приложений объем задач.
Вы все правильно говорите. Технология здесь ни при чем. Тут вопрос в том, что подобные сервисы пытаются в интерфейс напихать максимальное количество функций, требующих памяти. ВК не исключение, это не интерфейс, а калейдоскоп требующих оперативной памяти различных скриптов. Chromium тем и прославился, что он все пихает в оперативку , отнимая ее у других приложений. И конечно же, громоздкие интерфейсы не будут работать быстро в современных реалиях на любом фреймворке. Просто сервисам нужно пересмотреть принципы реализации "идей" в интерфейсах в сторону производительности и удобства. Но это не за горами. Они вынуждены будут это сделать, так как мощности уже не поспевают за "гением" идеологов, маркетологов и разработчиков сервисов.
Один GSAP, понапихнутый во все статические лендинги и многие страницы сервисов под давлением "дизайнеров" - это уже показатель.
Как превратить статью в профанационную помойку.
Разбираем по пунктам.
Различия в производительности заметны были на старых версиях vue и react, но при условии более 10 миллионов активных пользователей интерфейса. И то, и другое - создано для работы с динамическими данными, а никак не со статикой.
SSR - это костыль для того, чтобы не отделять статику от динамики. Фреймворки вроде next - инвалидная коляска для торопливых или зажатых в сроки разработчиков с низкой квалификацией. SSR в проектах вроде вашего съедает немного ресурсов, но уже требует постоянного scaling up при увеличении количества пользователей.
Как только вы столкнулись бы с более 100 млн посещений, расходы на масштабирование превысили бы экономическую выгоду проектов. SSR хорош для небольших систем.
Redis - костыль для динамических данных, но он хорош там, где вычисляемые данные статистически однотипны. Немного удешевляет масштабирование.
Разницы в react и vue нет никакой, если это не проект масштабов vk и прочих многопользовательских систем. Но порог входа в Vue гораздо ниже, чем у React.
У вас скорее вопрос управления кадрами. Так как вы не обучаете кадры, а пытаетесь найти готовых. Что в результате приводит к изменению парадигмы.
Если говорить о рендеринге данных для магазинов, то даже в этом случае применение SSR не всегда оправдано. Намного дешевле и практичнее передать вычисления клиенту - для чего и создавались js-фреймворки, как раз для удешевления масштабирования.
По-хорошему, у сервера должна быть одна функция - обрабатывать и отдавать данные. А представление - это дело браузера.
Но рендерить на сервере статику - это кощунство, если речь про статьи и журналы.
Я не очень понимаю, зачем там вообще динамика, кроме как для комментов.
Итог: в любом проекте надо выбирать оптимальный стек технологий, обучать junior до нужного скила, минимизировать расходы на масштабирование, а главное - микросервисная архитектура проектов, тогда и не будет помойки!