Как говорил М.Т. Калашников: «Просто» сделать в 1000 раз сложнее, чем «сложно». Веб-индустрии понадобилось более половины десятилетия, чтобы прийти от фреймворков-монстров к простой и элегантной конструкции. В IT простота это не только сэкономленные часы работы, а ещё и прозрачная архитектура, выливающаяся в понятный код, меньшее число багов, более быстрое внесение изменений и много других приятных вещей.

В этой статье я проведу сравнение Vue.js с двумя наиболее популярными на данный момент фреймворками: Angular и React. Vue.js намного моложе, поэтому разговор будет прежде всего о нём, об Angular и React грамотные разработчики и так знают. Я бы не начинал этот разговор, если бы Vue не предлагал чего-то действительно стоящего. К счастью это так, и я утверждаю, что в большинстве случаев Vue.js может серьёзно снизить сложность ваших программ, сделать код более лаконичным и выразительным, а отладку — короче и проще. Подробности под катом. Поехали!

Если совсем кратко, то Vue.js — невероятно ненавязчивый фреймворк. Если Angular и React заставляют вас установить целый зоопарк зависимостей, то Vue в минимальной конфигурации не просит от вас абсолютно ничего, кроме собственного js-файла. За это он даёт custom controls, data binding, кастомные директивы и, фактически, все востребованные фишки основных фреймворков. Пример ненавязчивости:

Как выглядит простейшая программа на Vue


Достаточно просто подключить библиотеку, создать контейнер и вызвать конструктор, всё как в старом добром Angular 1, только без его тормозов:

<div id="app">{{ message }}</div>

<script src="https://unpkg.com/vue"></script>
<script>
  new Vue({
    el: '#app',
    data: {
      message: 'Hello Vue!'
    }
  })
</script>

Это действительно весь код, который вам нужен, это не шутка. Вы можете прямо сейчас скопировать его в редактор, сохранить как something.html и он будет работать. Без плясок с бубном, dependency hell и прочих артефактов современности. Не буду рассказывать как то же самое делается в React или Angular 2+. Про то, как вытащить JSX из React или как писать без TypeScript на Angular 2+ можно написать целую статью.

Почему бы не оставить всё как есть
Чем плох TypeScript? Хотя бы тем, что я его не заказывал. В 2005-м году мы боролись за каждый килобайт веса страницы, а сейчас сайты весят по 15 мегабайт и, как будто бы, так и нужно, но это неуважение к пользователю. Я не говорю, что в этом виноват TypeScript, или JSX, или 100500 других побочных технологий, но я хочу сам выбирать, что использовать, а что нет. И чтобы не пришлось платить за этот выбор часами на stackoverflow.

Что касается конкатенации и минификации кода, то для Vue доступно много решений с готовыми сборщиками на том же yeomen (например github.com/birdgg/generator-vuejs), так же как и для React или Angular. Разница в том, что у вас есть право выбора, использовать их, не использовать, или самому создать сборщик под особенности конкретного проекта.

Custom Controls


Распространённый сценарий развития большинства веб-приложений — увеличение плотности функционала:

  • у вас была обычная кнопка, а стала кнопка со индикатором состояния запроса
  • была обычная таблица, а стала таблица с сортировкой и фильтрами
  • было обычное меню, а стало меню с многократной вложенностью

Если такие компоненты встречаются в приложении один раз — ничего страшного, но чаще бывает, что они раскиданы по разным страницам и в большом количестве. Без custom control такие задачи решаются через боль, мучения и большие затраты времени, с custom controls это делается быстрее в несколько раз. Если вы не сталкивались с такой проблемой — значит у вас не было более-менее серьёзных проектов. Custom controls — это абсолютно must have в современном frontend-программировании. В Angular 1 custom controls отсутствовали (если не считать директивы, которые изначально предназначались совсем для других вещей). В Angular 2+ и React они есть, но достаются довольно дорого. Синтаксис Vue.js очень похож на Angular 2+, но без его ограничений. Немного модифицируем код, представленный выше:

<div id="app">
  <ol>
    <todo-item v-for="item in list" :todo="item"></todo-item>
  </ol>
</div>

<script src="https://unpkg.com/vue"></script>
<script>
  Vue.component('todo-item', {
    props: ['todo'],
    template: '<li>{{ todo }}</li>'
  });
  
  new Vue({
    el: '#app',
    data: {
      list: ['first item', 'second item']
    }
  });
</script>

Получилось чуть подлиннее, но у нас здесь custom controls. Custom controls в 20 строчках кода, Карл! При этом сам компонент занял всего 4 строчки. Что это значит на практике: что вы можете делить свой код на компоненты настолько мелко, насколько вам хочется, с минимальными издержками. Если в React создание отдельного компонента — целая история, с завязкой, кульминацией и развязкой, то в Vue это просто несколько секунд. И дело не в этих секундах, а в том, что с большим количеством компонентов у вас будут слабее зависимости и меньше багов.

Это синтетический пример компонента, но в реальных Vue.js раскрывает себя ещё лучше. Мы можем, например:

  • вынести весь код компонента в отдельный *.vue файл, включая html, css и javascript
  • использовать css-препроцессоры прямо в коде файле компонента, просто указав lang=«scss» или другое
  • использовать любые глобальные объекты или получать объекты через import (в React, кажется, на это есть ограничения)
  • использовать компоненты только внутри других определённых компонентов, без объявления в глобальной области видимости. Использовать компонент под другим именем, без изменения самого компонента (удобно в случае коллизии имён сторонних компонентов)

и многое другое. Для большинства этих функций нужно подключать сборщик (в документации описан webpack), однако вам дают выбор, использовать Vue на 10%, 50% или на все 100%. Плюс, на мой взгляд, они выбрали самый стабильный и прозрачный сборщик из существующих, но вы можете поменять и его. Вообще Vue поражает своей модульностью и слабосвязанностью, архитектура просто очень хорошо продуманна, что выливается в огромное удовольствие при работе с любой его составляющей. Например:

Создание своих плагинов


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

Как это делается в Vue.js
  Vue.prototype.$myMethod = function (methodOptions) {
    // something logic ...
  }

Vue.prototype, Карл! Вам даже не нужно знать документацию, вы её и так знаете большую её часть на уровне подкорки. Больше никаких странных конфигов, магических свойств, которые нужно указать, чтобы всё заработало. Просто Vue.prototype и имя вашего метода, почему все фреймворки не используют это? Если хотите устанавливать плагин через Vue.use(MyPlugin), то нужно определить метод MyPlugin.install, но это, как и многое в Vue, по вашему желанию.

Общая обстановка


У меня есть большие претензии к команде Angular. Даже не побоюсь сказать, что они фактически убили Angular, создав два совершенно разных продукта и назвав их одним именем. Даже у Vue больше общего с Angular и 1 и 2, чем у этих версий между собой. Возникла огромная путаница в документации, которая ещё не скоро прекратится. Но дело даже не в этом, как гласит один из канонических принципов создания хорошего ПО: делайте программы открытыми для дополнения, и закрытыми для изменения. Подобные радикальные изменения API Angular говорят о том, что продукт изначально был создан проблемным, идеальные программы не нуждаются в изменениях (например /bin/true в linux не переписывалась с 1984 года :)). Конечно Angular это не /bin/true, но реформы — всегда признак проблем.

В чём же причина? Я думаю в том, что как React — это проект для внутренних нужд Facebook, так и Angular 2+ — это проект для внутренних нужд Google. Конкретной компании не требуется поддерживать универсальность. Зачем поддерживать ES6, если в самой компании пишут на TypeScript? Зачем отделять React от зависимостей, если внутри компании он без зависимостей не используется? Конечно пользователи просят, и иногда им идут на встречу, чтобы они совсем не отвернулись, но всё же главная задача этих проектов — не наше с вами счастье, а облегчение найма в эти компании, когда приходит новичёк и уже знает основной стек технологий. Но стек конкретной компании, пусть даже очень крутой, не может являться стандартом для всей отрасли. Отсюда все проблемы с Angular и React. Vue, насколько мне известно, напротив, создавался именно для сообщества, поэтому получился модульным, универсальным, легко адаптируемым под нужные задачи.
Ваше отношение к Vue.js

Проголосовало 1173 человека. Воздержалось 317 человек.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Поделиться с друзьями
-->

Комментарии (396)


  1. rumkin
    28.07.2017 17:47
    +16

    Нельзя сравнивать библиотеки хеловордами и туду листами. Соглашусь, что React и Angular требуют много зависимостей и тяжеловесны. Но в больших приложениях (даже начинающихся с легковесных библиотек), которые состоят из множества маленьких модулей рано или поздно наступает такой момент, когда вес страницы начинает зашкаливать из-за того, что каждая библиотека тянет за собой множество дублирующих друг друга вспомогательных библиотек (как пример одновременное подключение lodash и underscore). Это неприятно, но на данный момент неизбежно. Так, что давайте сравнивать по срезу проектов и по нескольким показателям.


    Для меня главным ресурсом является время на разработку, все остальное я могу оптимизировать.


    1. rboots
      28.07.2017 17:53
      -1

      Полностью согласен, но в рамках статьи показать что-то сложнее hello world и todo затруднительно. На Vue я пару месяцев назад начал первый production-проект, и пока ощущения лучше, чем от Angular и React, которые тоже использовал в production. Вот и решил поделиться.


      1. rumkin
        28.07.2017 19:15
        +9

        в рамках статьи показать что-то сложнее hello world и todo затруднительно

        С чего вы взяли?


        На Vue я пару месяцев назад начал первый production-проект

        Так дело не пойдет. Переименуйте тогда статью в "Почему я считаю vue лучшим фреймворком 2017" ну или как-то так.


        1. rboots
          28.07.2017 19:36
          -3

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


          1. antonksa
            29.07.2017 03:57
            +2

            Вам говорят о том, что вы поймали хайп.
            Мы за вас конечно рады, но вам предложили написать, что это ВАШЕ СУГУБО ЛИЧНОЕ МНЕНИЕ, а не безаппеляционное заявление, как сейчас выглядит заголовок.


            1. rboots
              29.07.2017 10:32

              Все оценочные утверждения это лишь мнения. Или вы думаете, что где то на планете есть великий мудрец, объявляющий «А на этот год лучший фреймворк такой-то». Естественно это мнение, странно, что можно решить иначе. К этому мнению я привожу список агрументов, так сказать, доказательств теоремы. Ваше право указать на неверные тезисы или согласиться.


              1. rumkin
                29.07.2017 19:13
                +2

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


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


      1. raveclassic
        28.07.2017 19:18
        +7

        пару месяцев

        Вы что, серьезно?


        Angular и React, которые тоже

        Тоже пару месяцев?


        1. rboots
          28.07.2017 19:34

          С учётом того, что Vue начал набирать реальную популярность только в 2016 и многие до сих пор боятся использовать его в production — абсолютно серьёзно. Сколько вам надо, 5 лет? На Angular наверное наберётся, но Vue в принципе моложе. Плюс документация осваивается за пару вечеров, а косяки которые не всплыли за первые два месяца, вряд ли могут иметь критическое значение, всё серьёзное проявляется очень рано.


          1. staticlab
            28.07.2017 22:04
            +7

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


            1. rboots
              29.07.2017 10:37
              -2

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


              1. staticlab
                29.07.2017 12:10

                Ниже я уже показал, что концепция слотов не так уж и уникальна, если то же самое можно и в Реакте повторить.


                Что касается архитектуры, то это вопрос не множества возможностей фреймворка, а, скорее, их взаимодействия между собой и с бизнес-логикой.


                1. TimTowdy
                  30.07.2017 02:59
                  +1

                  Концепция слотов не придумана Vue. Достоинство Vue как раз в том, что вместо придумывания своих велосипедов они взяли за основу уже существующую спецификацию W3C: http://w3c.github.io/webcomponents/spec/shadow/#shadow-tree-slots


                  1. staticlab
                    30.07.2017 13:44
                    +1

                    А в чём, собственно, достоинство?


        1. ncix
          29.07.2017 12:24
          +5

          Никому не нужен новый инструмент, который нужно осваивать дольше пары недель. Или в котором через два(!) месяца чувствуешь себя новичком. Серьезно.


          1. mariner
            30.07.2017 01:33
            +2

            с Vue вам понадобится два-три дня ;) там банально нет столько функционала, что бы изучать.


      1. TheShock
        28.07.2017 20:55

        но в рамках статьи показать что-то сложнее hello world и todo затруднительно

        Может проблема во фреймворке? Или еще в чем-то?

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


        1. Areso
          29.07.2017 17:09

          Написал игру на чистом JS, причем используя очень старые вещи. Ничего, работает)
          Даже jQuery пока нет в зависимостях.


          1. TheShock
            29.07.2017 17:53
            +1

            Ну и где статья? Мы ведь о статьях говорим, а не о игрушках?
            В рамках статьи о Vue сложно написать что-то сложнее Hello World, но в рамках статьи о других фреймворках и даже без фреймворков пишут вещи, которые значительно сложнее.
            Следовательно может быть проблема во фреймворке, что с ростом сложности читаемость падает слишком быстро и для статьи такой код не подходит.


            1. Areso
              30.07.2017 10:14
              -1

              Вы всерьез хотите увидеть статью об очередной ферме на JS, написанной любителем? Я ведь зарабатываю деньги совсем другими вещами. Причем написанной без новых, модных фич JS? К тому же код демонстрирует значительное количество непоследовательных решений, которые точно нельзя назвать best practice (к примеру, рендер в Canvas, а поверх просто расположение картинки со своими функциями или анимации, чтобы не мучаться с разделкой анимации и вставкой анимации покадрово в Canvas). Т.е. мне непонятно, чему бы я мог научить других людей такой статьей, а пиарить поделку-на-коленке тоже я смысла особого не вижу.

              Так-то написать можно, был бы положительный выхлоп.


    1. Tynnopet
      28.07.2017 18:17
      +4

      Писал по небольшому компоненту, с большим количеством перерисовок на react и vue. Из-за встроенного observable и computed свойств vue обошел реакт в 3 раза по фпс. Помимо этого кода было на порядок меньше, из-за тех-же computed свойств. Как я ни старался react по lifecycle хукам оптимизировать — vue без оптимизаций был быстрее.


      1. Reon
        28.07.2017 22:06
        +2

        Откуда у вас такая информация, что именно по этим причинам?


        1. RubaXa
          30.07.2017 23:16

          Из DevTools например


        1. Tynnopet
          31.07.2017 11:54
          +1

          Достаточно посмотреть на области перерисовки при одной архитектуре компонента

          React
          image


          1. justboris
            01.08.2017 20:18

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


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


            1. vintage
              01.08.2017 20:25

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


              1. justboris
                01.08.2017 20:26

                А зачем вам переносить элемент в другого родителя?
                Сколько разных интерфейсов ни писал, но этого делать не пришлось.


                1. vintage
                  01.08.2017 20:57

                  Дрегендроп, фуллскрин, да и просто динамический лейаут.


                  1. justboris
                    01.08.2017 20:59
                    +1

                    Пользователь не сможет провести столько драгендроп операций в секунду, чтобы это сказалось на производительности, разве нет?


                    Про фуллскрин и динамический лейаут я не понял пример, расскажите подробнее


                    1. vintage
                      01.08.2017 22:16
                      +1

                      Достаточно перетащить тяжёлую панель из левого дока в правый.


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


                      Смотрели список задач плоским списком, а потом решили сгруппировать их по ответственному.


    1. mariner
      30.07.2017 01:31

      использую с октября прошлого года. скорость разработки высокая, нехватка функционала (например, http клиент), быстро решается интеграцией того же axios через плагин к Vue. в общем, все круто там. не хочется возращаться к ангулару или реакту.

      экосистема развивается — https://github.com/vuejs/awesome-vue
      и да, single file components это просто бомба!


      1. franzose
        31.07.2017 05:59

        http-клиент есть: https://github.com/pagekit/vue-resource


        1. mariner
          31.07.2017 11:16
          +1

          Его больше не рекомендуют использовать (в блоге разрабов вью). Советуют axios.


          1. franzose
            31.07.2017 11:27

            Хм, спасибо, не знал. Надо будет в своём репозитории (https://github.com/franzose/symfony-ddd-wishlist) переделать на axios тогда, чтобы не вводить людей в заблуждение.


          1. s256
            31.07.2017 11:45

            По какой причине? Для простых вещей вроде довольно удобный


            1. Fragster
              31.07.2017 11:52

              По той, что есть axios. Это официальная позиция :)


      1. franzose
        31.07.2017 06:00

        Хотя это тоже отдельный плагин)


  1. j_wayne
    28.07.2017 17:52
    +7

    Vue мне хорошо подошел в проекте, т.к. уже есть фронтенд на jquery, целиком переписывать я не хочу, но с поддержкой уже есть проблемы и для новых фич нужна реактивность.
    Vue я могу применять точечно, для новых фич и постепенно переписывая старые.
    «Чистые» Elm и React/Redux не осилил, слишком много обычных сторонних либ.
    Vue не мешает «срезать углы» и сделать грязный хак, если надо.

    P.S. Также, я вынужденный фулл-стек программист и изучать большие фреймворки нет ресурсов.


    1. rboots
      28.07.2017 18:00

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


    1. friday
      31.07.2017 08:31

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


      1. j_wayne
        31.07.2017 09:36
        +1

        А проблемы с поддержкой уже были и более серьезные — легаси лапшекод на jquery.
        Я пробовал внедрить ограниченно (в рамках новой фичи ) react/redux, потом Elm.
        Концептуально красиво, безусловно. Особенно Elm.
        Но у меня просто нет ресурсов взять и переписать все эти уже используемые календари, чарты, пикеры и прочие сторонние библиотеки на redux/elm.
        В частности, jquery draggable/droppable. На redux я еще худо бедно сделал, вроде даже и в рамках концепции, но выглядело в коде это не ахти.
        На Elm drag/drop я просто не осилил (был глючный пример для старой версии, но как раз вышла новая где этот API прибили). Я думаю, что в принципе это возможно, но лично у меня заняло слишком много времени и непонятно, зачем такие сложности. Done is better than perfect. Это не значит, что к совершенству не надо стремиться. Но иногда компромисс неизбежен.


  1. justboris
    28.07.2017 18:19
    +19

    Если в React создание отдельного компонента — целая история, в завязкой, кульминацией и развязкой

    Если и история, то очень короткая:


    function MyReactComponent() {   // завязка
      return React.createElement('h1', 'Hello from my React component') // кульминация
    } // развязка
    
    ReactDOM.render(React.createElement(MyReactComponent), document.getElementById('app'));


    1. rboots
      28.07.2017 18:30
      -8

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


      1. andy128k
        28.07.2017 18:40
        +8

        Столько же

        function MyReactComponent(props) {
          return React.createElement('h1', props.message || 'Hello, React!');
        }
        
        ReactDOM.render(React.createElement(MyReactComponent, {message: 'Hello, Vue!'}), document.getElementById('app'));
        


        1. rboots
          28.07.2017 19:46
          -16

          Неплохо, но длина строк тоже имеет значение. 221 символ против 98 в пользу Vue. Хотя это не суть, суть в простоте и удобстве.


        1. Alex_ME
          28.07.2017 21:15
          +9

          Почему не JSX?


          function MyReactComponent(props)
          {
              return <h1>{props.message || 'Hello, React!'}</h1>
          }
          
          ReactDOM.render(<MyReactComponent message="Hello, Vue!"/>, document.getElementById('root'));

          Согласитесь, так гораздо нагляднее и компактнее, без всякого синтаксического шума, как выражались некоторые комментаторы.


          1. TheShock
            28.07.2017 22:17
            +5

            Кстати, с es6 импортами вполне можно было сделать довольно изящно на функциях без всяких синтаксических дополнений:

            function MyReactComponent(props)
            {
                return h1{props.message || 'Hello, React!')
            }
            
            ReactDOM.render(MyReactComponent("Hello, Vue!"), document.getElementById('root'));
            


            Или более развернуто:

            import { h1, h2, section, article, div } from "react-elems";
            
            function MyReactComponent(props)
            {
                return [
                    h1{[props.message || 'Hello, React!']),
                    section({ className: "abc" }, [
                        h2("blabla"),
                        article([
                            div({ className: "xyz" }, "foobar")
                        ])
                    ])
                ];
            }
            
            ReactDOM.render(MyReactComponent("Hello, Vue!"), document.getElementById('root'));
            


            В аргументах функции объект — это свойства, а массив или строка — чилдрены.
            Как по мне — вполне соответствует JSX по наглядности и компактности.


            1. Alex_ME
              28.07.2017 22:22
              +2

              Не могу с Вами согласиться. Все-таки JSX — по-сути привычный всем HTML, а этот синтаксис необычен и более многословен (все эти скобки и прочее). Есть ли плюсы у такого подхода? Всегда считал JSX одной из сильных черт реакта.


              1. TheShock
                29.07.2017 03:18
                +1

                На счет многословности не соглашусь: xml в принципе более многословен за счет закрывающего тега и кучи угловых скобок. По сути для крайнего случая это:

                tag({ property: value, [ item1() ] })
                // vs
                <tag property={value}><item /></tag>
                


                Для самого простого:

                tag(value)
                // vs
                <tag>{value}</tag>
                


                И т.к. мы пишем на JS, то всем кто это пишет это настолько же привычный JS, как и HTML.

                Лично мне нравится jsx, я просто описал, что такая альтернатива есть.

                Из плюсов — такой подход не нужно собирать (для браузеров с es6 и nodejs), это нативный JS (слабый плюс, конечно, но все-же). Ну и код слегка короче получается. Либы, которые хотят сделать «так же легко как в реакте, но без jsx» — могут использовать именно этот подход, он не сильно отличается.


              1. sshikov
                29.07.2017 11:14

                Ну исли этот синтаксис и необычен — то только для вас. Его полно везде, и уже давно.


                Да, фактор непривычности всегда существует, но тут вы его явно преувеличиваете. Это просто javascript, если на то пошло.


                Есть ли плюсы у такого подхода?

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


            1. Mox
              29.07.2017 06:35
              -1

              Эта штука хорошо бы сработала с CoffeeScript — получился бы HAML по сути


            1. Fragster
              31.07.2017 11:26

              ну а в vue просто используем pug


        1. vintage
          29.07.2017 08:27

          Добавляем интерактив с пользователем и получаем куда более увлекательный сюжет.


      1. justboris
        28.07.2017 18:40

        Не больше чем в аналогичном todo-list на Vue


        var h = React.createElement;
        
        function TodoItem(props) {
          return h('li', {}, props.text)
        }
        
        function TodoList(props) { 
          return h('ol', {}, props.items.map(function(item) {
            return h(TodoItem, {text: item});
          }));
        }
        
        var items = ['first item', 'second item'];
        
        ReactDOM.render(React.createElement(TodoList, {items: items}), document.getElementById('app'));

        И вот работающий JSFiddle


        1. dom1n1k
          28.07.2017 19:05
          +3

          Гораздо больше, если так можно выразиться, синтаксического шума.


          1. justboris
            28.07.2017 19:20

            Согласен, причесал немножко: https://jsfiddle.net/nwtmq49k/1/ Стало лучше?


            Ну и не стоит забывать о JSX. Если проект намечается большим, то тут уже можно и JSX подключить и писать верстку нормально.


        1. rboots
          28.07.2017 19:25
          -6

          Неплохо, но хитрость с map обернётся слабой выразительностью кода. И в целом javascript получилось не меньше, в изначальном примере его всего 11 строчек javascript, остальное — html, импорт библиотеки, теги script и т.п… Если сравнивать Fiddle, то вот: https://jsfiddle.net/km8jug2f/2/
          В целом соглашусь, что практически равные результаты, но Vue всё же читается и пишется проще.


          1. raveclassic
            28.07.2017 19:28
            +4

            но хитрость с map

            Почему хитрость? Обычное преобразование


            слабой выразительностью кода

            Почему? Разве стандартная языковая конструкция хуже чем кастомный dsl?


            11 строчек javascript, остальное — html, импорт библиотеки, теги script и т.п…

            Какая разница чего сколько, если все — исходники?


          1. justboris
            28.07.2017 19:37
            +6

            Ну вот, видите, не так уж страшно на React писать. А в статье много необоснованного хейта


            Angular и React заставляют вас установить целый зоопарк зависимостей

            плясок с бубном, dependency hell и прочих артефактов современности

            React создание отдельного компонента — целая история, в завязкой, кульминацией и развязкой

            Не надо так.


            1. rboots
              28.07.2017 20:17
              -1

              Официальная документация просит зоопарк устанавливать. Даже самый простой вариант с single html запрашивает babel и делает преобразование из jsx, что увеличивает время отрисовки страницы, по моим замерам, до 1.5 секунды. Кто же знал, что вы познали Дао React и можете написать Hello world лучше, чем основатели React. К вам претензий нет, к ним — есть, в том числе за документацию.


              1. raveclassic
                28.07.2017 20:20

                до 1.5 секунды

                Так вы в рантайме его зачем гоняете?


                1. rboots
                  28.07.2017 22:09
                  -6

                  Это не я, это официальная документация) Упаковка это хорошо, но я хочу иметь выбор. Почти любой фреймворк на чистом JavaScript прекрасно работает и в рантайме, а babel и typescript — нет. При этом преимущества такой надстройки абсолютно не очевидны, а минусы на ладони.


                  1. Alex_ME
                    28.07.2017 22:19
                    +1

                    Чтобы использовать более удобные вещи, которые еще не поддерживаются всеми браузерами (es6, 7, что там еще), совсем не поддерживаются браузерами (typescript, jsx, sass/less).


                    1. rboots
                      29.07.2017 10:40
                      -4

                      Они ещё остались? На мой взгляд async await была последней, если только вы программируете на для гос учреждений, не обновляющих браузеры.


                      1. staticlab
                        29.07.2017 11:43

                        Object rest/spread, например


                        1. rboots
                          29.07.2017 13:28
                          -5

                          1. конструкция очень спорная и может породить кучу багов
                          2. если очень хочется — можно использовать apply
                          3. проблемы с параметрами как таковой нет. С асинхронностью есть, с разбиентием на компоненты — есть, с параметрами — нет


                          1. staticlab
                            29.07.2017 17:22
                            +5

                            Простите, но что вы несёте?


                      1. raveclassic
                        29.07.2017 12:10

                        Банально es6-модули


                        1. rboots
                          29.07.2017 13:31

                          Есть сотни инструментов для этого, не тянущих за собой столько лишнего, как babel. Webpack, requirejs, ещё в 2012 мы самописные инструменты писали на 50 строчек, штука нужная, но очень простая


                          1. raveclassic
                            29.07.2017 15:52
                            +2

                            Вы какой-то странный хейтер бабеля. То есть дополнительные инструменты в проект тащить ок, но только не бабель?


                            1. staticlab
                              29.07.2017 17:13

                              Очевидно же, потому что бабелем можно транспилировать JSX.


                          1. Alex_ME
                            29.07.2017 19:55
                            +1

                            Если уж у нас есть всякие инструменты преобразования кода


                            • трансляторы less/sass
                            • автопрефиксеры
                            • минификация
                            • модули

                            то какая проблема добавить еще один для трансляции js?


              1. justboris
                28.07.2017 20:20
                +1

                А вот и нет. По указанной вами ссылке страница с тремя опциями: Try React, Create a New App, Add React to an Existing App


                Первая дает ссылку на codepen с примерно таким же контентом, как я написал в JSFiddle.


                Тут скорее проблема в том, что в сообществе, в том числе и на Хабре, сложился шаблон React — это Redux, Webpack, Babel и никак иначе. Так теперь и кочует из статьи в статью.


                1. rboots
                  28.07.2017 22:01

                  В примере на codepen тоже используется babel


                  1. staticlab
                    28.07.2017 22:16

                    И что? При транспиляции babel превратит его в такой:


                    ReactDOM.render(
                      React.createElement('h1', null, 'Hello, world!'),
                      document.getElementById('root')
                    );

                    JSX не используется в рантайме.


      1. lega
        28.07.2017 20:38

        а попробуйте хотя бы...
        А вы можете сделать аналог (гибкие шаблоны в компонентах, jsfiddle) на vue для сравнения?, а то для ангуляра 2 это целая проблема.


        1. rboots
          28.07.2017 22:19

          Что за гибкие шаблоны? Гугл не знает, по ссылкам понятный, но ничем не примечательный код. Какую задачу вы хотите решить? Может быть вам нужны слоты, они помогают сделать шаблоны гибче.


          1. lega
            29.07.2017 09:32

            Просто вы там выше меряетесь объемом кода:

            221 символ против 98 в пользу Vue
            Вот вам пример где vue проиграет, так же vue тут может поиметь проблем с миксом контекстов на одном шаблоне.


            1. rboots
              29.07.2017 10:48

              Так что за гибкие шаблоны то? И почему вы решили, что Vue обязательно проиграет?


              1. lega
                29.07.2017 11:03

                Я вам ссылку на статью кинул, там подробнее об этом. Дак от вас стоит ждать аналога на vue? для сравнения сложности и объемов вариантов.


                1. rboots
                  29.07.2017 13:49
                  +1

                  Понял, вы хотите менять шаблон компонента в зависимости от его параметров. Архитектурно это не правильный подход, так как шаблон для каждого типа компонентов компилируется один раз и сделать его динамическим — придётся платить за это тормозами, в любом фреймворке. Правильным подходом будет создать фабрику компонентов, где сгенерировать для каждого шаблона отдельный компонент со общими настройками логики. На практике же как правило достаточно того, что вам предложили в конце статьи, или внести все варианты шаблона в один и разрешить классами, или разрешить в шаблоне через if else. Код переписывать не буду — слишком много букв.


                  1. raveclassic
                    29.07.2017 15:57
                    +1

                    Не шаблон и не менять. Мне (и не только мне) нужен инструмент для проброса компоненту класса другого компонента для внутреннего использования в качестве параметра. Ну, проще говоря, компонент высшего порядка. TS/flow тут еще и помогает описать интерфейс этого нужного компонента.


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


                    1. JSmitty
                      29.07.2017 20:54

                      Не очень вникал, но то, что вы описываете — очень похоже на механизм scoped slots во Vue.js — доступный с 2.1 версии.


                      1. raveclassic
                        29.07.2017 21:04

                        Спасибо за наводку. Подходит скорей dynamic components из ссылки.


  1. s256
    28.07.2017 18:25
    +5

    Что касается custom controls я бы упомянул одну из мощнейших, на мой взгял фич Vue — слоты. Они привносят наследование в шаблоны, и в идеале я могу переопределять разметку чужих компонентов не затрагивая логику!


    1. staticlab
      28.07.2017 23:33
      +5

      В реакте прямой аналог неименованных слотов — это this.props.children, а именованных — другие кастомные пропы:


      Vue

      app-layout:


      <div class="container">
        <header>
          <slot name="header"></slot>
        </header>
        <main>
          <slot></slot>
        </main>
        <footer>
          <slot name="footer"></slot>
        </footer>
      </div>

      parent-container:


      <app-layout>
        <h1 slot="header">Here might be a page title</h1>
        <p>A paragraph for the main content.</p>
        <p>And another one.</p>
        <p slot="footer">Here's some contact info</p>
      </app-layout>

      Результат:


      <div class="container">
        <header>
          <h1>Here might be a page title</h1>
        </header>
        <main>
          <p>A paragraph for the main content.</p>
          <p>And another one.</p>
        </main>
        <footer>
          <p>Here's some contact info</p>
        </footer>
      </div>


  1. indestructable
    28.07.2017 18:46

    Vue использует глобальный объект для регистрации компонентов.


    В результате переименование — проблема, появляется зависимость от порядка объединения файлов, ну и узнать, где какой компонент, можно только поиском.


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


    1. rboots
      28.07.2017 19:04
      +9

      В любом компоненте можно определить свой локальный список components, дать им любые псевдонимы и не зависеть от имён компонентов (самый правильный пусть).

      React безусловно крут, иначе его не было бы в этом сравнении, но JSX это не JavaScript. На JavaScript без JSX можно, но тогда уж проще на VanillaJS, ещё быстрее будет. А шаблоны удобны тем, что их можно отдать верстальщику и снять с разработчиков 50% рутины, там шрифты не те, тут цвет и прочие не относящиеся к программированию вещи.


      1. indestructable
        29.07.2017 00:39

        В любом компоненте можно определить свой локальный список components, дать им любые псевдонимы и не зависеть от имён компонентов (самый правильный пусть).

        Я не использовал Vue, не могли бы вы показать коротенький пример или ссылку на доку?
        Я так понимаю, что в файлах определяется только конфигурация компонента (второй параметр Vue.component), а регистрируются дочерние компоненты прямо в родительском?


        React безусловно крут, иначе его не было бы в этом сравнении, но JSX это не JavaScript. На JavaScript без JSX можно, но тогда уж проще на VanillaJS, ещё быстрее будет.

        React — это далеко не только JSX, очевидно же. И JSX — это 10% его функционала максимум, просто самое запоминающееся.


      1. avdept
        29.07.2017 11:18
        -1

        Писать шаблоны в jsx ничем не сложнее обычного хтмл


        1. TimTowdy
          29.07.2017 12:05
          +1

          Писать — да. Но не читать.
          Посмотрите на PHP — это язык-шаблонизатор. Но почему-то в подавляющем большинстве случаев в нем используют сторонние шаблонизаторы. Как вы думаете, почему?


          1. VolCh
            29.07.2017 13:47

            Прежде всего для изоляции кода шаблона от остального кода приложения с основной целью запретить или сильно усложнить мутации окружения шаблона из шаблона.


          1. avdept
            30.07.2017 13:39

            Не одним php едины. Я не пишу на пыхе, и не знаю как там все обстоит. Но я знаю ситуацию в других веб ориентированых ЯП — и там используют кому что нравится, ибо отличия только в синтаксисе.
            А вот в чем проблема читать jsx я не пойму. Или религия не позволяет открывать файлы в которых намешана логика и вьюха? Да jsx это то, чего на протяжении десятилетий старались избегать в других ЯП\фреймворках. Но суть реактивного подхода — «каждая запятая» это отдельный компонент, и таким образом ваш компонент не должен быть больше чем пара десятков строк кода.


            1. TimTowdy
              30.07.2017 14:28
              +1

              Я тоже на PHP никогда не писал, привел просто для примера. В подавляющем большинстве шаблонизаторов используется свой DSL, а прямой вызов кода на GPL языке либо невозможен, либо не приветствуется.

              Вы, похоже, не понимаете, откуда взялся JSX. Это не просто очередной шаблонизатор. И не просто смесь логики и вьюхи.
              Для борьбы с нарастающей сложностью UI, ребята из FB решили реализовать идею «UI as function of state». Чтоб это не тормозило — использовали VirtualDOM. И все вроде бы хорошо: и сложность уменьшили, и работает быстро. Но оказалось что у такого подхода есть недосткток: разметка куда-то пропадает. Есть только код, генерирующий разметку. И, как вы понимаете, когда у вас возникает задача связанная с версткой, отсутствие разметки очень сильно сказывается на продуктивности. Для этого и придумали JSX — расширение JS, позволяющее использовать XML-подобный синтаксис написания JS-VirtualDOM кода. Идея, на то время, просто отличная.

              И, Vue, если вы не в курсе, делает абсолютно то же самое. Точно также транслирует код шаблона в VirtualDOM вызовы. Но делает это более элегантно, в том числе не позволяя размазывать разметку по разным кускам компонента. Эта разница во Vue и React связана с их историей. Во Vue сначала был дизайн, а VirtualDOM лишь потом оказался деталью реализации. React же с самого начала был твердо завязан на VirtualDOM, и JSX — это просто костыль, созданный для облегчения работы с ним. На 2013 год — костыль просто великолепный. Но уже 2017 на дворе.

              А про «реактивный подход» вы какую-то глупость написали. Он вообще-то ни к React, ни к компонентам не имеет никакого отношения.


              1. avdept
                30.07.2017 19:18

                Мой посыл был что писать шаблоны в jsx ничем не сложнее чем на хтмл, и довода обратно я не увидел.

                PS React — это и есть реализация паттерна реактивного программирования


                1. vintage
                  30.07.2017 19:53
                  +2

                  React — это и есть реализация паттерна реактивного программирования

                  Я бы так не сказал.


  1. vasIvas
    28.07.2017 18:47
    -7

    angular стал знаменитым благодаря архитектуре.
    react стала знаменитым благодаря агрессивному маркетингу.
    vue стал знаменитой благодаря laravel.

    И независимо от того, кто и что любит и у кого какое мнение, пока лидирует angular.
    Да и выбор, на мой взгляд, обуславливается уровнем.


    1. rboots
      28.07.2017 18:56
      +10

      Никогда не пользовался laravel. Vue стал знаменитым, потому что делает те же вещи проще и быстрее


    1. Apathetic
      28.07.2017 18:59
      +8

      Лидирует в чем?


      1. vasIvas
        28.07.2017 19:54
        -6

        В моем понимании он лидирует в нише, которой ещё только предстоит зародится. Он относительно молод, но на нем уже очень много приложений написано. Сам google на нем тоже пишет https://www.madewithangular.com/categories/google

        А когда я слышу о его сравнении, то в голову приходит сравнить уровень авто bmw и ваз по количеству экземпляров в России. Это Вы об таком сравнении меня спрашиваете? Или Вы хотите знать, в чью сторону посмотрят пришедшие из java или c# программисты? Или Вы хотите сравнить по скорости разработки приложения за 10 т.р. на fl.ru с приложениями google? Или может с десктоп приложениями сравнивать jQ?


        1. justboris
          28.07.2017 19:56
          +3

          он лидирует в нише, которой ещё только предстоит зародится

          Очень интересно рассказываете. И что же это за ниша?


          1. raveclassic
            28.07.2017 20:13
            +3

            Ух ты, назревает что-то интересненькое!


        1. Apathetic
          28.07.2017 20:04
          +3

          Ангуляр относительно молод? Относительно чего? GWT?) И да, странно, что google пишет на angular, они же его создали)


          Вы перечислили в своем исходном комментарии три инструмента: ангуляр, реакт, вью. И сообщили, что ангуляр лидирует. При чем тут jquery? При чем тут c#? Я задал конкретный вопрос — в чем ангуляр-то лидирует? В популярности? В количестве написанных приложений? В количестве разработчиков, желающих с ним продолжать работать? Приведите статистику, пожалуйста.


    1. teux
      28.07.2017 21:46
      +1

      Ангуляр 1 лидирует в силу древности. Вряд ли на нем начинают много новых проектов
      Angular — 9.4%
      React — 1,8%
      Vuy 0,3% подрастает


    1. YemSalat
      29.07.2017 17:26

      angular стал знаменитым благодаря архитектуре

      Изначально плохо продуманной архитектуре и маркетингу со стороны Гугла

      react стала знаменитым благодаря агрессивному маркетингу.

      Скорее как альтернатива Ангуляру и на том что «это просто вьюха» (т.е. гораздоо более «легкий» фрэймворк)

      vue стал знаменитой благодаря laravel

      На пыхе не пишу, про Ларавел знаю только название.
      Vue выехал на разрабах которым нужен был легкий (во всех смыслах) фреймворк, плюс на идее фронт-энд фрэймворка без патронажа крупной организации

      И независимо от того, кто и что любит и у кого какое мнение, пока лидирует angular.

      В каком смысле «лидирует»?


  1. grimalschi
    28.07.2017 19:23
    +3

    Vue.js — это песня. Делаю проект с использованием Hot Module Reload — невероятно удобно.

    Радует, что есть Vuex, и инструменты для его отладки, встраиваемые в DevTools.


    1. raveclassic
      28.07.2017 19:24

      Hot Module Reload

      HMR и в react есть.


      Радует, что есть Vuex, и инструменты для его отладки, встраиваемые в DevTools.

      dev-tools и для react/redux есть


      Расскажите лучше, чем действительно больше нравится


      1. grimalschi
        28.07.2017 19:56

        Single File Components, например.
        Позволяет в 1 файле хранить HTML, JS и CSS компонента.

        Вот так это выглядит
        image


        1. raveclassic
          28.07.2017 20:11
          +4

          Забавно слышать, как то, от чего все раньше плевались ядом на старте Реакта, теперь приводят как преимущество.


          Single File Components с самого начала пропагандировались в Реакте: html/css/js — все в одном флаконе. Только на одном языке (js) со всей вытекающей мощью.


          1. grimalschi
            28.07.2017 20:19
            -1

            JSX слабоват, но это дел вкуса.

            А CSS предлагается в inline-style описывать всегда?


            1. raveclassic
              28.07.2017 20:21
              +3

              JSX слабоват

              Чем же?


              А CSS предлагается в inline-style описывать всегда?

              Уже полно инструментов, которые автоматом экстрактят стили в файл.


              1. grimalschi
                28.07.2017 20:33
                -2

                Чем же?

                Условиями. Какой вариант читается проще?

                Vue/Angular/что-угодно:
                <div v-if="condition">...</div>
                

                React:
                { condition && <div>...</div> }
                


                Когда таких конструкций становится много, шаблон читается сложнее.

                Уже полно инструментов, которые автоматом экстрактят стили в файл.

                С HMR оно все работает?


                1. raveclassic
                  28.07.2017 20:51
                  +2

                  Когда таких конструкций становится много, шаблон читается сложнее

                  Ну по мне языковая конструкция воспринимается проще, чем сторонний dsl. Плюс, когда таких конструкций становится много, шаблон бьется на вспомогательные функции.


                  С HMR оно все работает?

                  Прекрасно работает. Даже с SSR и critical css.


                  1. grimalschi
                    28.07.2017 21:26

                    Ну и ладно.

                    Если бы не React не было бы snabbdom, а он сейчас лежит в основе Vue.js.

                    Что на счет Inferno.js? В репозиторие цитируют, что один из разработчиков ядра React писал следующее:

                    Inferno 1.0 is really well written. It's how I would've rewritten React. I'd recommend reading its source to learn.


                    Но Vue все-таки милее и приятнее. Это дело выбора, сами понимаете. Я с ним еще с 0.7 версии, уже несколько лет.

                    React у меня не получилось запустить с Redux, HRM, DevTools. Было ощущение, что пазл собираю, тогда как в Vue все части четко подогнаны друг под друга.


                    1. raveclassic
                      28.07.2017 21:41
                      +1

                      Что на счет Inferno.js?

                      Одно время засматривался, но потом взял себя в руки. Все-таки "React-like", а совместимость и поддерживаемость важнее, в продакшн не возьмешь.


                      не получилось запустить с Redux, HRM, DevTools

                      Ну чего уж лукавить, для хот-реплейса компонентов и редьюсеров там действительно поколдовать надо. Но можно начать с create-react-app, потом сюда или сразу сюда


                      1. grimalschi
                        28.07.2017 21:43

                        Спасибо за ссылки.


                1. YemSalat
                  29.07.2017 18:26
                  -2

                  React:
                  condition &&  ... 
                  

                  Когда таких конструкций становится много, шаблон читается сложнее.

                  Кто вам мешает писать по-человечески?
                  if (condition) ...
                  

                  На вьюхи Реакта надо смотреть как на обычный JS. Если вы такие конструкции в обычном коде будете выдавать — на вас будут косо смотреть, в шаблонах то же самое.


                  1. TheShock
                    29.07.2017 18:33
                    +2

                    В функциональном ретурне ИФ не вставится.

                    return (
                      <div>
                        <First />
                        {second && <Second />}
                        <Third />
                      </div>
                    );
                    


                    1. vintage
                      29.07.2017 19:12
                      +2

                      Вставится:


                      return (
                        <div>
                          <First />
                          { (()=> { if( second ) return <Second /> })() }
                          <Third />
                        </div>
                      );

                      Но самый тру вэй — это, конечно, подключить модуль composable-js:


                      import If from 'composable-js'
                      return (
                        <div>
                          <First />
                            { If( ()=> second , ()=> <Second /> ) }
                            </If>
                          <Third />
                        </div>
                      );


                      1. TheShock
                        29.07.2017 19:16

                        И станет еще более нечитабельно) Я простые условия допускаю именно такие ({second && <Second />}), а что-то последнее когда комбинировать нужно, то просто выношу в метод

                        class Foo extends React.Component {
                        
                          renderSecond () {
                            if (xA) return <SecondA />;
                            if (xB) return <SecondB />;
                            return null;
                          }
                        
                          render () {
                            return (
                              <div>
                                <First />
                                {this.renderSecond()}
                                <Third />
                              </div>
                            );
                          }
                        }
                        


                        1. vintage
                          29.07.2017 19:31
                          +2

                          А когда JSX разбивается на маленькие кусочки, то он теряет последние остатки смысла:


                          renderSecond () {
                              if (xA) return <SecondA />;
                              if (xB) return <SecondB />;
                              return null;
                          }

                          renderSecond () {
                              if (xA) return SecondA();
                              if (xB) return SecondB();
                              return null;
                          }


                          1. raveclassic
                            29.07.2017 19:57

                            Если перестать воспринимать JSX как HTML, то окажется, что XML-нотация — просто способ инстанцирования компонентов. И способ работы с SecondA будет варьироваться в зависимости от того, что она возвращает. Если компонент — JSX, если инстанс — return.


                            1. vintage
                              29.07.2017 20:05

                              Так зачем нам несколько способов делать одно и то же?


                              1. raveclassic
                                29.07.2017 20:16

                                В смысле? Функция и ее результат — не одно и то же. Класс и его инстанс — тоже не одно и то же. Другое дело, что new или просто вызов функции тут не спасают, нужен вызов createElement.


                                1. vintage
                                  29.07.2017 20:37

                                  Я привёл два кода — они полностью равнозначны.


                          1. YemSalat
                            29.07.2017 20:45

                            У вас некорректный второй пример, должно быть:

                            return second();
                            

                            function second () {
                              return (xA) ? <SecondA /> : <SecondB />;
                            }
                            


                            1. vintage
                              29.07.2017 20:48

                              function second () {
                                return (xA) ? SecondA() : SecondB();
                              }


                              1. raveclassic
                                29.07.2017 21:10

                                Этот трюк сработает только, если SecondA и SecondB — SFC.


                                1. vintage
                                  29.07.2017 21:18

                                  С классами его тоже не трудно подружить.


                                  1. raveclassic
                                    29.07.2017 21:22

                                    И как же?


                                    Вы не подумайте, меня самого xml бесит


                                    1. vintage
                                      29.07.2017 21:52

                                      Что-то типа:


                                      class Profile extends VirtualNode {
                                          get state() {
                                              return GlobalStore.get( this.id )
                                          }
                                          set state( next ) {
                                              return GlobalStore.set( this.id , { ... this.state , ... next } )
                                          }
                                          onchange( event ) {
                                              this.state = { name : event.target.value }
                                          }
                                          get children() {
                                              return [
                                                  Title({ title : 'User profile' }) ,
                                                  new Input({
                                                      value : this.state.name ,
                                                      oninput : event => this.onchange( event )
                                                  }) ,
                                              ]
                                          }
                                      }


                                      1. raveclassic
                                        29.07.2017 22:08

                                        Интересно. А зачем стейт держать в GlobalStore?


                                        1. vintage
                                          29.07.2017 22:47

                                          Чтобы он не сбрасывался при каждом создании экземпляра.


                                          1. raveclassic
                                            29.07.2017 22:57

                                            Вот сейчас я подвис.


                                            Стейт же локален для компонента. Это какой-то конкретный случай или вы всегда так делаете?


                                            1. vintage
                                              29.07.2017 23:23

                                              Это пример как можно сделать без React.createElement. При каждом рендеринге создаются новые экземпляры компонента. Если состояние хранить локально, то оно будет теряться, вместе со старыми экземплярами.


                                              1. raveclassic
                                                29.07.2017 23:40

                                                И зачем тогда классы? Состояние сбоку можно доставать и из SFC


                                                1. vintage
                                                  30.07.2017 09:24

                                                  Можно, но не удобно. А с классами — отнаследовался и работаешь с this.state не парясь о том, где его хранить.


                        1. TimTowdy
                          29.07.2017 21:25
                          +2

                          Вот в этом и беда JSX. Легко писать, трудно читать.
                          Рано или поздно разметка расплывается по коду. Становится невозможным окинуть взглядом кусок файла и понять, а что же там отрендерится. Потому что внутри JSX у вас неизбежно появляются методы которые возвращают JSX, да еще и с условиями внутри.


                          1. raveclassic
                            29.07.2017 21:27

                            Казалось бы и в чем проблема? Отрендерится то, что вы вернете из render или из SFC-функции. Вся мощь языка в ваших руках. Полный контроль без выкрутасов с DSL.


                            1. TimTowdy
                              29.07.2017 22:25

                              Я вам про читаемость, а вы мне про мощь языка и контроль :)
                              Это зачастую противоположные вещи. Когда у вас есть четко определенная доменная область (а разметка таковой является), от мощи языка нужно избавляться.
                              SQL, например, потому и популярен, что вместо «мощи» языка общего назначения позволяет писать запрос на более ясном, лаконичном и читаемом языке.

                              Что происходит в голове у программиста (и не дай бог вместо программиста будет верстальщик/дизайнер), который пытается понять, а что же будет в итоговой разметке?

                              class Foo extends React.Component {
                              
                                renderSecond () {
                                  if (xA) return <SecondA />;
                                  if (xB) return <SecondB />;
                                  return null;
                                }
                                // ...
                                // еще 5 экранов кода
                                // ...
                                render () {
                                  return (
                                    <div>
                                      <First />
                                      {this.renderSecond()}
                                      <Third />
                                    </div>
                                  );
                                }
                              }
                              

                              Ищем render(), читаем выражение которое он возвращает… Оппа, вызов метода — сохраняем прочитанную часть шаблона в «мозговой стэк», скроллим до renderSecond() читаем его, вычисляем, прыгаем назад по стэку, читаем дальше…

                              А если у вас там такое выражение?
                              { this.shouldRenderSecond() ? this.renderSecond() : this.renderSomethingElse() }
                              

                              Три раза скроллить будете? Голова не начнет болеть?
                              И не надо рассказывать что так на React не пишут. Пишут, да еще и гордятся этим.


                              1. TheShock
                                29.07.2017 22:48

                                Люди не зря придумали понятие абстракции. Вам достаточно знать имя метода и понимать: «Он отрендерит second». Нету необходимости знать детали реализации всей пирамиды при работе с определенным методом.


                                1. TimTowdy
                                  29.07.2017 23:39
                                  -1

                                  В том-то и дело. Я не хочу знать детали реализации. У меня четкая задача: понять какой будет итоговая разметка. Затратив на это минимум усилий. И чем больше джаваскрипта в разметке, тем больше понадобится усилий для понимания.

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

                                  Предложите забить т.к. юзер не привел шаги для воспроизведения? Извините, позволить конверсии просесть на неизвестную величину на неизвестный срок для бизнеса это не вариант.

                                  Вы мыслите с позиции программиста: делаю фичу, пишу код, ввожу абстракцию…
                                  А я мыслю с позиции жизненного цикла проекта: ввести в команду нового человека, пофиксить баг, добавить новую фичу не повысив ментальную нагрузку, позволить членам команды с разным уровнем опыта продуктивно работать в команде, продолжить работу если важный разработчик попал под автобус, минимизировать технический долг… И с этой точки зрения я зачастую предпочту именно Vue, а не React.


                                  1. TheShock
                                    29.07.2017 23:42

                                    Естествнно предполагаем что в каких-то случаях едет верстка. Ну и что толку с вашей великолепной абстракции?

                                    Смотрим итоговую разметку и правим CSS, у нас ведь не 90-ые, когда стилизация делалась кучей вложенных дивов. Верстка — исключительно семантическая. Или у вас не так?


                              1. raveclassic
                                29.07.2017 22:55
                                +1

                                Оппа, вызов метода — сохраняем прочитанную часть шаблона в «мозговой стэк», скроллим до renderSecond() читаем его, вычисляем, прыгаем назад по стэку, читаем дальше…

                                А вы, встречая в маркапе кастомный компонент, каждый раз переходите в него и смотрите, а что же он там рендерит? Ну чушь же. Компонент определяет свое предназначение своим именем, точно так же и с методами.


                                А если у вас там такое выражение?

                                Можно подумать, подшаблоны и зоопарк v-if/ng-if/что-угодно-if-switch-unless выглядят лучше. Голова болит еще хуже, так как приходится переключаться между языками.


                                //…
                                // еще 5 экранов кода
                                //…

                                Три раза скроллить будете? Голова не начнет болеть?

                                Бейте на подкомпоненты. Пять экранов html точно так же не вызывают ничего кроме изжоги.


                                И не надо рассказывать что так на React не пишут. Пишут, да еще и гордятся этим.

                                Вас просто бесит, что вместо привычного html вы видите какую-то инопланетную js-угрозу. А сказки про неперевариваемость верстальщиками из команды JSX — так совсем полная чушь, убедился на личном опыте. Даже обезьянка поймет, как использовать методы/подкомпоненты для разбиения разметки. Еще и в восторге потом будет.


                                1. TimTowdy
                                  30.07.2017 00:03
                                  -1

                                  А вы, встречая в маркапе кастомный компонент, каждый раз переходите в него и смотрите, а что же он там рендерит? Ну чушь же.

                                  Привел пример выше, совсем не чушь.

                                  Можно подумать, подшаблоны и зоопарк v-if/ng-if/что-угодно-if-switch-unless выглядят лучше.

                                  Да, выглядят лучше т.к. читаем специализированный DSL, а не мегаязык который умеет все.

                                  Голова болит еще хуже, так как приходится переключаться между языками.

                                  Это просто смешно. Придумываем надмножество JS, чтоб не формально не переключаться между языками. Больше не нужно переключаться, ведь наш мегаязык теперь включает в себя абсолютно все!
                                  Напоминает аргументацию креационистов: религия лучше чем наука, потому что религия может объяснить абсолютно все, а наука — нет!

                                  Бейте на подкомпоненты. Пять экранов html точно так же не вызывают ничего кроме изжоги.

                                  Любой условный рендеринг разбивать на подкомпоненты? Нет, спасибо.

                                  Вас просто бесит, что вместо привычного html вы видите какую-то инопланетную js-угрозу.

                                  Да, я использовал JS более 10 лет, и считаю его плохим языком (даже с учетом ES6). Поэтому замену JS+HTML+CSS на JS+JS+JS считаю вредной. Но это тема отдельного разговора.

                                  А сказки про неперевариваемость верстальщиками из команды JSX — так совсем полная чушь, убедился на личном опыте.

                                  В науке личный опыт — самый слабый аргумент.


                                  1. raveclassic
                                    30.07.2017 00:13
                                    +1

                                    Привел пример выше, совсем не чушь.

                                    То есть вы серьезно, когда видите что-то вроде <div><avatar/>{user.name}</div> ходите в avatar чтобы посмотреть, из чего он состоит? Мне вас жаль, абстракциями совсем не пользуетесь?


                                    а не мегаязык который умеет все.

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


                                    Напоминает аргументацию креационистов: религия лучше чем наука, потому что религия может объяснить абсолютно все, а наука — нет!

                                    Мои предположения о вашей паранойе крепнут.


                                    Любой условный рендеринг разбивать на подкомпоненты? Нет, спасибо.

                                    Что-то вы мечетесь. Я говорю вам, что нужно разбивать 5-страничные портянки, а не ветки условий.


                                    Да, я использовал JS более 10 лет, и считаю его плохим языком

                                    Ну вот и сложился пазл.


                                    В науке личный опыт — самый слабый аргумент.

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


                                    1. TimTowdy
                                      30.07.2017 00:55
                                      +1

                                      То есть вы серьезно, когда видите что-то вроде <avatar/>{user.name} ходите в avatar чтобы посмотреть, из чего он состоит? Мне вас жаль, абстракциями совсем не пользуетесь?

                                      Вы пример-то прочитали? Есть баг, в каких-то (неизвестных) условиях ломается верстка. Чем тут поможет ваша абстракция avatar?
                                      Представьте себе, возможно придется полезть и в него. Может аватар, загруженный из фейсбука, рендерится с неправильными размерами и смещает форму оплаты? Или у юзеров без аватара placeholder рендерится два раза вместо одного? И, в зависимости от размера экрана (или браузера) на мобильном девайсе, это смещает форму.

                                      Да, придется открывать разные файлы, и скроллить туда-сюда. Но ради абстракции с этим можно смириться. А вот ради условных операторов — вряд ли.

                                      Зачем мне учить что-то новое для решения проблемы, если мой инструмент и так ее решает? Еще и хорошо.

                                      Когда у вас есть только молоток, все вокруг кажется гвоздями.

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

                                      У вас аргументация демагога, причем тут промышленное производство? «Это полная чушь, потому что я убедился на личном опыте».

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


                                      1. raveclassic
                                        30.07.2017 01:21

                                        Представьте себе, возможно придется полезть и в него. Может аватар, загруженный из фейсбука, рендерится с неправильными размерами и смещает форму оплаты? Или у юзеров без аватара placeholder рендерится два раза вместо одного?

                                        Так может это проблема аватара, как отдельного элемента интерфейса? Может, он плохо оттестирован, плохо изолирован, раз так сильно влияет на свое окружение? В любом случае, вы первым делом открываете инспектор и ищите причину сдвига формы. Границы компонентов достаточно хорошо прослеживаются. Найдя дефект, вы знаете внутри какого компонента он находится. Разница между vue и react тут нулевая.


                                        Дальше, это все не имеет никакого отношения к условиям. Отдельный метод под ветку ничем не отличается от отдельного компонента под ветку. Если вы не хотите терять контекст при работе с разным блоками (родителем и разметкой ветки), пожалуйста — используйте && или тернарники. Без выкрутасов, без тройного сальта назад, без dsl.


                                        Когда у вас есть только молоток, все вокруг кажется гвоздями.

                                        Как же уже заколебала эта фраза, лезущая из всех щелей. Вы ребятам из команды kotlin тоже самое скажете? "Вы с ума сошли! Зачем вам один язык под все? Есть же такой клевый зоопарк на все случаи жизни"


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

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


                                        1. TimTowdy
                                          30.07.2017 02:01
                                          +1

                                          Найдя дефект, вы знаете внутри какого компонента он находится.

                                          Вы все еще не поняли? Баг вам воспроизвести не удалось. Дефект не найден. Но он есть. Толку от вашего инспектора, если не можете его ни воспроизвести, ни даже узнать как конкретно он проявляется? Все что вам сказал юзер: «не видно кнопку оплаты». Потенциальных причин — миллион.

                                          Моя позиция — чем проще вам охватить взглядом разметку и удержать ее в голове, тем легче будет найти чем этот баг вызван.
                                          В случае с React это 100% будет сделать сложнее — просто потому что он позволяет (и разработчики очень этим пользуются) сильнее размазать разметку. Просто потому, что удержать в голове разметку, которая генерируется языком широкого назначения — сложнее.

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


                                          1. TheShock
                                            30.07.2017 15:01
                                            -1

                                            ввожу вам объективную метрику: средняя удаленность кусков разметки компонента помноженная на количество этих кусков

                                            Ну, очевидно, по такой странной «объективной метрике» Vue вам ровно так же не подходит, а необходимо писать html без всяких компонентов для каждой страницы, где все в одном файле. Ну, то есть, вы, по сути, просите php 3.


                                            1. TimTowdy
                                              30.07.2017 15:30

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

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

                                              Причины, как я уже писал, скорее всего в истории этих библиотек:
                                              Vue — очередная попытка создать удобный JS-фреймворк, с учетом ошибок предшественников.
                                              React — попытка создать быстрый реактивный JS-фреймворк основанный на VirtualDOM.

                                              Оба со своими задачами справились прекрасно. Но Vue около года назад просто взял и добавил себе скорость React как одну из деталей реализации (VirtualDOM). А React не может сделать то же самое со своим дизайном. Именно поэтому вокруг Vue сейчас тот же хайп, который в 2015 был вокруг React.


                                              1. TheShock
                                                30.07.2017 16:04
                                                -1

                                                Я привел ее для примера человеку, который, похоже, наивно полагает, что React в абсолютно любой ситуации превосходит Vue.

                                                Вы ошибаетесь. Я никогда не пользовался Vue и не знаю, какой он. Если вы внимательно почитаете мои комментарии, то увидите, что я никогда не сравнивал Реакт с Vue и вообще не давал оценку Vue. Ибо, как я уже сказал, я понятия не имею, что там творится в Vue (хотя лично я тоже крайне не люблю разметку на псевдоязыке а-ля Ангулар)

                                                Я как раз говорю, что вынос кода в метод — это благо, а не наказание, без контекста Vue. То есть именно в Реакте то, что я могу вынести код в метод — это очень круто и помогает разработке, код становится читабельным, метод Рендер меньше и это хорошо.

                                                Чем дальше вы от этого уходите, тем сложнее будет работать с версткой

                                                От тут не согласен. Вы говорите логичные вещи, а потом бац — делаете из них не совсем связанный вывод. Тоже классический прием демагогии.

                                                У нас есть готовая верстка в браузере, у нас есть даже для браузера Реакт тулы, которые покажут, какой именно компонент рендерит этот кусок ДОМа.

                                                Но лично я никогда не пользовался этими тулами, ибо… не было необходимости.

                                                У меня Реакт рендерит логичную семантическую верстку и, пожалуй, не бывает момента когда ее нужно править ради баг-фикса. Баг или в JS-логике или в CSS.


                                                1. TimTowdy
                                                  30.07.2017 17:24
                                                  +1

                                                  Вы ошибаетесь. Я никогда не пользовался Vue и не знаю, какой он. Если вы внимательно почитаете мои комментарии, то увидите, что я никогда не сравнивал Реакт с Vue и вообще не давал оценку Vue

                                                  Я ведь не вам отвечал, когда привел свою метрику, а raveclassic. Пример метрики привел для именно для него.

                                                  У нас есть готовая верстка в браузере
                                                  Я же специально для этого привел пример с багом: верстка в браузере есть, но абсолютно никак не помогает решить задачу.

                                                  Верстка в браузере этого лишь один из возможных вариантов интерпретации шаблона/кода. Добавьте 5 условий — получите +32 варианта верстки.

                                                  Браузеры вот уже почти 25 лет интерпретируют HTML. От этого никуда не уйти. Теперь вам нужно придумать некоторую абстракцию, которая описывает как состояние преобразовывается в HTML. Чем ближе ваша абстракция (template/JSX) к конечному результату (HTML), тем проще ею пользоваться.

                                                  Вот вам банальная задача: отобразить список имен из массива. Т.е. преобразовать это:

                                                  const users = ['Alice', 'Bob', 'Charlie']

                                                  в это:
                                                  <ul>
                                                      <li>Alice</li>
                                                      <li>Bob</li>
                                                      <li>Charlie</li>
                                                  </ul>
                                                  


                                                  Решение на Vue:
                                                  <ul>
                                                      <li v-for="name in users">{{ name }}</li>
                                                  </ul>
                                                  


                                                  Решение на React (взял из официальной документации):
                                                  const names = users.map((name) =>
                                                    <li>{name}</li>
                                                  );
                                                  
                                                  return (
                                                    <ul>{names}</ul>
                                                  );
                                                  


                                                  Просто помедитируйте на эти три куска кода пару минут. Подумайте, какую ментальную нагрузку на разработчика несет преобразование из кода на React/Vue в конечный результат.

                                                  И я даже не упоминаю о том, что даже такую простую задачу как вывод списка, на React можно сделать несколькими разными способами. Еще больше способов найдется для условных операторов.
                                                  Не вспоминаю про className, inline-стилях, убогом setState вместо привычного присваивания, boilerplate коде…

                                                  У React была отличная концепция: components, unidirectional data-flow, functional UI, VirtualDOM. Прекрасные вещи. И все они есть во Vue. И реализованы на порядок лучше (просто потому, что у Vue была возможность учесть недостатки React).


                                                  1. TimTowdy
                                                    30.07.2017 22:55
                                                    +1

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

                                                    Итак, задача в голове программиста звучит так:
                                                    «рендерить компонент Second, только если second равно true».

                                                    React (ваоиант 1):

                                                    return (
                                                      <div>
                                                        <First />
                                                        {second && <Second />}
                                                        <Third />
                                                      </div>
                                                    );


                                                    React (ваоиант 2):
                                                    return (
                                                      <div>
                                                        <First />
                                                        { (()=> { if( second ) return <Second /> })() }
                                                        <Third />
                                                      </div>
                                                    );


                                                    React (ваоиант 3):
                                                    import If from 'composable-js'
                                                    return (
                                                      <div>
                                                        <First />
                                                          { If( ()=> second , ()=> <Second /> ) }
                                                          </If>
                                                        <Third />
                                                      </div>
                                                    );
                                                    


                                                    React (ваоиант 4):
                                                    renderSecond(){
                                                        if (this.second){
                                                            return <Second />
                                                        }
                                                        return null
                                                    }
                                                    // ...
                                                    return (
                                                      <div>
                                                        <First />
                                                        {this.renderSecond()}
                                                        <Third />
                                                      </div>
                                                    );
                                                    


                                                    Vue:
                                                    <div>
                                                      <First />
                                                      <Second v-if="second" />
                                                      <Third />
                                                    </div>


                                                    Абстрактный щаблонизатор:
                                                    <div>
                                                      <First />
                                                      {% if second %}
                                                        <Second />
                                                      {% endif %}
                                                      <Third />
                                                    </div>


                                                    1. vintage
                                                      30.07.2017 23:33

                                                      Вы бы хоть поправили в 3 варианте лишний закрывающий тег, который я не успел удалить :-)


                                                      Ну и вариант на view.tree тогда:


                                                      sub /
                                                          <= Head $my_first
                                                          <= Body $my_second
                                                          <= Foot $my_third

                                                      Body() {
                                                          return this.body() ? super.Body() : null
                                                      }


                                                  1. raveclassic
                                                    31.07.2017 13:48

                                                    Я привел ее для примера человеку, который, похоже, наивно полагает, что React в абсолютно любой ситуации превосходит Vue.

                                                    Видимо, вы наивно видите то, что хотите видеть.


                                                    Я ведь не вам отвечал, когда привел свою метрику, а raveclassic. Пример метрики привел для именно для него.

                                                    Какая к черту метрика? Размазанность маркапа по методам? Ну что за ахинея, вы так же размажете маркап по компонентам и будете прыгать из файла в файл. Не хотите — не размазывайте. Не надо только говорить, что возможность декомпозиции это минус и "vue тут явно выигрывает". Повторюсь, вы видите то, что хотите видеть.


                                                    Решение на React (взял из официальной документации):

                                                    Постеснялись бы хоть.


                                                    <ul>
                                                      {names.map(name => <li>{name}</li>)}
                                                    </ul>

                                                    Подумайте, какую ментальную нагрузку на разработчика несет преобразование из кода на React/Vue в конечный результат.

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


                                                    И реализованы на порядок лучше (просто потому, что у Vue была возможность учесть недостатки React).

                                                    Пока что я не услышал ни одного аргумента в пользу vue кроме лютой субъективщины. Окей, один аргумент — с реактом надо потратить один день (я знаю, что говорю), чтобы научить верстальщика jsx. "Vue тут явно выигрывает"


                                                    1. TimTowdy
                                                      31.07.2017 15:05

                                                      Постеснялись бы хоть.
                                                      Вот в том то и дело, что любой порядочный разработчик знает, что преобразование над элементами массива выполняется через map. Везде и всегда. Нужно из массива имен сделать массив элементов списка. Вуаля — map!
                                                      Так я и сделал через map, внимательней посмотрите. Скопировал из документации React один в один. Чего мне стесняться-то?

                                                      Окей, один аргумент — с реактом надо потратить один день (я знаю, что говорю), чтобы научить верстальщика jsx.
                                                      Вы делите мир на черное и белое: «верстальщик умеет в JSX» и «верстальщик не умеет в JSX». Я же утверждаю, что верстальщик знающий JSX все равно будет менее продуктивен, чем если бы ему пришлось работать с языком, более близким к реальной разметке. Измерить ментальную нагрузку конечно сложно, но по-моему в приведенных мною примерах это довольно очевидно (если смотреть на них без фанбоизма и эмоций).


                                                      1. raveclassic
                                                        31.07.2017 15:15
                                                        +1

                                                        Чего мне стесняться-то?

                                                        Ну вы же давите на "излишнюю разнесенность", специально тогда пишите пример с дополнительной переменной?


                                                        Вы делите мир на черное и белое:

                                                        Я делю мир на "нужно учить стандартные вещи" и "нужно учить нестандартную отсебятину". Невозможно знать все, мы постоянно учимся. Вопрос стоит в том, что учить — язык или еще один шаблонизатор


                                                        что верстальщик знающий JSX все равно будет менее продуктивен, чем если бы ему пришлось работать с языком, более близким к реальной разметке

                                                        Я же вам с уверенностью утверждаю, что это не так, так как прямо сейчас целая команда, ранее не знакомая с jsx, работает на таком уровне производительности, который им раньше и не снился. Попутно выучив JS. Одни плюсы.


                                                        если смотреть на них без фанбоизма и эмоций

                                                        но по-моему в приведенных мною примерах это довольно очевидно

                                                        Очевидно, что очевидно это только вам.
                                                        Ну и конечно, я все ждал, что меня обзовут фанбоем когда "поток аргументации" иссякнет.


                                                        1. TimTowdy
                                                          31.07.2017 15:54
                                                          -1

                                                          Ну вы же давите на «излишнюю разнесенность», специально тогда пишите пример с дополнительной переменной?

                                                          Еще раз говорю, пример взят из официальной документации React. В программировании бывает вводят дополнительную переменную чтобы код сделать проще для понимания. И посколько к JSX разработчики относятся именно как к коду (ведь он по сути им и является), то и подход используют точно такой же. Они таким упрощают понимание алгоритма генерирующего разметку, но усложняют понимание самой разметки. Это tradeoff, в большинстве случаев не осознанный. И далеко не всегда полезный.

                                                          Во Vue же, к разметке относятся именно как к разметке. Несмотря на наличие условных операторов, циклов, и последующего преобразования в VirtualDOM.

                                                          В React разметка становится кодом на этапе написания приложения. А во Vue — на этапе компиляции. Вы можете сколько угодно с этим спорить, но разметку всегда читать проще, чем код. И программисту, и верстальщику. А код, в 2017 году, пишется именно для того чтоб его читали.


                    1. YemSalat
                      29.07.2017 19:29

                      Ну тут опять же сводится к поддержке кода и аргументу автора статьи (столько-то символов против стольки-то).
                      В данном примере я бы вынес в отдельную переменную или функцию, или на худой конец в «ternary expression»:

                      return (
                          {
                            (condition)
                              ? <Something />
                              : null
                           }
                      );
                      

                      Тут возврат к моему начальному аргументу: «На вьюхи Реакта надо смотреть как на обычный JS...»


        1. serf
          28.07.2017 22:08

          Single File Components

          Это как раз плохой тон все пихать в одни файл, как по мне. Однако это опциональная возможность тк можно подключать шалон + js/css как внешние файлы.


          1. Virviil
            29.07.2017 16:19

            Если компонент уровня TableRowCell или TableControllPanelButton — почему бы и нет?


            1. serf
              29.07.2017 16:21

              Потому что это принципиально неправильно все смешивать в один файл, это можно сделать при сборке если нужно, но не на уровне исходников.


              1. VolCh
                29.07.2017 16:34
                +1

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


                1. serf
                  30.07.2017 15:54

                  Я не призываю отказаться, Vue как раз позволяет использовать оба подхода.


        1. SPAHI4
          29.07.2017 16:28

          https://github.com/zeit/styled-jsx


    1. trueClearThinker
      29.07.2017 10:29

      Vuex хорош лишь тем, что он встроен в инфраструктуру (тот же devtools). На самом деле есть вопросы к vuex, которые, похоже, разработчик не собирается решать.


    1. kellas
      29.07.2017 15:09

      https://github.com/alexstep/create-riot-app-ejected/


  1. Akuma
    28.07.2017 19:31
    +9

    Уж не знаю какую по счету статью про Vue vs React читаю, но никак не пойму на что напирают сторонники Vue?

    1. Хватит гнобить JSX. Это дело вкуса, но мне, как и многим людям, он нравится.

    2. Мне, как и многим людям, НЕ нравятся шаблоны в строках. По большому счету из-за отсутствия поддержки в IDE. Поправьте, если ошибаюсь и они уже работают так же «ровно» как JSX.

    3. Дайте четкое определение Custom Controlls. То, что в статье — просто отдельный компонент и он на Vue ничем не отличается от остальных.

    4. Создание компонентов в React — история? Скорее четверостишье. Просто функция в самом простом варианте. Впрочем, класс с render() не слишком сложнее.

    В общем, кроме расширения через прототип (вряд ли когда-нибудь понадобится, ну да ладно) плюсов вы не привели.

    Так вот: не надоело еще? Я имею ввиду писать статьи уровня «смотрите, мой ХеллоуВорлд круче, чем на Реакт». Напишите что-нибудь сложнее вывода {{message}}, используя фичи, которые есть только в Vue и тогда это будет сравнение преимуществ. А пока это больше похоже на реферат по информатике.


    1. raveclassic
      28.07.2017 19:36

      на что напирают сторонники Vue

      На то что не react и не angular.


      Это дело вкуса, но мне, как и многим людям, он нравится

      К сожалению это закоренелое убеждение, что все кончается html'ем


      так же «ровно» как JSX.

      Или, еще лучше, TSX


      кроме расширения через прототип

      Я правильно понял, что тут патчинг глобального прототипа приводится за преимущество? Эм...


    1. rboots
      28.07.2017 20:05
      -1

      Что за деление на сторонников того и другого фреймворка? Посмотрите голосование, среди тех, кто пробовал Vue довольных более чем в 5 раз больше. Есть те, кто ещё не пробовал, и, собственно, «сторонники». Поэтому ждём вас в наших рядах. А шаблоны в строках я тоже не люблю, это для демонстрации, а типичный компонент выглядит как-то так:

      Заголовок спойлера
      <template>
          <div class="ViewTestBusinessReport animated fadeIn">
              <div class="row">
                  <div class="col-12">
                      <div class="card" v-if="!loaded">
                          <div class="card-block">
                              Загрузка...
                          </div>
                      </div>
                      <div class="card" v-if="loaded">
                          <div class="card-block candidate-info">
                              <h3>Кандидат</h3>
                              <div class="row">
                                  <label class="form-group col-6">
                                      <b>ФИО:</b>
                                      <input type="text" v-model="candidateData.fio" 
                                             class="form-control"
                                             placeholder="не заполнено" readonly>
                                  </label>
                                  <label class="form-group col-6">
                                      <b>Позиция:</b>
                                      <input type="text" v-model="candidateData.vacancy" 
                                             class="form-control"
                                             placeholder="не заполнено" readonly>
                                  </label>
                                  <label class="form-group col-6">
                                      <b>Телефон:</b>
                                      <input type="text" v-model="candidateData.phone"
                                             class="form-control" 
                                             placeholder="не заполнено" readonly>
                                  </label>
                                  <label class="form-group col-6">
                                      <b>E-mail:</b>
                                      <input type="text" v-model="candidateData.email"
                                             class="form-control"
                                             placeholder="не заполнено" readonly>
                                  </label>
                                  <label class="form-group col-12">
                                      <b>Примечание:</b>
                                      <textarea v-model="candidateData.comment" class="form-control"
                                                placeholder="не заполнено" readonly></textarea>
                                  </label>
                              </div>
                          </div>
                      </div>
                      <div class="card" v-if="loaded">
                          <div class="card-block" v-if="results">
                              <h3>Результаты теста</h3>
                              <div v-for="metricResult in results">
                                  <b v-text="metricResult.title + ':'"></b>
                                  <span v-text="getMetricRating(metricResult) + ' из 100'"></span>
                              </div>
                              <br />
                              <button type="button" class="btn btn-default"
                                      @click="print" v-if="beta">Распечатать</button>
                              <router-link :to="'/test_science_result/' + testId" 
                                           class="nav-link" v-if="beta">Научный отчёт</router-link>
                          </div>
                          <div class="card-block" v-if="!results">
                              Кандидат ещё не прошёл тест. Ссылка на прохождение теста:
                              <CopyInput :text="testLink"></CopyInput>
                          </div>
                      </div>
                  </div>
              </div>
          </div>
      </template>
      
      <script>
          import CopyInput from '../../components/CopyInput.vue'
      
          export default {
              name: 'test_business_report',
              components: {
                  CopyInput
              },
              props: ['testId'],
              data: function () {
                  return {
                      beta: window.beta,
                      loaded: false,
                      candidateData: null,
                      results: null
                  };
              },
              created: function () {
                  this.testLink = config.host + 'test.html#/link/' + this.testId;
      
                  axios.post('/api/test_report/business', {
                      testId: this.testId
                  })
                      .then(this.onGetTestResults.bind(this))
                      .catch(this.onAjaxError.bind(this));
              },
              methods: {
                  onGetTestResults: function (response) {
                      this.candidateData = response.data.candidateData;
                      this.results = response.data.results;
                      this.loaded = true;
                  },
                  getMetricRating: function (metricResilt) {
                      var rate = metricResilt.plus / (metricResilt.plus + metricResilt.minus);
                      return Math.round(rate * 100);
                  },
                  complete: function () {
                      document.clearCookie('activeTest');
                      location.href = '#/dashboard';
                  },
                  print: function () {
                      console.log('Print');
                  },
                  onAjaxError: function (error) {
                      console.error(error);
                  }
              }
          }
      </script>
      
      <style lang="less">
          .ViewTestBusinessReport {
              .candidate-info {
                  input[type="text"].form-control,
                  textarea.form-control {
                      background: #fff;
                      color: #444;
                      border: 0;
                      padding: 0.3rem 0;
                  }
              }
      
              #CopyField {
                  border: 1px solid rgba(0, 0, 0, 0.15);
                  color: #888;
              }
          }
      </style>
      


      1. Akuma
        28.07.2017 20:32
        +3

        Вы вкурсе, что в этом опросе можно выбрать только один вариант?
        Я вот например выбрал «Не планирую использовать». И нравится/ненравится не выбирал.
        Причем, я не говорю, что он мне не нравится. Я говорю, что это уже 100500-я статья про «Почему Vue лучше» и в 100500-й раз в ней НЕ написано о том почему Vue лучше.

        Давайте проще. Основная фича React — это отсутствие собственных обязательных выдумок. Все делается на чистом JS. Абсолютно все.

        У Vue же болячки первого Angular: выражения в шаблонах ограничены, присутствуют собственные атрибуты, собственные изобретения. Первый Ангуляр явно показал чем это плохо. Он показал, что все эти ng-if заставляют разработчика бороться с фрейморком. То же будет и с Vue, я вас уверяю.

        Простой пример. У меня есть обычный JS Array:

        let list = [{type:'one'}, {type:'two'}, {type:'three'}]
        

        Мне нужно вывести список, который будет в зависимости от type рендерить разные компоненты.

        React:
        {list.map(item => {
            switch(item.type){
                case 'one':
                return <ComponentOne />;
                ....
            }
        })}
        


        Vue:
        <component-one v-if="item.type == 'one'" />
        ...
        


        Видите разницу? В первом случае это просто JS, который вернет список. Во втором это HTML с кастомными атрибутами.

        Скажете, что не слишком явное преимущество? А если нужно в каждый компонент передать разные props и еще и вычислять их по разному для каждого компонента?

        React удобен тем, что он простой как помидор. Vue напоминает первый Ангуляр без DI и с некоторыми упрощениями, но не более того. Сначала все радуются, потом начнут с ним бороться.


        1. taujavarob
          28.07.2017 20:56
          -1

          Akuma

          React удобен тем, что он простой как помидор. Vue напоминает первый Ангуляр без DI и с некоторыми упрощениями, но не более того. Сначала все радуются, потом начнут с ним бороться.
          Читаю в коментах через строку и так понимаю сам себе:
          • React простой как помидор, Vue простой но эта та простота что хуже ...
          • React сложен, — вот Vue простой.
          • React простой как помидор, Vue простой но эта та простота что хуже ...
          • React сложен, — вот Vue простой.
          • ...


          Простота хуже воровства — это мнение стороны, пострадавшей от этой простоты, и некого обвинить, и некому предъявить. То есть, если тебя ограбили, ты можешь обратиться в суд, и, возможно, вернешь украденное, а если сам сдуру отдал? А если кто-то тебя подставил по простоте своей? ( взято на просторах инета)


        1. TimTowdy
          28.07.2017 21:53

          Рендеринг списка динамических компонентов это стандартная задача, и во Vue уже есть готовое решение. Вам не нужно решать каждую проблему написанием JS — подавляющая часть проблем уже решены.

          Вот как на самом деле будет выглядеть рендеринг списка динамических компонентов (пишу по памяти т.к. я не фронтэндщик):

          <component v-for="item in list" :is="item.type">
          


          Видите разницу? В вашем случае, чтоб понять что рендерится динамический компонент нужно прочитать несколько строк JS перемешанного с html.
          В случае DSL от Vue сразу видно что происходит. Никаких swtich/case/return <JSX>. Одна строка.Этим он и подкупает — ментальная нагрузка на разработчика гораздо ниже.


          1. Akuma
            28.07.2017 22:07
            +5

            Эм. Вот я далеко не первый год в веб-разработке и с ходу я не скажу, что делает ваш код.
            Даже при том, что я очень активно использовал Angular 1 когда тот появился.

            Он возьмет имя компонента из item.type? Т.е. оно должно 100% совпадать.
            Что будет, если не совпадет?
            Как мне передать props в эти компоненты?
            «Какие» компоненты он будет использовать?
            IDE покажет использование этих компонентов этим кодом?
            Как мне скрыть некоторые компоненты в зависимости от props?

            И я не прикалываюсь. Реально при многолетнем опыте я не знаю как это сделать на Vue без чтения документации. А вот как это сделать на JS — поймет даже школьник.
            Это все болячки первого Ангуляра, я еще раз повторюсь.

            Vue этим подкупает, согласен. Если выучить синтаксис конечно. Но потом вы начнете бороться с фреймворком, т.к. Vue не позволяет «ходить на лево».

            У React безусловно тоже есть свои болячки, но они обычно связаны со сторонними библиотеками. А «чистый» React полностью выполняет свои задачи.


            1. TimTowdy
              28.07.2017 23:36
              +2

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

              Ваш пример как раз очень наглядный: Vue-разработчику, для того чтоб понять что рендерится динамический компонент достаточно увидеть :is. Потому что для типовой задачи сделали типовое решение. А вот в случае React придется прочитать кучу (по сравнению с 3 символами) кода: вызов map(), стрелочная функция, switch/return… Более того, дайте эту задачу трем реакт-разработчикам, и они выдадут три РАЗНЫХ решения (вы сделали map, кто-то сделает функцию с for, кто-то заведет отдельный object с маппингом имени в компонент...). В случае с React у вас всегда будет JS, который разные разработчики напишут по-разному. А иногда даже один и тот же разработчик напишет это по-разному в зависимости от настроения или понимания (например для трех компонентов сделает switch, а для 20 — отдельный объект).

              В этом большая проблема современного фронтэнда — любую задачу вы привыкли решать написанием нового JS-кода. Когда у вас есть только молоток, вам везде мерещатся гвозди.

              Он возьмет имя компонента из item.type? Т.е. оно должно 100% совпадать.

              Да. Точно также как оно должно на 100% совпадать в вашем <ComponentOne />. Только у вас теперь еще неявное отображение "one" -> ComponentOne, которое тоже нужно держать в голове, увеличивая ментальную нагрузку.

              Как мне передать props в эти компоненты?

              Динамические props? Элементарно:
              <component v-bind="item.props">
              

              А что в React? Опять куча JS?

              «Какие» компоненты он будет использовать?
              Насколько я понимаю (пусть знатоки поправят, если ошибаюсь), либо глобальные, либо заданные в родительском компоненте, если вы хотите ограничить их набор. Опять-таки Vue выигрывает: типовая задача «ограничить доступные родительскому компоненты» во Vue уже решена: компонент может принимать набор доступных ему дочерних компонентов. А что в React? Опять кастомный JS, который разные разработчики напишут по-разному?

              IDE покажет использование этих компонентов этим кодом?
              Не понял вопрос. Но если честно, аргумент насчет IDE всегда слаб. Когда-то IDE и JSX не отображали. Кому нужно — тот настроит. В случае с Vue, насколько я знаю, настраивать обычно приходится меньше.

              Как мне скрыть некоторые компоненты в зависимости от props?
              Если «скрыть» — это поведение компонента, то возможно его стоит вынести в сам компонент.
              Ну, а для простых случаев есть директива v-show (либо v-if, если компонент нужно не скрыть, а вообще не создавать):
              <component v-show="item.isVisible">
              


              Видите в чем прелесть? Вы сейчас спрашиваете как решить какие-то стандартные задачи, и во Vue они уже решены. Ответы в документации, а не на stackoverflow. И решение одно, и с ним уже знакомы все разработчики. Вам не нужно выбирать из десятка модулей, а потом объяснять каждому новому члену команды как на вашем проекте задаются стили компонентов, и почему это отличается от того, что он делал в другой компании.


              1. indestructable
                29.07.2017 00:45

                Что может быть стандартнее Javascript на фронте? Уж точно не DSL Vue.


                1. raveclassic
                  29.07.2017 01:04
                  +1

                  Я уже молчу про годами складывающиеся функциональные паттерны (а мы понимаем, что реакт со всей своей декларативностью это про фп). Компоновка интерфейса следует знакомым и понятным законам. Компоненты высшего порядка, букет всевозможных Maybe/Either, совершенно другой уровень абстракции, совершенно другой уровень переиспользуемости.


                1. TimTowdy
                  29.07.2017 01:38

                  Вы немного путаете контекст. «Стандартность» JS на фронте нужна браузерам, т.е. среде исполнения. Но никак не программистам. Им этот «стандарт» нужно читать, а не исполнять. И читать всегда проще именно DSL. В конце концов, именно для этого DSL и создаются.

                  Стандарт — это не просто «один язык, один фреймворк, один фюрер». Стандарт — это в первую очередь ограничения. И строгий DSL как раз эти ограничения задает. В отличие от динамического JS, который наоборот, дает слишком большую свободу.

                  К сожалению Javascript/React никак не способствуют написанию кода в стиле «There should be one-- and preferably only one --obvious way to do it». Поэтому ваша абстрактная «стандартность» разбивается о реальность разработки.

                  Пример: во Vue один способ вывести список компонентов: директива v-for. А знаете сколько различных способов вывода списка компонентов я видел в React? Пальцев рук не хватит, чтоб посчитать.


                  1. Akuma
                    29.07.2017 09:12

                    А знаете сколько различных способов вывода списка компонентов я видел в React?

                    Ммм… один? Отдать массив компонентов. Это такой стандартный элемент JS со времен динозавров. Его все знают и не нужно читать документацию :)


                    1. TimTowdy
                      29.07.2017 12:01
                      +2

                      Возьмите 10 разработчиков, попросите каждого написать код, который выведет список компонентов, и сравните результаты. Везде «отдать массив компонентов» будет сделано по-разному. for, for of, map, _.each, стрелочные функции vs обычные, итерация внутри JSX либо снаружи… Нет, вы конечно во всем этом разберетесь довольно быстро, в конце концов это просто генерация массива. Но ментальная нагрузка будет выше.

                      Честно, я не понимаю зачем вы спорите. Хороший DSL всегда проще читать чем GPL. React-сообщество почему-то категорически отрицает разметку как отдельную область, аргументируя это тем, что в 201х году нельзя не знать JS, поэтому разметка через JS это ок. Не ок. Подход «все — джаваскрипт» конечно можно проглотить. Но подход «мухи отдельно, котлеты отдельно» работает лучше.

                      Реакт, продавая реактивность, VirtualDOM и UI as a function of state незаметно подсунул всем JSX. Многие проглотили, и даже сказали что им нравится. В общем-то тут не было злого умысла: фокусируясь на VirtualDOM в 2013 году, придумать JSX было хорошим решением. JSX действительно улучшал читаемость. Vue (в текущем его виде), тогда был просто невозможен.

                      Но сейчас не 2013 год. И Vue, и React реализуют идею "UI is a function of state". Вот только и UI, и state во Vue сделаны лучше. Это очевидно каждому, кто сравнивает эти две библиотеки.

                      Попробуйте задуматься, кто быстрее разберется: Vue-разработчик в чужом Vue коде, или React-разработчик в чужом React коде? На мой взгляд, это должно быть основным критерием выбора библиотеки в 2017 году. И Vue здесь однозначно побеждает.


                      1. VolCh
                        29.07.2017 14:18

                        Как по мне, то именно сейчас во фронтенде основным критерием должна быть скорость, с которой незнакомый с фреймворком разработчик сможет выполнять реальные задачи в проекте, где он уже есть.


                        1. TimTowdy
                          29.07.2017 15:25

                          Не согласен.
                          Проекты ведь не две недели длятся. Время знакомства с фреймворком обычно на порядки меньше, чем длительность участия разработчика в проекте. Грубо говоря, 1% времени разработчик не знаком с фреймворком, 99% времени — знаком. Мне важно насколько эффективен разработчик (и команда в целом) будет в течение этих 99%.
                          Ваш критерий, мне кажется, применим только если у вас жуткая текучка кадров.


                          1. VolCh
                            29.07.2017 16:28

                            По разному длятся. И не текучка может быть в привычном смысле, а ротация по проектам (вариант — эпикам) на разных стэках внутри одной компании. И я даже не про аутсорс.


                            1. TimTowdy
                              30.07.2017 17:39

                              Если уж и брать ваш критерий, то сравнение Vue vs React явно будет не в пользу последнего.
                              Не зная фреймворк, и Vue и React код разработчику будет казаться сплошной магией.
                              Но Vue можно освоить за пару часов, в отличие от React. Это на самом деле очень показательно, учитывая что большая часть концепций у Vue и React одинаковые.


                      1. Akuma
                        31.07.2017 00:17

                        Я вроде и не спорю :) Давайте тогда на этом остановимся. Выбор фрейморка в какой-то степени дело вкуса. Vue — на мой вкус не очень, т.к. я сбежал от первого Angular. Возможно именно это дает свой отголосок.


          1. indestructable
            29.07.2017 01:01
            +2

            Это все проходили во времена первого Ангуляра. На нем легко писать простые приложения, но очень сложно писать сложные вещи и библиотеки.


            Попробуйте написать хороший drag and drop, хороший грид (с настраиваемыми ячейками, редактированием, заголовками и т.д.).На реакте это написать довольно легко (с учетом, конечно сложности самого решения) — Реакт не будет мешать, а будет только помогать — всей мощью Джаваскрипта.


            На Vue вы будете бороться с шаблонизатором — я это понял, как только прочитал про "слоты", которые, как я понимаю, являются аналогом трансклюдов Ангуляра.


            В реакте у вас нет слотов, а есть функции и объекты, из которых вы можете создавать другие функции и другие объекты. Поэтому в Ангуляре (да и скорее всего в Вью) никогда не будет, например, декораторов для компонентов, при помощи которых можно сделать, например, редактирование по маске для любого input, даже из third-party component set.


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


            1. indestructable
              29.07.2017 01:19

              Посмотрите, как сделаны гриды для первого Ангуляра, тот же Кендо. Там компонентностью и не пахнет даже. Огромный объект конфигурации, строковые шаблоны на DSL шаблонов от Кендо, это просто страх и ненависть. И по-другому не сделаешь.


              Есть ли во Вью какой-нибудь прогресс с этим?


              1. DarthVictor
                30.07.2017 02:16
                +1

                Справедливости ради гриды от кендо написаны на чистом jQuery, для AngularJS там только обертка. Что не мешает им быть функциональнее абсолютно всех гридов для ангуляра / реакта, а также рискну предположить, что и для Vue.js/Elm/любой фреймворкнейм


            1. rboots
              29.07.2017 02:11
              +2

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


            1. TheShock
              29.07.2017 03:24

              На реакте это написать довольно легко (с учетом, конечно сложности самого решения) — Реакт не будет мешать, а будет только помогать — всей мощью Джаваскрипта.

              Иронично, но я не видел на современных фреймворках (ни в одном) такие же клевые штуки, которые столь же легко подключались бы, как возможности, например JQuery UI. Тот же select в Реакте значительно хуже, чем в JQuery UI.


              1. vintage
                29.07.2017 07:59
                +1

                Тот же select в Реакте значительно хуже, чем в JQuery UI.

                Чем именно хуже?


                1. TheShock
                  29.07.2017 10:54
                  -1

                  Признаюсь честно — не помню. Вы пользовались и тем и другим?


                  1. vintage
                    29.07.2017 14:07

                    Нет, мы пилим своё решение. Вот и интересуюсь, что именно вам не хватает в существующих.


            1. s256
              29.07.2017 09:38
              +1

              Я сейчас скажу страшное — в Vue тоже есть render-функции и тоже можно использовать vanilla.js для написания чистых компонентов. То есть вы в праве не использовать шаблонизатор и если возникает потребность в действительно сложной логике — на Vue это можно сделать в React-like стиле.


              1. raveclassic
                29.07.2017 12:16
                -1

                Ну и зачем тогда vue?


                1. Fragster
                  31.07.2017 11:41

                  потому что в 99.753% случаев эти рендер функции не нужны?


            1. denismaster
              29.07.2017 09:46

              https://github.com/eastbanctechru/right-angled
              Очень удобный грид(список) для ангуляра(4) Работает на директивах и нескольких компонентах(по сути управляют отображением). Разметка любая может быть.

              Что касается кастомных атрибутов, то они очень даже пригождаются. Например, когда вижу в коде подобное:

              <input type="text" xrm-datepicker />
              

              То сразу становится понятно, что передо мной компонент для выбора даты.
              А вот другой пример кода, который управляет отображением:
              <div class="panel panel-default" *xrm-role-admin>...</div>
              

              И сразу видно, что здесь добавляем дополнительный атрибут — и блок отображается только, если роль пользователя «администратор».

              Редактирование по маске?) Можете рассказать подробно, зачем вообще такая задача?)
              Но, в любом случае, можно написать директиву, которая берет first или third-party input-ы, которые являются детьми блока, к которой директива применяется, после чего их функция writeValue(интерфес ControlValueAccessor, реализуется чем угодно и всеми стандартными инпутами) декорируется с учетом маски и логики редактирования. А разметка остается та же.


            1. alek0585
              30.07.2017 17:13

              Покажите, пожалуйста, хорошую библиотеку drag-n-drop на vue. Которая была бы не оберткой над другой библиотекой.


        1. zenkz
          28.07.2017 22:30
          +1

          Спасибо. Своим комментарием вы только что меня убедили, что Vue.js удобнее реакта.

          То, что на реакте занимает 7 строчек js-кода, в которые нужно вчитаться и понять что там происходит, на Vue решается простейшим и понятным аттрибутом.

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


        1. rboots
          28.07.2017 22:48
          -3

          С React без JSX, если честно, возникала мысль: «А какую ценность он вообще добавляет?», так как эти React.createElement очень напоминают просто обёртку над document.createElement с небольшим API для установки атрибутов и вложенности, которая пишется за 50 строчек. Ценность как раз и состоит в DSL, но JSX во-первых очень самобытный и не совместимый ни с какими другими DSL, а во-вторых очень сложно извлекается из React. А главная проблема всей этой конструкции, вместе или по отдельности — сильная связанность всего со всем. Ощущение будто его просто выдрали из реального проекта с многолетней историей и даже не стали особо рефакторить. Писать на JavaScript я и на VanillaJS могу, и это не такой уж плохой путь, кстати. Он ещё проще. А React слишком много всего просит за ту простоту функционала, или скажете у него низкий порог входа?
          Vue добавляет сложности, но самую малость, не больше чем обычная библиотека. Шаблоны там стандартные, знакомые ещё с Angular, Knockout и похожие на многие серверные. А самое главное он эффективно отделяет логику от представления, шаблон можно целиком переверстать не затрагивая основную логику, можно начать разработку до этапа дизайна, просто по ТЗ, и заранее иметь готовую логику, можно органично проводить А/В тесты, опять же не трогая основной код. Много чего можно, что с концепцией «всё в js» становится сложнее. HTML это отличный инструмент для создания View и не нужно от него отказываться.


          1. Akuma
            28.07.2017 23:22
            +6

            React предоставляет быстрый рендеринг за счет сравнения DOM в памяти + shouldComponentUpdate. Это шаблонизатор и ничего более.

            JSX и не должен быть совместим с чем-то другим. Он создавался для React и нечего его использовать отдельно. Впрочем, там «нового» ничего и нет, лишь пара фигурных скобок. Остальное HTML и JS.

            Где вы видели шаблонизатор из которого потом нужно что-то извлекать? Это маразм. Хватит. Вы пишите шаблон под конкретный шаблонизатор. Всегда, везде и в любом языке.

            Да, его выдрали из ядра Facebook, по сути. И у них это неплохо получилось.

            Да, у него низкий порог входа. Куда ниже чем у Vue. Потому что react — шаблонизатор, а не фреймворк.
            Кстати Babel вы все равно будете использовать ради ES6, а если нет, то продолжайте мучить себя.

            Зачем отделять логику шаблона от самого шаблона? Где вы нахватались этих «умных» выражений про отделение логики? Логика шаблона — это не логика приложения. А если вы всю логику приложения пихаете в React компонент, то либо делайте это осознано, либо не делайте вообще, либо не жалуйстесь. v-if это тоже логика, давайте ее выделим в отдельную библиотеку?

            И все же, давайте вернемся у статье: в чем преимущества и уникальность Vue? В статье лишь избитый Todo-list, который скоро встроят в Хром и он будет запускаться просто тегом <todo-list />, т.к. уже всех достал.

            Некоторые пишут про некие «слоты». Я уверен, у Vue есть и другие уникальные фичи, которые будут интересны. Я не пытаюсь холиварить о том, что лучше, я пытаюсь выяснить что умеет Vue. В документации я не нашел дял себя ничего интересного, а лишь переделанный Angular 1 от которого убежал давным-давно.


            1. rboots
              29.07.2017 01:54
              +2

              Я «нахватался» этого из 15-тилетней практики, это сильно облегчает работу и если вы этого не используете — вы себя обкрадываете. Да, он очень похож на Angular 1, с той разницей, что сделан по человечески, скоупы изолированны, отладка стала информативной, производительность выше. Из нового появились custom controls, которые для реакта не новость и вообще тренд последние 7 лет, но наконец их сделали удобными, совместив синтаксис а-ля polymer, который а-ля нативный, с шаблонизацией через свойства html. Это значит, что когда поддержка нативных custom controls станет мейнстриомо в браузерах — от половины Vue можно будет избавиться, либо она будет работать с бешеной производительностью на нативном рендеринге, да и все другие фреймворки будут двигаться в этом направлении. Решение от Facebook неплохое, но не живучее, о нём забудут так же, как забыли про ExtJS, который предлагал много всего хорошего, но не стал доминирующим, так как сильно отличался от стандартов. Я привожу эти аргументы, так как бесполезно спорить что лучше, шаблоны в js или html, у каждого свои вкусы. Но W3 решили, что нативные custom controls будут на шаблонах в html, а поддержки jsx в браузерах нет даже в проекте. Vue по сути придумали очень мало нового, они как и jQuery, как и babel, как и polymer, просто ускорили будущее.
              Про низкий порог входа React, это иллюзия вследствие большого опыта, видимо. Для меня, например, чистый JavaScript проще любых фреймворков, но 90% программистов так не считают, видимо они правы и это просто деформация от долгого использования. Общепринято, что React осваивается тяжелее, я например первые 2 недели только и и делал, что гуглил проблемы. А Vue до практического уровня освоился за 2 часа, правда после polymer и angular, у которых он многое взял.
              Про уникальные фичи, всё придумано до нас, и вряд ли найдётся что-то совсем революционное. Мой тезис про другое, они просто сделали работу с UI простой и удобной, ориентируясь не на субъективное мнение, а на стандарты отрасли и сильные стороны JavaScript. React, на мой взгляд, создавали люди, у которых первый язык был всё таки не JavaScript, отсюда эта любовь к классам где надо и не надо и прочему, без чего серверники жить не могут. Только JavaScript гораздо глубже и богаче, почему классы, а, например, не монады? Концепция ничем не хуже, весь jQuery на них построен, express активно применяет, а React — нет, потому что его создатели, хоть и талантливые, но JavaScript знают поверхностно.
              А babel я применять не буду, синтаксического сахара не так много даёт. Единственное что хочется использовать это async await, но под Node он уже и так доступен, а в браузере вот-вот начнёт быть мейнстримом, пока промисов хватает.


              1. raveclassic
                29.07.2017 12:24

                любовь к классам где надо и не надо и прочему,

                SFC?


                почему классы, а, например, не монады?

                Теплое и мягкое? При чем тут монады?


                потому что его создатели, хоть и талантливые, но JavaScript знают поверхностно.

                Потрясающее заявление!


                А babel я применять не буду, синтаксического сахара не так много даёт.

                Вы ишака поддерживаете?


          1. staticlab
            29.07.2017 01:16

            React.createElement очень напоминают просто обёртку над document.createElement с небольшим API для установки атрибутов и вложенности, которая пишется за 50 строчек.

            Да, на первый взгляд так и кажется. А затем попробуйте вывести массив элементов как в v-for, поменяйте местами любые два элемента массива и добейтесь минимального обновления DOM в 50 строчек.


            1. rboots
              29.07.2017 02:00
              -4

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

              parentNode.insertBefore(movingNode, prevNode)
              

              Вот, аж одна строчка, и с минимальными обновлениями DOM.


              1. staticlab
                29.07.2017 11:49

                Только вы забыли найти movingNode и prevNode


                1. raveclassic
                  29.07.2017 12:24

                  Еще и с RAF синхронизироваться


        1. Virviil
          29.07.2017 16:33

          Во Vue можно писать на JSX. А можно писать на html с атрибутами. Чтобы "побороть" Vue надо написать компонент на JSX. Зато если не надо бороть — можно не писать на JSX.
          Поэтому компонент Table пишем на JSX, а компонент SignInUp пишем на атрибутах.
          В результате лэйаут может сделать верстальщик (то самое рекламируемое преимущество ангуляра), а компоненты вроде d3 графиков или всплывающих от вебсокета нотификаций — программист.


          И в отличие от Ангуляра, у Vue под капотом тот самый "простой как помидор" реактивный рендер цикл. Просто его присыпали "ангулярным" сахарком, и ещё сделали быстроразвёртываемое дев-окружение.
          И пользуясь полученным опытом расширили redux наработанными essentials вроде thunk — получили vuex.


          Так что vue — это причёсанный react. В котором с помошью сахара можно "писать в стиле ангуляр".


        1. JSmitty
          29.07.2017 21:08

          Ой, классный пример, спасибо. Прелесть современного Vue.js в том, что он умеет и JSX тоже (и той же ценой). И именно ваш пример (рендер компонента в зависимости от типа в массиве объектов) в одном из проектов именно через JSX на Vue.js реализовывали. Да, это проще, чем городить огород из условного рендеринга в шаблоне или использовать ":is". Логика более очевидная.

          Vue.js 2+ позволяет писать компоненты с рендер-функцией, ровно как в React, и поддерживает как JSX, так и нативный интерфейс для создания объектов vnode для Virtual DOM.


          1. raveclassic
            29.07.2017 21:11
            -1

            Но если вы на vue пишете как на реакте, то зачем тогда vue?


            1. JSmitty
              30.07.2017 09:18

              Понимаете, он позволяет писать низкоуровнево, но не принуждает к этому. Есть выбор — привычно/удобно так — пиши как нравится, никто не принуждает.

              Это существенный плюс, когда в команде есть люди, знакомые с HTML и слабо знающие JS — то синтаксис темплейтов им ближе, чем типовые конструкции React() для достижения того же.
              Наши пара проектов (большие и долгосрочные) на Vue.js используют в основном темплейты, но в паре критичных мест используются напрямую рендер-функции.

              И потом, стоит понимать, что внутри себя Vue.js 2 компилирует темплейты в рендер-функции. Этот механизм также доступен через API. Т.е. для Vue.js 2 темплейты — это сахар поверх рендер функций, и кмк не особо проблематично сделать аналог для реакта (а, может быть, он уже и существует).

              Опять же, с точки зрения использования — магия отслеживания изменений во Vue.js проще в использовании, чем работа с состоянием в React — никаких this.setState() или dispatch(). По мере роста приложения это достоинство нивелируется, но на старте оно сильно облегчает вход (буду откровенен, местами эта магия встает-таки поперек горла).


      1. vintage
        29.07.2017 10:54
        -2

        Вот за что я не люблю html шаблоны — в них зачастую очень сложно проследить намерения. Семантики не хватает и разработчики фигачат кто во что горазд. Я попробовал переписать ваш код на $mol, надеюсь правильно угадал всю скрытую семантику.


        report.view.tree
        $my_test_business_report $mol_list
            test_id     test_link_pattern \http://example.org/test.html#/link/{id}
            sub /
                <= Candidate $my_card
                    title <= candidate_title @ \Candidate
                    content /
                        <= Candidate $mol_row
                            sub /
                                <= Name $my_report_param
                                    title <= name_label @ \Full name
                                    value <= name                         <= Vacancy $my_report_param
                                    title <= vacancy_label @ \Vacancy
                                    value <= vacancy                         <= Phone $my_report_param
                                    title <= phone_label @ \Phone
                                    value <= phone                         <= Mail $my_report_param
                                    title <= mail_label @ \E-mail
                                    value <= mail                         <= Comment $my_report_param
                                    title <= comment_label @ \Comment
                                    value <= comment         <= Results $my_card
                    title <= results_title @ \Test Results
                    content /
                        <= metrics /
                        <= Beta $mol_row
                            sub / 
                                <= Print $mol_button_minor
                                    event_click?val <=> event_print?val null
                                <= Science $mol_link
                                    title @ <= science_title \Science report
                                    arg *
                                        test_science_result <= test_id -
                <= Results_empty $my_card
                    title <= results_empty_title             content <= Test_link $my_copycode
                        title <= test_link_title @ \Link to test
                        value <= test_link     -
            Metric!id $mol_labeler
                title <= metric_title!id         content /
                    <= $mol_portion
                        portion <= metric_portion 0


        1. bano-notit
          31.07.2017 01:34
          +1

          Ну здрасте) Опять вы со своим $mol мелькаете в глазах...


          1. vintage
            31.07.2017 09:07

            А когда люди со своим Реактом мелькают в глазах — вас не смущает?


            1. Odrin
              31.07.2017 11:20

              От чтения React кода хотя бы не вытекают глаза.


              1. vintage
                31.07.2017 11:23

                Почитайте комментарии в этой теме — у многих вытекают.


            1. bano-notit
              31.07.2017 17:07
              +1

              Честно? Смущает. Но у них хотя бы ники разные, а Вы один такой неповторимый)


      1. raveclassic
        31.07.2017 20:09

        del


    1. xlenz
      29.07.2017 00:24
      +1

      Лично мне vue.js понравился тем, что проще реакта и ангулара на средних приложений.


      Во времена ангулара 1, мне он нравился, потом перешёл на реакт, понравилось больше. Не так давно попробовал ангулар 2 и вернулся на реакт. А потом, без энтузиазма, попробовал vue.js и мне очень понравилось.
      За счёт каких-то определённых вещей не скажу, понравилось всё в целом, отсутствие боли, как с другими фреймворками.
      Фреймворк не идеален, просто хотел поделиться впечатлением. Пока остаюсь с vue.js.


  1. raveclassic
    28.07.2017 19:36

    del


  1. ju5tify
    28.07.2017 20:19
    -11

    Vue.js > Angular > Говно > Моча > React


    1. Sirion
      29.07.2017 20:20

      Вы чудовищно неправы, моча лучше говна.


      1. raveclassic
        29.07.2017 20:28
        +2

        может просто поменять > на <?


  1. Metus
    28.07.2017 20:44
    +1

    Скажите пожалуйста, а ember мёртв?


    1. grimalschi
      28.07.2017 21:32

      Жив, но фокус сместился сначала на Angular, потом на React. Сейчас вот Vue мелькает все чаще.

      В «тренде» виртуальный DOM, его использует и React и Vue, и многие новые библиотеки (Preact, Inferno, Snabbdom, Mithril...).


      1. s-kozlov
        29.07.2017 09:45
        +1

        фокус сместился


        Как странно вы пишете слово «хайп».


    1. prostofilya
      29.07.2017 11:02
      +1

      Да нет, помаленьку развивается, вроде как собираются переходить на модульную основу, хотите роуты — качайте эмбер-роут, хотите модели — качайте эмбер дату. Помаленьку развивается движок glimmer, он вроде не такой шустрый как fiber, но на месте не стоит. Оптимизируют, худеет помаленьку. У авторов есть roadmap на офсайте, бросать не собираются.


  1. alist
    28.07.2017 21:38
    +9

    Отпишусь.


    Используем Vue в продакшене, начали с 1.0.x, планировали перейти на 2.0, но сразу же переход сделать времени не было — и хорошо: вышел 2.2, который по честному нужно было бы назвать 3.0, отличий много. Недавно таки перевели приложение на 2.4.


    В целом фреймворк действительно очень хороший, приятный в использовании. Недостаток — сторонние библиотеки и плагины. Те, что пишутся командой самого Vue — vue-router, vuex, и тд — отличные, все там хорошо. А вот шаг вправо — шаг влево, и все становится грустно.


    Мы взяли одну библиотеку компонентов — Keen UI, которая прошлым летом была супер-популярной и по фичам обгоняла все остальные так, что народ сворачивал свои проекты и шел контрибьютить туда. И буквально на первых же контролах оказалось, что Keen то не умеет, этого не умеет, мы стали компоненты расширять, баги исправлять, засылали пул-реквесты и тд. Какие-то принимали быстро, какие-то медленно. В общем, как обычно. Но проблема и Keen, и других UI-библиотек под Vue, что пишут их реально криво. В самом Vue есть слоты из Web Components, про которые уже выше упоминали, но по факту ребята-авторы видимо пришли с Реакта или других фреймворков, где такого API нет, и им почти не пользуются. И на каждый чих вместо того чтобы просто расширить компонент слотами, приходиться форкать, допиливать и засылать пулреквесты, которые тоже народ не торопится принимать, тк часто доработки довольно специфичные, и никому почем зря раздувать API компонента не хочется.


    Ну а сейчас Keen UI заглох — последний коммит в январе, а все остальные библиотеки компонентов либо только-только начинают, либо пишутся китайцами для сингапурцев, и чуть что доки и коммиты на мандарине, и когда вопрос задаешь, тебе никто толком ответить не может.


    В результате у нас как почти у всех — свои кастомные UI-элементы. И Вот кажется, что вот он прогресс — Angular, React, Vue, так сильно фронтенд скакнул со времен IE6 и jQuery, — а на деле сидим мы в 2017 году и как лохи делаем свои списки, аккордеоны и модалки.


    1. serf
      28.07.2017 22:09

      Vuestrap ?


    1. negasus
      28.07.2017 22:14

      http://element.eleme.io/ не пробовали? Интересно мнение


      1. xlenz
        29.07.2017 01:09

        Пробовал vue-bulma, тоже что и с keen. Сейчас вот начал работать с элемент, пока не могу ответить однозначно.


      1. s256
        29.07.2017 09:29
        +2

        Использовал для написания навороченной админки — в целом впечатления очень положительные. Да над некоторыми компонентами приходится посидеть с напильником, но в целом очень и очень не плохо


    1. Fragster
      31.07.2017 11:50

      http://bootstrap-vue.js.org/ пилится активно, к выходу 4 бутстрапа. не всё мне нравится, например то, что они сделали с table. Но в остальном — терпимо.


  1. teux
    28.07.2017 22:14
    +5

    Год назад узнал про Vue, почитал и понял, что он должен быть.
    Хотя посыл статьи не разделяю (личные симпатии выдаются за реальное состояние) и сам надеюсь никогда на vue не писать, но…


    Технологии фронта очень резко развернулись. Не буду детализировать в какую сторону, суть не в этом. Главное, есть много людей, которых jQuery приучил к плагинам, а фреймворки типа Angular 1, Marionette, Ext, Knockout и пр. – к паттерну MVC.


    На мой взгляд, для этих людей подходы React/Redux с фактическим отрицанием MVC кажутся непривычными и неудобными. Однако пользу от виртуального дома они хотят получать. И что греха таить, действительно полноценная экосистема React очень сложна. Angular не сильно проще, да еще и "вещь в себе".


    Так в нише между React и Angular появился Vue. Он и с виртуальным домом, и с привычным MVC, и не сильно сложный. Такая буферная зона для небольших проектов, или на период изучения React, или просто чтобы не забивать голову "ерундой". Не думаю, что у него есть шансы сравниться с React, но почитателей он должен был найти.


    1. vintage
      29.07.2017 07:42
      +2

      React/Redux с фактическим отрицанием MVC

      image


      image


      1. teux
        29.07.2017 07:55
        -1

        Fluxxor такой источник непререкаемой информации ) Давайте посмотрим на более авторитетный источник


        image


        Здесь есть связь store > view, но нет store < view


        1. vintage
          29.07.2017 08:15
          +1

          В редаксе эта связь есть (mapStateToProps). В любом случае до "фактического отрицания" тут как до луны.


          1. teux
            29.07.2017 08:21

            А поконкретнее, пожалуйста. Что есть mapStateToProps? В какую сторону эта связь?


            1. vintage
              29.07.2017 08:28

              1. teux
                29.07.2017 08:54
                +1

                Ну так не интересно. Я ожидал аргументацию вокруг заведомо ложного тезиса )


                mapStateToProps, как следует из названия, передает данные о состоянии приложения (хранится в store) в props компонента. То есть это связь store > view


                Вроде мелочь, есть ли обратная связь или нет. Но это то, почему загнулся (т.е. не популярен) упомянутый fluxxor, иже с ним reflux и прочие ранние реализации flux, цеплявшиеся за паттерн MVC.


                В отсутствии прямой связи store < view приложение вынужденно превращается в систему обмена сообщениями. По сути, передача Action в store через dispatch это и есть отправка сообщения тому редьюсеру, который может сообщение обработать.


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


                Либо в случае react/redux компонент реализует некую событийную модель. Он просто отправляет сообщения "у меня произошло то или другое событие". А потом получает из стора обновленные данные.


                1. TheShock
                  29.07.2017 10:53
                  -1

                  View запрашивает данные у Store, а не Store решает, какие данные передать View, вот о чем эта стрелочка на диаграмме.

                  Флакс — самый обычный MVC, но в силу целевой аудитории переименовал понятия, иначе кто бы захотел пользоваться мерзкими корпоративными подходами?

                  Даже я писал по MVC односторонние потоки за пару лет до фласка, что уж говорить о значительно более умных людях?


                  1. teux
                    29.07.2017 11:05

                    View запрашивает данные у Store, а не Store решает, какие данные передать View

                    Протест ) Понятие "запрашивает" означает действие. У действия есть инициатор, и в вашей схеме это view. По факту в Redux все наоборот: view ничего не запрашивает, а только отправляет сообщения о событиях в Redux. Потому во флаксе нет обратной стрелочки.


                    Флакс — самый обычный MVC...

                    Тогда давайте подведем под MVC и паттерн глобального неймспейса. В нем можно нарисовать те же стрелочки. Вьюха пишет данные в window.MyStore и читает оттуда же. Чем не MVC? Нет контроллера? Так долго ли вынести пару функций из вьюхи в отдельный модуль.


                  1. teux
                    29.07.2017 11:08

                    Не знаю, есть ли правильно название у паттерна redux. Я бы охарактеризовал его как "глобальное хранилище с общей шиной сообщений". Это не сильно похоже на MVC


                    1. staticlab
                      29.07.2017 11:58

                      Конечный автомат же


              1. teux
                29.07.2017 09:12

                В принципе, в паттерне MVC модель тоже может слушать события на вьюхе. Но есть у MVC другие негативные черты.


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


                Во-вторых, чтобы собрать состояние приложения, надо свести данные всех инстанов всех моделей. Это практически непосильная задача. Кто работал c Redux DevTools, тот понимает удовольствие, когда состояние приложения как на ладони.


                В-третьих, рано или поздно возникает необходимость обмениваться данными между моделями. Тут сразу две проблемы:


                1. Как это делать? Передавать ли ссылку на инстанс модели в другую модель (возникает жесткая связанность компонентов). Использовать ли общую шину типа pubsub (связанности нет но взаимодействие непрозрачно).
                2. Менять данные в чужой модели напрямую или через ее хендлеры событий. А вдруг события чужой модели не подходят для этой вьюхи? А прямые изменения — это неконтролируемые хаки.

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


                Vue от MVC-подхода не ушел. Поэтому, на мой взгляд, это нишевый продукт для маленьких проектов.


                1. Riim
                  29.07.2017 09:55

                  У вас какое-то очень странное понимание MVC (ну или у меня). Модель слушающая события въюхи, бизнес логика распределяемая между моделью и въюхой, обмен данными между моделями и тд., видимо меня всю жизнь обманывали рассказывая про какой-то другой MVC.


                  1. teux
                    29.07.2017 10:17

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


                    Это еще одна проблема MVC: в многообразии его трактовок можно потеряться.


                    1. Riim
                      29.07.2017 10:30

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


                      1. teux
                        29.07.2017 10:42

                        Возможно. Но такой поворот дискуссии — это разговор "в пользу бедных". Или вы демонстрируете свой единственно правильный взгляд на MVC и мы приходим к чему-то общему, или нет смысла продолжать.


                        При обилии спецификаций MVC понимание зависит от опыта применения. У меня он в целом негативный, причем не на одном фреймворке. Проблемы встречал одни и те же, о чем и написал.


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


                        1. Riim
                          29.07.2017 11:11

                          Или вы демонстрируете свой единственно правильный взгляд на MVC

                          мой взгляд полностью совпадает с общепринятым.


                          Проблемы встречал одни и те же, о чем и написал

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


                          1. teux
                            29.07.2017 11:35

                            Скажем вы решаете проблему обмена данными между инстансами модели, но зачем?

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


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


                            Значит надо подключить существующие инстансы к этой вьюхе, значит делать хранилище инстансов.


                            А если капризная вьюха начнет менять данные в общих моделях, останутся ли данные консистентными для других вьюх?


                            А если другие вьюхи отмонтированы и делают destroy моделей, что произойдет с остальными вьюхами, подключеным к тем же инстансам?


                            А если вьюха не дестроит модель, то кто это делает?


                            А если вьюха отмонтирована, снова подмонтирована, получила живой инстанс модели и пытается провести начальную инициализацию...


                            … если, если. И получается безопаснее не переиспользовать инстансы моделей.


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


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


                            Вы скажете "Так ведь можно попросить бек сделать подходящий эндпоинт для капризной вьюхи". Согласен, часто так и делается. Но это уже архитектурная связанность даже не на уровне компонентов, а на уровне API


                            1. Riim
                              30.07.2017 05:39

                              пока какой-то новой вьюхе не потребуются данные обоих эндпоинтов (какая капризная).

                              так в чём проблема-то? Вполне нормально когда въюха показывает данные нескольких моделей. Может данные зависимы друг от друга?


                              1. teux
                                30.07.2017 09:54

                                Важно, сколько усилий тратится на решение проблем с подходом MVC и Reac/Redux, насколько эффективно получается решение изначально.


                                За функциональной сложностью растет сложность архитектуры, отладки, поддержки. При использовании MVC сложность растет быстрее, чем в случае React/Redux.


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


                                Бывает так в React/Redux? Конечно. Но вопрос в трудоемкости рефакторинга. Когда изначально все данные хранятся в одном месте, разработчик сразу понимает, что общие данные надо хранить в нормализованном виде, не делать кастомный препроцессинг под потребности конкретной вьюхи. Если такая обработка нужна, она выносится в компонент-контейнер (обертка над вьюхой). Применяются селекторы для оптимизации производительности. Код получается гранулярным и тестируемым.


                                И такой подход универсален в React/Redux. Один раз освоить, и можно использовать для решения любой задачи. В MVС, по моему опыту, как только получаешь гладкую архитектуру, как появляется новая задача, которая вносит противоречия, и нужно перестраивать отдельные модели и вьюхи.


                                Поэтому MVC для меня лично (никому не навязываю) — это антипаттерн в отношении архитектуры фронта.


                              1. teux
                                30.07.2017 10:02

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


                                Redux, по-сути, вернул подход единого хранилища. Данные хранятся как раньше — в едином дереве. Появились прекрасные инструменты итроспекции типа Redux DevTools.


                                1. vintage
                                  30.07.2017 10:11

                                  И где вы тут видите неудобства интроспекции?


                                  1. teux
                                    30.07.2017 13:03

                                    А как вам такая картинка (Redux DevTools визуализирует стейт)?


                                    1. vintage
                                      30.07.2017 13:21
                                      +1

                                      Эти красивые картинки бесполезны при числе моделей более 100.


                                      1. teux
                                        30.07.2017 14:01

                                        Ахм… ну ладно, закончим на магическом числе 100 )


                1. JSmitty
                  29.07.2017 21:19

                  А vuex вы во внимание не принимаете? Он, конечно, сильно проще чем Redux — но тоже местами жизнь сильно упрощает.


  1. CodeViking
    28.07.2017 22:44
    +7

    Мне одному кажется что данный холивар бессмысленный?


  1. SbWereWolf
    28.07.2017 22:55

    Видимо всем всё понятно и ни кто примеров из статьи не запускал, у меня второй пример не взлетел. Был список, то есть элементы , но у элементов не было .InnerText.
    Я попытался на авось поменять код тут и там — не помогло, в консольке был варнинг со ссылкой https://vuejs.org/v2/guide/list.html#key и вот там в примере вместо «todo.text» было просто «todo», я подставил как в примере и у меня заработало.

    <div id="app">
      <ol>
        <todo-item v-for="item in list" :todo="item"></todo-item>
      </ol>
    </div>
    
    <script src="https://unpkg.com/vue"></script>
    <script>
      Vue.component('todo-item', {
        props: ['todo'],
        template: '<li>{{ todo }}</li>'
      });
      
      new Vue({
        el: '#app',
        data: {
          list: [ 'first item',  'second item']
        }
      });
    </script>
    

    вопрос к автору, почему не работает todo.text? я что то упустил?


    1. c01nd01r
      29.07.2017 00:39

      В проперти todo компонента <todo-item> приходит item — элемент массива list. Никого свойства text у него нет.


    1. rboots
      29.07.2017 10:49

      Исправил


  1. Valery4
    28.07.2017 23:48

    Дочитал до момента, чем плох TypeScript и дальше не стал читать. Мне кажется плохим тоном преподносить даже что-то хорошее, за счёт очернения другого, которое тут ещё и не к месту приплели.
    В общем статья для меня возымела противоположный эффект, к моей симпатии к Vue.js и потенциальным желанием как нибудь попробовать, теперь осадочек мутный.


    1. ArVaganov
      29.07.2017 01:00
      +4

      Ребята давайте будем откровенны, статья – так себе и несет много необоснованного хейта. Человек даже 2 месяца не проработал на фреймворке и на волне хайпа просто набрал текст и выложил его сюда. Не нужно выплескивать негатив в комментарии и серьезно тут устраивать холивар.
      У меня уже есть небольшой опыт использования Вью, мы с командой пишем проект на Laravel + Vue, (до этого не знал ни одного фронтенд фреймворка).
      Могу вам сообщить действительно отличное преимущество у Вью – это возможность включать его в проект точечно. Это очень полезно когда нужно переписывать и улучшать легаси код. Подключил на страничке скрипт весом несколько килобайт, написал парочку vue компонентов, и вот уже то — что на JQuerry и ванилле было лапшой навешано (и невозможно поддерживать) теперь аккуратно, компактно лежит, реактивное, а главное при этом еще и работает быстро.
      Лично я хочу делать карьеру именно во фронтенде, поэтому параллельно работе с вью учу и реакт. И я хочу вам сказать, что у этих двух фреймворков просто разный подход к рендеренгу шаблонов, всю бизнес логику можно написать на них обоих. И по сути конечный результат зависит от прослойки между стулом и монитором без разницы при помощи чего вы будете создавать свой код.
      Теоретически большие одностраничные приложения можно делать как с использованием Vue, так и с Реактом. Поддерживать легаси, писать какую-то небольшую динамику на странице проще однозначно на Vue. Порог входа очень легкий и документация классная! Так что не бойтесь, пробуйте. В любом случае от «лишних знаний» хуже не станет, т.к. и вью и реакт нужны для специализации по фронту.


      1. rboots
        29.07.2017 02:33

        У вас логическая ошибка. 2 месяца я проработал на Vue, и до этого лет 5 на Angular, а так же 15 лет во фронтенде в целом. По идее, раз так, я наоборот должен был бы хейтить Vue, так как старые технологии всегда кажутся более понятными, а новые вызывают много непонимания, но здесь наоборот. Хейтить Ангуляр я имею полное право, точнее не хейтить, а аргументированно указывать на недостатки. По Реакту мне подсказали, что компоненты можно создавать проще, если отключить JSX, в этом я не прав, но даже с учётом этого их размер всё равно больше, чем на Vue, поэтому моих знаний React вполне хватило для обоснованной аргументации.
        Давайте будет откровенны, ваш пост несёт в себе много много необоснованного хейта, и я только что пояснил, в чём именно. Ваш же пост такой агрументации не содержит, только предположения о человеке, второй снизу уровень на пирамиде Грэма. Поэтому повышайте культуру общения, и удачи вам с вашими собственными статьями.


    1. rboots
      29.07.2017 02:20
      -1

      Если бы прочитали одно предложение дальше — узнали бы, что ничем. А теперь у вас осадочек мутный. Мне кажется плохим тоном критиковать то, что не прочитал.


  1. Fragster
    29.07.2017 00:39
    +1

    Мне только одно непонятно, зачем в vuex выделили мутации и запретили менять state из action напрямую?


    1. JSmitty
      29.07.2017 21:24

      Action — это такая калька с actionCreator-ов в React (точнее redux-thunk по сути), соответственно мутации как бы эквивалентны action+reducer. Дизайн делался с оглядкой на Flux/Redux, и это видно во всём.


      1. Fragster
        31.07.2017 11:18

        Общий смысл мне понятен. Но непонятно, почему в компоненте я пишу this.var = value и всё работает, а в vuex я вынужден для каждой переменной store писать функцию по установке значения и в action'ах писать context.commit('setVar', value)?


  1. indestructable
    29.07.2017 01:15

    Вью — это то, каким должен был быть первый Ангуляр. С ним легко начать, и легко делать простые приложения, но для сложных вещей его DSL недостаточно гибкий.


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


    Реакт требует пересмотра самого подхода к проектированию. Использовать стейтфул компоненты можно, но Реакт этого не поощряет (я имею ввиду не стейт самого компонента, а бизнес данные в стейте).


    С Реактом и, например, редаксом, тяжело начинать (особенно первые несколько раз), потому что подходы к архитектуре кардинально отличаются от подходов, например, Ангуляра.


    Одно только редактирование форм после Ангуляра может заставить человека бросить Реакт и вернуться к Ангуляру :)


    Однако, сложные вещи делать проще, расширять приложение проще, приложение более гибкое, и изменения применять проще.


    Я приведу свой опыт с Реактом — я Реакт практически не замечаю. Потому что вся сложность — она в app state. Компоненты разрабатывать проще — потому что думаешь про функционал самого компонента — какие свойства ему нужны и как они повлияют на отображение компонента.


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


    1. vintage
      29.07.2017 07:50

      проще сделать двусторонний байндинг, а не разнести потоки данных

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


  1. dos
    29.07.2017 11:04

    Вопрос к знатокам React/Vue — если бы была задача реализовать компонент грида, обладающего хотя бы основными возможностями грида от ExtJS то на каком бы из фреймворков бы вы это делали и почему?


    1. raveclassic
      29.07.2017 12:36

      Вы понимаете, что только подливаете маслеца в огонь? :)
      Половина скажет React, половина — Vue.


    1. Starche
      29.07.2017 14:46

      Я б делал на втором ангуляре. Просто потому что я уже его делал на втором ангуляре. Сортировка, фильтрация, нормальная пагинация/бесконечный скролл, прибитая к верху шапка, подгрузка с сервера/подготовленные заранее данные, кастомно оформленный скроллбар (перетащил логику из nanoscroller.js), выделение чекбоксами. Мне пока не были нужны фичи типа группировки строк, но я представляю, что мне надо дописать в существующий код, чтобы их получить. И это будет не очень много возни.
      Ну а ячейки я могу оформить как угодно, потому что это пишется прямо в шаблоне, могу хоть компоненту графика туда подгрузить, хоть редактируемую ячейку сделать.
      Аналогично и с оформлением шапки/футера: любые кнопки можно вкинуть, это не проблема.
      Ну и количество кода, конечно, смехотворное на это уходит.


  1. jakobz
    29.07.2017 12:47
    -1

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


    1. staticlab
      29.07.2017 13:22

      А как же TypeScript?


      1. jakobz
        29.07.2017 22:04

        Речь про DSL шаблонов, в котором строгой типизации нет, и как ее приделать — непонятно.


        1. JSmitty
          30.07.2017 09:25

          Пишите рендер-функции, и будет типизация как и в остальном коде.


    1. vintage
      29.07.2017 14:20

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


    1. VolCh
      29.07.2017 14:47

      JSX — это XML по сути со вставками JS/JS+Flow Type/ Typescript (то, что лично пробовал) со всеми вытекающими.


    1. JSmitty
      29.07.2017 21:27

      Сам фреймворк, AFAIK, написан с использованием Flow. Для желающих есть поддержка Typescript от коммьюнити.


      1. raveclassic
        29.07.2017 21:29

        Речь идет не о фреймворке, а о проектах его использующих.


  1. G-M-A-X
    29.07.2017 14:52
    -1

    Я хз, может я баран.
    Но мне проще писать на jQuery как я хочу, а не вникать в эти новые веяния, которые быстро умирают, в отличии.
    При этом учитываем, что:
    а) старые ресурсы нету особого смысла переписывать на что-то другое
    б) есть куча заготовок, которые упрощают жизнь

    В чем их преимущество над jQuery? :)


    1. TimTowdy
      29.07.2017 15:30
      +3

      В том, что разваливаться от сложности ваш проект на jQuery начнет через 3 месяца, на React через 6, а на Vue через 9.
      <sarcasm>А на Angular — еще до начала проекта.</sarcasm>


  1. kellas
    29.07.2017 15:08

    Меня удивляет что все как-то обходят стороной Riotjs


  1. Fen1kz
    29.07.2017 15:27
    +1

    Давно присматриваюсь к vue, но статья вообще не убедила. Автор, прости, она, мягко говоря ужасна.


    Чем? Цель этой статьи — убедить использовать "лучший фреймворк на 2017 год". Как она убеждает?


    Я прошелся по статье и собрал все плюсы vue которые вы написали


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

    Что бть? Серьезно, не шутите? Давайте в автожурналах писать "Хендай — лучшая машина 2017" и первым пунктом там ставить "у нее пепельница вынимается быстрее чем в других машинах". И это первый мать его реальный плюс. Не надо так, пожалуйста.


    Получилось чуть подлиннее, но у нас здесь custom controls. Custom controls в 20 строчках кода, Карл! При этом сам компонент занял всего 4 строчки. Что это значит на практике: что вы можете делить свой код на компоненты настолько мелко, насколько вам хочется, с минимальными издержками.
    Если в React создание отдельного компонента — целая история, в завязкой, кульминацией и развязкой, то в Vue это просто несколько секунд. И дело не в этих секундах, а в том, что с большим количеством компонентов у вас будут слабее зависимости и меньше багов.

    I see what you did there… Вы думаете что лучший фреймворк как UI — чем меньше тем лучше? Ну, ваше право.
    В Реакте такой компонент занимает 1 строчку и 91 символ (я видел вы в комментах считаете и символы):
    export default ({todo}) => (<li>{todo}</li>)


    Это синтетический пример компонента, но в реальных Vue.js раскрывает себя ещё лучше. Мы можем, например:

    Ну, неужели пошли какие-то реальные плюсы?


    вынести весь код компонента в отдельный *.vue файл, включая html, css и javascript
    использовать css-препроцессоры прямо в коде файле компонента, просто указав lang=«scss» или другое
    использовать любые глобальные объекты или получать объекты через import (в React, кажется, на это есть ограничения)

    использовать компоненты только внутри других определённых компонентов, без объявления в глобальной области видимости. Использовать компонент под другим именем, без изменения самого компонента (удобно в случае коллизии имён сторонних компонентов)

    Ну как бы это стандартный import todo from


    и многое другое. Для большинства этих функций нужно подключать сборщик (в документации описан webpack), однако вам дают выбор, использовать Vue на 10%, 50% или на все 100%.

    Воу, воу, вы уже сказали что первый и главный плюс, цитирую "Это действительно весь код, который вам нужен, это не шутка." То есть в начале сказали что отсутствие сборщиков — плюс к vue, а сейчас — присутствие сборщика — плюс к vue?


    Vue.prototype, Карл!

    Карл, ты когда пишешь в плюсах "не засирает глобальную область", ты как бы в прототип-то не лезь, Карл.


    Зачем отделять React от зависимостей, если внутри компании он без зависимостей не используется?

    Фейспалм.


    В общем, я расстроен, у меня были такие надежды на vue и на вашу статью (из-за провокационного заголовка), а получился какой-то hello world =\


    1. VladVR
      29.07.2017 15:56

      export default ({todo}) => (<li>{todo}</li>)

      И я об этом же написал. За парой нюансов — мне не нравятся анонимные функции, в стектрейсе если что хочется видеть имя, и я не использую export default, потому что навигация в VsCode не так срабатывает. Чтобы перейти на имплементацию надо два клика вместо одного. И я готов ради таких удобств жертвовать краткостью. Что сразу же подразумевает, что краткость для меня — не первый приоритет.
      В ангуляре же(что первый, что второй/четвертый), как и во Vue(если не ошибаюсь), речи про навигацию вообще не идет. нужно скопипастить строчку и ctrl-shift-f.


      1. raveclassic
        29.07.2017 16:09

        Кстати, если совместить именованные экспорты и TS, то большинство IDE/редакторов смогут помочь автоимпортом.


      1. Fen1kz
        29.07.2017 20:30

        На самом деле плевать сколько там строчек, лично для меня, в отличие от автора, это будет приятный бонус, нежели один из основных пунктов что этот фреймворк — "лучший в 2017"


  1. VladVR
    29.07.2017 15:32
    +1

    «Просто» сделать в 1000 раз сложнее, чем «сложно».
    «Простота» здесь относится к чему? Сложилось впечатление, что Карлу пытались объяснить, что простота = количество строк кода.
    вот это
    Vue.component('todo-item', {
        props: ['todo'],
        template: '<li>{{ todo }}</li>'
      });
    

    на реакте пишется вот так
    export function TodoItem({todo}){
        return <li>{todo}</li>;
    }
    

    Существенно проще, не правда ли?

    Если говорить о простоте в терминах «понять как оно работает», и «понять как на этом писать», то получается, что у реакта jsx являет собой некоторую сложность, конечно, но сложность несравнимо меньшая, чем некоторый template engine, в котором, как и в ангуляре, свой ужасный микро-язык (я вот об этом v-for=«item in list», не хватает только любимого хака track by $index), с кучей всяких деталей и конвенций, которые нельзя понять, можно только простить. И вот мы все успешно это изучили, а теперь с приходом второго ангуляра это надо как то из головы выбросить и начать вталкивать другой микро-язык, который стал еще хуже(box-of-bananas-syntax [()] ). И еще одна альтернатива, которая взяла из ангуляра худшее, и переиначила на свой лад ради более краткого синтаксиса — просто идет в топку.

    И да, не стоило «отвергать» typescript. На типизованном языке настолько проще поддерживать код, что на чистый js возвращаться уже не хочется. Вот тут, кстати я посмотрю, некоторые люди ui фреймворки отвергают, и пишут на jquery. Какой уж там typescript.



    1. franzose
      31.07.2017 07:06

      Во Vue можно использовать "локальные" компоненты. Будет примерно то же самое:


      export default {
          template: '<li>{{something}}</li>'
      }


  1. sitev_ru
    29.07.2017 16:40
    +3

    На данный момент не использую для веба ни Vue, ни Angular, ни React, обхожусь пока Javascript/JQuery). Поэтому сильно не бейте). Решил попробывать Ваш примерчик.

    Меня напрягает сразу же следующее: появляется надпись {{ message }}, которая держится целую секунду! Потом надпись меняется на «Hello Vue!»

    Как сделать, чтобы сразу выводилось «Hello Vue!»?


    1. vintage
      29.07.2017 19:28
      +1

      Стандартный костыль ко кривому дизайну: https://vuejs.org/v2/api/#v-cloak


      1. TimTowdy
        29.07.2017 21:55
        +1

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

        sitev_ru
        Решается проблема очень просто: вместо того чтоб шаблон брать из DOM, его стоит передавать в компонент напрямую через template (передавать туда либо строку шаблона, либо #id &ltscript> тэга с шаблоном).


        1. vintage
          29.07.2017 22:02

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


          1. TimTowdy
            29.07.2017 22:28

            Например как? Мне правда, очень интересно.


            1. vintage
              29.07.2017 22:50
              +1

              1. restyler
                29.07.2017 23:01

                и что, по-вашему, Vue так не умеет? :) https://jsfiddle.net/coligo/fjpqz387/


                1. vintage
                  29.07.2017 23:28
                  -1

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


                  1. TimTowdy
                    30.07.2017 02:29

                    Речь о том, что вы не разобрались во Vue, но спешите его критиковать.
                    Во Vue есть два понятия: mount element (el) — элемент, внутри которого будет рендериться ваше Vue приложение, и template — собственно шаблон разметки вашего приложения.
                    Задача Vue — реактивно рендерить шаблон внутри mount element.

                    В исключительном случае, когда приложению передан только mount element, без template, Vue делает следующее:
                    1. генерирует template из DOM-содержимого mount element
                    2. замещает содержимое mount element отрендеренным template
                    Именно в этом причина проблемы sitev_ru.

                    Элемент <template> ничем не помогает: Взять шаблон из конечно него можно, а вот использовать его как mount element, по понятным причинам — нет.

                    Ну и судя по тому, что в предоставленной вами ссылке стоит No Support у IE, и вопрос — у части мобильных браузеров, я не вижу ничего удивительного в том, что Vue нигде не рекомендует использовать такой способ передачи шаблона.


                    1. vintage
                      30.07.2017 09:42

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


                      В чём проблема преобразовать <template> в <script type="template"> поддерживающийся всеми браузерами?


                      1. TimTowdy
                        30.07.2017 14:38

                        Кто будет преобразовывать? Vue работает в том числе и без транспиляторов.
                        Да и зачем? Если можно сразу использовать <script type=template>?
                        Вы свою аргументацию вообще слышите?
                        «логика кривая потому что этого вообще не должно быть»
                        «вместо <script> нужно использовать <template> и преобразовывать его в <script>»


                        1. vintage
                          30.07.2017 14:53

                          Ну пишите вручную <script type="template"> какие проблемы?
                          Логика кривая потому, что отображение неинтерполированного шаблона никому не нужно. Вообще никому. Но в документации мы видим именно такие примеры. От чего каждый разработчик ходит по одним и тем же граблям.


                          1. TimTowdy
                            30.07.2017 15:44

                            Так я и пишу <script>, это вы зачем-то рассказываете что «правильнее» использовать <template>, хотя потом выясняется что это не так.

                            В документации этот случай описывается неоднократно. Но я согласен что магия двойного использования mount element скорее вредит новичкам, чем помогает. Предполагаю что это сделано по большей части для маркетинга (легче рекламировать Vue). Лично мне эта магия не нравится, но жить совсем не мешает (я всегда указываю template). Разводить из-за этого истерику и кричать о «костылях» я точно не собираюсь.


    1. JSmitty
      30.07.2017 09:30

      Вариант такой:

      <div id="app"><span v-text="message"></span></div>
      

      А вообще проблема типовая, для Angular.js 1 даже название придумали — FUC (Flash of Uncompiled Content). И да, в случае полноценно собираемого SPA приложения проблемы не будет.


    1. Akuma
      31.07.2017 08:34

      Ахаха, я все ждал когда появится этот комментарий, но к сожалению уехал.
      Вернулся — а тут оно самое :)

      Добро пожаловать в мир Vue (Angular 2017).
      Совсем скоро вы познакомитесь с «track by $index» и другими модными костылями :)


  1. erlyvideo
    29.07.2017 18:19

    Если в React создание отдельного компонента — целая история, с завязкой, кульминацией и развязкой, то в Vue это просто несколько секунд.


    ну вы серьезно? Не, так не надо продавать то, что вам нравится.


  1. riky
    30.07.2017 03:05
    +2

    vue выстрелит за счет низкого порога входа. его киллер фича в этом.
    думаю скоро его будут пихать как jquery на каждый сайт.


    1. serf
      30.07.2017 15:57

      Он еще довольно легкий по размеру и с хорошей документацией.


  1. KirEv
    30.07.2017 04:08
    -1

    не холивара ради, но почему не использовать технологию\язык исходя из:
    а) я владею и разбираюсь
    б) решение быстрее и удобнее

    Посмотрел пример модального окна: https://vuejs.org/v2/examples/modal.html

    Чтобы сделать подобное на яквери:
    1. подключить jquery ui
    2. написать 4 html-тега для окошка
    3. и одна строчка js-кода, одна строчка Карл!

    Мне не понятно в каком месте vuejs что упрощает.

    Но самое интересное начнется при необходимости нетривиального решения.


    1. JSmitty
      30.07.2017 09:37

      Вы сравниваете несравнимое. Попробуйте реализовать этот контрол на чистом JS + HTML.
      Ну и для полноты — есть такая библиотека, vueStrap, там модалка реализуется фактически в 0 строк JS:

      <modal v-model="show" @ok="show = false">
        Текст в модалке
      </modal>
      <button @click="show = true">Открыть модалку</button>
      


  1. Areso
    30.07.2017 11:11

    https://unpkg.com/vue
    259 килобайт


    1. staticlab
      30.07.2017 12:57
      +1

    1. Fragster
      31.07.2017 12:02

      vue.common.esm.js 50кб gzip
      vue.esm.js 70кб gzip (это если зачем-то на клиенте нужно шаблоны «компилировать»)


      1. Areso
        31.07.2017 12:21

        Вы в страницу в соурс скрипта будете gzip вставлять? Это работает?
        Просто я прошелся по ссылке на скрипт из примера и слегка огорчился.
        Примерно также меня огорчает jQuery UI в половину мегабайта ради настраиваемых надписей на модальном окне с предупреждением.


        1. staticlab
          31.07.2017 12:59

          В любом случае сервер скорее всего передаст и html, и js гзипованными.


        1. TimTowdy
          31.07.2017 13:07

          Вы сейчас шутите? Посмотрите на заголовки HTTP-запроса вашего браузера. «Accept-Encoding: gzip» ни о чем не говорит?
          Пожатый Vue весит ~20KB, в 2 раза меньше React и в 5-6 раз меньше Angular.
          https://gist.github.com/Restuta/cda69e50a853aa64912d


  1. teux
    30.07.2017 15:18

    Хром недавно поддержал параметр ?react_perf и теперь можно профилировать react-компонеты на Timeline.
    Интересно, будет в хром параметр vue_perf?


    1. vintage
      30.07.2017 16:15
      +1

      Хром тут ни при чём, это возможность самой библиотеки.


      1. teux
        30.07.2017 16:20

        Да, вы правы. Я не точно выразился. Просто порадовался новому удобству в Хроме


  1. alek0585
    30.07.2017 17:04

    Статья ни о чем, конечно, но и комментаторы сплошь гении. Так может быть кто-нибудь сможет ответить на вопрос заголовка статьи?


    1. TimTowdy
      30.07.2017 17:29
      +2

      Почему Vue.js — лучший фреймворк для front-end разработки на 2017 год?
      Просто потому что Vue моложе и воспользовался возможностью учесть ошибки своих предшественников. Взял от них лучшее, избавился от худшего. Получилось крайне удачно.


  1. indestructable
    30.07.2017 19:32

    Вынесу вопрос в корневой комментарий.


    При чтении комментариев неоднократно натыкался на утверждение, что Vue использует virtual DOM, и на самом деле, неявно работает похожим на React (а точнее, на JSX) образом, а именно преобразует шаблон компонента в построение виртуального дерева, и на самом деле шаблоны можно не использовать, а можно использовать render функции (то есть практически аналог функции render() в Реакте, как я понял).


    У меня в связи с этим несколько вопросов:


    1. Правда ли это вообще?
    2. Есть ли где об этом почитать, статью или раздел документации?
    3. Значит ли это, что шаблоны Вью нельзя расширить новыми атрибутами, то есть там нет аналога директив Ангуляра.
    4. Работают ли паттерны функциональной композиции применительно ко Вью, например, компоненты высшего порядка?

    Спасибо


    1. staticlab
      30.07.2017 19:52

      Не специалист во Vue, но Virtual DOM в нём действительно есть: https://github.com/vuejs/vue/blob/dev/src/core/vdom/patch.js


      Это как раз то, что автор данной статьи предлагал легко написать в 50 строк.


    1. indestructable
      30.07.2017 20:12

      Частично отвечу на свой вопрос:


      https://vuejs.org/v2/guide/render-function.html


      Действительно, вместо шаблона можно использовать функцию, которая возвращает виртуальный DOM, есть даже JSX для Vue (сюрприз-сюрприз). Шаблоны компилируются в нее же.


      Судя по беглому изучению документации, все это очень сильно завязано на внутреннюю кухню Вью, элегантности Реакта (все есть или функция или ее параметры, все: свойства, события, дочерние элементы (которые могут быть опять же чем угодно)) здесь нету.


      Меня больше удивило другое: во Вью присутствуют элементы самых разных концепций: change tracking + dependency graph, вычисляемые свойства со встроенной мемоизацией (тут я могу ошибаться), встроенная шина сообщений.


      Делается это, насколько я понимаю, для оптимизации генерации virtual DOM (зачем еще это может понадобиться, ума не приложу).


      Если проводить аналогии с Реактом, то Вью — это Реакт + MobX для стейт менеджмента локальных данных компонента + свой язык шаблонов для описания рендер-функций, более близкий к HTML, чем JSX.


      Для себя я сделал предварительные выводы:


      • тот, кто говорит что Вью проще Реакта — говорит в первую очередь о языке шаблонов (и противопоставляя его JSX). Внутренняя кухня имеет на порядок больше концепций, чем Реакт, и изучать ее гораздо сложнее.
        Попробуйте, не заглядывая в доку, сказать, что делает этот кусок кода:


        render: function (createElement) {
        var self = this
        return createElement('input', {
        domProps: {
          value: self.value
        },
        on: {
          input: function (event) {
            self.value = event.target.value
            self.$emit('input', event.target.value) // Все понятно, но зачем это???
          }
        }
        })
        }

        (создает двустороннюю привязку)


      • Оптимизация рендеринга многоуровневая — как по данным, так и по виртуальному ДОМ. Вью скорее всего будет быстрее. Однако нужно помнить подводные камни каждой оптимизации, слишком легко их сломать неправильным использованием.
      • Язык шаблонов Вью — это его действительно сильная сторона, это не Ангуляр с произвольно расширяемым набором атрибутов есть кастомные директивы. Однако, для Реакта ничего не мешает сделать то же самое, первый же найденный пример — http://wix.github.io/react-templates/


    1. TimTowdy
      30.07.2017 20:13
      +1

      1. Да, начиная с версии 2, Vue под капотом использует VirtualDOM.
      2. Например здесь: render()
      3. Custom directives есть.
      4. Функциональная композиция это возможность JS, а не фича какого-то отдельного фреймворка. Во Vue тоже можно ее использовать, хотя в документации это почти не упоминается. Кстати, часть потребностей в HOC покрывается слотами.


      1. indestructable
        30.07.2017 20:17

        Спасибо за ответ.


        1, 2 — сам разобрался


        3. Зачем они нужны? Работают ли они с виртуальным ДОМ или с реальным? Правильно ли я понимаю, что директивы — это способ работы с ДОМ элементами?


        4. Можно пример функциональной композиции ангуляровской директивы или компонента?


        1. TimTowdy
          30.07.2017 22:40

          3. Предназначены для работы с реальным ДОМ, но доступ к виртуальному есть.
          4. С ангуляром у меня отношения не сложились, поэтому пример не приведу. Композицию контента можно посмотреть в ссылке про слоты. Обычно композицию компонентов во Vue все же делают более стандартными extends/mixins. Но функциональная композиция вполне возможна, просто потому что она не привязана к какому-то фреймворку. Хотя до идиоматичности во Vue ей конечно пока далеко.


          1. indestructable
            30.07.2017 23:38

            А как считаете, помимо языка шаблонов (который можно прикрутить и к Реакту), и скорости (которая достигается через observable data, и может быть использована в Реакте через сторонние либы), какие преимущества у Вью?


            На мой неискушенный взгляд в нем слишком много концепций со своими ограничениями: наблюдаемые данные, шина сообщений, ограничение на вычисляемые данные в шаблоне, встроенная мемоизация — нужно ли это? Не приводит ли это к странным неинтуитивным багам типа когда не вызвал apply в Ангуляре, или явно борешь ленивость логических выражений, чтобы затрекались зависимости в Нокауте?


            1. vintage
              31.07.2017 00:30
              +1

              может быть использована в Реакте через сторонние либы

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


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

              Это вы о чём?


              1. indestructable
                31.07.2017 22:51

                В Нокауте зависимости между observable трекаются так:


                • начинается вызов observable a
                • все другие observable/computed, вызванные выше по стеку (во время выполнения а), считаются зависимостями а. При их изменении а считается измененным.

                Проблема заключается в следующем. Пусть есть observable (вернее, computed, в терминологии KnockoutJS), который вычисляется следующим образом:


                areAllTrue: ko.computed(function areAllTrue() {
                    return this.a() && this.b() && this.c();
                })

                Для того, чтобы a, b и c были помечены как зависимости, они должны быть выполнены при выполнении areAllTrue. Однако, если a() === false, то b() и c() вызваны не будут (т.к. результат логического выражения уже известен), и, значит, они не будут помечены как зависимости, а значит, не areAllValid не будет пересчитан при изменении b() или c().


                В общем-то, это не большая проблема, если фреймворк строит граф зависимостей при каждом вызове (а не один раз при первом).


                1. vintage
                  31.07.2017 23:49

                  Так нокаут при каждом вызове и трекает же. С чем вы там боретесь-то?


                1. VladVR
                  01.08.2017 00:26

                  Если говорить о проблемах в нокауте, то мы натолкнулись вот на такую:
                  есть массив объектов, у которых observable свойство isChecked. Мы делаем фичу selectAll. Чтобы отобразить значение чекбокса над гридом пишем примерно такой код

                  isChecked = ko.computed( () => return !items.some(item => !item.isChecked()))

                  далее по нажатию на этот чекбокс нужно все элементы поставить в новое значение чекбокса над гридом
                  onChange = (newValue) => items.forEach(item => item.isChecked(newValue))

                  при изменении каждого из этих observable пересчитывается вышеозначенный computed, то есть мы получили на пустом месте O(n в квадрате)


                  1. vintage
                    01.08.2017 00:36
                    +1

                    В нокаут уже давно завезли отложенное обновление, но по умолчанию оно выключено для совместимости.


            1. TimTowdy
              31.07.2017 01:30

              Не думаю что у Vue есть хоть одно серьезное преимущество в плане каких-то уникальных фич. Многие расхваливают слоты, но это конечно далеко не killer-фича.

              Для меня Vue это просто SPA-framework с хорошим интерфейсом. Умеет абсолютно все то же, что и остальные фреймворки, но делает это чуточку лучше.
              Переписывать существующие React/Angular приложения на Vue смысла не вижу. Как и не вижу смысла начинать новое приложение на React, если есть Vue. Как чтение, так и написание кода приложений лично мне кажется более интуитивным по сравнению с React. Когда я смотрю на код React-приложений, у меня постоянно возникает мысль «ну неужели это нельзя было сделать лучше?!». Vue в этом плане как глоток свежего воздуха.

              Подводные камни конечно встречаются и внутренняя магия может дать о себе знать. Одно только отслеживание зависимостей computed свойств чего стоит (элегантное, но жутко неочевидное решение). Новички вероятно столкнутся с проблемами, вызванными непониманием внутренностей. Но это будет в любом фреймворке. C другой стороны сообщения об ошибках и warnings у Vue очень информативные.

              Часть проблем вызвана недостатками самого языка, например в Javascript до сих пор невозможно сделать getter/setter/deleter на индексы (даже с учетом транспиляторов, спасибо IE). Т.е. возникает такая ситуация:

              this.a = ['test1'] // реактивно
              this.a[0] = 'test2' // не реактивно
              


              В целом, неинтуитивные баги конечно встречаются, но (субъективно) реже чем в других фреймворках. YMMV.


              1. vintage
                31.07.2017 09:23
                -1

                Умеет абсолютно все то же, что и остальные фреймворки,

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


                1. franzose
                  31.07.2017 09:30

                  Немного странные претензии.


                  1. Детальная кастомизация зависит от того, каким образом сам компонент написан и позволяет ли он сам себя кастомизировать.
                  2. Автоматическая вставка индикатора — зачем именно автоматическая?
                  3. Падать из-за сбойного компонента. А как по-другому, если нормальная работа приложения невозможна?
                  4. Локализацию можно сделать самостоятельно.


                  1. vintage
                    31.07.2017 09:48

                    1. О том и речь, что зависит. А есть фреймворки, в которых не зависит.
                    2. А зачем она ручная? Это одинаковый код в куче мест.
                    3. Почему это невозможна? Упал какой-то блок на странице — ну и чёрт с ним, нарисуй грустный смайлик вместо него, но не белый экран же вместо всего приложения.
                    4. Можно. Много чего можно. Зачем вам вообще фреймворк с такой любовью делать всё самостоятельно? :-)

                    Ну и знаете, аргумент "этого нет в моём фреймворке, поэтому это не нужно, а значит в нём есть всё, что нужно" — так себе.


                    1. franzose
                      31.07.2017 12:11

                      1. Делаем кастомный компонент — будет полуавтоматическая :)
                      2. Будет повод как можно быстрее эту ошибку исправить, а не забить до лучших времен.

                      Ну и знаете, аргумент "этого нет в моём фреймворке, поэтому это не нужно, а значит в нём есть всё, что нужно" — так себе.
                      Я этим отнюдь не руководствуюсь)


                      1. vintage
                        31.07.2017 12:41

                        1. Мало сделать компонент, в большинстве фреймворков нужно ещё создать развесистый конфиг и написать кучу кода по его интерпретации.


                        2. Вы про какую ошибку?


                        1. franzose
                          31.07.2017 12:45

                          Ну, про программерскую ошибку. Или вы имели в виду ошибки типа отвалившегося запроса по таймауту или чего-то подобного?


                          1. vintage
                            31.07.2017 12:46

                            Вам нравится с горящей задницей фиксить баг в каком-нибудь датапикере, который сбоит на сегодняшней дате, от чего у половины пользователей приложение перестало открываться? Особенно весело, когда это сторонний компонент, написанный в лучших традициях говнокода.


                            1. franzose
                              31.07.2017 12:58

                              В таком случае я бы просто заменил компонент на другой. Ну, а если в наличии ничего более адекватного нет, то либо сделал бы pull request авторам, либо своё б написал на худой конец.


                              1. vintage
                                31.07.2017 13:40

                                Суть не в том, какой плохой компонент, а в том, как фреймворк реагирует на исключительные ситуации.


                                1. raveclassic
                                  31.07.2017 13:59

                                  Кстати в React 16 наконец-то запилили адекватный механизм обработки ошибок


                                1. franzose
                                  01.08.2017 15:06

                                  Любой фреймворк выдаст вам ошибку и упадёт. Серверные поступают ровно так же.


                                  1. vintage
                                    01.08.2017 16:27

                                    1. bano-notit
                                      01.08.2017 16:36
                                      +1

                                      -_-
                                      А ещё какой-нибудь пример можно?


                                      1. vintage
                                        01.08.2017 16:44

                                        А этот чем не нравится? Впрочем, пожалуйста: http://mol.js.org/#demo=mol_app_habhub_demo/gist=21423554


                                        1. raveclassic
                                          01.08.2017 16:48

                                          Мне бы вашу невозмутимость :)


                                        1. bano-notit
                                          01.08.2017 16:52
                                          +1

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


                                          1. vintage
                                            01.08.2017 17:03
                                            -1

                                            Мне о таких не известно. Скорее всего больше никакие.


                                            1. lega
                                              02.08.2017 01:14

                                              В alight можно прикрутить обработку ошибок, можно вывести трейс, скоуп, обработать проблемный элемент и т.п. пример.


                                              1. vintage
                                                02.08.2017 08:14

                                                К сожалению работает не везде: https://jsfiddle.net/gkrzztrb/4/
                                                Всё приложение тем не менее не падает, да. Но без реактивности оно в общем случае не сможет восстановить свою работу и будет глючить до перезагрузки, даже если причина исключения устранена.


                                                1. franzose
                                                  02.08.2017 08:49

                                                  В итоге всё равно ошибки необходимо будет обрабатывать самостоятельно.


                                                1. lega
                                                  02.08.2017 13:39

                                                  Работает везде (где нужно), просто баги в разных местах могут иметь нюансы, напрмер в вашем примере ошибка возникает до «объявления» обработчика, а обрабочик дожен быть привязан заранее (до ошибки) если нужно что-б он был вызван, поправил пример

                                                  Но даже без обработчика, все «приложение» работает за исключением этого багового биндинга на кнопке.


                                                  1. vintage
                                                    02.08.2017 14:15

                                                    $scan, error in expression: {{xx}}

                                                    Классный стектрейс, сразу понятно, где ошибка :-)


                                                    Но даже без обработчика, все «приложение» работает

                                                    Без реактивности более-менее сложное приложение может начать глючить вплоть до невозможности использования.


                                                    1. lega
                                                      02.08.2017 14:23

                                                      Классный стектрейс, сразу понятно, где ошибка :-)
                                                      У этой ошибки нет трейса, т.к. это «выражение» находится в DOM, грубо говоря там 1 строка трейса, что и выводится, так же проблемный элемент подсвечивается, так что найти проблему очень просто.

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

                                                      Можно даже заморочится и делать разные компоненты на разных версиях фреймворка (кстати — идея, для плавного апргрейда).


                                                      1. vintage
                                                        02.08.2017 15:24

                                                        У этой ошибки нет трейса, т.к. это «выражение» находится в DOM, грубо говоря там 1 строка трейса, что и выводится, так же проблемный элемент подсвечивается, так что найти проблему очень просто.

                                                        Исключение возникает не в выражении, а в коде, который из него вызывается.


                                                        Как раз наоборот, сложное приложение состоит из изолированных компонентов которые никак не влияют друг на друга побочными эффектами.

                                                        Ещё как влияют. Пользователь изменил своё имя — оно должно поменяться везде.


                                                        1. lega
                                                          02.08.2017 16:18

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

                                                          Пользователь изменил своё имя — оно должно поменяться везде.
                                                          Ключевое слово «побочными эффектами», если один компонент поменял имя, он отразил изменения в сервисе, другие компоненты получили это изменение из сервиса (как вариант архитектуры). Если в каком либо компоненте что-то сломалось, оно никак не повиляет* на другие компоненты.


                                                    1. lega
                                                      03.08.2017 23:17

                                                      Хотел поправить, а там все в порядке, проблема в примере, throw строки трейса не дает, при настящей ошибке трейс есть, пример.


                                                      1. vintage
                                                        04.08.2017 00:20

                                                        Блин, точно, извиняюсь.


                                                  1. lega
                                                    02.08.2017 14:16

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


                                                    1. vintage
                                                      02.08.2017 14:18

                                                      Ну, стектрейс-то хотябы не надо проглатывать.


                  1. TimTowdy
                    31.07.2017 13:22
                    +1

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

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


                    1. franzose
                      31.07.2017 13:29

                      Ну, лично я за компонентность, а не монолиты)


                    1. vintage
                      31.07.2017 13:45

                      • микромодульность vue не умеет тоже :-) В микромодульном фреймворке core нет по определению, ибо каждый модуль — сам себе маленький core.


  1. TimTowdy
    31.07.2017 15:23
    +1

    Предлагаю фанатам React провести мысленный эксперимент: представьте, что в 2013 году Facebook выпускает не React, а Vue (версии 2). А сам React (в текущем виде) выходит в 2016. Как вы думаете, смог бы React набрать хоть какой-то значимый вес? Простили бы ему в 2016 году JSX?


    1. taujavarob
      31.07.2017 18:27
      +2

      Предлагаю фанатам React провести мысленный эксперимент: представьте, что в 2013 году Facebook выпускает не React, а Vue (версии 2)
      Это невозможно - Facebook никогда не выпустил бы такое как Vue! ;-)


    1. VladVR
      31.07.2017 21:39
      +2

      Абсолютно ничего бы не изменилось. Vue — всего лишь «еще один фреймворк», по крайней мере если судить по тому как его презентовал автор. React предлагает принципиальное отличие. Там где «все остальные фреймворки» тащат javascript в разметку, react затащил разметку в javascript. Совместно с typescript, это еще и дает то, что весь рендер типизован.
      А это в свою очередь дает то, что если человек опечатался где то, то он получит исчерпывающее сообщение об ошибке на этапе сборки приложения. А не типичную ситуацию «обычного порошка», когда ты собрал приложение, запустил, и получил пустое место, там где должен быть какой то текст. Или не вставилась директива/компонент. И сиди догадывайся что не так. Ибо возможностей для отладки около нуля, нормальных сообщений об ошибках примерно столько же, валится по совершенно непонятным причинам.
      И опять даже если использовать реакт без типизации, и допущена ошибка, во первых с наибольшей вероятностью будет стектрейс с указанием компоненты, строчки и позиции, где эта ошибка случилась, во вторых, если оно не упало, а просто «не работает», то можно поставить брейкпоинт и посмотреть содержимое всех переменных, а не догадываться, чему они могли бы быть равны в тот момент когда ошибка случилась, а не тогда, когда открыл батаранг, но уже поздно.

      Еще один концептуальный шаг вперед, это redux и PureComponent вместо обычного Component. Также как и в случае с Flux, cостояние полностью отрывается от представления, и вся концепция приложения разрывается на 3 части, но в отличие от Flux, две части из трех становятся чистыми (pure).
      1) новое состояние = чистая функция от двух параметров — предыдущего состояния и «возбудителя»
      2) разметка = чистая функция от состояния
      3) сервисы, в них смещен весь «нечистый» код, в частности асинхронный.
      Конечно команду надо сильно попинывать, чтобы не нарушали концепцию, но возможность иметь две трети приложения написанными чистым кодом того стоят.
      Второй ангуляр кстати очень неплохо ударил по этому фронту, даже свою реализацию redux написали, хоть и не по феншую совершенно. Однако если на нее не смотреть, а взять обычный, православный redux, и stateless компоненты, то можно достичь близкого результата. Терпимого я бы сказал, в условиях того, что заказчик уперся и хочет второй ангуляр хоть ты тресни.


      1. raveclassic
        31.07.2017 23:34

        заказчик уперся и хочет второй ангуляр хоть ты тресни

        до слез


      1. babylon
        04.08.2017 10:05

        Там где «все остальные фреймворки» тащат javascript в разметку, react затащил разметку в javascript. Совместно с typescript, это еще и дает то, что весь рендер типизован.

        Согласен с комментом. Есть ещё jsonnet


    1. staticlab
      31.07.2017 22:02

      представьте, что в 2013 году Facebook выпускает не React, а Vue (версии 2)

      просто говорили бы, что ФБ тупо скопировал всё у Гугла.


    1. Fen1kz
      01.08.2017 19:11

      deleted


  1. cdrw3
    03.08.2017 15:21
    +1

    Эх, помнится на заре моей юности такие холивары устраивали по вопросу, на чем лучше писать — на delphi или с++))
    Только не бейте меня сильно (react в своих проектах не использую), но нас раньше учили отделять код от верстки, а сейчас JSX позиционируется чуть ли не как панацея от всех бед. Что изменилось?


    1. indestructable
      03.08.2017 15:39
      +1

      Нужно отделять бизнес-логику от верстки, код управления состоянием от верстки, служебный код (логгирование, замеры производительности) от верстки.


      Но код, управляющий версткой, от верстки отделять не нужно.


      1. vintage
        03.08.2017 15:58

        Нужно отделять всё, что отделяется. В частности программный код и декларативную композицию.


        1. raveclassic
          03.08.2017 16:01

          Что мешает в декларативной композиции использовать возможности языка вместо кастомных DSL?


          1. vintage
            03.08.2017 16:03

            Теряется собственно декларативность.


            1. raveclassic
              03.08.2017 16:07

              Теряется, если ее намеренно терять. Вам точно так же в code-behind классах для XAML компонентов (типичный представитель view) никто не запретит ходить в базу. Так какой смысл в этом параноидальном отделении кода для view от шаблона для view?
              А если не плодить сайд-эффектов, то декларативность остается.


              1. vintage
                03.08.2017 16:42

                Как вы думаете, почему конфиги пишут на ini/yaml/xml/json, а не на js/php/c#/java?


                1. raveclassic
                  03.08.2017 16:48

                  Не знаю, я обычно на js пишу :) Тот же вебпак вспомнить…
                  Не представляю, какая жесть писать конфиг к нему в виде json. К нему и так писать конфиг жесть, но json…
                  Только если с кастомной шаблонизацией внутри — привет DSL.


                  1. vintage
                    03.08.2017 17:51

                    Попробуйте MAM — там вообще никаких конфигов не надо писать.


                    1. raveclassic
                      03.08.2017 18:00

                      MAM?


                      1. vintage
                        03.08.2017 18:03

                1. VladVR
                  04.08.2017 15:58

                  Вероятно потому что конфиг это сериализуемые данные. Какой правильный ответ то?
                  К слову мне в мире C# всегда было непонятно, почему build-процедуры пишутся на каком то левом языке msbuild (поверх xml).
                  В мире JS, как оказалось его легко писать на том же языке, что и основной проект. Берешь Gulp и вперед.
                  И, внезапно, в последнее время начали появляться build системы, где можно писать на C#, слышал на дотнексте про fake и cake (т.н. f-sharp make и c-sharp make).
                  Тоже можно было задавать пространные риторические вопросы, типа «а угадай почему билд скрипты пишут на xml» намекая на то, что существует в природе какая то логическая связь и собеседник должен о ней догадаться и склониться к твоей точке зрения. Однако, внезапно оказалось, что причина то банальна, «вчера» сделали как смогли, а «сегодня» делают, как правильно/удобно, а логическая связь — неверна.


                  1. vintage
                    04.08.2017 17:57

                    Правильный ответ: возможность различного анализа без исполнения. Простой пример: из view.tree благодаря декларативности очень легко достать информацию о классах, свойствах, типах, связях компонент. Сейчас я пилю абстрактный редактор, который может взять любой компонент и как угодно его изменить. А сделать такое с JSX, например, не получится.



                    1. VladVR
                      06.08.2017 20:34

                      А сделать такое с JSX, например, не получится.

                      «Такое» можно сделать даже в компилируемой среде .Net. А в мире скриптов такое заявлять совсем кощунственно. Именно так работают фиддлеры. Человек в браузере пишет jsx или, к примеру, typescript, нажимает кнопку, написанный код уезжает на сервер, там транспайлер его жует, и результат выдается обратно в браузер. Останется прикрутить поверх jsx свой редактор, и «такое» будет отлично работать.


                      1. babylon
                        06.08.2017 22:59

                        Многое из того что потом кодируется напрямую зависит от формата данных.
                        Давайте лучше обсудим apache avro vs MsgPack
                        Быстрее это всё в текстовом редакторе набрать в JSON схемах.


                      1. vintage
                        07.08.2017 00:14

                        Останется прикрутить поверх jsx свой редактор, и «такое» будет отлично работать.

                        Вы не забыли, что JSX — это не XML, а JS, с "мощностью" которого не каждая IDE-то толком может совладать?


            1. VladVR
              04.08.2017 15:46

              Взамен на типизацию, возможности отладки, вменяемые сообщения об ошибках.
              Ну и широкоизвестный язык, который лет 20 живет вместо узкоспециализированного DSL, который умрет через пару лет.


        1. VolCh
          04.08.2017 19:29

          Нужно отделять всё, что отделяется.

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


    1. VolCh
      04.08.2017 19:21
      +1

      В нормальном JSX кода не больше чем в вёрстке шаблона на любом, ну, почти любом, шаблонизаторе. А императивного кода и того меньше из-за невозможности использовать if/else, for и т. п. внутри разметки.