Comments 64
Я не могу показать код по понятным причинам … код получился очень читаемым … и я точно знаю …На Хабре таки пришлось бы показывать.
Интересное заявление в конце статьи, но реакт это не фреймворк(React is a declarative, efficient, and flexible JavaScript library for building user interfaces.).
Хотя сам по себе React — не фреймворк, его использование автоматически означает отказ от других фреймворков, потому что он с ними несовместим.
Поэтому рассмотрение React как альтернативы фреймворкам, а фреймворков как альтернативы React — оправдано.
Да, но при этом потеряется вся разметка Ангуляра, благодаря которой он и выигрывал. Это средство для оптимизации критических участков, но никак не основное решение для проекта.
Вот с бэкбоном React совместим, да. Потому что они обе библиотеки и решают разные задачи.
Вопрос конечно в осмысленности этого совмещения.
Я согласен с тем, что в ангуляре это несколько странно(хотя я видел проекты где так было сделано и все замечательно работало), но вот допустим в метеоре или эмбере(особенно в прошлой версии эмбера, где ихний слой отображения был так себе) — вплоне неплохо он смотрится.
Angular2 отличный фреймворк, в котором продумано почти все. По крайней мере, сравнивая с конкурентами. Typescript — вы можете его использовать в режиме как ES6 без типизации, любому JS девелоперу хватит 1-2 дней чтобы начать писать.
P.S.: я это пишу, чтобы у читающих была альтернатвная точка зрения, так как в статье один из лучших выборов на сегодня (Angular2) описан вскольз
В ангуляре постоянно ощущение что для получения ровно того же результата, что и в реакт+редукс. приходится проделать куда больше манипуляций.
Относительно скорости — пока не тестировал ангуляр в этом плане, но реакт без проблем справляется с десятками тысяч записей, включая их регулярное обновление.
Огромное преимущество ангуляра — это наличие там определенной стандартизации в подходах, т.е. человек умеющий работать с ангуляром с большой вероятностью без особой сложности сможет работать с другим проектом на ангуляре.Тогда как реакт не подразумевает вообще ничего и может идти с любым произвольным набором библиотек, что может сделать вхождение в проект затруднительным.
(ангуляр имею в виду конечно второй)
redux-form?
авторы, видимо, любители подхода «х*як-х*як и в продакшен»
>>«подход разбивания компонентов на супертупые (dumb) компоненты из-за ограничений JSX всегда выдергивает вас из потока, в котором вы решаете реальную бизнес-задачу»
и далее
>>«Из React Vue.js взял компонентный подход»
выглядит немного противоречево
Опять таки, я всегда считал что правильно сначала понять что ты хочешь написать, а затем писать, но видимо авторы любители рисковать :) Ну и если надо переписывать приложение — значит много нового кода, но потом придет этап поддержки проекта и тут чистые функции и компонетный подход значительно проще поддерживать (при условии здравого смысла при разбиении на компоненты)
В общем надеялся прочитать какие-то адекватные аргументы, но тут снова «JSX не поддерживает if»
выглядит немного противоречево
автор ясно и три раза повторил, что на его взгляд компоненты это важно, а компоненты на каждый чих — не очень.
Мне всегда так нравится эта подмена понятий!.. JSX, значит, не новый язык, а новые атрибуты в HTML — это новый язык.
Если речь идет о задаче верстки — то так и есть. В этом самом другом файле код пишется подряд и до обеда, в то время как в JSX надо заводить новый компонент каждый раз когда нужен условный оператор.
А вот вебштромовский плагин для vue есть, но обновлялся месяцев 9 назад. Умеет ли он vue2?
Автор, вы в чем код пишете?)
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 тесте результаты не дают представления о реальной производительности.
[Реализации](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 раза меньше.
Если вы считаете, что какая-то из реализаций выполнена неправильно — можете поправить или хотя бы указать что именно сделано не по канонам соответствующего фреймворка.
" И я точно знаю, что если бы я писал отдельную функцию для каждого поля формы, как в React, я бы, конечно, не прыгал от счастья. " redux-form отлично справляется с сложной логикой форм. В нашем проекте как раз есть сложные динамические формы, и переписав их на 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 для остального.
Как же мне повезло спрыгнуть на 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://facebook.github.io/react/
https://github.com/facebook/react
Другое дело построить график по React будет уж больно нерелевантно
Начать проект на Angular2 — не сложнее, чем ng new project_name && cd project_name && ng serve
. Никто не заставляет вас использовать типизацию, можно обойтись и без нее, если уж так хочется побыстрее начать писать код. Субъективно: это лучшее в вебе, что я видел.
Близко — нет. Посмотрел скринкастов: очень отпугнул JSX (напомнил PHP-шный говнокод, ну в статье есть про это), не понравилась необходимость использовать отдельные библиотеки для слоев MС. Во втором все из коробки есть.
Почему мы выбрали Vue.js (а не React)