Comments 109
Это – одни из самых популярных JavaScript-библиотек в мире. Взгляните на этот список, посмотрите их репозитории на GitHub.
Я бы рекомендовал смотреть на более объективные источники, например реальные опросы большого количества людей
В.И. Ленин?
И в этом есть какой то глубокий смысл…
Однако, не смотря на то что я с автором не точен, сути это не меняет. Я не считаю опросы реальных людей репрезентативнее GitHub'а. А вы?
Я честно говоря не программирую веб, вот такие статьи читаю и пытаюсь понять что это вообще такое.
Такое впечатление, что чистого языка мало и придумывают язык в языке, как какое-то мета-программирование…
Но в чем смысл? Почему не написать просто на JS? Это что сильно труднее?
Знал бы только JS и радовался, но нет, нужно еще понять, что такое React, Vue, Angular, JQuery.
Получается работы по изучению в 5-10 раз больше. И можно ли стать хорошим специалистом если единая в общем веб технология растаскивается на разные подмножества языков, библиотек, компиляторов из мета-языков в другие языки…
Можно хоть на чистом JS, конечно. Но только в процессе создания большого продукта Вы фактически создадите свой микро (или даже не микро) фреймворк, а потом кому-то не вам его поддерживать.
Знал бы только React и радовался, но нет, нужно ещё понять, что такое MyAwesomeFoo, YetAnotherBar, CoolBaz. Получается работы по изучению в 5-10 раз больше.
Например,
1) у железячников
Verilog/VHDL — все более или менее стабильно годами. Ну появился SystemVerilog, но как-то не быстро народ его берет на вооружение.
2) У микроконтрольщиков, там вообще только C редко C++. Микроконтроллеры плюс-минус одинаковые. То же время не быстро бежит. Ну наверное побыстрее, чем у ASIC-WORLD
3) C++ да появляются новые стандарты C++11, C++14, C++17 ну тут побыстрее жизнь идет, уже трудно идти в ногу со временем и приходится стараться.
4) Ну и апофеоз — это веб программирование JS/HTML/CSS и все эти фреймворки. Вот тут мне кажется началась полная вакханалия. Все бегут со скоростью ракеты изобретать новые фреймворки и мета языки.
Просто сложные приложения писать даже на современных JS/HTML/CSS сложно вдвойне.
Справедливости ради, библиотеки и фреймворки и на С++ есть. За ними так же нужно поспевать.
React также можно компилировать на сервере, написанном на Go (golang).
Почему не js?..
Ну, у каждого свои причины. Мне нравится, что каждый компонент — это независимая боевая единица. Сделал компонент «Карточка товара» — она доступна, куда бы её не воткнуть. Это даёт некую уверенность в коде. Например, можно сделать страницу с 50 компонентами, и сделать автотесты, которые проверяют, что ни один пиксель не поменялся при изменении кода, ничего не сдвинулось и так далее. Плюс реактовские плюшки вроде виртуального DOM значительно в некоторых кейсах ускоряют отклик и скорость работы фронтенд части (по сравнению с классическим подходом $('.js-element').html('3 товара')).
Но в чем смысл? Почему не написать просто на JS? Это что сильно труднее?
Более-менее сложные SPA или web-компоненты, написаные просто на JS очень сложно поддерживать и практически невозможно развивать. React, Vue и дргуие инструменты позволяет применяет более-менее декларативный подход при написании front-end, что существенно сокращает затраты на развитие проекта, поддержку, тестирование.
Компилируется это на этапе сборки проекта перед публикацией. Т.е. в браузере работает уже "скомпилированная" версия. Не совсем скрипты, совсем не PHP.
Ну, в общем идея такая, что с языком (JS) все более-менее в порядке. Дело в том, что HTML и CSS слишком низкоуровневы для Rich Internet Applications. Поэтому логичным образом появились более высокоуровневые абстракции, который приближают решение проблемы к оперированию над объектами предметной области. В случае с React и Vue отдельно стоит упомянуть Virtual Dom и те проблемы, которые он решает (и создает, ага): https://habrahabr.ru/post/256965/
Отдалённо, связь такая же как и между языком ассемблера и си. На первом можно реализовать абсолютно всё, но долго и дорого.
А с другой стороны я мог бы прийти в любой проект на реакте и легко в него внедрится потому что
- Весь код организован по некоторым соглашениям и втиснут в общепринятые рамки
- Есть документация и готовая экосистема решений
- Не нужно придумывать велосипед
В общем, надеюсь, идею вы поняли
Оба поддерживают server-side rendering (самый настоящий). Немножко про варианты решения проблемы с индексацией можно прочитать тут http://vuejs.org/v2/guide/ssr.html
Вы ж спросили про поисковики)
И так, как это делается в React: сервер отрисовывает полностью сформированную, готовую страничку и отдаёт её клиенту. Затем клиент получает эту страничку и иницилизирует SPA поверх уже отрисованного div'а, но так как данные на сервере и клиенте обязательно совпадают, то клиентский код получает точно такой же результат рендера, виртуальный дом видит что нет разницы, и перерисовки на самом деле не происходит. В результате этого клиент получает обычный SPA, очень красиво и незаметно
У меня так получилось, что к angularjs SPA проще генерировать шаблоны на jinga2+pyjade, чем писать их целиком. В итоге, заполнить шаблон на сервере вместо форм данными модели или уже отдать заполненные формы — легче лёгкого.
Вполне пристойно обстоят, есть некоторые нюансы, но можно и без server-side рендеринга обойтись: http://andrewhfarmer.com/react-seo/
У ember-data по сути только и есть единственная существенная проблема это нет отслеживания изменений связи из коробки, и то отказаться от этого были причины.
Возможно Ember не идеален, но он следует методологии "соглашения превыше конфигураций", за это имхо можно многое простить. Он навязывает структуру прокта и другие принятые в комьюнити конвенции. В случае больших проектов это дает бонус при поддержке и расширении, особенно ценно для пришедших в уже функционирующий проект разработчиков. Наверное, никто не любит поддерживать код, в котором предыдущие программисты пускались в творчество, полузуясь кучей слабосвязанных библиотек. Да и переживать за архитектуру почти не приходится.
До версии 2.0 документация была скудновата, очень многие моменты приходилось собирать по сторонним блогам. Из-за этого и порог вхождения повышался. Сейчас они вроде как исправились, больше деталей описывают в туториале, больше примеров дают, конференции организовывают, митапы
Как по мне, то если бэкендщику (классический ООП, MVC, вот это вот всё и совсем немножко ФП) нужно лезть на фронт, то лучше React нет. Да ещё если MobX прикрутить.
Angular2 заточен, скорее, под верстальщиков, которые хотя начинать "настоящей" разработкой заниматься.
Похожая ситуация с Ember. Меня больше заботит то, как данные взаимодействуют. Отрисовать малая часть проблемы в SPA как по мне (если заботиться чисто о view то React подойдет лучше).
bjornd у Ember есть недостаток с тем что у него довольно высокий порог вхождения (как по мне). Наш первый проект был болью но последующие, мне сложно представить как бы мы изошрялись без Ember.
Думаю в каждом из фреймворков есть как + так и — , кому то что то пойдет сложно кому то легче. И еще, по одному проекту судить сложно, думаю для объективной оценки нужно сделать 2-3 проекта.
Я так и делаю. Пишу сущность, причём не тупую структуру с данными, а полноценный JS объект с методами изменения состояния, пишу стор/репозиторий с инжектированным шлюзом к серверу/локалстораджу/чемуугодно. Вызываю ReactDOM.render, передав в корневой элемент сторы. И всё. Компоненты реактивно отрисовывают изменения сущностей и репозиториев, обработчики событий дергают их методы.
Я как бекенд разработчик, тоже очень редко сталкиваюсь с фротендом.
И вот свой проект о котором уже писал тут, переписываю с Angular 1 на Vue. И всё получается очень красиво (на гитхабе можно следить за прогрессом).
До этого было в планах переписать на Angular 2, но в него действительно нынче порог вхождения больше чем в остальные фреймворки: Vue, React и Angular 1.
React имеет большой набор хороших преимуществ, но Vue оказался быстрее и менее многословным и фишку с jsx для Vue я уже тоже заиспользовал, вместо Redux там есть Vuex.
В общем я пока остановился на Vue как основном инструменте для фронт энда для своих проектов. А попробовал уже всё.
Но мой опыт это опты не больших (по не которорым меркам) своих проэктиков и никакого энтерпрайза (там у нас есть фронтендщики). И я доволен Vue так же как когда-то был доволен Angular :)
А ну и собственно попробовать Vue меня убедило вот это видео:
Там добротно рассматривается "что не так" с современными фреймворками.
После просмотра и реального использования Vue я готов подтвердить слова автора.
Ну и ещё раз, как бекэнд разработчик моё мнение не совсем объективно.
Просто vuex от автора vue, что как минимум подкупает, а для меня, как человека далёкого от фронтэнда, оказалось очень удобным.
Но спасибо, гляну на revue
Ну Vue вроде как тоже самое обещает https://weex-project.io/
На сколько я понял из то что знаю, а познакомился я с ним 2 недели назад всего
Самое главное забыли написать про Vue — их подход к компонентам.
Вы можете создавать и поставлять отдельные компоненты с расширением *.vue (подмножество XML). Внутри этого файла могут лежать шаблоны, скрипты и стили.
Кроме того, если не хочется все складывать в один *.vue файл, компонент можно разнести отдельно на .css, .js, а в *.vue просто подключить эти файлы через атрибут src:
<script src="./mycomponent.js"></script>
<style src="./mycomponent.css"></script>Все это потом прекрасно собирается либо browserify (через vueify), либо webpack.
Получается такой себе Яндекс БЭМ из коробки, плюс разделение скриптов и шаблонов.
Если честно, это не сильно отличается от Angular 2, но там это вынесено в проперти template и styles — причем последний коллекция, что позволяет несколько стилей объединять в один (общие стили например).
И подход к scoped стилям такой же в Angular 2.
А если что можно и по разным файлам разнести, а потом с помощью browserify или webpack собрать.
vue-loader как раз доя обработки *.vue файлов, а для jsx нужен другой.
Мешанина html и js всегда плохо я согласен, но бывают задачи когда jsx удобен, я уже писал выше, что для одного случая заюзал именно jsx, так как он удобнее. Во всех остальных нормальные *.vue компоненты
<ul>
<li v-for="(item, index) in items">
{{ parentMessage }} - {{ index }} - {{ item.message }}
</li>
</ul>
и
<ul>
{ items.map( (item, index) => <li>{parentMessage} - {index} - {item.message}</li> ) }
</ul>
А разница как раз не в этом, а в том что очень часто пересекаются много js кода с большим количеством html кода например как-то так:
let childrenComponents;
if (this.state.someting) {
childrenComponents = children.map(c => (<MyChildComponent {...myChildProps} v-for="c of children"></MyChildComponents>));
} else {
childrenComponents = children.map(c => (<MyOtherChildComponent {...myChildProps}></MyOtherChildComponent v-for="c of children">));
}
return (<div>
<div class="layout-8">
{childrenComponents}
</div>
</div>);И это очень простой пример, в реальности бывает и хуже. И не надо говорить про плохой код вынесение в компоненты и всё такое :) На самом деле такие вещи встречаются довольно часто. Не смотря на то что я для фронтенда считайте, что не пишу, очень часто видел такие конструкции. Они понятны, в них легко разобраться, но выглядят хуже чем например вот так:
<div>
<div class="layout-8">
<MyChildComponent {...myChildProps} v-if="someting"></MyChildComponents>
<MyOtherChildComponent {...myChildProps} v-else></MyOtherChildComponent >
</div>
</div>И дивы все друг под другом и читать его проще и даже верстальщик может что-то в нём править (если таковые имеются).
И не забывайте что в vue можно использовать jsx без каких либо проблем (с небольшими тонкостями правда). Просто это не основной способ в отличии от React, и для некоторых ситуаций он как раз оптимальный. Я например как писал выше тоже в одном компоненте с радостью заиспользовал jsx, потому что это должно работать быстрее, хотя и обычный <template></template> с v-if-else работал бы нормально.
Они понятны, в них легко разобраться, но выглядят хуже чем например вот так: ...
Этот пример в моем коде выглядел бы вот так:
const ChildClass = this.state.something ? MyChildComponent : MyOtherChildComponent;
return (
<div>
<div class="layout-8">
{children.map(c => <ChildClass {...myChildProps} />)}
</div>
</div>
);
Вообще правильное разделение логики представления и бизнес-логики позволяет оставить в render-методах компонентов только базовые if и for, что как раз соответсвует семантике vue-шаблонов, о чем и был мой первоначальный комментарий.
PS: условие if спрятанное где-то в центре блока кода читается просто ужасно.
Ну вы же понимаете, что есть много примеров в которых так просто всё не перепишешь.
PS: условие if спрятанное где-то в центре блока кода читается просто ужасно.
Да, поэтому обычно я пишу спереди, это тут в примере написал плохо :)
Когда я бы читал эту разметку, я бы задумался, что за компонент у нас такой ChildClass. И хорошо если бы я его сразу нашёл выше, а не пошёл искать по файловой системе в папке components.
Да и линтер должен ругаться на локальную переменную с большой буквы (а если не ошибаюсь компоненты и впрям должны быть с большой буквы).
А при разном наборе свойств вы бы не сократили код до тернарного оператора и всё равно оставили бы if.
В общем, будь у меня достаточно опыта во фронтенде, я бы спорил более аргументировано. Но сейчас со стороны своего бэкэнда — это выглядит не очень. И из всех исходников/туториалов/статей, что мне попадались, было очень много кода похожего на тот, что я написал выше.
Я уверен, что его можно сократить до вашего примера (особенно если разные компоненты повыносить в переменные как у вас), но мало кто так пишет. И именно в этом я часто вижу проблему.
Хотя иногда это и удобно. Вот например как написал я.
И тут действительно jsx удобнее и быстрее, за счёт хеш-таблицы.
Но например на ангуляре 2 гораздо лучше бы смотрелся вот такой код:
<template choose="type">
<template case="text">
<Child1>...<Child1>
</template>
<template case="password">
<Child1>...<Child1>
</template>
<template case="number">
<Child1>...<Child1>
</template>
<template case="select">
<Child1>...<Child1>
</template>
</template>Если бы у vue было бы что-то подобное, то я бы лучше его заюзал чем jsx.
Так в vue тоже virtual dom и native есть
А ну и так же есть сравнение от самих авторов react, и даже benchmarkи:
https://vuejs.org/v2/guide/comparison.html#React
И чуть ниже сравнение скорости.
В общем, так вышло, что первое большое приложение на React я стал писать уже после давнего знакомства с Vue. Я был крайне удивлен, насколько у реакта все плохо с некоторыми аспектами.
Во-первых, еще не начав ничего писать, вы уже получаете огромный бандл, который можно уменьшить только с помощью какой-то странной магии, да и то, не существенно. И чем дальше в лес, тем жирнее этот бандл становится.
Больше всего меня разочаровал раутер. И старый, и новый. Он оказался настолько незрелым и неудобным по сравнению с vue-router, что я долго бродил по гуглу, пытаясь понять, что я делаю не так. Оказалось, так и задумано.
Я оценил красоту концепции в основе Redux, но для ее удобного использования приходится ваять огород из middleware и разных хелперов. И в конечном итоге все это выглядит крайне многословно и запутано. Теряется понимание того, что и куда мы посылаем, и как это «что» в процессе трансформируется.
Еще меня озадачило отношение разработчиков React к некоторым частям этой библиотеки. Например, они крайне не рекомендуют использовать mixins и context. Насчет последнего я понимаю, но миксины-то чем мешают? В Vue это простой и удобный инструмент, который не вызывает лишних вопросов. В React это страшилка, которой пугают детей. Это еще одна особенность React — разработчики тянут из года в год обратную совместимость, не решаясь отрезать лишнее.
Лично для себя я пришел к следующему выводу: люди, разрабатывающие React, больше озабочены красотой концепций и теорией, в то время как Иван Ю, создатель Vue, думает об удобстве разработки, поддерживаемости кода и минимальном размере конечного результата. В итоге Vue вышел не совсем концептуальным, зато чертовски удобным, быстрым и мощным. Точнее, у него просто концепция другая, ориентированная на разработчика.
приложение на React… Больше всего меня разочаровал раутер. И старый, и новый
В React нет роутера…
приходится ваять огород из middleware и разных хелперов
В React нет middleware…
но миксины-то чем мешают?
Их нельзя использовать с классами.
В React это страшилка, которой пугают детей. Это еще одна особенность React — разработчики тянут из года в год обратную совместимость, не решаясь отрезать лишнее.
Миксины, как раз кандидаты на отрезание, т.к. .createClass() рано или поздно станет атавизмом.
В экосистеме React много разных роутеров. Особенно если учитывать, что экосистема React лишь подмножество экосистемы JS. А роутер, как по мне, должен быть изолированным компонентом системы, который обеспечивает возможность подписаться на изменения текущего роута и собственно изменять его. Причём тут React?
В мире Vue есть один, но зато хороший раутер. Он умеет все на свете, хорошо интегрирован с Vue, но при этом простой и не прибит гвоздями.
На $mol конечно же.
Большинство использует jQuery и чихать хотело на эту ерунду, которая скоро умрет :)
Большего всего мне нравится: можно начать с простого, а дальше легко расширить, т.е. архитектура легко масштабируется.
Нравится подход vue в целом, но пока что связка TypeScript + React для меня решает, vs code подсказывает пропсы прямо в JSX(TSX), для vue проверки типов в шаблонах еще не придумали, да и для использования TS там придется использовать свои костыли, классы с декоратором
Если вы про проверку типов пропсов — она есть.
Да и вообще некоторые SPA либы (фреймворки) весят меньше чем jquery* — можно немного сэкономить на весе клиентского js.
Мне как конечному пользователю глубоко фиолетово сколько кода занимает функциональность, мне надо чтобы это работало и не тормозило хоть с мобильным инетом, хоть с ПК.
Но сейчас твердо убежден, что ClojureScript + Re-frame (Reagent)
* React v0.12.2
*
* Copyright 2013-2014, Facebook, Inc.
* All rights reserved.
React или Vue? Выбираем библиотеку для фронтенд-разработки