Comments 64
UFO just landed and posted this here
Интересное заявление в конце статьи, но реакт это не фреймворк(React is a declarative, efficient, and flexible JavaScript library for building user interfaces.).
Хотя сам по себе React — не фреймворк, его использование автоматически означает отказ от других фреймворков, потому что он с ними несовместим.
Поэтому рассмотрение React как альтернативы фреймворкам, а фреймворков как альтернативы React — оправдано.
Еще как совместим. Вплоть до того что реакт можно использовать как библиотеку отображения в ангуляре. Равно как и в, допустим, метеоре или эмбере. Или бэкбоне.
Да, но при этом потеряется вся разметка Ангуляра, благодаря которой он и выигрывал. Это средство для оптимизации критических участков, но никак не основное решение для проекта.
Вот с бэкбоном React совместим, да. Потому что они обе библиотеки и решают разные задачи.
Естественно потеряется, т.к. вы заменяете систему отображения ангуляра на реакт. Но в каком месте это означает, что он не совместим? Реакт это библиотека, которой нужно данные на вход подать. Откуда эти данные приходят абсолютно без разницы. Как результат — реакт совместим в общем со всем чем угодно.
Вопрос конечно в осмысленности этого совмещения.
Я согласен с тем, что в ангуляре это несколько странно(хотя я видел проекты где так было сделано и все замечательно работало), но вот допустим в метеоре или эмбере(особенно в прошлой версии эмбера, где ихний слой отображения был так себе) — вплоне неплохо он смотрится.
Вопрос конечно в осмысленности этого совмещения.
Я согласен с тем, что в ангуляре это несколько странно(хотя я видел проекты где так было сделано и все замечательно работало), но вот допустим в метеоре или эмбере(особенно в прошлой версии эмбера, где ихний слой отображения был так себе) — вплоне неплохо он смотрится.
React — формально, наверное, библиотека. Возможно, фреймворк это не самое удачное слово, но как еще назвать решение, на которое навешивается, например, роутер, со словом «react» в названии? называть «библиотекой отображения» такой комбайн — еще сильнее режет уши, на наш взгляд. Во всяком случае, если пытаешься себе представить что Twig начал вдруг рулить роутингом в PHP…
а ember не рассматривали?
UFO just landed and posted this here
UFO just landed and posted this here
React медленное неуклюжее тормознутое непонятно что. Очень забавно, что все недостатки разработчики FB преподносят как достижения. Еще к нему идет какая-то хреновина для тестов, которая называется «насмешка» или чт-то типа того, которая вообще делает процесс разработки невозможным. Единственный плюс, React почти нихрена не делает, поэтому выбирая реакт хреново будет работать только та часть, за которую он отвечает.
Angular2 отличный фреймворк, в котором продумано почти все. По крайней мере, сравнивая с конкурентами. Typescript — вы можете его использовать в режиме как ES6 без типизации, любому JS девелоперу хватит 1-2 дней чтобы начать писать.
P.S.: я это пишу, чтобы у читающих была альтернатвная точка зрения, так как в статье один из лучших выборов на сегодня (Angular2) описан вскольз
Angular2 отличный фреймворк, в котором продумано почти все. По крайней мере, сравнивая с конкурентами. Typescript — вы можете его использовать в режиме как ES6 без типизации, любому JS девелоперу хватит 1-2 дней чтобы начать писать.
P.S.: я это пишу, чтобы у читающих была альтернатвная точка зрения, так как в статье один из лучших выборов на сегодня (Angular2) описан вскольз
В мире JS нельзя просто так написать «один из лучших выборов», не добавив «сегодня».
Делаю проекты и на реакте и на ангуляре. Чисто субьективно — мне удобнее работать с реактом. Разработка идет быстрее, проблем меньше, дебаггинг проще(одно только то что ошибки в шаблонах отлавливаются не в рантайме — огромный плюс).
В ангуляре постоянно ощущение что для получения ровно того же результата, что и в реакт+редукс. приходится проделать куда больше манипуляций.
Относительно скорости — пока не тестировал ангуляр в этом плане, но реакт без проблем справляется с десятками тысяч записей, включая их регулярное обновление.
Огромное преимущество ангуляра — это наличие там определенной стандартизации в подходах, т.е. человек умеющий работать с ангуляром с большой вероятностью без особой сложности сможет работать с другим проектом на ангуляре.Тогда как реакт не подразумевает вообще ничего и может идти с любым произвольным набором библиотек, что может сделать вхождение в проект затруднительным.
(ангуляр имею в виду конечно второй)
В ангуляре постоянно ощущение что для получения ровно того же результата, что и в реакт+редукс. приходится проделать куда больше манипуляций.
Относительно скорости — пока не тестировал ангуляр в этом плане, но реакт без проблем справляется с десятками тысяч записей, включая их регулярное обновление.
Огромное преимущество ангуляра — это наличие там определенной стандартизации в подходах, т.е. человек умеющий работать с ангуляром с большой вероятностью без особой сложности сможет работать с другим проектом на ангуляре.Тогда как реакт не подразумевает вообще ничего и может идти с любым произвольным набором библиотек, что может сделать вхождение в проект затруднительным.
(ангуляр имею в виду конечно второй)
UFO just landed and posted this here
> и теперь вы должны написать 10 функций, чтобы получить входные данные из 10 полей формы
redux-form?
redux-form?
>>«а не быстро и хорошо решенную бизнес-задачу»
авторы, видимо, любители подхода «х*як-х*як и в продакшен»
>>«подход разбивания компонентов на супертупые (dumb) компоненты из-за ограничений JSX всегда выдергивает вас из потока, в котором вы решаете реальную бизнес-задачу»
и далее
>>«Из React Vue.js взял компонентный подход»
выглядит немного противоречево
Опять таки, я всегда считал что правильно сначала понять что ты хочешь написать, а затем писать, но видимо авторы любители рисковать :) Ну и если надо переписывать приложение — значит много нового кода, но потом придет этап поддержки проекта и тут чистые функции и компонетный подход значительно проще поддерживать (при условии здравого смысла при разбиении на компоненты)
В общем надеялся прочитать какие-то адекватные аргументы, но тут снова «JSX не поддерживает if»
авторы, видимо, любители подхода «х*як-х*як и в продакшен»
>>«подход разбивания компонентов на супертупые (dumb) компоненты из-за ограничений JSX всегда выдергивает вас из потока, в котором вы решаете реальную бизнес-задачу»
и далее
>>«Из React Vue.js взял компонентный подход»
выглядит немного противоречево
Опять таки, я всегда считал что правильно сначала понять что ты хочешь написать, а затем писать, но видимо авторы любители рисковать :) Ну и если надо переписывать приложение — значит много нового кода, но потом придет этап поддержки проекта и тут чистые функции и компонетный подход значительно проще поддерживать (при условии здравого смысла при разбиении на компоненты)
В общем надеялся прочитать какие-то адекватные аргументы, но тут снова «JSX не поддерживает if»
выглядит немного противоречево
автор ясно и три раза повторил, что на его взгляд компоненты это важно, а компоненты на каждый чих — не очень.
Кроме того, автор жалуется на прерывание «потока» при написании JSX, но при переключении в другой файл для написания шаблона на другом новом языке «поток» почему-то не нарушает
Мне всегда так нравится эта подмена понятий!.. JSX, значит, не новый язык, а новые атрибуты в HTML — это новый язык.
Рад что вам так нравится! Только вот asci не подменял понятия, "другом новом языке" подразумевает что JSX это новый язык
+1
Если речь идет о задаче верстки — то так и есть. В этом самом другом файле код пишется подряд и до обеда, в то время как в JSX надо заводить новый компонент каждый раз когда нужен условный оператор.
К сожалению, не затронут вопрос поддержи редакторами. Тот же react в моем любимом webstorm прекрасно поддерживается. И это не просто подсветка синтаксиса — например webstorm раскуривает propTypes компонентов и делает автоподстановку, что очень удобно и предотвращает опечатки.
А вот вебштромовский плагин для vue есть, но обновлялся месяцев 9 назад. Умеет ли он vue2?
Автор, вы в чем код пишете?)
А вот вебштромовский плагин для vue есть, но обновлялся месяцев 9 назад. Умеет ли он vue2?
Автор, вы в чем код пишете?)
Вызывает некоторые опасения манера автора Vue лихо закрывать многие issues с формулировками типа «это не проблема Vue, это проблема браузера» или «это проблема сторонней библиотеки».
По поводу реальной среды для разработки — ставим через vue-cli стартовый набор с webpack на борту, и вуаля — 300+ метров в node_modules. Для чистой сборки проекта «с нуля» на CI кэш пакетов просто жизненно необходим.
Уровень интеграции Vue со средами Jetbrains удручает. Элементарная подсветка работает крайне нестабильно, чего уж про автодополнения умные заикаться.
Но для one-man framework штука впечатляющая. Иногда есть ощущение, что Эван вообще не спит никогда (да, общается он жестковато, согласен). Такое еще наблюдение — да, волна хайпа началась. Что на хабре, что в англоязычных источниках. Коллега сегодня поворчала — «о, очередной восторг по поводу, что бы уже полезное написали лучше».
Уровень интеграции Vue со средами Jetbrains удручает. Элементарная подсветка работает крайне нестабильно, чего уж про автодополнения умные заикаться.
Но для one-man framework штука впечатляющая. Иногда есть ощущение, что Эван вообще не спит никогда (да, общается он жестковато, согласен). Такое еще наблюдение — да, волна хайпа началась. Что на хабре, что в англоязычных источниках. Коллега сегодня поворчала — «о, очередной восторг по поводу, что бы уже полезное написали лучше».
Стоит также отметить, что view.js позволяет писать гораздо более отзывчивые приложения чем React.
впечатляет, спасибо за ссылку!
Вот более серьезный бенч: да, последняя версия Vue по-шустрее в целом, но реакт не так сильно отстает, как в тесте по вашей ссылке. Мнение автора vuejs на эту тему:
То бишь: с асинхронным рендером на одном синтетическом todo-mvc тесте результаты не дают представления о реальной производительности.
Due to internal implementation differences, frameworks that uses async rendering (e.g. Vue, Om, Mercury) gains the advantage by skipping part of the calculations that happened in the same event loop. The real world user experience doesn’t demonstrate such dramatic difference.
То бишь: с асинхронным рендером на одном синтетическом todo-mvc тесте результаты не дают представления о реальной производительности.
«Более серьёзный бенчмарк» — синтетический, то есть показывает сферическую производительность в вакууме, а ToDoMVC пусть и простое, но реальное приложение, не заточенное под бенчмарки, — тут эмулируются действия пользователя: каждое добавление и удаление задачи — это отдельное асинхронно запускаемое событие.
А где можно посмотреть код ваших фантастических тестов, в которых vanillajs оказывается в 2 раза медленнее angular 2 и в 5 раз медленнее сами знаете чего?
[Бенчмарк](https://github.com/eigenmethod/todomvc/blob/master/benchmark/index.html)
[Реализации](https://github.com/eigenmethod/todomvc/tree/master/examples)
[Интерфейс](https://github.com/eigenmethod/mol/tree/master/app/bench)
В этом нет ничего удивительного, сделать эффективное приложение на чистом яваскрипте крайне сложно. Поэтому ванилла выигрывает только в синтетических бенчмарках, где логика работы проста до безобразия. В реальном же приложении добиться максимальной эффективности без комбинаторного взрыва копипасты можно лишь применяя определённые архитектурные паттерны, реализуя которые вы фактически получаете фреймворк.
Ну, сами виноваты, что ссылки не работают :-)
[Реализации](https://github.com/eigenmethod/todomvc/tree/master/examples)
[Интерфейс](https://github.com/eigenmethod/mol/tree/master/app/bench)
В этом нет ничего удивительного, сделать эффективное приложение на чистом яваскрипте крайне сложно. Поэтому ванилла выигрывает только в синтетических бенчмарках, где логика работы проста до безобразия. В реальном же приложении добиться максимальной эффективности без комбинаторного взрыва копипасты можно лишь применяя определённые архитектурные паттерны, реализуя которые вы фактически получаете фреймворк.
Ну, сами виноваты, что ссылки не работают :-)
В этом нет ничего удивительного, сделать эффективное приложение на чистом яваскрипте крайне сложно.
Сложно\не сложно — вопрос не в этом. Как может быть фреймворк, написанный на JS, который решает широкий круг задач, быстрее чем код, написанный на JS, который решает одну конкретную задачу. Это просто чушь. В худшем случае можно замерить десяток фреймворков, выбрать лучший и вырезать из него необходимый код, удалив все лишнее. Во всех тестах ванильный JS нужно принимать за точку отсчета… быстрее него фреймворк быть не может (максимум одинаково). Ознакомьтесь со статьей, на которую есть ссылка из бенчмарка, который я приводил выше: http://www.stefankrause.net/wp/?p=316. Автор там пишет такую вещь:
Inferno is crazy fast. It’s only 7% slower and I had to add some tricks for vanillajs to match inferno.
Архитектурные решения не нужны в приложении для бенчмарка: оно может быть нечитаемо, скорей всего его не возможно поддерживать и так далее, но оно должно быть максимально оптимизировано. И фреймворка там никак не выйдет.
Ну и еще один аргумент в пользу нерепрезентативности приведенного вами теста: если добавить TypeScript к реакту — это волшебным образом ускорит его в 3 раза (приблизительно)…
Приведённый мной бенчмарк сравнивает не абстрактные фреймворки, а реализации конкретных приложений, выполненных на разных фреймворках. Именно читаемых, поддерживаемых и так далее приложений. Написанных именно так, как среднестатистический разработчик написал бы их для реального проекта. Этот бенчмарк отвечает на простой вопрос: «насколько отзывчивым у меня получится приложение, если я построю его с использованием такого-то инструмента?». Именно это важно для конечного пользователя, а не эфемерное «какой фреймворк покажет больше попугаев?» и сомнительное «насколько большой скорости можно достичь, если над оптимизацией кода изрядно поработает крутой спец?».
Почему typescript+react оказался раза в полтора раза (у меня) быстрее javascript+react я не знаю, но реализации там довольно существенно отличаются. Кода в варианте на typescript (оттранслированного в js) получилось в полтора же раза больше. А кода на том же vue — в 2 раза меньше.
Если вы считаете, что какая-то из реализаций выполнена неправильно — можете поправить или хотя бы указать что именно сделано не по канонам соответствующего фреймворка.
Почему typescript+react оказался раза в полтора раза (у меня) быстрее javascript+react я не знаю, но реализации там довольно существенно отличаются. Кода в варианте на typescript (оттранслированного в js) получилось в полтора же раза больше. А кода на том же vue — в 2 раза меньше.
Если вы считаете, что какая-то из реализаций выполнена неправильно — можете поправить или хотя бы указать что именно сделано не по канонам соответствующего фреймворка.
Мтранно что ссылка на SO вы дали на довольно неудачный ответ. В большинстве ситуаций достаточно тернарных операций.
" И я точно знаю, что если бы я писал отдельную функцию для каждого поля формы, как в React, я бы, конечно, не прыгал от счастья. " redux-form отлично справляется с сложной логикой форм. В нашем проекте как раз есть сложные динамические формы, и переписав их на React все испытали очень большое облегчение. Разработка пошла быстрее, багов стало меньше.
" И я точно знаю, что если бы я писал отдельную функцию для каждого поля формы, как в React, я бы, конечно, не прыгал от счастья. " redux-form отлично справляется с сложной логикой форм. В нашем проекте как раз есть сложные динамические формы, и переписав их на React все испытали очень большое облегчение. Разработка пошла быстрее, багов стало меньше.
Добавлю свои 5 копеек против vuejs. Это просто мое мнение, как человека потратившего ~2 месяца на работу с фреймворком.
tldr Мне не нравится как оно выглядит под капотом (по состоянию когда я с этим работал (лето 2016)), мне не понравилось общение с автором.
Немного про плюсы. Конечно, vue хорош: структура(vue-component, способ импорта компонентов и многое другое), производительность, документация, поддержка sublime, свой плагин в chrome (удобно смотреть состояние), template проекта есть замечательный (см https://github.com/vuejs-templates я использовал webpack). В принципе для среднего разработчика предусмотрено многое. Я бы остался с vue, если бы не некоторые мелочи.
Ключевой причиной почему я ушёл с vuejs стала плохая поддержка hot reload + canvas/proxy textarea (пропадал фокус после hot reload'а).
Обсуждение с автором:
https://github.com/vuejs/vue/pull/3227
https://github.com/vuejs/vue-loader/issues/275
Может, я плохо объясняю, но автор вообще не понял в чем проблема его модели hot reload.
Я сделал простой hook на hotreload. 1 строчка, которая не мешает никому, но решает реальную бизнес-проблему. После всего срача с автором фреймворка я принял решение, что не хочу поддерживать свою ветку vuejs (пусть даже с одним патчем в 1 строку, которую так просто добавить), потому что потом автор поменяет реализацию и оно все-равно сломается, уже была практика с другими проектами.
Про vue-component. ( https://github.com/vuejs/vue-loader/pull/198/files#diff-3fab227e34d65fe9bb2d6ea53eec41cf Прим. Это уже поправили. Но тогда это была веская причина) Реализация мягко говоря мне не нравится, но работает и не трогай. Вместо честного парсинга XML как в mxml (привет adobe Flex) через CDATA, автор… просто применяет ко всему, что ему не нужно комментарии.
Еще веселая переписка по поводу поддержки вложенности компонентов A > B > A
https://github.com/vuejs/vue-loader/issues/292
«Отличный» ответ. А главное, не понятно что мне делать, не показано как надо.
Также до сих пор не починили https://github.com/vuejs/vue-syntax-highlight/issues/41 Конечно, это не проблема vue, но добавляет негатива при работе с ним.
P.s. закончилось всё тем, что я перешёл на самописный велосипед для pet проектов и react для остального.
tldr Мне не нравится как оно выглядит под капотом (по состоянию когда я с этим работал (лето 2016)), мне не понравилось общение с автором.
Немного про плюсы. Конечно, vue хорош: структура(vue-component, способ импорта компонентов и многое другое), производительность, документация, поддержка sublime, свой плагин в chrome (удобно смотреть состояние), template проекта есть замечательный (см https://github.com/vuejs-templates я использовал webpack). В принципе для среднего разработчика предусмотрено многое. Я бы остался с vue, если бы не некоторые мелочи.
Ключевой причиной почему я ушёл с vuejs стала плохая поддержка hot reload + canvas/proxy textarea (пропадал фокус после hot reload'а).
Обсуждение с автором:
https://github.com/vuejs/vue/pull/3227
https://github.com/vuejs/vue-loader/issues/275
Может, я плохо объясняю, но автор вообще не понял в чем проблема его модели hot reload.
Я сделал простой hook на hotreload. 1 строчка, которая не мешает никому, но решает реальную бизнес-проблему. После всего срача с автором фреймворка я принял решение, что не хочу поддерживать свою ветку vuejs (пусть даже с одним патчем в 1 строку, которую так просто добавить), потому что потом автор поменяет реализацию и оно все-равно сломается, уже была практика с другими проектами.
Про vue-component. ( https://github.com/vuejs/vue-loader/pull/198/files#diff-3fab227e34d65fe9bb2d6ea53eec41cf Прим. Это уже поправили. Но тогда это была веская причина) Реализация мягко говоря мне не нравится, но работает и не трогай. Вместо честного парсинга XML как в mxml (привет adobe Flex) через CDATA, автор… просто применяет ко всему, что ему не нужно комментарии.
Еще веселая переписка по поводу поддержки вложенности компонентов A > B > A
https://github.com/vuejs/vue-loader/issues/292
«Отличный» ответ. А главное, не понятно что мне делать, не показано как надо.
Также до сих пор не починили https://github.com/vuejs/vue-syntax-highlight/issues/41 Конечно, это не проблема vue, но добавляет негатива при работе с ним.
P.s. закончилось всё тем, что я перешёл на самописный велосипед для pet проектов и react для остального.
По вложенности компонентов — A >B >A — какое-то решение было предложено в том тикете, куда вы ссылались (насчет поздней инициализации второго компонента).
Hotreload глючный в принципе (нас постоянно достает глюк с subroutes), но если выбирать на тот момент, то были (и есть в vue 1) баги куда более существенные — так как влияют на нормальное функционирование фреймворка. Как вам отображение полностью пустой страницы, если router-view отсутствует в дереве? (пришлось приложение существенно перекраивать).
Предложение ваше по hot reload хорошее, но cons вы тоже очень грамотно обрисовали.
И как там, на реакте — всё прямо гладко?
Hotreload глючный в принципе (нас постоянно достает глюк с subroutes), но если выбирать на тот момент, то были (и есть в vue 1) баги куда более существенные — так как влияют на нормальное функционирование фреймворка. Как вам отображение полностью пустой страницы, если router-view отсутствует в дереве? (пришлось приложение существенно перекраивать).
Предложение ваше по hot reload хорошее, но cons вы тоже очень грамотно обрисовали.
И как там, на реакте — всё прямо гладко?
И по поводу хука — мало сделать код, надо его еще аргументировать и документировать надлежаще.
Если глючная горячая перезагрузка **стейтфул компонент** является самой большой проблемой фреймворка, то это должно быть идеальный фреймворк. :-)
Спасибо, вы вернули мой 2009-й. Как вспомню *_multistep_form, так вздрогну.
Как же мне повезло спрыгнуть на RoR тогда.
Думал Drupal уже тихо скончался под завалами хуков и странных ajax-решений.
Как же мне повезло спрыгнуть на RoR тогда.
Думал Drupal уже тихо скончался под завалами хуков и странных ajax-решений.
Работа с формами и Redux заставят вас печатать весь день напролетПочему-то всех всегда тянет написать свой велосипед, в 99% случаев можно подобрать подходящий под конкретные задачи пакет.
По поводу форм, для себя выбрал redux-form. Он берет на себя связывание формы со стейтом, имеет валидацию и прочие плюшки из коробки
Потому, что часто это работает так:
- У меня есть задача "А", и мне не нужно писать для нее свой велосипед, ведь есть замечательный BicycleA.js!
- У меня есть задача "В", а для нее прекрасно подходит BicycleB.js, нет никакого смысла писать свое решение!
- У меня есть задача "С", в ней мне нужно подружить "А" с "B", и готовых решений пока нет, напишу свое… Черт, просто так их подружить не получается, придется переписать "А"… А теперь и "В"… Так, пора чистить проект от огромного количества легаси-мусора...
Кто может пояснить, почему в бенчмарке из статьи у реакта создание тасков происходит в 3 раза медленнее, чем у 2 ангуляра. При этом загружается он быстрее.
https://eigenmethod.github.io/mol/app/bench/#bench=%2Ftodomvc%2Fbenchmark%2F#sample=angular2~react~typescript-react
https://www.google.ru/trends/explore?q=vue.js,react%20js,angular.js,redux
подправил вашу ссылочку: линк. Ангуляр все еще лидер в мире фронтенда и куча проектов, к сожалению, все еще начинают писать на этом фреймворке.
У «redux» несколько значений, в отличие от.
И даже в этом есть ошибка — нет такой библиотеки React.JS (React JS), она называется просто React.
https://facebook.github.io/react/
https://github.com/facebook/react
Другое дело построить график по React будет уж больно нерелевантно
https://facebook.github.io/react/
https://github.com/facebook/react
Другое дело построить график по React будет уж больно нерелевантно
Начать проект на Angular2 — не сложнее, чем ng new project_name && cd project_name && ng serve. Никто не заставляет вас использовать типизацию, можно обойтись и без нее, если уж так хочется побыстрее начать писать код. Субъективно: это лучшее в вебе, что я видел.
А с реактом близко знакомы? Просто у меня о нём такое же субъективное мнение. Но вот до Angular руки ещё не дошли.
Близко — нет. Посмотрел скринкастов: очень отпугнул JSX (напомнил PHP-шный говнокод, ну в статье есть про это), не понравилась необходимость использовать отдельные библиотеки для слоев MС. Во втором все из коробки есть.
А мне вот после 4х лет первого ангуляра (в продакшене, еще когда была бета) реакт показался гораздо более приятным. Именно приятным и увлекательным – думаю, из-за того, что основе программирования на с React лежит JS. Не html-шаблоны с директивами, не компоненты, а стандартные конструкции языка — с тем лишь отличием, что они могут возвращать html в качестве результата. Приятно потому что это насыщает работу чистым программированием, а не строительство конструкций в мире фреймворка.
начни с этого
Sign up to leave a comment.
Почему мы выбрали Vue.js (а не React)