Зачем нужен React js

Favicon

Блог по web технологиям. Веб студия г. Воронеж. Создание и поддержка сайтов на заказ.

Главная
/
JavaScript
/
Когда проекту необходим React?

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

Вы знаете, когда проекту необходим 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> h3.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, в этом нет ничего плохого. Как знать, возможно как раз он идеально подойдет для вашего проекта.

Почему стоит использовать React JS при разработке приложений

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

Библиотека React была впервые выпущена компанией Facebook в 2013 году. Для того, чтобы понять, насколько популярной эта технология стала за прошедшее время, давайте обратимся к опросу разработчиков, проведенному сайтом StackOverflow в этом году. Более 50 000 разработчиков поделились информацией о своей работе и профессиональных предпочтениях. Помимо более или менее предсказуемых результатов, которые обрисовывают состоянии IT-индустрии на сегодняшний день, есть также и кое-что любопытное относительно непосредственно React. Эта библиотека стала одной из самых любимых и востребованных технологий, а также самой трендовой технологией на StackOverflow:

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

Что такое React JS. Краткий обзор

React это библиотека для создания пользовательских интерфейсов. Одной из ее отличительных особенностей является возможность использовать JSX, язык программирования с близким к HTML синтаксисом, который компилируется в JavaScript. Разработчики могут добиваться высокой производительности приложений с помощью Virtual DOM. C React вы можете создавать изоморфные приложения, которые помогут вам избавиться от неприятной ситуации, когда пользователь с нетерпением ожидает, когда же наконец завершится загрузка данных и на экране его компьютера наконец появится что-то помимо анимации загрузки. Созданные компоненты могут быть с легкостью изменены и использованы заново в новых проектах. Высокий процент переиспользования кода повышает покрываемость тестами, что, в свою очередь, приводит к более высокому уровню контроля качества. Используя React Native мобильные приложения для Android и iOS, используя опыт JavaScript и React разработки.

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

Какую пользу из React может извлечь заказчик?
Итак, давайте разбираться:

Virtual DOM может повысить производительность высоконагруженных приложений, что может снизить вероятность возникновения возможных неудобств и улучшает пользовательский опыт;
Использование изоморфного подхода помогает производить рендеринг страниц быстрее, тем самым позволяя пользователям чувствовать себя более комфортно во время работы с вашим приложением. Поисковые системы индексируют такие страницы лучше. Поскольку один и тот же код может быть использован как в клиентской, так и в серверной части приложения, нет необходимости в дублировании одного и того же функционала. В результате время разработки и затраты снижаются;
Благодаря переиспользованию кода стало гораздо проще создавать мобильные приложения. Код, который был написан во время создания сайта, может быть снова использован для создания мобильного приложения. Если вы планируете использовать не только сайт, но и мобильное приложение, нет необходимости нанимать две большие команды разработчиков.

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

Улучшения пользовательского опыта ваших сайтов и приложений
Увеличения скорости разработки
Использования наиболее трендовых технологий разработки

Изоморфные приложения. Поймать двух зайцев

Когда мы говорим об изоморфных приложениях или об изоморфном JavaScript, мы имеем в виду, что мы можем использовать один и тот же код как в серверной, так и в клиентской части приложения. Когда пользователь открывает сайт в своем браузере, содержимое страницы должно быть загружено с сервера. В случае с SPA-приложениями (Single Page Application), это может занять некоторое время. Во время загрузки пользователи видят либо пустую страницу, либо анимацию загрузки. Учитывая, что по современным стандартам ожидание в течение более чем двух секунд может быть весьма заметным неудобством для пользователя, сокращение времени загрузки может оказаться крайне важным. А вот еще одна весомая проблема: поисковые машины не индексируют такие страницы так хорошо, как нам хотелось бы. Исполнение JavaScript кода на стороне сервера помогает исправить подобные проблемы. Если вы создаете изоморфные приложения, вы можете извлечь заметную выгоду, производя рендеринг на стороне сервера. После загрузки страницы вы все еще можете продолжать рендеринг компонентов. Такая возможность рендеринга страниц как на сервере, так и на клиенте приводит к заметным преимуществам, таким как возможность лучшего индексирования страниц поисковыми машинами и улучшение пользовательского опыта. Более того, такой подход позволяет снизить время, затрачиваемое на разработку. При использовании некоторых современных фреймворков, вы должны создавать компоненты, которые должны рендериться на стороне сервера, а также шаблоны для клиентской стороны приложения. React разработчики могут создавать компоненты, которые работают на обеих сторонах.

Virtual DOM. Просто потому, что так быстрее

Document Object Model, или DOM, — это способ представления и взаимодействия с объектами в HTML, XHTML и XML документах. Согласно этой модели, каждый такой документ представляет собой иерархическое дерево элементов, называемое DOM-деревом. Используя специальные методы, мы можем получит доступ к определенным элементам нашего документа и изменять их так, как мы хотим. Когда мы создаем динамичную интерактивную веб-страницу, мы хотим, чтобы DOM обновлялся так быстро, как это возможно после изменения состояния определенного элемента. Для данной задачи некоторые фреймворки используют прием, который называется «dirty checking» и заключается в регулярном опросе состояния документа и проверке изменений в структуре данных. Как вы можете догадаться, подобная задача может стать самой настоящей головной болью в случае высоконагруженных приложений. Virtual DOM, в свою очередь, хранится в памяти. Именно поэтому в момент, когда «настоящий» DOM меняется, React может изменять Virtual DOM в мгновение ока. React «собирает» такие изменения сравнивает их с состоянием DOM, а затем перерисовывает изменившиеся компоненты.

При данном подходе вы не производите регулярное обновление DOM. Именно поэтому может быть достигнута более высокая производительность React приложений. Второе следствие вытекает из изоморфной природы React: вы можете производить рендеринг на стороне сервера совсем как на стороне клиента.

Как переиспользование кода помогает разрабатывать и тестировать приложения более эффективно

Мобильные приложения имеют некоторые преимущества по сравнению с сайтами. Их можно использовать без соединения с Интернетом. Они имеют доступ к таким возможностям устройства, как всплывающие уведомления. Также они позволяют быть в контакте с вашими пользователями в режиме 24/7. React Native — это фреймворк, который позволяет вам создавать мобильные приложения, используя React. Логика приложения пишется на JavaScript, таким образом, программисту не нужно отказываться от привычных приемов веб-разработчика. Все что нужно — научиться писать специфичный для устройства код, который адаптирует компоненты, ранее созданные для веб-сайта к новой среде обитания.

Если мы сравним затраты на разработку разных видов мобильных приложений, мы получим примерно следующие результаты:

В случае с нативными приложениями вы можете надеяться на довольно высокую производительность, но стоимость разработки будет довольно высокой;
Если вы предпочтете фреймворки, которые позволяют использовать HTML5, CSS3 и JavaScript, например PhoneGap, вы можете снизить стоимость. Но в этом случае уровень производиетльности будет гораздо ниже;
В случае React вы можете достигнуть уровня производительности, сравнимого с нативными приложениями. При этом стоимость разработки сравнима с предыдущим примером.

Читать еще: Как сдавать гормоны

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

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

Заключение

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

Объявсните, зачем нужны React, Angular и Vue.js?

Что-то никак не пойму, зачем всё это нужно. Можете подсказать пример сайта (или его части) где без этого всего ну вообще никак? Пока что понял, что через эти библиотеки можно выводить контент в html. Но зачем?

Объявсните, зачем нужны автомобили?

Что-то никак не пойму, зачем всё это нужно. Можете подсказать пример региона (или его части) где без этого всего ну вообще никак? Пока что понял, что через эти штуки можно перемещаться по дорогам. Но зачем?

По сабжу: они нужны именно для того, чтобы выводить контент в html.

Объявсните, зачем нужны автомобили?

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

Ты прав. А большинство сайтов интернета может быть заменено пабликами вконтакте.

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

Рендерить на стороне сервера — довольно таки затратно.

Просто я не врубаюсь, зачем через js рендерить контент в html, если он не с сервера пришел.

Вот нажал пользователь кнопочку «скрыть меню». Ты его скрыл. Без всякого взаимодействия с сервером. Решил пользователь залезть в меню, нажал опять на кнопочку, ты меню показал. Без всяких повторных запросов. Вот затем и рендерить через js, чтобы страница на действия пользователя реагировала.

Ты прав. А большинство сайтов интернета может быть заменено пабликами вконтакте.

А так скоро и будет в Чебурнете.

Это всё делается на HTML и CSS. Без джаваскриптов вобще. Или я тебя не так понял.

Ну в самом простом случае – делаешь кнопку «скрыть меню» из тега A, в него вкладываешь список-меню из тегов UL/LI. В css пишешь:

Можно использовать чекбокс и :checked, например. Масса вариантов.

Я не форнтенд девелопер но пробовал React. Только один кейс от человека который далек от js. У меня была модель (динамически подгружаемые данные), её нужно было преобразовать во view в табличном виде, как это сделать? В начале я подумал сделать свой велосипед для биндинга данных в dom дереве, но быстро нашел knockoutjs. Все в нем было хорошо, кроме того что нужно было править html при изменении структуры данных. ReactJS мне позволил сделать динамичную генерацию view от модели.

Это не гибко и не семантично.

Все нормальные верстальщики так делают.

Это не гибко и не семантично.

Ох, пожечки ты мой, ну.

Я про всю массу вариантов, а не про первый. Всеравно читер ))

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

Тут стоит использовать простое правило: если вам не понятно, зачем это нужно, – значит оно вам не нужно.

Вобщем, о чём это я. Меню (в том числе многоуровневое) строится на html/css. Не смотря на то, что я пару лет как основательно пишу чисто на js, этого факта отрицать не могу. А берутся пункты меню откуда? Либо заданы жёстко разметкой в простейшем случае, либо дёргаются из базы данных с помощью (ТАДАМ!) серверных ЯП. Я лично не вижу смысла дёргать из БД данные, скажем, на PHP, генерить из них JSON, отдавать клиенту, на клиенте с помощью JS из JSON генерить HTML с той же подвязкой из CSS, когда можно минуя JS/JSON сразу создать разметку на стороне сервера на PHP и (sic!) закешировать её.

Ну а тут я с тобой согласен на все 146%.

Хотя мне вот недавно по проекту требование прилетело — запиливать на vue. Хотя радует что делать можно не SPA, а только там, где реально можно красиво/удобно запилить, т.е. не перегибать и не ударяться в крайности.

Тут стоит использовать простое правило: если вам не понятно, зачем это нужно, – значит оно вам не нужно.

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

Каждой задаче свое решение. Вот многостраничный список, разбитый по 50 записей на страницу – либо дергать сервер на генерацию всей страницы, либо только на отдачу JSON. Второе менее затратно. Но примеров и за и против вообще можно много нарисовать.

Ты так же легко можешь кешировать эту постраничку постранично.

Ты сравнил костыльную библиотеку, на которой хипстеры по две недели делают формочку на 5 инпутов с автомобилем? Однако.

Да, тут, согласен, не надо всё меню сразу выдавать клиенту, и перегружать страницу – тоже не надо. В далёком мохнатом году для подобных задач придумали AJAX, который по сей день прекрасно с ней справляется и парсить JSON из строки в дерево объектов/массивов давно научились все современные браузеры. Остаётся написать короткую рекурсивную функцию, которая от корневого UL пройдёт по дочерним и в соответствии с JSON заполнит их тегами LI с содержимым. Но это всё не тянет для использование монстра типа Angular и подобных. Это на данный момент даже jQuery уже не требует.

Читать еще: Когда отмечают день прощения

Жизнь кеша может стать слишком короткой, если данные часто изменяются.

Это всё делается на HTML и CSS. Без джаваскриптов вобще.

Можно пошаманить с CSS и HTML, можно бэкэнд на крестах написать. Можно много чего руками сделать. Но на vue это делать проще.

Разумеется, ради одной кнопки скрытия меню, тащить жирную либу нет смысла. Но если тебе нужно не только скрытие меню, а ещё что-нибудь из 100500 вариантов, то колбасить это всё руками нет никакого смысла.

когда можно минуя JS/JSON сразу создать разметку на стороне сервера на PHP и (sic!) закешировать её.

И, как минимум vue, этому никак не мешает.

Модель-Вид-Контроллер, Модель-Вид-МодельВида, Модель-Вид-Представитель, активная модель, пассивная модель, пассивный вид, контроллер-супервизор. четырёхклятаяфигня. мне работать надо, а не в сортах контроллеров разбираться. Есть некоторая грань, переходя через которую ты перестаёшь писать код для людей, а начинаешь бить морды друг другу в курилке за поклонения разным шаблонам проектирования.

Я сравнил гроб на четырёх колёсах, под которым хипстеры лежат по две недели, не вылезая из гаража с фреймворком. Да.

мне работать надо, а не в сортах контроллеров разбираться.

И что тебе мешает работать?

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

Ну так не переходи эту грань.

Кеша шаблонов или кеша данных? Хотя не важно, и там и там это решается временем изменения.

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

И что тебе мешает работать?

Как что. Берут меня (фронтэндщика), какого-то парня (бэкэндщика) дизайнера там, тестера на простенький проектик, и ставят в надзирание на пол ставки тимлида. Тимлид вчера читал хабру и наткнулся там на очередной Vue, он узнал из статьи, что Vue круче, чем Angular, поэтому новый проект мы (вернее я, он то ничего делать не будет) будем писать на Vue, а старый – поддерживать на ангуляре. А ещё он прочитал, что PHP – это недостаточно по-хипстерски и не потянет наш хайлоад по продаже спиннеров в Нижнезадрыщенске, поэтому бэкэндщик будет писать тоже на JS, а не на привычном ему PHP, так что тот обязан по ходу дела разобраться в ноде, npm, и кей-вэлью БД, потому что так хипсторы делают. Один дизайнер тихонько сидит в уголке и плачет, обнимая свой фотошоп, потому что не дай бог тимлид узнает, что есть бесплатный GIMP.

Смени работу, думаю ещё есть много мест где достаточно открывать меню css.

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

Ну так не переходи эту грань.

Я открываю «мой круг» и смотрю вакансии.

Так-так, что у нас там по CSS?

Less, Sass, Scss, Haml. погодите, что? Четыре языка стилей, кроме одного? Ну ок.

А что у нас там по JS фреймворкам? jQuery, React, Redux, Angular, Vue, Backbone. как я, чёрт возьми, это всё изучу?

А это ещё, матерь божья, что такое? CoffeeScript, TypeScript – ещё два языка для фронтэнда, которые в итоге скомилируются в JavaScript?

Вам не кажется, что слишком много развелось утилит для определённого круга задач, который раньше решался тремя-четырмя? Это как придумать пятьдесят одинаковых молотков с разным цветом ручки – и пока все цвета не выучишь, к забиванию гвоздей не подпускать!

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

Ну так жизнь проф. фронтендщика тяжела. Потому я туда и не лезу.

Но это разнообразие не отменяет того факта, что vue, при разумном его применении, облегчает разработку.

Top 23 Best Free JavaScript Frameworks for Web Developers 2017

Есть ещё которые не Free и которые не Top. Я не зря сказал про пятьдесят цветов рукояток молотков.

Haml — не язык стилей, а шаблонизатор. Sass и Scss — два диалекта одного и того же языка. jQuery, React, Redux — не фреймворки (Vue и Backbone разве что с натяжкой). Redux так вообще просто библиотека state machine, не зависящая от view-слоя. CoffeeScript устарел, TypeScript от современного JavaScript отличается только типизацией. Так что выбирай что-то одно из каждого набора и учи. Зачем тебе одинаковые молотки, если нужны молоток, отвёртка и плоскогубцы?

Да в этом случае проще вообще не кешировать на стороне приложения, а оставить все на бд и ее кеши.

Рендерить на стороне сервера — довольно таки затратно.

Все нормальные люди пользуются кешированием.

А бд в любом случае проверяет то же самое — филемтайм файла или аналогичное поле в структуре в памяти/файле. Но в бд нет шаблонов.

Все нормальные люди пользуются кешированием.

Ты не закэшируешь все миллиарды вариантов стейта, в зависимости от которых будет разный отрендеренный DOM для разных юзеров.

Зачем тебе учить всё, тем более если половина из перечисленного (less, jquery, backbone, coffeescript) — трупы?

Не, ну, смотря какая задача стоит.

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

Куда-то не туда ушел веб.

Зачем тебе учить всё, тем более если половина из перечисленного (less, jquery, backbone, coffeescript) — трупы?

Скажем так. Мне – уже незачем, потому что ввиду того что я давно интересуюсь вебом, я все эти штуки хорошо знаю. Ну, если быть совсем честным, то первые две – на отлично, а остальные – на четвёрочку, может, с минусом, но не суть. Ещё в моих амбарах безумия есть воспоминания о Marionette, Dart, LiveScript, ещё я на флеше писал, но застал только третий ActionScript, который тоже из семейства ECMA*, ну прочая фигня.

А вот новичку что делать? Если ты берёшь, открываешь список вакансий, а там полно их с требованием знать jQuery тот же. ведь не смотря на то, что браузеры сейчас много умеют, некоторые хотят чтобы сайт работал и в IE8. И в вакансиях есть less. И бэкбон, и прочие мёртвые технологии. Я бы с удовольствием сейчас писал на мэйнстрим яваскрипте, но на моей текущей работе от меня требуют поддержки не меньше IE10 и только недавно я выбил >=IE11.

Пока что понял, что через эти библиотеки можно выводить контент в html.

Неправильно понял. Если говорить о ангуляре/реакте – то это не веб-фрейморвки. Это обычные графические тулкиты вроде Qt. И нужны они ровно за тем же самым.

Источники:

http://favicon.tech/kogda-proektu-neobhodim-react/
http://xbsoftware.ru/blog/pochemu-stoit-ispolzovat-react-js-razrabotke-prilozhenij/
http://www.linux.org.ru/forum/web-development/13551545

голоса

Рейтинг статьи