Комментарии 28
Если подобные большие проекты создать на чистом JS, они будут передавать больше данных, чем аналогичные проекты, созданные на фреймворках
По-моему тут начальные данные не верны, т.к. если система сбора данных, зафиксировала наличие фреймворка [vue, angular, react], то это 9 из 10 spa и сравнивать количество js кода в spa и статичным сайтом не корректно. P.S. 1 из 10 пусть останется за ssr)))
То же касается и времени работы. Вы учитываете только время работы «на клиенте». Понятно, что если фреймворки рендерят страницы в браузере, на это уходит время. А рендер на сервере типа не учитывается. (А пользователю ведь фиолетово кого ждать, браузер или сервер).
Все эти различия проявляются только в процессе взаимодействия приложения с пользователем, а не при анализе типа «загрузили–посмотрели».
То же касается и времени работы. Вы учитываете только время работы «на клиенте». Понятно, что если фреймворки рендерят страницы в браузере, на это уходит время. А рендер на сервере типа не учитывается. (А пользователю ведь фиолетово кого ждать, браузер или сервер).
Клиентские устройства в большинстве случаев на порядок менее производельные чем сервер. Так что да, на сервере всё происходит намного быстрее и это время можно не учитывать.
Со сервер ведь и загружен больше.
Настоящая причина ускорения производительности — в сетевом лаге. При полностью клиентском рендере браузер вынужден делать как минимум на 1 запрос больше — надо же ещё и данные получить после загрузки всех скриптов. Плюс отрендеренную сервером страницу можно показать пользователю ещё до загрузки скриптов, это тоже ускорение.
Про загрузку ответил в соседеней ветке: https://habr.com/ru/company/ruvds/blog/499280/#comment_21575252
Что касается описанных вами причин увеличения производительности при серверном рендерниге — да, они также имеют место быть. Не уверен, что будет оказывать больший эффект — тут уже нужны конкретные тесты на конкретном примере.
Однако, клиентское устройство одновременно обслуживает одного клиента. А сервер — тысячи.
Сможете сделать, произвести замеры и доказать?
Вообще тема интересная и тут есть что пообсуждать, но меня (и еще сотни других людей) напрягает это и поэтому Хабр не место для обсуждения. Если у вас есть на примете более подходящий ресурс — маякните плиз.
Фреймворки заняли свою нишу веб-приложений, где они идеально подходят и эта цена оправдана. Сомневаюсь что одноразовые самописные решения были бы лучше фреймворкой как в плане качества кода, так и в плане производительности.
Это и неудивительно — нельзя сделать JavaScript-фреймворк основой сайта и ожидать того, что объём JS-кода проекта окажется очень низким.
Вообще-то можно. Если взять фреймворк, который для реализации приложения требует писать мало бойлерплейта и автоматизирует многие рутинные задачи, то вручную написанный код будет весить больше. Либо вручную будет точно так же написан свой безымянный фреймворк. Вообще, странно судить обо всех фреймворках по трём пусть и популярным, но жирным представителям.
Сайты с jQuery выглядят лучше всего. В настольных версиях сайтов они содержат на 15% больше JavaScript, чем все сайты, а в мобильных — на 18% больше.
Учитывая, что jQuery обычно применяется на многостраничных сайтах, то стоит учитывать и объём html, который для каждой страницы может запросто доходить до полумегабайта.
Согласен с автором по поводу распространения JS библиотек. Однако, предложил бы альтернативное пожелание создателям framework'ов:
Я не верю в то, что ограничение функций framework'а даст желаемый результат по увеличению производительности. Убежден, что, как только будут введены ограничения на использования функций(это оптимизация, уменьшением их количества) — сразу же найдутся противники такого подхода, голосующие тем, что либо будут использовать сразу 2 и более framework'ов с взаимодополняющими функциями(это даст обоатный эффект) либо, просто перестанут использовать библиотеку.
Если взять тот же jquery- то, несомненно, люди ее использующие, не берут все возможные функции из библиотеки, а значит б`ольшая часть кода просто лежит и занимает память и трафик. Тут можно спорить будет ли это minified обфускированная версия или цельная, но суть та же. Так вот, почему до сих пор в мире JS никто не использует мобильность?(кроме Node.js конечно)
Почему например, если я хочу использовать только fadeOut() у меня вся библиотека анимации загружается? Модульность, которая используется, скажем во фрагментах(прекомпилированных кусках кода, в Java) могла бы не только снизить трафик и загрузку памяти, но и нагрузку на ЦП, так как были бы уже разжёваны для машины.
Просто пишешь:
Import jquery.animation;
Получаешь функции по анимации.
Import jquery.ajax
Получаешь ajax функции.
Итд.
Либо в параметре к src можно указать
https://cdn.jquery.com/jquery.js?animation=true&ajax=false
Чем не вариант, который и операторов устроит и разработчиков?
Вот если бы можно было тот же jquery «кушать по частям» — ну было бы круто. И сайты бы быстрее грузились.
JQuery UI поставляется именно таким образом.
Что касается самого JQuery, то есть его облегченная версия JQuery Slim. Уровень модульности не такой, как вы описывате, конечно, но это шаг в этом направлении.
В то время, каждый производитель браузеров добавлял свое API, свои спецификации итд. И вот на сегодняшний день мы имеем тормознутое браузерное API, кучу кода для обратной совместимости. Одно наследование на прототипах чего стоит :)
Кстати, фреймворки и jQuery появились не просто так. Это были и есть инструменты, которые позволяют создавать, в первую очередь, удобные абстракции для программистов. Что бы можно было удобно, быстро работать с DOM, шаблонами динамикой итд.
Для тех, кто ругает фреймворки за объем, порог входа итд. Попробуйте запилить приложение на чистом JS. С красивым кодом, без дубликатов и повторений. Уверен, вас ждет неимоверное и увликательное приключение. А в конце вы все равно придете, к своему велосипеду.
За все надо платить. Мы выбираем комфорт и удобство в разработке. А за это мы расплачиваемся производительностью.
К впоросу, а что можно сделать, что бы это исправить.
Не использовать JS — сегодня, это не реально. Врядли заказчики соглясятся выключить динамические ништяки в угоду производительности. Лично я в это не верю.
Не использовать фреймворки — можно, но в конце вы сделаете свой велосипед и не факт, что он будет лучше существующих. А вот цена и время разработки вырастет в разы. И как объяснить заказчику, почему условный Вася из соседней конторки запросил $1K за условный сайт, а вы взяли $10-20K. А результате выйдет одино и то же.
Революция в браузерах — фантастичеко-мифический, я бы сказал, пункт. Переписать DOM API с нуля и выкинуть к черту обратную совместимость. Написать нормально движок для CSS. Выкинуть JS и вместо него добавить Go/Rust (или ваш любимый мега-супер-пупер быстрый язык). Можете добавить еще что нибуть, что считаете нужным :)
Увы, мы сегодня имеем что имеет. Миллионы сайтов уже написаны. Никто их переписывать не будет. Так что остается только опитимизировать фреймворки, оптимизировать свой код. Не добавлять стопиццот зависимостей в проект. Использовать JS там где это необходимо, а не на каждый чих. Ну и верить в чудо :)
Как думаете, webassembly здесь чем-нибудь поможет?
WASM выигрывает только на этапе загрузки. Так как данных надо меньше скачивать по сети. Не требуется парсинг и компилация в байткод, так как скомпилированный байт код уже будет скачен из сервера.
Основная проблема на сегодня, как я уже написал выше — кривое, косое и неудобное DOM API и CSS engine. И пока я не вижу, что может помочь исправить ситуацию.
Что касается JS, то лично мне не нравится наследование на прототипах. Предпочел бы видеть вместо JS Go или Rust. Но это сугубо лично мое мнение и я его ни в коем случае, никому не навязываю.
Так что, поживем посмотрим. Возможно нас еще удивят :)
Ну и Blazor как конкретная реализация для моего стека технологий .NET
JS-фреймворки — это очень удобно для разработчика, но за это удобство расплачивается пользователь.
Я для себя решил отказаться от всех фреймворков для сайта который виден «наружу», и Angular для админки, которой пользуется ограниченный круг людей. Между прочим, Яндекс не умеет индексировать SPA сайты, так что делать с таким подходу что-то что должно отображаться в поиске — так себе затея.
По поводу JQuery — его популярность сейчас обусловлена еще тем что Bootstrap основан на нем и не работает иначе. А Bootstrap очень популярен сам по себе.
Сравнивать лэндинг на jquery и полноценное приложение на angular — несколько странно. Это выглядит как анализ средней длины конечностей у людей, вот только половина опрашиваемых, как оказалось, нарушали ТБ на пилораме, а ещё часть — вообще дети.
Цена JavaScript-фреймворков