Фото — Maria Teneva, площадка Unsplash
Иногда React, Angular, Vue.js и т. д. — это лишнее
Правда ли, что JavaScript-фреймворков слишком много и выбор становится чересчур сложным? Или, может, мы просто забыли о соображениях производительности и о том, что за лишний трафик в итоге должны платить пользователи?
Вернемся в эпоху jQuery
Помните, было время, когда JQuery использовали для всего! JQuery то, jQuery сё — повсюду легкий аромат jQuery. На любом веб-сайте и в каждом веб-приложении — jQuery.
В чем причина популярности этой библиотеки?
Простой JavaScript казался слишком сложным в применении. К тому, же между браузерами было много отличий.
Но пришло спасение — библиотека jQuery избавила сообщество JavaScript от этой головной боли. Правда, большинство из нас в результате стали лениться, поскольку перестали понимать, что происходит «под капотом».
Я прозрел, когда появился этот сайт.
Эпоха чрезмерно большого выбора в мире JavaScript
Начинается 2020 год, и у наших сайтов и веб-приложений определенно есть «лишний вес». К нашим услугам Angular, React, Vue.js, Svelte, Polymer (и это далеко не всё) — но необходимость постоянно делать выбор в стремительно разрастающемся зоопарке фреймворков утомляет.
Вы можете подумать: «Говори лучше за себя». Но именно это я сейчас и делаю: я критически оцениваю собственную «усталость» от изобилия в мире JavaScript.
Скажем честно: никогда еще не было так просто сделать веб-сайт или веб-приложение. Сегодня достаточно одной команды:
ng new ИмяПроекта
в Angular,
…
в случае React и т. д.В большинстве случаев мы выбираем то, что лучше подходит. Однако при этом нужно уменьшать количество JavaScript-кода и внимательнее относиться к тому, что загружается в приложение.
Потому что — а вдруг сочетания HTML, CSS и JavaScript окажется достаточно?
И говоря о JavaScript-фреймворках, я имею в виду и библиотеки JavaScript: Angular, React, Vue.js и Svelte — всё это вместе (и многое другое).
Плюсы и минусы использования JavaScript-фреймворков
В использовании JavaScript-фреймворка есть свои плюсы и минусы. И речь здесь не о плохих и хороших фреймворках, а о том, какие из них в каких ситуациях показывают себя лучше.
На основной работе я использую Angular, но люблю поэкспериментировать с React и Vue.js, а иногда пробую какую-нибудь небольшую микробиблиотеку JavaScript, которая делает что-то одно, но зато очень хорошо.
Когда использовать JavaScript-фреймворк не нужно
Есть несколько ситуаций, в которых вместо JavaScript-фреймворка я рекомендую использовать микробиблиотеку или простой JavaScript.
- Ваше приложение — простое или маленькое. Например, у вас небольшой проект, вроде какого-нибудь эксперимента с новым JavaScript API.
- Высокие требования к производительности — если приложение должно быть высокопроизводительным даже при плохом интернет-подключении.
Если в счет идет каждый передаваемый по сети байт, то использовать большой фреймворк — не самое разумное решение: за удобство JavaScript-фреймворка приходится платить излишним количеством кода.
Есть множество инструментов, которые помогают в таких ситуациях. Но лучше предотвратить проблему, чем решать ее.
Когда JavaScript-фреймворк — это разумный выбор
Часто использование JavaScript-фреймворка будет обосновано — но даже в этих случаях нельзя терять бдительности.
1. У вас большое приложение
Если вы разрабатываете большое приложение, использование JavaScript-фреймворка может быть разумным выбором, ведь в большинстве случаев у вас будет хорошая поддержка со стороны сообщества.
Обычно у вас будет много справочных материалов, которые помогут обеспечить долгосрочную поддержку приложения.
2. Вы (или компания) цените открытый исходный код
Самое лучшее в открытом коде — то, что его можно свободно использовать (в рамках лицензии, конечно).
Многие элементы таких фреймворков разрабатываются в свободное от основной работы время — поэтому за его использование ничего платить не нужно.
А если захочется внести вклад в открытый JavaScript-фреймворк, это принесет пользу и другим.
3. Быстрая разработка новых функций
У большинства фреймворков есть множество инструментов, которые позволяют быстрее реализовывать новые функции: разработчик может опереться на опыт знающих свое дело специалистов, которые вместо него хорошенько протестировали код.
Заключение
В этой статье преимуществ использования JavaScript-фреймворков оказалось больше, чем недостатков. (Если у вас есть что добавить — поделитесь в комментариях!)
Но даже если использование фреймворка звучит привлекательно, нужно внимательно следить за тем, что мы загружаем на свои веб-сайты и в разрабатываемые приложения.
Всегда задавайтесь вопросом: «Нужен ли здесь этот фреймворк? Может, лучше сделать всё своими руками или использовать что-то готовое?»
«Как применение фреймворка отразится на пользователях? Будет ли приложение на низкопроизводительном телефоне таким же удобным в использовании, как на флагманском устройстве?»
AriesUa
Наверное стоит понимать, что все эти фреймворки появились не просто так. А потому что в браузере DOM API корявое и убогое. И кривое оно, потому что такова была эволюция браузеров. Да пытаются сейчас исправить, улучшить. Но поломать легче сейчас, чем впилить что-то разумное. На сегодняшний день API очень далеко от совершенства. Поэтому мы видим изобилие фреймворков, как от корпораций, так и собственных.
Каждый из них, позволяет делать разработку легче и быстрее. Если вы попробуете сделать сайт на нативном JS, то рано и поздно, но у вас скопится огромная куча повторяемого кода, и вы изобрете собственный
велосипедфреймвор, что бы легче, что бы не повторятся.Но все эти улучшения не даются просто так. Жервой будут размер бандла, перформанс, пожирание памяти. Все то, что мы имеем сейчас.
Сможем ли мы исправить в ближайшее время ситуацию — думаю нет. Откажемся ли мы от фреймворков — нет конечно, не откажемся. Сделать API лучше, не получится. А кодить в приятных абстракциях и структурах хочется.
Так что же делать? В первую очередь думать головой и применять те инструменты, которые нужны. Искать золотую середину.