Создатель Vue.js отвечает Хабру



    Всех с пятницей!

    Как и обещали, публикуем ответы Эвана Ю (Evan You) на вопросы, которые мы долго и мучительно собирали в предыдущем посте, а также русскоязычном Vue чате в Telegram.

    В общем о Vue


    В: Какова самая уникальная киллер-фича Vue.js?
    O: Прогрессивная адаптивность: ты можешь использовать его как замену jQuery или создавать приложения любой сложности, используя CLI, роутер и Vuex.

    В: Каковы самые слабые места Vue?
    O: На данный момент, наверное, недружественность к типизации. Наш API разрабатывался без планирования поддержки типизированных языков (типа TypeScript), но мы сделали большие улучшения в 2.5.

    В: React называет себя библиотекой, Angular — фреймфорком. Почему Vue позиционирует себя как фреймфорк?
    O: «Прогрессивный фреймворк» означает, что его можно использовать как библиотеку ИЛИ как фреймворк, по твоему желанию. У нас есть части фреймворка (CLI, роутер, паттерны управления состоянием), но никто не заставляет их использовать, если они не требуются. (см. более подробное видео (eng) — прим. пер.)

    В: Является ли Vue полноценной заменой React/Angular или это нишевый фреймворк?
    O: Да, он может быть полной заменой. Это не нишевый фреймворк.

    В: Какой ожидаемый жизненный цикл Vue.js? Смогут ли Веб Компоненты (Web Components) / VanillaJS заменить JS фреймворки в ближайшем будущем?
    O: Мы растем довольно быстро, и сейчас находимся в относительно стабильном / зрелом состоянии. Нет, я не думаю, что Веб-компоненты когда-либо заменят фреймворки. Они являются лишь низкоуровнивыми строительными блоками. Даже если ты используешь их уже сегодня, ты, скорее всего, вынужден использовать Polymer, который *является* фреймворком над Веб-компонентами. У него есть собственные дополнительные API, паттерны, библиотеки и инструменты. Преимущества Веб-компонентов, в основном, в совместимости между фреймворками или сторонних пакетах (3rd party distribution). Внутри же приложения, они не дают ничего нового в сравнении с существующими моделями компонентов (на самом деле, они могут меньше). VanillaJS имеет смысл, только если ты можешь позволить себе потратить вечность на разработку проекта.

    В: Какова политика Vue относительно deprecation, несовместимых изменений и обратной совместимости?
    O: Мы следуем semver. Мы можем объявить фичи устаревшими в минорных релизах, но на самом деле они не будут удалены, так что ваше приложение не сломается. Мы достаточно осторожно относимся к мажорным версиям / несовместимым изменениям и не планируем их в ближайшем будущем.

    В: Какова рекомендуемая структура кода для Vue: ООП или ФП/Декларативный подход?
    O: Ни первое, ни второе. Я думаю, бессмысленно натягивать высокоуровневые парадигмы на код UI. Выбирайте удачные идеи обоих. Но если ты действительно хочешь выбрать сторону Vue, то, думаю, там будет чуть больше ООП.

    В: Формы — сильная черта у Angular и слабая у React. Как хорошо работает Vue со сложными формами?
    O: У Vue есть встроенная двусторонняя привязка (binding) в виде v-model, который очень похож на ngModel у Angular. Также возможно строить Angular-подобные библиотеки валидации поверх, и несколько уже есть в экосистеме.

    В: Какие самые большие конкуренты Vue в Китае?
    O: React and Angular весьма популярны в Китае. Кроме них, на самом деле, других нет.

    В: Ходят слухи, что Vue определяет, что запущен бенчмарк, и специально завышает результаты тестов (привет, VolksWagen!) Твои комментарии?
    O: Слухи без доказательств остаются лишь слухами ;) Код Vue.js в открытом доступе, поэтому, если такой код есть, его легко можно найти.

    Сторонние инструменты


    В: Какие перспективы у Weex? Стоит ли начинать работать с Weex уже сейчас? Или лучше сконцентрироваться на работе с NativeScript-Vue?
    O: Weex — надежная технология, т.к. она широко используется внутри Alibaba. Просто, в отличие от других, они не выделяют много ресурсов на документацию / поддержку разработчиков. NativeScript-Vue имеет лучшую документацию и обратную связь с разработчиками. Я не стану давать однозначные рекомендации, потому что ваш выбор должен определяться командой/продуктом/окружением. Чтобы узнать полный потенциал этих технологий, нужно попробовать обе.

    В: Что ты думаешь о Nuxt?
    O: Nuxt — отличная штука. Если нужен SSR под Vue — используй его, если не хочешь настраивать все самостоятельно (есть еще фреймворк-независимые альтернативы типа Razzleприм. пер.)

    В: Что ты думаешь о Quasar Framework для Vue.js как об аналоге ReactNative для React.js?
    O: Нет. Quasar больше похож на Ionic для Vue, так как основан на Cordova / WebView.

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

    В: Будет ли поддержка языка программирования Kotlin во Vue (SFC, плагины и т.д.)?
    O: Мне не известно ни о чем подобном.

    Документация


    В: Примеры в официальной документации Vue.js не всегда понятны из-за того, что их невозможно запустить прямо на странице. Если планы по интеграции CodePen или JSFiddle в официальную документацию Vue.js?
    O: Хорошее предложение. Возможно, мы рассмотрим его, когда у нас будет больше времени.

    В: Как делить макет страницы на компоненты перед началом разработки? Есть ли что-то вроде «Списка критериев Компонента» от Эвана Ю?
    O: Это невозможно, все приложения — разные.

    В: Есть ли единое официальное руководство по программному стилю вроде руководства Angular от Джона Папы (John Papa)?
    O: ru.vuejs.org/v2/style-guide

    В: Существуют ли официальные инструкции по миграции на Vue с других фреймворков?
    O: На этот вопрос трудно ответить, не зная, с каких именно технологий идет миграция.

    В: Как превратить приложение на Vue в Web Component?
    O: При помощи консольной утилиты vue-cli версии 3

    В: В официальной документации Vue.js рекомендуемой опцией компилятора TypeScript является «module»: «es2015». Насколько допустимо использование «module»: «amd», «module»: «system».
    O: Эта рекомендация основана на предположении, что используется упаковщик совместимый с ES module, такой как webpack или rollup. Лично я больше не использую AMD или System, поэтому не могу ответить на этот вопрос. Мое общее предложение — не используй их, если не знаешь, что делаешь. Поскольку ты все же задаешь этот вопрос — используй мейнстрим (т.e. настройки по умолчанию — прим. пер.).

    В: Когда будут выпущены спецификации для построений AST для шаблонов?
    O: Не думаю, что у нас есть такие планы. Нам понадобится очень убедительный сценарий использования, чтобы рассмотреть такое решение.

    Запросы фич


    В: Будет ли возможно использовать компилятор однофайловых компонентов без модульных бандлеров?
    O: Да, у нас есть компилятор SFC (Однофайловых компонентов), мы надеемся что его можно будет использовать для создания внешних или внутрибраузерных компиляторов.

    В: Будет ли шаблон для генерации библиотек добавлен в vue-cli?
    O: vue-cli 3 можно использовать и для создания библиотек.

    В: Фрагменты из React версии 16.2 хорошо себя зарекомендовали. Будет ли что-то похожее у Vue.js?
    O: Да, хоть и не в ближайшем будущем, т.к. потребуется много изменений в текущем алгоритме нахождения различий (diffing algorithm). React'у для этого потребовалось полностью переписать все в течение почти 2х лет.

    В: Будет ли во Vuex поддержка обработки middleware между actions и mutation?
    O: Маловероятно. Скорее всего, мы будем избавляться от различий между действиями (actions) и мутациями (mutations).

    В: Когда запуск команды `npm run lint` будет поддерживать autofix?
    O: vue-cli 3 уже это поддерживает. Ты также можешь самостоятельно изменить команду, добавив флаг `--fix`.

    В: React недавно выпустил асинхронный рендеринг aka Fiber. Какой будет ответ Vue? Является ли Vue по-прежнему самым быстрым из всех троих фреймворков?

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

    Вкратце: мы не планируем создавать полный эквивалент Fiber, но мы предоставим API для некоторых новшеств, появившихся в нем.

    В: Будет ли во Vue.js добавлена возможность рендера одного и того же слота в компоненте дважды как это позволяет делать React?

    // [Предупреждение Vue]: Duplicate presence of slot "default" found in the same render tree - this will likely cause render errors.
    
    <div>
     ...content
     <slot>
     ...content
     <slot>
     ...content
    </div>
    

    // в React работает без пробем
    <div>
     ...content
     {this.props.children}
     ...conent
     {this.props.children}
     ...content
    </div>
    

    O: Хотя React это позволяет, я не думаю, что это хорошая идея.

    В: Поддерживает ли Vue единый репозиторий для приложений масштаба энтерпрайз вроде Nrwl Extention в Angular?
    O: Это проблема организации проекта, она пока вне наших интересов.

    Пожалуйста, порекомендуй


    В: Сейчас Vue.js можно выполнять валидацию форм двумя различными способами:
    — декларативный, когда все правила описываются как директивы в разметке;
    — императивный, когда все правила описываются в коде соответствующего Vue-экземпляра

    Планируется ли сделать какой-либо из этих способом реализацией по-умолчанию в Vue.js? Или оба способа сразу?


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

    В: Чем и как лучше всего тестировать Vue? Avoriaz рекомендует перейти на vue-test-tools, но последний все еще бета.
    O: @vue/test-utils заменит Avoriaz. Используйте @vue/test-utils.

    В: Cостояние (state) Vuex reactive/observable, как и любые данные компоненты Vue. Если бы не наследие Flux, возможно было бы манипулировать им напрямую (даже если это плохая идея)?
    O: Если требуется реактивное состояние хранилища, которым можно будет манипулировать напрямую, — просто используй непримонтированный экземпляр Vue.

    В: Существуют ли планы или рекомендации для компонент по возврату нескольких корневых нод (root nodes)? Возможен ли такой списочный («list-based») подход хотя бы в теории?
    O: Да, мы планируем это, но потребуется некоторое время.

    В: Твои идеи по поводу повторного использования, наследования и тюнинга компонент во время запуска? Есть ли какие-нибудь проверенные подходы и решения?
    O: Извини, но это слишком большая тема, чтобы ответить здесь :)

    Коммьюнити


    В: Vue впитал в себя много фишек Angular и React. Какие отношения у Vue с сообществами Angular и React?
    O: На самом деле я довольно часто общаюсь с сообществом React. Мне нравятся все их хорошие идеи. Однако я не знаком с таким количеством людей из сообщества Angular.

    В: Я хочу внести свою лепту в развитие Vue. В каких областях нужна моя помощь?

    O: Начни отвечать на вопросы других! Это могут быть обсуждения на GitHub, чат в Discord или StackOverflow (или Тостер — прим. пер.). Нужно помнить, что отвечать нужно максимально понятно. Обычно, чтобы лучше разобраться в проблеме, может потребоваться перечитать документацию или даже исходники. Занимаясь этим какое-то время, ты начнешь понимать Vue гораздо лучше и сможешь решить больше проблем на Github, помогая с примерами кода, поиском источников багов и даже созданием фиксов и новых фич.

    В: Какие самые крупные конференции, митапы и мероприятия по Vue, которые стоит посетить?
    O: Мы только что провели Vue.js конференцию в Амстердаме в феврале этого года. И планируем провести ее там же в следующем году. Также в марте этого года состоится конференция VueConf в US. По всему миру проводятся достаточно много конференций — стоит только поискать рядом с тем местом, где ты живешь (Vue в Москвеприм. пер.).

    Планы на будущее


    В: Ведется ли работа над Vue 3.0? Если да, то каковы ключевые изменения?
    O: У нас есть планы на 3.0, но пока что ничего определенного. Ближайший большой релиз — это ветка 2.x-next, которая полностью совместима по возможностям с 2.x, но в ней внутренняя система реактивности переписана на ES2015 Прокси. Это улучшит производительность и позволит избавиться от некоторых ограничений существующей реализации (например, отслеживание изменений в объектах и массивах — прим. пер.). Мы прекратим поддержку IE11 и ниже, но позволим использовать последние возможности ES2015 для более эффективного кода.

    В: Доступ к родительским компонентам (через $parent) позволяет неопытным разработчикам делать ужасные ошибки. Что ты думаешь на этот счет? Планируется ли когда-либо убрать такой доступ (например, в версии 3.0)?
    O: Маловероятно, что мы уберём его, поскольку он бывает полезен в определённых ситуациях. Всегда можно запретить доступ к родителю с помощью статического анализа, например с помощью пользовательского правила (custom rule) для ESLint.

    О себе


    В: Давай уйдем в сторону от IT-тематики. Суммируя свой опыт, какими знаниями ты можешь поделиться? Какие у тебя интересы и как они сочетаются с программированием? Какой совет ты бы дал людям в целом и разработчикам в частности?
    O: У меня художественное образование, я учился программированию, по большей части, самостоятельно. Наверное, из-за этого я склонен ценить практичные и легко изучаемые решения. Со временем я также понял, что чаще всего программирование — это выбор правильных компромиссов. Думаю, мой совет не должен быть слишком категоричным — будьте практичны и будьте готовы к компромиссам.

    В: Сколько часов в день ты посвящаешь работе над Vue.js?
    O: С тех пор, как это стало моей основной работой, я провожу обычный средний рабочий день с 9 до 5 (ну ладно, может чуть дольше)

    В: Расскажи о своем прошлом опыте работы в Google, Meteor и т.д. Как родилась идея Vue?
    O: Я только что закончил эпизод подкаста, который скоро появится на devchat.tv. Там я рассказываю об этом в подробностях.

    В: Какой, по твоему, самый важный момент в стеке веб технологий на сегодня? В каких областях назрела необходимость изменений? Что в порядке, а что — нет?
    O: Я могу рассуждать только о фронтенде. Думаю, основная проблема в том, что стандартные API, которые предоставляет веб платформа, слишком низкоуровневые. В результате, очень многие библиотеки решают почти каждую проблему, которую не решает платформа. Это и хорошо, и плохо. Хорошо тем, что эти инновации (вызванные конкуренцией) порождают отличные идеи. Негативная же сторона в том, что почти каждый стек, который вы видите, состоит из огромного числа быстро развивающихся зависимостей. Это, вероятно, продолжится еще несколько лет.

    Лично я надеюсь на то, что однажды браузеры станут достаточно эффективны, и мы сможем перестать беспокоиться о бандлинге или микрооптимизации доставки ресурсов (assets). Это уберет все проблемы с временным (stop-gap) инструментарием, которые обычно есть в архитектурах сегодняшнего фронтенда. Однако, я не знаю когда это произойдет.

    В: Каким техническим решением во Вью ты гордишься больше всего?
    O: Я сделал его легким в изучении и одновременно довольно мощным.

    В: Тони Хор (Tony Hoare) назвал null ошибкой на миллиард долларов. Какое было самое неудачное техническое решение в твоей карьере?
    O: Было бы неплохо использовать TypeScript изначально, еще когда я начал переписывать код для Vue 2.x.

    В: Какая самая сложная фича Vue, над которой ты работал?
    O: Наверное, оптимизация серверного рендеринга в 2.4, которая позволила рендереру обрабатывать смесь нод VDOM и строковых нод (string representation nodes), созданных во время компиляции.

    P.S.


    Спасибо всем, кто помогал с организацией и переводом (Alex Sokolov, ai_boy, hiperteksto, irsick, z6Dabrata, gbezyuk) и, конечно самому Эвану.

    P.P.S.


    См. видео(eng) нашей предыдущей Q&A сессии с Эваном
    Поделиться публикацией
    Похожие публикации
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 68
    • 0
      > VanillaJS имеет смысл, только если ты можешь позволить себе потратить вечность на разработку проекта.

      Ну или же ты используешь SvelteJS ;-)
      • +6

        Не уверен, что дропнуть саппорт ie11 — хорошая идея (хотя и очень хочется)

        • +3
          Людей с плохим зрением в разы больше чем пользователей IE. Забейте наконец на него и позаботьтесь о людях.
          У нас в конторе порядка 3% заказчиков заходили через IE, однако мы приняли решение не тратить время на адаптацию нового сайта для старых браузеров т.к. лучше реально что-то более полезное сделать. Сразу скажу, что 3% с нашими оборотами это около 150-200 тыс руб прибыли ежемесячно. В итоге силы решили потратить на всевозможные оптимизации и ускорения сайта.
          • +2
            Ну да, забить можно. Просто это закрывает дорогу приложениям на Vue в корпоративный сектор. Для сайтов это не критично, а если ты делаешь веб-приложения то ой.
            • +3

              Корпоративный сектор бывает разный.


              Доводилось мне делать одну штуку для крупной финансовой компании. Там по стандарту у всех сотрудников стоял последний Google Chrome. Поэтому мы использовали web-components, es6-фичи и т.д.


              Множества "корпоративный сектор" и "компании сидящие на IE" хоть и пересекаются, но не тождественны.

              • +1
                Зависит от этого самого сектора и кто конкретно будет пользоваться. Я вот пилю продукт для энтерпрайза (медиа-агенства и аналитики из больших корпораций). У нас вообще требований как таковых нет, вся разработка идет только в хроме, фаерфокс открываем раз в несколько месяцев, на Edge всем вообще пофиг (а про ИЕ даже никто и никогда не спрашивал).
              • +3
                Ну так то да, можно найти проект, где не надо ие. Но если работаешь в b2b секторе, то там не все так просто. У меня есть статистика по продукту, где за год из 200 млн. сессий 40 млн. юзерами 46% из них используют ие, а именно 11-го 90%, а остальные 4-5%.
                • +2

                  Это если еще гос. клиентов нет. Мы вот только год назад с трудом дропнули поддержку 9-го. Боль и унижение — объективная реальность.

                • 0
                  Сразу скажу, что 3% с нашими оборотами это около 150-200 тыс руб прибыли ежемесячно. В итоге силы решили потратить на всевозможные оптимизации и ускорения сайта.


                  А решение-то принимал бизнес-руководитель или разработчики?
                • +3

                  Это для сильно будущих версий. В актуальных билдах работа так же продолжится.
                  Сейчас Vue не поддерживает все, что ниже IE 9. Когда-то такое время наступит и для 11 ослика.

                • –6
                  VanillaJS имеет смысл, только если ты можешь позволить себе потратить вечность на разработку проекта.

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

                  • +8
                    Наверное, имеется ввиду что для реализации одного и того же функционала на vanillaJS потребуется сильно больше времени и кода, чем на vue. И с этим не поспоришь, фреймворки и создаются же для того чтобы ускорить разработку путём переиспользования кода.
                    • 0

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

                      • +4
                        Я бы сформулировал иначе. Не «во многих случаях избыточен», а «в некоторых случаях избыточен». Чаще всего, фреймворки как раз значительно ускоряют разработку. А при условии наличия прямых рук — даже не чаще всего, а почти всегда.
                        • –2

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

                          • +2
                            Например, в каких это проектах? В любом проекте есть два сценария — либо используется готовый фреймворк, либо пишется свой (варианты говнокода где каждый раз с нуля подключаемся к базе, или каждый раз парсим url — не рассматриваем). В итоге в любом проекте есть фреймворк — вопрос только в том самописный или готовый. Так в каком случае это бомба то? Особенно если это фронт-енд, где вариант быстро возникшей нагрузки которую не тянет фреймворк — не рассмативается.
                            • +2

                              Есть вариант написания "фреймверка" под проект или серию проектов с прицелом на определенную предметную область. Бомба — это когда фреймверк утратил популярность и найти разработчика под проект становиться дорого, а баги фреймверка годами остаются не пофикшенными.

                              • +9
                                Вот только самописные фреймворки оказываются в состоянии «найти разработчика под проект становиться дорого, а баги фреймверка годами остаются не пофикшенными» намного быстрее…
                                • +1

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

                                  • +9
                                    Это только до тех пор пока команда не разбежится. А она разбежится обязательно, потому что нельзя всю жизнь делать один и тот же проект.

                                    После этого для следующего поколения программистов это будет уже не «собственный фреймворк», а «чужое легаси без документации».
                                    • 0

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

                                      • +5
                                        Тем не менее, когда на проект приходит новый разработчик — для него освоить чужой велосипед не проще чем устаревший фреймворк.

                                        Вот только у устаревших фреймворков есть актуальная документация — а у чужих велосипедов таковой обычно не наблюдается.
                                        • 0

                                          … а так же есть старые баги.


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


                                          Хороший пример (если мы о бэкэнде) зависимость от определенных реализаций БД, чем часто грешат фреймверки. Подходит для мелких проектов и совершенно не подходит для крупных, где может быть несколько баз данных с различными подходами к работе с данными.


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


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


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

                                          • +3
                                            Старые баги есть в обоих случаях, как в старом фреймворке — так и в чужом велосипеде.
                                            • +2

                                              jMas не надо обобщать.Конкретно Vue.js достойный продукт, с оригинальными решениями, до которых любому разработчику еще надо додуматься. Лично я много чего из него подчерпнул по части идей. Просто люблю досконально изучить документацию. Чтобы потом не казалось, что можно улучшить, то что уже есть.

                                              • +2
                                                В вашем самописном фреймворке без документации будет ещё больше багов, чем в том, который попользовали 1000+ разработчиков в разных окружениях.

                                                И вообще — в чём проблема исправить баги в неподдерживаемом более фреймворке? Это ничуть не сложнее, чем исправить их в самописном, а даже легче, если есть документация. Особенно когда оригинальная команда, создавшая «кастомный фреймворк» давно разбежалась. Если проект настолько большой и серьёзный — то на исправление багов выделяется отдельная команда, в обоих случаях.

                                                Я много раз за карьеру видел, как проектируются и пишутся эти «самописки» (поработал в том числе в компаниях на 200000+ человек, с сильным IT департаментом и кучей внутренних IT-решений). Получается это хорошо (на самом деле крайне редко) только в том случае, если у вашей команды работа — писать фреймворки и опыт их написания лет 100 суммарно. А бизнесу обычно надо решать бизнес-задачи, а не проектировать кастомные фреймворки, которые денег не приносят и так же будут погребены под костылями, как и «народные», будут сильно забагованы и никто не будет знать, как оно точно работает.

                                                Да, бывают очень узкие задачи, где кастом — самое то. Но это, по опыту, крайне редко проекты на 5+ лет жизни. Кстати, наблюдение: иногда можно испытать иллюзию, что своё лучше готового по причине того, что «своим» толком никто и не пользуется и складывается ощущение, что оно работает хорошо.

                                                Вы привели в пример Bootstrap, где со временем накостылено так, что оно уже не работает как bootstrap. С кастомным будет ровно то же — задачи будут сыпаться в изобилии, делать их надо будет быстро и рано или поздно руководство будет принимать административные решения забить на концептуальную чистоту и сделать БЫСТРО, потому что деньги.

                                                Ваши аргументы за «кастом» актуальны только в мире, где заказчик точно знает чего хочет, может это изложить, и больше никогда и ни за что не будет требования менять. В мире, которого в обозримом поле зрения нет. Атомные станции и самолёты делают доли процента всего IT мира.
                                                • 0

                                                  Заказчику намного чаще нужны кастомные решения, на стандартных фреймворках, тех которые он сам использовал ранее, а не кастомные фреймворки, для уже решенных задач. Главное чтобы не поломалось, то что и без них работало. Лично я редко меняю фреймворки на более новые в работающих решениях. Для новых пожалуйста, если заказчик не против. Но как правило заказчик консервативен и боязлив и правильно поступает.

                                                  • 0

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

                                                  • –2

                                                    На мой взгляд в сравнении фреймвоков и самописных решений упущен очень важный момент — количество кода и зависимостей и при при прочих равных когда баги есть и в устаревших фреймворках и в самописных решениях второй вариант лучше потому что там просто меньше кода. Для наглядности — возьмем популярные шаблоны для создания приложений. При создании нового пустого проекта с популярным нынче create-react-app устанавливается 969 зависимостей, а с vue-cli устанавливается 1434 зависмости. 1434, карл!!! Мне кажется, имея 1434 пакетов, придется чуть ли не каждый день изучать ченджлоги потому что обновился пакет и исправил какие-то баги или добавил какие-то фичи. А что насчет безопасности? Сколько вы потратите времени на аудит, учитывая что каждый из этих пакетов может либо содержать увязвимости, либо быть скомпрометированным и достаточно добавить post-install-скрипт в один из этих 1434 зависимостей чтобы при выполнении команды "npm i" этот скрипт получит полный доступ к компьютеру с возможностями начиная от воровства токенов закачивая шифровальщиками или всякими вирусами. И при всем этом я что-то ни в одном проекте не видел чтобы зависимости коммитили в гит (чтобы избежать подмены исходников на npm, компрометации, или вообще взлома серверов по ссылках в lock-файлах) А какой процент фич от этих тысячи пакетов реально будет использоваться? Учитывая что каждый пакет имеет тенденцию добавлять все новые фичи на все возможные случаи, то чем больше комбинаций из этих пакетов — тем больше будет дублирования этих фич и попытка для большого бизнес-проекта, которому нужны гибкие и специализированные решения и быстрое развитие, выбрать какой-то жирный фреймворк как минимум столкнется с конфликтами, ограничениями и костылями. А теперь если сравнить с самописными решениями? Реакт (до 16 версии имел 20-25к теперь 18к строк) можно написать на 200 строчек кода, получив diff виртуального дома + компоненты. Имея js-парсер можно на 100 строчках реализовать сборку в бандл и webpack вместе с 431 зависимостями будет не нужен. В итоге, если сравнивать по количеству багов, то для того чтобы исправить какой-то баг — что проще — разобраться в устаревшем фреймворке на 20к строчек (собранный вдобавок из кучи других зависимостей) или в маленьком файле на 200 строчек? Я уверен что самописные решения (хотя правильно это было бы назвать "специализированный инструмент заточенный под нужды бизнеса") всегда будут гибче и проще как в поддержке так и развитии

                                                    • +2
                                                      Если следовать аналогии — то и веб-сервер нужно свой, с нуля писать. Зачем нам apache или nginx, если у них есть куча ненужных для конкретного проекта фич? А безопасность! Недавно вон какой опасный баг всплывал (heartbleed). Нужно непременно написать свой веб-сервер (без фреймворков типа Express), в одном файлике, в 100 строк, и поддерживать будет просто, и с обновлением не сломается. Это же критичное место проекта, нельзя его оставлять в опасности, а я ни разу не видел чтобы апач в гит коммитили. А HTML? Ключевая технология, а стандарт постоянно меняется. Хранить и актуальный браузер в гите!

                                                      А если серьёзно — самописные решения это стиль индусов, и кода из начала двухтысячных. Хотя бы потому что в случае самописного фреймворка при смене разработчика ему потребуется только вникнуть не только в бизнес-логику, а и в кучу «кастомных решений», которые ускорили проект на 1% (потому что без «лишнего кода») за счёт утроенного времени разработки.
                                                  • +2

                                                    Каждый раз мне приходит на ум одна и та же аналогия. Представьте, что вам нужно сконструировать некое механическое устройство. И тут ваш разработчик начинает вас убеждать, что использовать резьбовые соединения "по ГОСТу" — это удел ленивых.


                                                    Заголовок спойлера

                                                    "Мы расчитали диаметр и шаг резьбы точно под необходимые нагрузки. Это не какое-то универсальное решение. Это именно то, что нужно вам в этом изделии. Не работа по шаблону, а индивидуальный, только для вас выполненный заказ. В результате прочность будет на 2% выше, а вес на 1,5% меньше, чем у решения основанного на стандарте. Ну правда нам понадобится небольшое инструментальное производство, чтобы изготовить сверла нестандартных диаметров, метчики, плашки для нашей резьбы. Но смета вырастет всего лишь на какие-то 20%
                                                    Мы думаем еще делать головки болтов семигранными… или пятигранными, мы еще не решили, что будет лучше. Гайки будут шестигранными, но со скошенными гранями, т.к. профиль нашей резьбы несимметричный. Это на 100% соответствует вашим запросам. Да, потребуется изготовить нестандартный монтажный инструмент, но это выходит за рамки этого проекта. Конечно, мы можем спроектировать переходники на стандартные инструменты, но это повлечет увеличение сроков… Зато мы почти бесплатно получаем шурупы, которые монтажники могут забивать молотком, это позволит ускорить сборку готовых изделий минимум на 30%. Правда понадобится специальный молоток, а его мы не включили в смету… Что? Уже есть такие шурупы? И забиваются обычным молотком? Ну вы понимаете, как быстро все меняется в мире разработки! За всем не уследить… Но убирать работу по разработке наших шурупов из сметы мы уже не будем, мы же честно работали. Мы не виноваты, что нас опередили! Что? Нет… К бизнес-логике мы еще не приступали, надо же было изучить задачу, подготовить инфраструктуру. Зато теперь все будет готово очень быстро!"

                                                    • –3

                                                      Но нужно помнить, что "госты" во фронтэнде (достаточно длительное время) не были в стабильном состоянии. Если вы превели аналогию с болтами, то я не про это. Я про архитектуру, а вы про низкоуровневые компоненты. Первый мой комментарий был о том, что разработчик Vue незаконно навязывает идею, что Vanilla JS — это плохо, а я говорю о том, что хорошая архитектура может быть построена на чем угодно (пускай голый HTML и обвязка правильно спроектированного JS API вокруг этого всего). Просто разработик пытается выгородить свой инструмент за счет приуменьшения значимости чего то еще. Это выглядит не очень. Некоторые вещи можно делать в разы быстрей (факт!) вместо конфигурации сборки фреймверка, изучения того что по факту не понадобится, причем это не будет чем то с чем не знакомы другие разработчики, просто это будет скучно.

                                                      • –3

                                                        Простой пример: вам нужно несколько форм и список чего то на фронтэнде. Голый HTML, CSS и form over HTTP (возможно JS) прекрасно справятся с задачей быстро сделать MVP, только не нужно спорить что это сложнее, чем притащить Vue. А в некоторых случаях есть большие успешные проекты использующие подобную модель и не чувствующие большого дискомфорта. Я за рациональность и за "не тащить все что попало", если это действительно не требуется. Разработчик Vue откровенно лукавит. Не всегда есть задачи в которых не обойтись без Vue, обычным Vanilla JS.

                                                        • 0
                                                          Не всегда есть задачи в которых не обойтись без Vue, обычным Vanilla JS.
                                                          А в каком именно месте разработчик vue сказал что нет задач в которых можно обойтись без vue?

                                                          вам нужно несколько форм и список чего то на фронтэнде. Голый HTML, CSS и form over HTTP
                                                          MVP — вещь которую нужно сделать максимально быстро. Спорим что с помощью vue получится сильно быстрее и удобнее? И я не говорю о вебпаках и прочих сложностях — один (!) скрипт на страницу подключил, и погнал.
                                                          • +3
                                                            Мне как раз приходится поддерживать (чужой) самописный фреймверк и я знаю что это такое.
                                                            1. Полное отсутствие документации.
                                                            2. Крайне бедный функцонал и отсутствие гибкости (запилить нову фичу фактически нужно лезть в ядро фреймерка).
                                                            3. Куча неотловленных багов.
                                                            4. Дикая тормознутость (начальная загрузка страницы на слабых девайсах до 20 сек. хотя на десктопах пару секунд).
                                                            5. Отсутствие обновлений — ну естественно все же уже наигрались в мега-разработчиков и свалили и вследствие этого использование библиотек и версий языков 5-летней давности.
                                                            6. Самый дикий. Черезмерно честолюбивые разработчики на фоне доверявших им менеджеров раположили фрейм в своих приватных репах вседствии чего по невнимательности ли, по злому умыслу ли некоторые репы удаллились вследствии чего приходилось искать их чуть ли не копии на каких-то списанных компьютерах.

                                                            Но конечно любоая разработка настоящего и полезного фрема как например Vue или React начинается со «своего фремверка». Тут наверное важнен правильный менеджмент и оценка возможностей. Т.к. если группа из 3 разработчиков начинает гнуть линию в сторону своего фреймверка скорее всего они не понимают во что ввязываются. Т.к. тут важно три момента что любой фрейм это не просто гениальный код это как минимум
                                                            — тысячи человеко-часов работы
                                                            — тестирование, документация
                                                            — поддержка версий продукта, обновления в связи с выходом новых версий связанных продуктов.
                                                            • 0

                                                              Для того, чтобы создать фреймворк менеджмент не нужен. Вообще. Нужны правильные и свежие идеи и правильная реализация. Чаще всего фреймворки "умирают", по причине, того что новые идеи невозможно совместить с наличием старых. До сих пор выходят версионные upgrade устаревших фреймворков. Это делается по причине, того, что на них реализовано определенное количество продуктов. Нетестируемый фреймворк никто в продакшн не возьмет. Да документация тоже желательна. И как правило в минимальном генерируемом виде она присутствует всегда. Как и поддержка.

                                                              • 0
                                                                Согласен если говорить о хороших фреймерках. Я же говорю о плохих фреймерках, которых (чужих) только у меня на поддержке в настоящее время четыре. Всен они как один 1. Не документированы 2. Отстали лет на пять 3. Находятся в репозитариях к которым в лучшем случае просто нет доступа на редактирование а в худшем случае вообще нет никакого доступа (то есть проект невозможно развернуть). Я не думаю что это исключитеьная ситуация. Мне даже не так волнует, что при этом страдает поукпатель или ваделец бизнеса (хотя мы же работаем для клиента и на владельца). Мне просто тосклливо вспоминать тот период когда мне пришлось разбираться со всем этим хотя можно было бы более проивзодительно затратить это время на работу с нормальным фреймверком который бы мне обеспечил опыт работы с нормальными технологиями (тем же Vue)

                                                                А цмирают порой даже хорошие идеи из-за разных обстоятельств. Например не смог автор собрать вокруг себя сообщество. Или же была неверная маректинговая политика. Из последних крупных таких фейлов — прекращении разработки RethinkDB — и это уже после выхода в подакшн (есть еще надежда что это проект получит развтите как open sorce — хотя весьма слабая надежда).
                                                                • 0

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

                            • +1
                              Может кто подскажет по поводу ie11. Это относится к 2.х или же к планам 3.0?
                              • +1
                                Поддержку IE могут убрать как 2.x, так и в 3.x

                                В оригинале
                                We do have some plans for 3.0 but nothing concrete yet. The closest thing is 2.x-next which is a feature-compatible branch of 2.x with the internal reactivity system replaced using ES2015 Proxies. This will improve both performance and get rid of some caveats in the current implementation. It will drop support for IE11 and below but will allow us to leverage all the latest ES2015 features for a more efficient codebase.
                                • 0
                                  оу, а можно где-то этот оригинал почитать?
                                  • 0
                                    Тут (это другая сессия вопросов) говорится, что поддержку уберут в 3.0, но вторую версию продолжат параллельно поддерживать.
                                    • +1
                                      Вот английская версия
                              • +3
                                O: Хотя React это позволяет, я не думаю, что это хорошая идея.

                                Странное мнение. Как по мне это самый большой недостаток vuejs и вместе с тем нарушение компонентного подхода. Есть компоненты которые могут принимать данные через пропсы. Никто же нас не ограничивает в том сколько раз мы эти данные отобразили в компоненте, так почему теперь, когда вы решили передать компоненту несколько div-элементов в качестве пропса-слота, мы жестко ограничены в том что больше одного раза отобразить его в компоненте мы не можем? Вот в реакте сделали настоящий компонентный подход — передав элементы через пропсы (либо вложенные либо через отдельный пропс) <Component someContent={<div>...</div>}/> — компонент может сколько угодно раз отрендерить то что ему передали а не один раз как во vuejs.

                                • +2
                                  Тут разница в том, что в React передается VDOM-описание компонента, а не сам компонент — его-то и можно вот так клонировать.

                                  Во vue.js же компоненту передаются не VDOM-описания, а инстансы дочерних нод. Их клонировать невозможно.
                                  • 0

                                    Всё возможно клонировать. Но не в ноду, а в массив.

                                    • –2
                                      Покажите как будет выглядеть клонирование экземпляра компонента, который уже начал выполнение асинхронного запроса.
                                      • +1

                                        Всё и всегда это разные слова.

                                    • 0
                                      там не передаются инстансы — посмотрите в дебагере — слот заменяется на объекты VNode который является обычным объектом описывающий верстку — точно так же как в реакте. Другое дело что vuejs прикрепляет к этим объектам ссылки на инстансы компонентов, но это уже недостаток реализации самого vuejs
                                      • 0

                                        Похоже что они не прикрепляют ссылки, а наоборот по ссылкам на инстансы строится объект. Может я ошибаюсь.

                                  • +5
                                    cvvv sd brnnnnnvrfgv fbbhhhwjb vfvfn vvvvv hj
                                    • +12
                                      Народ, извините, полуторагодовалый «хакер» в лице моей дочурки решил высказат своё мнение за те 30 секунд, пока я ходил чай наливать :)
                                      • +10
                                        Строчка в резюме: "… в 1.5 года отправила первый коммент на хабр" )
                                        • 0
                                          … причём получила за него плюсы!
                                        • +1
                                          напомнило цитату с башорга
                                          ребенок подошел к ноутбуку, и постучал ладонями по клаве в руби конференции
                                          когда я подошел, в том коде уже разобрались и нашли ошибки
                                      • +1
                                        В: Будет ли возможно использовать компилятор однофайловых компонентов без модульных бандлеров?
                                        O: Да, у нас есть компилятор SFC (Однофайловых компонентов), мы надеемся что его можно будет использовать для создания внешних или внутрибраузерных компиляторов.

                                        Уже сейчас можно подключать .vue компоненты напрямую в браузере, что может упростить разработку, но в прод такое конечно пускать не рекомендуется. https://github.com/FranckFreiburger/http-vue-loader

                                        • 0

                                          Наконец таки Proxy, страсть как бесит невозможность полноценно использовать мапы и сеты

                                          • 0
                                            >O: Прогрессивная адаптивность: ты можешь использовать его как замену jQuery или создавать приложения любой сложности, используя CLI, роутер и Vuex.

                                            Вот это именно та приина, почему я перешёл с AngularJS на Vue.js. React и Angular невыносимо тяжело использовать в легаси-проектах. AngularJS можно просто подключить и потихоньку переписывать jquery-виджеты и добавлять новые, с Vue.JS можно поступать так же.
                                            • +2
                                              Во-первых, большое спасибо за переданный вопрос.
                                              Во-вторых, так как здесь собралось много разбирающихся в Vue людей, хочу спросить(не холивара окаянного ради): какие для вас преимущества предоставляет Vue по сравнению с React? Для меня это два основных пункта:
                                              1. Инфраструктура с рекомендуемыми командой разрабокти компонентами: vue-router, Vuex, vue-meta, и т.п. Под React есть множество хорошо проработанных роутеров, библиотек для управления состоянием, и выбирать нужные кирпичики для постройки приложения приходится дольше. Да-да, я жалуюсь на обилие возможностей :)
                                              2. Наличие SSR фреймворка без значимых проблем в архитектуре. Nuxt великолепен, очень прост в работе, в нем не встретишь всяких `dangerouslySetInnerHTML` для подключения стилей, он понимает TS и JSX, есть поддержка инфраструкутры Vue(Vuex, vue-meta, vue-i18n), очень хорошо проработано генерирование статики.

                                              Дальше плюсы React:
                                              1. Проще найти работу/работников
                                              2. React Native. Киллер-фича, как по мне. Он не создает впечетление полусырого продукта, есть внятная документация, есть активное англоговорящее сообщество. Для человека, у которого знания китайского языка(你好, weex) ограничаются матерными фразами из Firefly, это очень важно :)
                                              3. Поддержка Facebook. Эти ребята легко генерируют штуки вроде Draft.js, Yoga, Relay, и т.п. Они там вообще спят?
                                              • +1
                                                Не совсем понял Ваш вопрос. Nuxt ведь это же Next реализованный на vue. И в стандартной экосистеме react весьма развит — react- router, redux с некоторых пор.
                                                • 0
                                                  Тот, да не тот. Действительно, изначально Nuxt появился как «симметричный ответ», однако вскоре обогнал Next по возможностям, добавив генерирование статики, плагины, поддержку vue-meta и vue-router, систему шаблонов.
                                                  Некоторые из этих возможностей повторили уже в zeit, при чем те же плагины появились только в 5 версии. Но при этом в Next остается несколько архитектурных проблем, к примеру, моя «любимая» — это полная перерисовка с потерей состояния родительских компонентов при навигации на стороне клиента.
                                                  Как писал ранее, это все не ради холиваров, я стараюсь собрать побольше информации об особенностях обоих проектов, так что спасибо за замечание.
                                                  • 0
                                                    Современное состояние react такое что нему уже не нужен next тк с выходом react routee 4 и последних версий webpack для code splitting все можно реализовать на чистом react. В подтверждение этого тезиса я написал несколько сообщений на этом сайте и сделал тестовый проект в рамках проекта reakworld см github.com/gothinkster/realworld/issues/186 примечательно что весь код этого проекта основан на компиляции официальных доков react и webpack
                                                    • 0
                                                      Спасибо за пример, хорошая демонстрация прогресса развития React. Штука в том что и Next и Nuxt, и альтернативы вроде after.js(который очень похож на приведенный пример) представляют из себя такой же каркас приложения + конфигурация Webpack. Одна команда в CLI — и мы готовы работать с прототипом, все настроено, плюс есть всякие плюшки вроде модулей и плагинов, и уже решены многие проблемы вроде подключения TypeScript или flow, конфигурации метаданных, или генерирования статики в кластере.
                                                      В итоге, решая все эти проблемы на самодельном SSR-фреймворке мы придем к клону того же Next. Впрочем, Jared Palmer(создатель after.js) так и сделал, из-за наличия фундаментальных проблем в архитекутре Next.
                                              • 0
                                                Кстати про ssr или если точнее про uni ersal/isomorphic приложения. С учётом возможнстпй но react router и динамического import() от webpack реализовал universal приложение можно при помощи исключительно базового стандартного набора react который уже описан с примерами в документации reacf
                                                • +2
                                                  «Вдогонку» vue — это просто глоток свежего воздуха. Восхитительный проект. Я, когда решил посмотреть что там в мире фронтенда, потратил около 2 месяцев в попытках просто выбрать чем стоит заняться, angular или react. Посмотрел кучу видеокурсов на плюралсайте, прочитал море статей и так и не выбрал. В одной статье доказывают что лучше ангулар, в другой совершенно аргументированно говорится что рулит реакт. Устал выбирать. Смотрю код — и там понятно и там понятно. А куда идти — неясно. Душу воротит от jsx, и не хочется монструозности ангулара. И все это с огромным количеством (безусловно нужного и понятного) бойлерплейта.

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

                                                  Простите за комментарии восторга от вью. Стараюсь всюду оставлять свое мнение о вью, чтобы он, не дай бог, не помер. Спасибо за него. Простите за некоторый оффтоп. Просто хотел поблагодарить.
                                                  • +1
                                                    Люто плюсую. Надеюсь vue «выстрелит» не хуже реакта или ангуляра, потому что он по сравнению с ними — небо и земля.
                                                  • 0

                                                    Спасибо автору за сий труд. Для меня лично, многое стало понятнее, после ответа на этот вопрос:


                                                    В: Тони Хор (Tony Hoare) назвал null ошибкой на миллиард долларов. Какое было самое неудачное техническое решение в твоей карьере?
                                                    O: Было бы неплохо использовать TypeScript изначально, еще когда я начал переписывать код для Vue 2.x.

                                                    Может Vue.js 3.0 уже будет на TypeScript при примеру Angular?

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

                                                    Самое читаемое