Как стать автором
Обновить
Каждый разработчик знаком с ситуацией выбора технологического стека для проекта. Приходится проанализировать множество факторов - от целей проекта и ресурсов до бюджета, соотнести все это с особенностями фреймворков, например, Angular и React, и на основе этого уже подбирать решение. Причем у разных разработчиков оно может быть разным: и каждый будет уверен, что он прав. Мы не будем сравнивать фреймворки, тем более что статей, отзывов и другой информации полно и на Хабре, и на других ресурсах. Да и на профильных конференциях о них постоянно говорят. Сегодня мы предлагаем вам сразиться в поединке умов.
К барьеру
Всего голосов 59: ↑54 и ↓5 +49
Комментарии 80

Комментарии 80

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

Зашел сюда прочитать этот комментарий

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

Точно, лучше кроме jQuery ничего не использовать, ибо хипстота!
(сарказм)

Так Vue и есть jQuery наших дней.
Вы так говорите, как будто это плохо.
НЛО прилетело и опубликовало эту надпись здесь
Уважаемый, вы сопоставили целую архитектурную концепцию (vue) с набором вспомогательных методов (jQuery) к слову уже убитых нативным браузерным API. Нет, vue это скорее angularJS v1.6 наших дней если уж открыто сравнивать с чем-то устаревшим.

Когда хипсторские тренды навязывают неудобный инструмент — это да, плохо. Но когда дают крутой фреймворк, который может также легко использоваться как jQuery, который осваивается за пару вечеров, у которого есть крутой cli, который создаст тебе сборщик в одну команду и несколько нажатий клавиш up/down и eneter. И в тоже время, он имеет такой же функционал как и ReactJS — это хорошо.
Да и я не заметил, чтобы Vue был хипстерскее чем тот же ReactJS, статьями про которого завалин медиум.

ангуляр и реакт — два разных концепта, vue пришел в конце и попытался объединить самые приятные моменты
правда хз, почему он выбрал redux, а не ангуляровские сервисы…
НЛО прилетело и опубликовало эту надпись здесь
этож заново сборку ваять

А не надо новую сборку валять. cli сам создает сборку с typescript/babel/scss/jest/vuex/linter/e2e и.т.д. в зависимости от того, что вы выберите. Вот, посмотрите https://cli.vuejs.org/guide/creating-a-project.html#vue-create

То, что вам генератор выплюнет нужные конфиги – это только полдела. С ними нужно еще разбираться, что там есть и как оно работает.
Скоро ещё и Tensor выкатит свой Wasaby на гитхаб. Будет, что пощупать.
А у вас там ошибочка в вопросе за Angular. В «react-redux» слово React явно лишнее. redux всё же независимая либа, а react-redux другая либа, которая и интергирует redux в react.
И вообще редакс в этих вопросах лишний, далеко не все им пользуются с реактом
Согласен, учитывая, что для мелких проектов хватит RxJS, а для крупных есть свои куда лучшие реализации, да и нормальной стилистике Angular.

"Как отрендерить строку в React компоненте?"


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

Вот кстати да. Ответил то правильно, но в надежде на «визуальность» ответа, а не на фактическое представление строки или span-а.
Ответ неправильный в тесте.

Единственный правильный ответ должен быть такой
render() { return 'Your custom string here' }

Формулировка вопроса допускает разные толкования.

вуй жс даже не берут в расчет, а вопросы по реакту имеют неправильные ответы
Зачем нужен vue когда есть React который подходит для 100% задач.

Зачем нужен React, когда есть Backbone.js, который подходит для 100% задач?

Зачем нужен Backbone.js, когда есть jQuery, который подходит для 100% задач?

Зачем JQuery, если все равно в конце будет Assembler, и я знаю Assembler?
НЛО прилетело и опубликовало эту надпись здесь
Зачем вообще что-то делать, если можно ничего не делать?
зачем вообще всё, если энтропия?
А зачем делать что-то руками, если можно ничего не делать?
Чак Норрис, это вы?
Прилично так странных/некорректных вопросов по React. Больше всего зацепил #27.
Вопрос: Что не так с этим кодом?
1) setState имеет неправильную сигнатуру — с сигнатурой всё в порядке
2) запрещено вызывать несколько setState подряд — всё можно вызывать, это нормально
3) при вызове setState несколько раз подряд порядок выполнения не гарантирован — функциональные setState вызовутся в по порядку (я выбрал этот вариант, помечен неправильным)
4) обновленя будут поставлены в очередь, а затем выполнены в том порядке, в котором они были вызваны — да, всё верно

И вопрос «что тут не так с кодом?». Единственное, что тут не так, это отсутствие prop-types/flow/ts для описания props.value. Все остальные варианты никак не отвечают на поставленный вопрос.


// EDIT

Я не работал с Angular 2+, ответил на 28/30. Но зато работаю с React с бета версии и ответил на 25/30. Много косяковых вопросов…

Да. Много спорных вопросов про React. Ну и вопросы с фотографиями людей, с годами релизов тех или иных библиотек — это немного за гранью… На мой вкус и цвет. Ну вот зачем мне знать из какой страны автор MobX? Ну вот правда, нафига? Или скажем вопрос про то, по какой причине отделили ReactDOM от React. Его отделили уже после того, как я пришёл в React. Зачем эта вся история? :)

В Ангуляр тоже ответы так себе местами. Например


1) "какую библиотеку библиотеку включает в себя ангуляр 6 по-умолчанию?" Подумал с заковыркой вопрос, ответил ни какую, но там rxjs. Так насколько я понимаю ничто не мешает не добавлять ее в package.json.


Просто добавь jquery, забудь про Http service. И фигач без rxjs. Или это имеется ввиду anuglar-cli генерированный "пустой" проект?


2) Что обеспечивает ngModel… ответ я правильный выбрал two-way binding, но он не верен имхо. Двойной байндинг обеспечивает syntax sugar, а ngModel только one-way binding (reading), ngModelChange это функция (эмиттер) для приема изменений в обратном направлении (writer). По сути ангуляром можно смело пользоваться как реактом, если подключить еще redux или ngrx.


3) Главный разрабочик вообще не по теме вопрос (это уже какая-то история философии). Я только Савкина знаю по его блогу, и Мишко только звякнуло (возможно неправильно) как разработчик Meteor.js который как раз ругал ngrx в пользу redux.


В реакт из теста узнал что Редукс русский разработчик сделал =)

НЛО прилетело и опубликовало эту надпись здесь
Это показывает, что Вы следите за open-source, и вообще за новостями в мире React.
НЛО прилетело и опубликовало эту надпись здесь
За новостями я слежу из рассылки, фоточек контрибьюторов по комнате, сорян, не расклеиваю
>Angular или React
Оба говно. Vue рулит.
Вопрос: «имена DOM элементов в React пишутся:». Ответ «lowercase» не подходит. Может, вы все-таки имели ввиду имена React компонентов? Имена DOM элементов в React пишутся в lowercase(div, span, textarea, p etc).
Может, вы все-таки имели ввиду

Они имели ввиду «заплатите бабки и приходите на нашу конфу».
In React, all DOM properties and attributes (including event handlers) should be camelCased

Скорее всего, это имелось ввиду.
Так это про свойства и атрибуты элементов, но никак не про имена.
Меня это тоже сбило с толку.

Не работаю но с тем, ни с другим. Ответил правильно на 16 в Angular и 13 в React. Пойти, что ли, в разработчики ?))

Проходил оба теста.


По React:


  • Считать, что PureComponent обеспечивает лучшее быстродействие, чем Component — неверно.
  • Считать, что в react есть только jsx — неверно. Что забавно, есть два вопроса: в одном это учитывается, в другом нет.
  • Функция, которая соединяет react и redux необязательно называется connect. Даже в том же react-redux есть connectAdvanced. А вообще юзер может написать свою функцию, если есть нужда.

По Angular меньше вопросов с реально неправильными ответами.


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


Уфф, высказался. Уж извините, но низкокачественные тесты это большая подстава.

Считать, что PureComponent обеспечивает лучшее быстродействие, чем Component — неверно.

Обоснуй.

Об этом сказано даже в оффициальных доках: you can use React.PureComponent for a performance boost in some cases.


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


Во-вторых, сама проверка на неизмененность props/state может быть бесполезной в случае, если контейнер этого компонента перерисовывается только тогда, когда перерисовывается этот компонент. Или функция render может быть сама по себе достаточно быстра.


В третьих, вы можете написать свой собственный shouldComponentUpdate, который будет более эффективно отсекать перерисовки.

Они отличаются только наличием shouldComponentUpdate. Стало быть вот вам несколько вариантов:


  • у вас свой shouldComponentUpdate, который из-за особенности бизнес-логики может быстрее решить — нужно ли ререндерить компонент или нет, нежели это делает shallowComparison
  • у вас стандартный pure-shouldComponentUpdate в 95+% случаев выдаёт true. Или даже в 100%. Лишняя проверка производительность не повысит
  • у вас необычный компонент, который в render возвращает, скажем, 1 простой <span/>text</span>, но на входе имеет множество props. В этом случае может статься так, что shallowComparison будет по времени сопоставима с render method + reconcile + dom. Хотя тут конечно пример сильно надуманный
  • у вас не immutable-props-ы, и вы в принципе не можете использовать shouldComponent без багов

Ну и бонусом — вместо pureComponent или Component вы можете вообще inline сделать. Т.е. Вместо того чтобы писать <MyComp .../> вы можете написать {MyComp(props)}. В рамках экономии на спичках у народа получалось на этом что-то сэкономить, т.к. полностью игнорируется react life-cycle.

Считать, что PureComponent обеспечивает лучшее быстродействие, чем Component — неверно.

Позволяет отрезать ветку рендеринга, все очень даже верно.
А тест действительно шикарен. Кто на фотографии, Что было в 15ом году, почему чего то там в отдельную библиотеку вынесли. Отвечает Александр Друзь…
Позволяет [периодически] отрезать [лишнюю] ветку рендеринга, [за счёт дополнительных проверок, при условии, что вы оперируете immutable-данными].

Я поправил ;) На самом деле сий вопрос куда хитрее, чем в тесте указано. It depends.

Про immutable это не «при условии», сравнение чистого компонента с обычным как раз подразумевает сравнение немутабельной модели с мутабельной. Мутабельная модель просто не будет работать с чистым компонентом.
И shallow-comparision, хоть и дополнительная, но дешевая проверка. И дело не в отрезании рендеринга конечного компонента, который спан рисует. Отрезается половина рендеринга страницы, так как не изменился объект состояния, соответствующий этой половине. Дело до shouldComponentUpdate конечных компонентов даже не дойдет. Я бы даже сказал наоборот, на конечных компонентах, где один спан, не имеет смысла использовать чистый компонент, да и реакт-компонент вообще, надо определять компоненты этого уровня как функции.

И даже если начать заморачиваться с тем, чтобы руками начать писать shouldComponentUpdate с мутабельной моделью — это реально делать для конечных компонентов, и нереально делать до компонентов верхнего уровня, потому что на верхнем уровне надо «знать» реализацию всего что внутри. И каждый раз когда внутри что то меняется, лезть наверх и обновлять эту сложную перенагруженную функцию shouldComponentUpdate. А с immutable моделью это «бесплатно».

Я в курсе всех этих вещей. И nsinreal, я полагаю, тоже в курсе. Собственно о том и речь, что pureComputed не серебрянная пуля, и это, как говорится, it depends. Надо рассматривать конкретный случай, чтобы судить о производительности. А вопрос поставлен абстрактно. Оттого к нему и претензии.

А вопрос поставлен абстрактно.

Возможно так специально сделали, чтобы вызвать «ажиотаж и бурления» в комментариях, и подсветить тех кто разбирается в теме.
Вот есть же еще нормальные люди, которые стек протестируют напрямую, а не вопросом «как давно вы чесали ваш стек?».

Пожалуй самая упоротая статья, что я когда либо видел, от этих тестов вытекли мои глаза. З. Ы. После Ализара конечно

Angular: 18 из 30. При том, что отца мог бы нагуглить, но выбрал вариант «Это я».
По Angular только читал книгу почти год назад, ни одного проекта на нём не сделал.
Тесты ничего не показывают, любой тест это просто игра.
Тесты ничего не показывают, любой тест это просто игра.

В вашем случае ведь что-то показало.
«Браво, + 1 балл в копилку Angular. Вы настоящий лидер своей команды! Ваши навыки позволяют вам с готовностью принимать любой вызов. Команда по праву может вами гордиться, хантеры из Google, должно быть, уже ищут, как с вами связаться, чтобы предложить топовую позицию.»
Камооон. «Лидер команды», «любой вызов». Вопросы, на которые ответит любой джун.
Согласен, ибо я джун, за тем же React я провел 2 недели, даже документацию толком не изучил, правильно ответил на 21 вопрос из 30. Буду теперь «ждать» свои Middle React Developer офферы (сарказм).
Меня одного смущает слово «компонентат» в первом вопросе React?
Судя по кратинке к статье, Ангуляр победил, а React левша =)
Спасибо за опрос. React Error Boundaries изучил :)
НЛО прилетело и опубликовало эту надпись здесь
Прикольные тесты. Не хватало только правильные ответы увидеть. 21 балл по ангуляру и реакту :)
Делая выбор между React vs Angular правильный ответ — Vanilla!

Ребятам стоит самим подучить React как мне кажется...

НЛО прилетело и опубликовало эту надпись здесь
хочется норм ООП
задумался над переходом Angular

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

Возьмите MobX и пишите себе ООП в Реакте
А на стороне Elm выступить не получится?
Один в поле не воин
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре , чтобы оставить комментарий