Для чего нужны javascript-фреймворки

03-04-2019Время чтения ~ 10 мин.jQuery и JavaScript 11401

В последнее время всё больше шума вокруг js-фреймворков React, Angular и Vue. Порой складывается впечатление, что без этих библиотек веб-разработка уже не существует и единственный верный путь - бросать «никому не нужный» PHP, и срочно изучать реакт, поскольку он сейчас самый якобы востребованный на рынке. :-)

Бум вокруг JS в общем-то понятен — это язык имеет довольно низкий порог вхождения, поэтому появляется всё больше «специалистов», которые прошли курсы по JavaScript, хотя полноценно не осилили ни HTML, ни CSS, а PHP для таких — просто ругательство. Почему я обращаю внимание на этот момент? Всё из-за того, что в этом шуме-буме, на самом деле есть несколько интересных и полезных вещей, на которые стоило бы обратить внимание веб-разработчику. Но из-за таких горе-специалистов докопаться до сути несколько проблематично. Лично я считаю себя достаточно «продвинутым» программистом с хорошим знанием многих технологий, включая и JavaScript, но даже для меня оказалось не таким простым занятием понять реальное назначение современных js-фреймворков.

Какой javascript-фреймворк изучать в 2019 году?

Типовой вопрос, как оказалось. :-) Нам всегда хочется получить ясный и понятный ответ и не допустить ошибки выбора. Скажем выучишь React, а он просто не нужен: ни в работе, ни клиентам.

Реальность немного сурова: любой фреймворк нужно изучать с основ JavaScript. При этом сразу подразумевается, что уже есть хорошие знания HTML и CSS. Хорошие — это значит, что вы без проблем можете сверстать средней сложности лендинг, а лучше сделать их штук 10 на нативном HTML и CSS. Потому что не бывает сайтов без HTML и CSS.

Ну а React, Angular, Vue и даже jQuery базируются на одном и том же — языке JavaScript и вот без его знания делать просто нечего.

Что лучше: React, Angular, Vue?

Ну хорошо, пусть уже есть знания, за что браться, какой из фреймворков более продвинут?

Здесь важно понять, что все фреймворки служат для определённой цели и предлагают некую модель построения, которой придётся придерживаться. С моей точки зрения — все они примерно одного уровня сложности: все они требуют изучения с нуля, но при этом используют свой «синтаксический сахар», который, собственно, и определяет удобство пользования фреймворком. А здесь уже на вкус и цвет...

Какой легче для новичка?

На этом этапе я спотыкался несколько раз, поскольку никак не мог сообразить, что все эти js-фреймворки, хоть и написаны на JS, на самом деле не могут (просто так) работать в браузере, как это положено любому js-скрипту.

Если, например мы хотим использовать jQuery, то мы просто подключаем js-файл и все функции библиотеки доступны на странице. С js-фреймворками всё немного сложней.

Формально Vue или React позволяют подключить себя обычным js-файлом и пользоваться на странице. Но при этом, тот же React использует синтаксис JSX, что в свою очередь потянет за собой js-файл babel.min.js размером примерно 1,5Мб. ;-(

В Vue к этому вопросу подошли куда более серьёзней и там действительно можно ограничиться только подключением js-файла. И, это классно, но только ровно до того момента, пока не нужно будет разбить проект на несколько js-файлов и использовать js-команду import.

С помощью import/export можно организовать модульность js-файлов, примерно как это делается в PHP с помощью require. Но проблема в том, что браузеры до сих пор не поддерживают import (ECMAScript 6), а это значит, что придётся отказаться от модульности, что делает js-фреймворк уже не таким привлекательным.

Чтобы решить эту проблему, используются различные системы сборки проекта. Нужно понять, что привычного «просто подключил js-файл» уже недостаточно: придётся использовать специальную программу сборки. И с моей точки зрения, выигрывает тот фреймворк, который предлагает самую простую и понятную инструкцию, чтобы не заморачиваться с установкой и настройкой эти самых «сборщиков».

Если рассматривать именно с этой точки зрения, абсолютным победителем будет Vue с его Vue CLI, который не просто позволяет создать каркас, но и предоставляет страницу управления сайтом прямо в браузере (команда vue ui).

Самое забавное, что в руководстве по Vue, наоборот не рекомендуют использовать Vue CLI, хотя именно с его помощью исчезает головная боль с настройкой приложения.

Что касается Angular, то я даже не смог его запустить. Проблема, как мне кажется в настройках node или может была какая-то старая версия, но немного повозившись, я просто плюнул на него.

Говорят, что новая gmail-почта написана именно на Angular. В принципе этого го.на уже достаточно, чтобы напрочь отбить охоту пользоваться этим фреймворком.

С React ситуация получше, спасает наверное чуть лучше документация и, главное, готовый Create React App, который может служить каркасом простого приложения. По своим возможностям он сильно уступает Vue CLI (где например можно указать url-адрес готового сайта).

Рассматривать же фреймворки с точки зрения простоты написания кода, на данном этапе не имеет смысла. Все они имеют свои особенности.

Программы-сборщики

Обычно для проекта предполагается модульная структура, то есть будет множество файлов. Поскольку import не работает в браузере, да и может использоваться «свой синтаксис», то сборщик должен будет преобразовать исходные файлы в понятный и рабочий для браузера код.

Поэтому сборщик (обычно это Webpack) должен иметь свои настройки, с которыми новичку сложно разобраться. Здесь как раз и выручает Vue CLI, который работает из коробки. Но, если стоит задача сделать как-то по другому, то придётся все настройки выполнить самостоятельно. А чтобы это сделать, нужно изучать Webpack и желательно сделать это до или параллельно с изучением js-фреймворка.

Зачем вообще нужны javascript-фреймворки

В процессе изучения я постоянно ловил себя на мысли — зачем вообще нужны все эти сложности, если можно всё спокойно сверстать на HTML/CSS и добавить jQuery (да хоть нативный JS!). Если нужны данные, то есть PHP с доступом в базе данных и много ещё чего. Зачем вообще городить всё это?

Так вот польза от этого действительно есть и на это есть как минимум две «жирные» причины.

Первая — Web-компоненты

Модульный или компонентный подход к разработке уже давным-давно используется почти везде, кроме JS. Всё, что есть сейчас в JS — на самом деле это довольно примитивные вещи. Веб-компоненты — это технология будущего, которая может изменить положение дел и привести вебсайты в разряд полноценных приложений.

Примером веб-компонента может служить тег VIDEO, который выводит довольно сложный визуальный компонент с элементами управления. То есть мы указываем лишь тег и его параметры, а браузер преобразует его в что-то более сложное.

Если не вдаваться с техническую составляющую веб-компонентов, то по сути они предоставляют разработчику возможность создавать отдельные сущности (компоненты) с помощью обычного HTML и CSS (scoped!), а программную логику писать на JavaScript.

Например нам нужно разместить jQuery-слайдер на странице. Сейчас нужно подключить js-файл, css-стили, которые при этом не должны конфликтовать с остальными стилями сайта, а также прописать код инициализации. С веб-компонентами это будет немного проще — это всего лишь какой-то специфичный html-тэг (например MY-SLIDER) и набор атрибутов-опций.

Но на сегодняшний момент, поддержка веб-компонентов слабая, поэтому единственным способом получить что-то подобное, будет предварительная сборка проекта в понятный для браузера код. И вот здесь как раз мы и подходим к вопросу - насколько js-фреймворк соответствует концепции web-компонентов.

Сразу скажу, что я не готов сделать заключение, кто из Vue, React, и Angular лучше, поскольку у меня практически нет опыта работы с ними. Если чисто субъективно, то Vue выглядит более логичным за счет использования файлов .vue — по сути это и есть «чистый» компонент.

Хотя существуют другие js-фрейморки, которые реализуют поддержку веб-компонентов.

Вторая причина — реальная поддержка сайта

Если вы захотите увидеть примеры сайтов, сделанных на React, Angular или Vue, то скорее всего это будут какие-то жалкие единицы — просто пыль по сравнению с полноценными сайтами на PHP.

Шум вокруг js-фреймворков явно не коррелирует с их реальной используемостью в веб-разработке. Так какие-же сайты делают на этих фреймворках?

Как правило это какие-то закрытые разработки под конкретного заказчика (b2b), который готов платить большие деньги за такую работу. Но суть не только в том, что клиенты, как правило плохо разбираются в технологиях, а в том, что заказчику важно не только создание проекта, но и его дальнейшая поддержка.

Если рассматривать типовой сайт на PHP, то он будет сильно завязан на исполнителя. Например, есть некий условный php-специалист Вася, который знает только Джумлу, который всё сделает, чтобы убедить клиента использовать именно эту систему. После того, как Васю всё-таки уволили, приходит Петя и предлагает всё переписать на Друпал, поскольку это же «круть!». Понятно, что смена любого «движка» ведёт за собой череду дополнительной работы и не факт, что все изменения пойдут на пользу проекту.

Сайт на PHP состоит из нескольких частей. Первая — это работа с базой данных, то есть получение выборки в виде структурированных данных. Это самая простая часть работы. Дальше данные поступают на уровень шаблона, где уже идёт формирование HTML-вывода. Здесь уже не столько php-программирование, сколько html-верстка. После этого наступает очередь CSS, чтобы привести вывод к необходимому дизайну. Если нужно изменить/добавить какой-то элемент страницы, то цикл PHP-HTML-CSS нужно будет повторять снова и снова.

Поддержка такого проекта будет заключаться в том, чтобы иметь полноценных специалистов, которые будут разбираться сразу в нескольких технологиях. И это в какой-то мере проблема кадров, поэтому нужно стараться построить сайт так, чтобы структурные части взаимодействовали друг с другом только посредством каких-то примитивных методов.

Именно этот подход и используется в js-фреймворках. На уровне PHP обеспечивается некое API, запросы к которому возвращают json-данные. Эти данные получаются в js посредством ajax, а значит js-программист может вообще не понимать как они возникли — ему дали url и пример использования, и этого уже достаточно. PHP-программисту же не нужно верстать HTML-код и даже задумываться о том, как эти данные будут выглядеть на сайте.

Сама же верстка происходит на уровне компонентов — это уже HTML и CSS с примитивными вкраплениями js.

То есть работа разделена на части, где сильно уменьшена зависимость от человеческого фактора. Если Вася окажется плохим js-программистом, то нет проблем найти таких же с десяток, поскольку профессиональные требования здесь на уровне «детского садика». Но, при этом проект продолжает работать, потому что исключены все критические зависимости. Все довольны, клиент продолжает платить деньги. :-)

(React || Angular || Vue) vs. jQuery

На самом деле очень странная постановка вопроса, поскольку сравнивать эти фреймворки с jQuery несколько некорректно. Но если погуглить, то этот вопрос оказывается наиболее частым.

Нужно понять, что jQuery — это просто набор функций, которые собраны в одной оболочке (библиотеке). Это ничем не лучше или хуже, чем тот же Vue или React, которые представляют собой свои наборы функций.

Вопрос здесь скорее в общей идеологии. jQuery может использовать где угодно на странице и с любыми элементами. Это такой «атомарный» подход, который позволяет использовать любые элементы. JS-фреймворки же предполагают более комплексный подход и рассматривают страницу уже не как простой набор html-тэгов, а как связанные между собой компоненты. И никто не мешает использовать jQuery совместно с ними.

Существует ряд задач, который проще решить именно с помощью фреймворка, особенно если они «заточены» под эти задачи. Но точно также гораздо проще использовать готовый jQuery-плагин, вместо того, чтобы изобретать новый велосипед.

Типы сайтов для javascript-фреймворков

JS-фреймворки, в силу того, что работают на стороне клиента, не могут нормально использоваться там где много динамических данных и разных страниц/адресов, как например в блогах. Поэтому основное для них назначение — это SPA (single page application), где всё действие происходит на одной-единственной странице. И хотя уже сейчас для них существуют решения в виде роутинга, выглядит это всё равно несколько странно.

Поэтому js-фреймворки будут интересны только там, где необходима высокая «динамичность», как например в той же gmail-почте. Главная фишка тут в том, что интерфейс меняется без перезагрузки страницы и выглядит в целом как обычная программа.

Я очень сомневаюсь, что js-фреймворк следует использовать на обычных сайтах или лендингах. Как правило здесь нет потребности в множественных аякс-запросах, а значит можно легко обойтись обычным PHP/HTML/CSS/JS/jQuery.

Стоит также учесть, что эти фреймворки сильно тормозят (речь, конечно о чём-то более-менее серьёзном). Пример новой gmail-почты очень показателен — пользоваться совершенно нереально как раз именно из-за очень низкой скорости загрузки, тормозной реакции и постоянных сбоев и самоперезагрузок. Или например недавно мой банк обновил свою клиентскую часть и стал загружаться примерно 2 минуты, при том часто с ошибками. Раньше это было не так красиво, но работало раз в 100 быстрей. Думаю, что нужно учитывать этот фактор, особенно если сайт как-то завязан на бизнес.

Кроме того и SPA-приложений есть один очень существенный недостаток — плохая поддержка поисковиками. Из-за того, что страница формируется js-кодом, да ещё и по множественным аякс-запросам, то её довольно сложно нормально проиндексировать. Гугл, конечно, пытается, но очевидно, что до обычной HTML-страницы ему ещё далеко.

В заключении всё-таки отмечу, что при всех недостатках, есть несколько причин поизучать React, Angular или Vue. Первая — это просто интересно, особенно в плане будущего перехода к веб-компонентам. Полноценный сайт всё-равно не сделаешь, но для общего развития будет полезно. Вторая причина прозаическая — если «богатые буратины» готовы платить за это деньги, то почему бы и нет? Вреда от этого мало, а полученные деньги могут пригодится на что-то более стоящее. Например на платные курсы PHP. :-)