React или jquery: Jquery или React?

Содержание

Когда проекту необходим React? — Favicon

Вы знаете, когда проекту необходим HTML и CSS, ведь он целиком из них и состоит. Ясно для чего вы добавляете JavaScript — вам нужна интерактивность или какая-то функциональность, которую может предоставить только JavaScript. Вполне понятно зачем нам нужны библиотеки. Мы подключали jQuery, чтобы помочь нам упростить работу с DOM, Ajax и справиться с кросс-браузерными проблемами с помощью JavaScript.

Поскольку потребность в этих библиотеках гаснет, и мы наблюдаем массовый рост новых фреймворков, кстати в данной статье есть примеры известных приложений, исполюзующих React, но я бы сказал, что не совсем понятно, когда эти фреймворки нужно использовать. В какой момент нам нужен тот же React?

Я просто собираюсь использовать React в качестве альтернативы для своего рода больших JavaScript-фреймворков: Vue, Ember, Angular, Svelte … и так далее. Я понимаю, что они все далеко не одинаковые, но в каких случаях их использовать, я нахожу одинаково туманным.

Вот мои список «за» и «против».

Большое количество состояний (state).

Слово «состояние» или state тоже немного туманное. Представьте себе следующие вещи:

Какой элемент навигации активен
Будет ли кнопка отключена или нет
Какие разделы аккордеона расширены
Момент загрузки области
Пользователь, вошедший в систему, и категория, к которой он принадлежит
Опубликована ли статья, над которой работает пользователь, или же это черновик

React не помогает вам организовывать эти состояния, он просто говорит: я знаю, что вам нужно иметь дело с состоянием, поэтому давайте просто назовем его state и будем иметь программные способы установки и получения этого состояния.

Долгое время мы рассматривали DOM как единственный источник данных. Например, вам нужно знать, может ли форма на вашем сайте быть отправлена. Скорее всего вы сделаете такую проверку: $(«.Form input[type=’submit’]).(«:Disabled»), потому что вся логика, которая решает вопрос о том, может ли форма быть отправлена в конечном итоге это — атрибут Disabled кнопки отправки. Или например, получить имя автора первого комментария в статье. Наверняка вы напишете подобное $(«.Comments>ul>li:first> h4.comment-author).text(), потому что DOM единственное место, в котором есть эта информация.

React говорит нам:

Давайте начнем думать обо всем этом как о событиях (state).
Кое-что я улучшу: state — это часть JSON, и с ним легче работать и который возможно приятнее совмещать с вашим бэкендом.
И еще одно улучшение: вы строите свой HTML, используя кусочки этих state, и вам не придется иметь дело с DOM напрямую, я беру все это на себя (и, вероятно, сделаю эту работу лучше и быстрее чем вы).

Борьба с «Спагетти-кодом»

Спагетти-код — это запутанный и трудный для понимания код, он назван так, потому что ход его выполнения похож на миску спагетти, тоесть извилистый и запутанный (wikipedia).

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

React поощряет распределение кода на модули. Таким образом, эта форма, скорее всего, либо будет самостоятельным модулем, либо будет состоять из более мелких модулей. Каждый из них будет обрабатывать логику, которая имеет прямое отношение к форме.

React говорит: хорошо, вы не собираетесь следить за изменениями и содержанием DOM напрямую, потому что DOM принадлежит мне, и вы не можете напрямую работать с ним. Почему бы вам не начать думать об этих вещах как о части состояния, когда вам нужно изменять эти состояния, а я разберусь с остальным, представлю то, что должно быть представлено.

Следует сказать, что сам React полностью не исключает спагетти-код. Вы все еще можете иметь state в самых странных местах, непонятным образом называть переменные и прочее.

По моему ограниченному опыту, именно Redux — это то, что действительно убивает спагетти (или съедает напрочь если хотите). Redux говорит: я буду обрабатывать все важные состояния, полностью, глобально, а не модуль за модулем. Если вам нужно изменить state, то нужно провести определенную церемонию или выполнить определенные правила. Существуют «редюсеры» (reducers) и «диспатчеры» (dispatch) и тому подобное. И все они следуют «церемонии проведения».

Множество манипуляций с DOM.

Ручные манимуляции с DOM, вероятно, являются самым ярким показателем спагетти-кода.

React говорит: вы не можете напрямую обращаться к DOM. У меня есть виртуальный DOM, и я занимаюсь этим. События привязаны непосредственно к элементам, и если вам нужно сделать что-то сверх того, что можно напрямую обработать в этом модуле, вы можете по определенным правилам обращаться к модулям более высокого порядка, но тут все просто и отслеживаемо.

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

Просто так. Потому что это тренд.

Изучать чтото ради обучения чему-то это конечно здорово. Но все же к разработке проекта на продакшен нужно подходить более внимательно.

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

Блог представляющий собой SPA («Single Page App»), одностраничное приложение не требующее перезагрузки страниц браузером, до сих пор является пустой нишей. В свою очередь, CMS веб приложения, для создания блогов например, будут отличным выбором в сторону React.

Мне просто нравится JavaScript и я хочу писать все на JavaScript.

Только с недавних пор веб-истории стало возможным никогда не покидать JavaScript. У вас есть Node.js для выполнения кода на стороне сервера. Есть множество проектов, которые вытаскивают CSS из миксов и обрабатывают стили с помощью JavaScript. И с React-ом ваш HTML тоже хранится в JavaScript.

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

Это то, что я знаю.

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

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

Потому что есть специалисты.

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

Выбрать React для своего проекта, потому что у вас есть специалисты по React, в этом нет ничего плохого. Как знать, возможно как раз он идеально подойдет для вашего проекта.

Не совсем точный перевод статьи css-tricks.com

Почему не следует использовать ReactJS для сложных интерактивных фронтенд-проектов / Блог компании NIX / Хабр

Перевод статьи, посвящённой использованию ReactJS для создания фронтенда.

React — отличный инструмент для реализации простых интерактивных веб-сайтов. Но насколько он применим в сложных фронтенд-проектах? Работает ли он там столь же хорошо?

В этой статье мы рассмотрим некоторые проблемы, с которыми можно столкнуться при использовании React во время веб-разработки. Также вы узнаете, почему автор статьи решил разработать новый фреймворк на Scala, благодаря которому удалось сократить количество строк кода с 30 тысяч (на React) до одной тысячи.

Ключевые моменты

Компоненты React трудно использовать повторно в сложных веб-проектах.

Алгоритм Virtual DOM в React медленный и неточный.

HTML-шаблоны React не являются ни полными, ни мощными.

React требует сложного асинхронного программирования при общении с сервером.

Binding.scala содержит меньше концепций, но больше функций. Перспективный Binding.scala решает сложные проблемы, которые React решить не может.

Предпосылки

Многим фреймворк React кажется более простым и удобным по сравнению с AngularJS. Одной из самых полезных его функций является связывание данных (data binding). Оно позволяет сопоставить источники данных с элементами веб-страниц, что предоставляет удобный способ реализации простых интерактивных веб-сайтов.

Однако возможны ситуации, в которых React не может решать запутанные проблемы так же легко, как простые. Если поэкспериментировать с TodoMVC, то окажется, что приложение на фреймворке Binding.scala содержит всего 154 строки кода по сравнению с 488 строками на React.

Дальше мы рассмотрим четыре проблемы React и как их решает Binding.scala.

Проблема 1: компоненты React трудно повторно использовать в сложных интерактивных веб-проектах

Минимальным блоком для повторного использования в React является компонент (React.Component). Он более лёгкий, чем Controller и View в AngularJS. От веб-разработчика требуется лишь реализация функции render, которая транслирует свойства (props) и состояние (state) компонента в HTML-элементы.

Такой легкий компонент очень удобен при создании простых веб-страниц. Однако, когда требуется взаимодействие между несколькими компонентами, неизбежна передача функций обратного вызова (callback functions) в качестве параметра. В частности, для веб-страниц со сложными структурами приходится использовать десятки взаимосвязанных компонентов, в которых коллбэки передаются от родителей к потомкам из слоя в слой. Единственным результатом применения фреймворка React в таких сложных интерактивных веб-проектах будет то, что код станет слишком беспорядочным и трудноподдерживаемым.

Проблема 2. Virtual DOM в React является медленным и неточным

Алгоритм рендеринга в React использует Virtual DOM.

Разработчик обязан предоставить функцию render, которая создает виртуальный DOM, используя свойства и состояние компонента. А React на основе этого виртуального DOM конструирует реальный.

При изменении состояния React вновь вызывает функцию render и строит новый Virtual DOM. Затем он анализирует различия между старой и новой версией виртуального DOM и применяет их к реальному DOM.

У этого процесса есть два недостатка:

1. Независимо от того, что изменилось в состоянии, функции рендеринга всегда будут генерировать новые полные виртуальные DOM. Если функция render сложна, то вычислительные ресурсы тратятся впустую.

2. Сравнение двух версий DOM медленное и подвержено ошибкам. Например, если вы хотите вставить элемент li в начало ul, то React ошибочно решит, что вы модифицировали все компоненты li в ul и добавили один li в конце.

Поскольку две версии виртуального DOM независимы друг от друга, React не имеет представления о том, что происходит на самом деле. Он случайным образом угадывает произошедшие изменения, основываясь на обоих DOM. Этот алгоритм очень медленный и неточный. Веб-разработчики вынуждены использовать свойство key, а также методы shouldComponentUpdate и componentWillUpdate, чтобы помочь фреймворку угадать правильно.

Проблема 3. HTML-шаблоны React не являются ни полными, ни мощными

Для разработки HTML-шаблонов React поддерживает JSX.

Теоретически, фронтенд-разработчики могут превратить статический HTML в динамическую веб-страницу, просто скопировав HTML в JSX-файлы и добавив немного дополнительного кода. Действительно, React больше подходит для повторного использования HTML-шаблонов по сравнению с другими фреймворками, такими как Cycle.js, Widok и ScalaTags.

К сожалению, поддержка HTML в React является неполной. Разработчик должен вручную заменить class на classname, а for на htmlFor. Кроме того, синтаксис встроенных стилей необходимо поменять с CSS на JSON. И хотя веб-разработчики могут копипастить HTML в код, это всё равно требуется много времени и усилий. Таким образом, нельзя сказать, что React превосходит Cycle.js, Widok или ScalaTags.

Для проверки валидности данных React предоставляет механизм propTypes. Но этот механизм полон дыр. Даже используя propType React сможет найти ошибки только во время работы программы, а не во время компиляции.

React также не способен найти ошибки в именах. Например, если написать onclick вместо onClick, то сообщения об ошибке не будет, но программа завершится сбоем. На поиски таких бессмысленных ошибок разработчики обычно тратят очень много времени и энергии.

Проблема 4: React требует сложного асинхронного программирования при общении с сервером

Рассмотрим работу React с сервером в терминах шаблона Model-View-ViewModel. Веб-разработчику нужно реализовать слой доступа к базе данных (Model), state в качестве ViewModel и функцию render в качестве View. Модель обеспечивает доступ к API бэкенда и устанавливает state (ViewModel), используя промисы (Promise and fetch API). Затем render (View) обеспечивает визуализацию ViewModel на веб-страницах.

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

Выводы

Binding.scala в некотором роде кажется похожим на React. Но лежащий в его основе механизм полностью отличается от React и Widok, он проще и универсальнее. Binding.scala гибче и мощнее, чем React. Мы можем использовать Binding.scala для решения сложных проблем, которые React решить не может.

Кроме четырех аспектов, упомянутых выше, есть и довольно значительная проблема управления состоянием в React. Если для управления состоянием использовать стороннюю библиотеку, такую как Redux, то структура приложения станет еще более запутанной, а количество слоев увеличится.

Для сравнения, Binding.scala описывает сложное состояние, используя тот же механизм связывания данных (data-binding), что и для рендеринга веб-страницы. И нет никакой надобности в сторонних библиотеках для обеспечения таких функций, как клиент-серверное взаимодействие, управление состоянием и URL-диспетчеризация.

Различия между Binding.scala и React:

		Binding.scala	React
Повторное использование	Минимальный блок для повторного использования	Метод	Компонент
	Уровень сложности повторного использования	Возможность повторного использования независимо от интерактивных или статических компонентов	Простота повторного использования в статических компонентах, но трудно использовать в интерактивных компонентах
Алгоритм рендеринга веб-страницы	Алгоритм	Точная привязка данных	Virtual DOM
	Производительность	Высокая	Низкая
	Корректируемость	Автоматически обеспечивает правильность	Необходимо вручную настроить ключевые атрибуты
HTML	Синтаксис	Scala XML	JSX
	Поддерживает синтаксис HTML или XHTML?	Полностью поддерживает XHTML	Частично поддерживает, не может компилировать нормальный XHTML. Разработчики должны вручную заменить атрибуты `class` и `for` на `className` и `htmlFor`, а также изменить синтаксис стилей с CSS на JSON
	Как проверяется синтаксис	Проверяется автоматически при компиляции	Выполняется через `propTypes`, но не может найти очевидные орфографические ошибки
Взаимодействие с сервером	Механизм	Автоматическая удаленная привязка данных	MVVM + асинхронное программирование
	Уровень трудности реализации	Легко	Тяжело
Другое	URL-диспетчеризация	Поддерживает URL-адреса как обычные связанные переменные, не требует сторонней библиотеки	Не поддерживает, требуется сторонняя библиотека react-router
	Полнота функциональности	Полное решение для фронтенд-разработки	Содержит только функциональность слоя View. Требует сторонние библиотеки для полной фронтенд- разработки
	Кривая обучения	API относительно прост. Легок для понимания даже теми, кто никогда не использовал Scala	Удобно. Но чрезвычайно трудно изучить стороннюю библиотеку, которая используется для компенсации слабых сторон фреймворка

Ещё недавно среди представителей сообщества Scala.js самым популярным фронтенд-фреймворком был Widok. Но вскоре это место занял Binding.scala. Даже автор Widok Тим Нирадзик (Tim Nieradzik), не смог удержаться от похвалы и назвал Binding.scala наиболее перспективным фрейворком для рендеринга HTML5. Awesome Scala, сравнивая Binding.scala с конкурентами, также приходит к выводу, что этот фреймворк сейчас популярнее, чем Udash и Widok

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

Умерла ли библиотека jQuery — Разработка на vc.ru

Этот вопрос разжигает дискуссии в мире разработчиков.

Почему считают, что jQuery мёртв

Потому что с появлением Vue.js, React, Angular сложные задачи стали простыми. Попробуйте сделать фильтр на jQuery, зависимый от поведения пользователя контент либо сложную анимацию — уверен, у вас возникнут трудности.

Стоит ли использовать библиотеку jQuery

Смотря для каких задач. Если вам надо сделать слайдер, валидацию формы или простую анимацию, то используйте jQuery. В других случаях — Vue.js, React, Angular.

Как долго jQuery будет жив

Более 80% плагинов написаны на этой библиотеке, более 85% сайтов используют jQuery. Я считаю, что библиотека будет жить минимум пять лет. По мере развития нативного JavaScript развивается и jQuery.

Спасибо за внимание! Жду ваших яростных комментов 🙂

Стоит ли использовать jQuery в 2019 году: сравнение с vanilla JavaScript

От автора: многие люди выступают за «просто используйте vanilla JavaScript, вам не нужен jQuery». Ну, многие вещи мне не нужны, но, тем не менее, их приятно иметь. Мне не обязательно нужен JQuery в 2019 году, у него есть не только плюсы, но и минусы. Но его, конечно, приятно иметь!

Такие страницы, как You might not need jQuery, пытаются продвигать идею, что вы можете легко отказаться от jQuery, но самый простой пример того, почему — это хорошая идея использовать jQuery: одна строка обычного кода jQuery заменяет 10 строк vanilla JS!

Большая часть JavaScript API — особенно DOM API — оскорбляет мое чувство эстетики, и это просто вежливый способ сказать, что я думаю, что JavaScript — это отстой.

el.insertAdjacentElement(‘afterend’, other) несомненно работает, но $(el).after(other) на самом деле более приятно. Хотя я никогда не был большим поклонником того, как выглядит функция $(), она намного лучше, чем то, что дает нам DOM.

Простой пример: как вы получаете элемент одного уровня? Это nextSibling или nextElementSibling? Какая разница? Какие браузеры поддерживают что? Пока вы заняты тем, что пытаетесь свериться с MDN, я просто буду использовать в jQuery next() или prev().

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Узнать подробнее

Многие обычные операции в стандартных API-интерфейсах JavaScript неудобны; я мог бы привести целый список, но страница You might not need jQuery (YMNJQ) уже сделала это.

Вам по-прежнему понадобятся вспомогательные функции для различных общих задач. Опять же, на странице YMNJQ перечислены некоторые из них. Использование jQuery является стандартным способом включения этих вспомогательных функций вместо копирования / вставки их из случайных тем Stack Overflow каждый раз, когда они вам нужны.

Хотя совместимость браузеров является гораздо менее существенной проблемой , но она все еще актуальна, особенно если вы не принадлежите к типу людей «если это работает для 85% всего мира , то это достаточно хорошо для меня».

Вы всегда должны использовать JQuery? Нет, конечно нет. Добавление любой зависимости сопряжено с увеличением сложности и размера файла, но jQuery не так уж велик: сборка по умолчанию составляет 30 КБ, сжатая, пользовательская сборка без ajax и необычных вещей 23 КБ, а сборка, использующая querySelector вместо SizzleJS, составляет 17 КБ. И оригинальные 30K, и оптимизированные 17K кажутся мне вполне приемлемыми для многих целей.

Вы можете посмотреть на Bootstrap удаляет jQuery, чтобы увидеть пример того, как много усилий может потребоваться для использования vanilla JS: они написали свои собственные хелперы, пришлось отказаться от поддержки IE, так как ее было слишком сложно добавить, сделали API несовместимым («мы сломали все») и потратили на это полтора года. Если я посмотрю на конечный результат, я не могу сказать, что это намного лучше.

Я понимаю, почему они это сделали; люди хотят использовать Bootstrap с Vue.js и еще много чего, а использовать и Vue.js, и jQuery немного глупо. Я за то, чтобы уменьшить «веб-раздутие», но мы должны быть прагматичными и реалистичными. Включение ~17K jQuery действительно так плохо? Когда я упоминаю, что вам нужен более чем мегабайт JavaScript для такого сайта, как Medium или New York Times, то что, 17 КБ jQuery такое уж невыносимое бремя?

Есть несколько веских причин не использовать jQuery: если вы пишете код, который хотите использовать повторно, или если вы пишете только небольшую функцию. Но делать что-то, просто чтобы избежать jQuery? Просто используйте jQuery! «JQuery для всего», вероятно, не была такой уж хорошей идеей, но и «jQuery ни для чего» не лучше.

Я не зациклен на jQuery, и я с радостью использую «jQuery light», который соединяет JS API с чем-то более привлекательным. YMNJQ рекомендует bonzo и $dom, а также несколько других для AJAX и тому подобного, но многие из них, кажется, не поддерживаются достаточно. Кроме того, все уже знают jQuery. Зачем заменять его чем-то другим, если для этого нет веских причин?

Некоторые читатели могут задаться вопросом «а как же Vue.js, React или какой-либо другой современный фреймворк?» Цель этого поста — сравнить vanilla JavaScript с jQuery, а не предлагать Великую унифицированную теорию развития веб-интерфейса.

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

Означает ли это, что эти веб-фреймворки всегда плохи? Нет, не так уж много вещей плохи «всегда» (или хороши), чаще всего это набор компромиссов (как, впрочем, и в случае jQuery).

По сути, я думаю, что Интернет — это система для просмотра документов, а не операционная система. Даже для многих «веб-приложений» (что бы вы ни имели ввиду) подход к документам работает достаточно хорошо (эта тема заслуживает отдельной публикации… может, когда-то в будущем).

Автор: Martin Tournoij

Источник: https://arp242.net

Редакция: Команда webformyself.