Специальное примечание
ЭтоsimvisoКомментарии команды в JSConf.Asia оКомпромиссы при проектировании фреймворкаСодержание документов, переведенных по смежным темам, не является дословным переводом, а некоторые из них являются собственными размышлениями автора. А поделился автор Vue.js @youyuxi, адрес склада Vue:github.com/vuejs/vue
Давайте посмотрим, как узнать больше о компромиссах в дизайне фреймворка и о том, как Vue делает компромиссы непосредственно через сам фреймворк в текущей ситуации с трехсторонними фреймворками.
Адрес видео:
- [Обмен передовыми зарубежными технологиями, внешний интерфейс, китайские субтитры] Ю Юйси: поиск баланса в дизайне рамы
- [Обмен иностранными передовыми технологиями — передние — китайские субтитры] Ю Юйси: поиск баланса в дизайне фреймворка
Авторские права на перевод видеоsimvisoвсе
Внешний публичный аккаунт
Введение
Привет всем, приятно быть здесь. Как ваш день сегодня? Ok
Я почти уверен, что вы видели много лекций и знаете о сегодняшнем занятии, надеюсь, оно не будет слишком скучным, но я хотел бы кратко представиться тем, кто меня не знает.
Меня зовут Эван Ю, мой аккаунт в Твиттере — Ююкси, а мое китайское имя — Ююйси. Я являюсь независимым разработчиком с открытым исходным кодом с 2016 года.
То есть я уже три года независим и работаю с открытым исходным кодом, в основном работая над Vue.js.
Сколько из вас на самом деле используют его?
отлично
Это началось как мой побочный проект в 2013 году, и я поддерживаю его на постоянной основе с 2016 года. За годы работы с фреймворками я многому научился, и это также дало мне много информации о внутреннем дизайне. Некоторые из компромиссных решений, которые люди принимают при построении правильной структуры.
Кто из вас помнит то время в 2013 году, когда новый фреймворк JavaScript выходил каждый день, у NBC был список вроде 40, 50 фреймворков, которые создавали одно и то же, Vue был примерно таким же. смотрю на некоторые существующие решения и пытаюсь понять, что бы я сделал, если бы построил что-то подобное.
Но очевидно, что мои представления о том, что делать, сильно изменились с течением времени.
Но сегодня я собираюсь обсудить некоторые из этих открытий, особенно проектирование интерфейсной среды.
Во-вторых, выбор фреймворка.
Бьюсь об заклад, многие люди используют фреймворки, даже если вы не используете Vue, может быть, React, Angular или что-то еще.
Трудно представить создание сложного внешнего приложения без таких инструментов.
Конечно, вы все еще можете использовать простой JavaScript для выполнения этих задач, просто это займет у нас больше времени.
Думаю, когда большинство людей сталкиваются с этими фреймворками, они устают их сравнивать.
Всякий раз, когда средства массовой информации присылают мне статью о сравнении фреймворков, например «7 лучших новых фреймворков для использования в 2019 году», я обычно говорю: «Ха~».
Речь идет не о том, чтобы сказать: «А, я написал Vue, я хочу, чтобы люди использовали его, и я не хочу слышать о нем плохие вещи».
Но потому что в большинстве случаев эти статьи сосредоточены только на количестве звезд github, загрузках npm, статистике вопросов stackoverflow и другом контенте, который можно найти через Google в любое время и в любом месте.
Однако в какой-то степени эта статистика все же полезна, например, для маркетинга.
Но если попытаться принять техническое решение и попытаться конкурировать с устоявшимися на рынке технологиями, то корреляция этих цифр на определенном пороге становится все меньше и меньше.
Например, вы знаете, что большинство вещей, которые мы используем в производстве, вероятно, имеют рейтинг выше 10 000 звезд.
Но так ли важен этот порог? Сколько тысяч звезд в библиотеке?
Это не важно, вместо этого вас должны больше беспокоить некоторые внутренние технические решения, например, что является реальной причиной задержки выпуска этих фреймворков.
Итак, прежде чем углубиться, давайте сделаем шаг назад и подумаем об общей цели всех этих фреймворков, о той же цели, которую мы все пытаемся достичь. Все авторы фреймворков работают над целью «заставить вас создавать веб-приложения максимально эффективно», так почему же у нас вообще есть эти конкурирующие идеи разных сравнений, хороших или плохих?
Так почему же у нас так много разных фреймворков, у каждого из которых так много последователей?
Точно так же, как у React и Angular более полумиллиона пользователей.
Я не думаю, что о фреймворке можно судить просто по тому, хорош он или плох.
Люди склонны задавать вопросы, например, какой фреймворк лучше, пожалуйста, перестаньте спрашивать об этом.
Потому что трудно просто оценить один фреймворк как лучший, чем другой.
Мы все знаем, что проектирование программного обеспечения связано с компромиссами, На самом деле, в нашем текущем дизайне интерфейсной среды слишком много компромиссов, особенно в Интернете.
Потому что Интернет — это платформа, полная разнообразных элементов.
Мы можем создавать всевозможные интересные вещи в Интернете, от самых простых страниц до сложных программ, которые вы используете каждый день.
Таким образом, чтобы приспособиться ко всем этим ситуациям, производители должны идти на компромиссы по ряду направлений.
Сегодня я расскажу о некоторых из них, надеясь помочь вам в этой области. Но по причинам времени я, конечно, не могу глубоко вникать в каждую ситуацию.
Поэтому я остановлюсь только на части.
Первое: Сфера ответственности. По сути, как много фреймворк может сделать для вас.
Второе: механизм рендеринга. Когда вы используете фреймворк, как вы выражаете свой уровень представления и как фреймворк обрабатывает код? Как он на самом деле отображает вещи на странице?
Третье: государственный механизм. Изменяемый и неизменяемый, грязная проверка и отслеживание зависимостей, реактивный и реактивный. Собственно, у меня нет времени вникать в это, может быть, я смогу рассказать об этом в следующем обмене.
3. Сфера ответственности
На этот раз я углубляюсь в сферу ответственности. Посмотрите, что фреймворк может сделать для нас.
Мы разделим его на две части, с вашей точки зрения, этот фреймворк или библиотека могут делать некоторые уникальные мелочи, с нашей точки зрения, у нас будет много целостных соображений, взяв фреймворк в качестве примера, я бы попытался предоставить как можно больше функций. возможно.
1. Реакция и Угловой
Чтобы привести некоторые репрезентативные примеры, с которыми вы, возможно, знакомы, React близок к нативной библиотеке, в то время как Angular предоставляет больше абстракций.
Мало кто объяснит принцип ясно.Эта библиотека (React) ориентирована на предоставление очень простой модели пользовательского интерфейса.Она ориентирована на предоставление нативной реализации более низкого уровня, на основе которой вы можете построить собственный набор абстракций.
Круг ответственности (концепция дизайна) намеренно сужен, поэтому вся экосистема React очень активна.Среда сообщества React похожа на торговый центр (систему), набор экосистем, выстроенных снизу вверх вокруг базовой модели React.
С другой стороны, такие фреймворки, как Angular и другие, такие как Ember и aralia, больше похожи на соборы.
Они проектируются сверху вниз, и в процессе проектирования учитываются проблемы, с которыми могут столкнуться пользователи.
Например, проверка формы, анимационные эффекты и т. Д. Вы часто встречаетесь в ежедневном развитии.
Чтобы фреймворк предоставил нам решение, в начале проектирования фреймворка мы должны спроектировать его сверху вниз, то есть нам нужно подумать о том, как собрать все вместе, чтобы оно работало.
Намеренно расширяя сферу ответственности (философия дизайна), философия дизайна заключается в том, что когда вы пытаетесь решить проблему, вы можете найти решение в рамках.
Мы называем это большой и малой зоной ответственности (здесь две философии дизайна), и это ни хорошо, ни плохо.
Хочу еще раз подчеркнуть.
2. Небольшой объем
преимущество
Небольшой объем ответственности (философия дизайна) Преимущество заключается в том, что в начале нужно понять очень мало концепций.
И гибкость у него лучше. Поскольку фреймворки и библиотеки предоставляют только некоторые базовые нативные реализации, когда вам нужен класс компонента, он должен иметь некоторые реквизиты, а затем вы можете передавать данные через реквизиты и возвращать узлы VDOM.
Лучше всего то, что вы можете строить сколь угодно сложные системы.
У React очень активная экосистема, мы видим, что у него есть несколько очень гибких инструментов, и мы можем быть более креативными на их основе, и эти замечательные идеи исходят от React, сообщества React.
Кроме того, намеренное сужение сферы ответственности также позволяет командам иметь меньшие уровни обслуживания, чтобы они могли сосредоточиться на том, что они считают важным.
Таким образом, команда может сосредоточиться на изучении некоторых из наиболее творческих идей, поэтому React может тратить так много времени на параллельный режим, приостановку, React Hooks и все эти интересные вещи, которые были созданы за последние несколько недель или месяцев. предмет.
На самом деле они потратили годы, работая над этими вещами, просто потому, что они менее детализированы, и именно поэтому они могут больше сосредоточиться на этом.
недостаток
Конечно, у малогабаритной конструкции есть и очевидные недостатки.
Прежде всего, когда вы хотите использовать простую концепцию для решения уже сложной проблемы, вам нужно провести больше исследовательской работы.
Мне особенно нравится то, что сказал в своей речи этот парень Стил: «Развивай язык». Во время речи он взял себе за правило, что он должен употреблять во время речи односложные слова, а если хочешь употребить что-либо похожее на многосложное слово, то должен сначала определить его как односложное слово.
У него есть очень ограниченные, очень примитивные вещи для построения сложных идей.
Так что вы можете себе представить, что происходило с этой речью.
Раньше каждый раз, когда он хотел сказать понравившееся предложение, ему приходилось листать несколько слайдов, находить кучу слов и продолжать. Это немного похоже на создание очень сложного приложения производственного уровня на примитивном языке очень низкого уровня.
Вы должны построить много абстракций, чтобы повысить собственную эффективность в процессе.
Из-за этого со временем естественным образом появляются закономерности.
Когда мы говорим, что React действительно легко освоить, игнорируем ли мы тот факт, что вам более или менее нужно изучать Redux. Прежде чем считать себя настоящим разработчиком React, вы должны понимать компоненты HOC более высокого порядка, свойства рендеринга. А теперь вы изучите хуки и различные способы использования CSS в JS.
Хотя эти паттерны появились со временем, они стали полунеобходимыми состояниями. Вы действительно можете называть себя разработчиком React, если не знаете этого?
И эти вещи часто не имеют официальной документации. Если вы зайдете на официальный веб-сайт React, он не расскажет вам о конкретном решении CSS и JS, вам придется исследовать и изучать его самостоятельно.
Вот почему пользователи действительно должны иметь возможность учиться самостоятельно.
Сегодня слишком быстро растущие экосистемы могут привести к фрагментации и постоянной потере пользователей. Я верю, что последователи ранних идей Flux обнаружат, что каждый день внедряется новое решение Flux, и тогда каждая реализация Flux будет соответствовать новой реализации CSS/JS.
Это здорово, плюс в том, что всегда есть новые идеи. Кроме того, мы прилагаем все усилия, чтобы найти лучшее решение.
Тем не менее, это не хорошо для тех, кто просто хочет использовать его после того, как вы будете постоянно думать FOMO (страх пропустить, страх упустить), всегда боясь упустить следующую лучшую вещь.
3. Большой объем
Мы закончили говорить о недостатках небольших зон ответственности (философия дизайна). Теперь поговорим о некоторых преимуществах больших зон ответственности.
преимущество
Наиболее очевидным преимуществом является то, что наиболее распространенные проблемы могут быть решены путем построения абстрактных понятий.
Если вы просто хотите заняться разработкой, мне просто нужен маршрут, несколько анимаций и HTTP-клиент для получения некоторых данных.
Такие фреймворки, как Angular, предоставляют все необходимое для этого.
Правда в том, что вам не нужно искать информацию, вы просто следуете документации и используете фреймворк, и вы можете это сделать.
Централизованный дизайн обеспечивает собственную согласованность с экосистемой.
Когда вы сталкиваетесь с конкретной проблемой, вам не нужно искать какие-то разные решения, вам просто нужно посмотреть, что делает для вас фреймворк, и, скорее всего, у него (фреймворка) уже есть решение для нее. . Таким образом, вам не нужно копаться в так называемых 10 различных решениях и находить то, которое лучше всего подходит для вашего случая.
недостаток
Теперь поговорим о недостатках, этот недостаток в том, что будет более высокий порог обучения.
Чтобы поместить пиксель на экран, вам нужно пройти несколько шагов, что является большим препятствием для новичков. Для тех, кто не адаптирован, я не говорю о тех, кто адаптирован здесь, если вы не имеете опыта использования таких языков, как Java или C#, а только изучили HTML/CSS и JavaScript, когда вы видите документацию Angular на раз, вы можете чувствовать себя немного странно.
То же самое касается меня.
Затем он становится негибким, если встроенное решение не подходит для текущего варианта использования. Иногда вы можете подумать, что я просто хочу сделать это по-другому, но у меня нет способа его заменить.
В конце концов, фреймворк с широким кругом обязанностей и согласованным фреймворком может удорожить внедрение некоторых низкоуровневых новых идей, потому что слишком много мест для поддержания его согласованности.
Затем, когда вы захотите попробовать низкоуровневую идею, она повлияет на каждый компонент вашего проекта.
Так что делать такого рода «изменения» стало очень трудно. И если вы говорите в экосистеме React, что я внедряю хуки, чтобы сделать Redux более избыточным, то, друг мой, это не проблема, потому что React и его основная команда на самом деле не заботятся об этих решениях.
Вот и все.
4. Прогрессивный фреймворк Vue
Здесь на помощь приходит Vue. Но прежде чем мы углубимся в то, что Vue делает прямо сейчас, я хочу подчеркнуть, что я не говорю, что Vue лучше, чем любой из фреймворков.
Потому что быть посередине не обязательно лучше. Если NG и React сильно различаются по степени инкапсуляции функции, все, что должен сделать Vue, — это сузить разницу, и тогда вы обнаружите, что Vue на самом деле не самый лучший.
Таким образом, мы как бы откладываем немного, чтобы найти то, что мы считаем лучшим балансом. И каждый вариант удовлетворит потребности разных групп людей.
Это не то, что работает для всех.
Итак, я говорю о том, как Vue решает проблему сферы ответственности. Вы, наверное, знаете, что мы все называем Vue прогрессивным фреймворком.
преимущество
Прогрессивная сфера ответственности означает, что инфраструктура использует многоуровневую структуру, которая позволяет выбирать функции прогрессивным образом. То есть, если вам не нужна маршрутизация, если вам не нужно управление состоянием или даже если вам не нужны шаги сборки. Вы можете использовать Vue без каких-либо функций, вам просто нужно добавить vuejs на свою страницу, и вы можете сразу начать что-то делать.
Одним из препятствий для обучения, которое необходимо преодолеть новичкам, является требование, чтобы вы захватили пиксель с экрана и сначала удалили его.
Таким образом, низкий порог обучения действительно важен для нас, что также является миссией Vue: позволить большему количеству людей участвовать в веб-разработке, позволить людям изучить его (Vue) и сосредоточиться на разработке, а не позволить вам изучить куча Вы сейчас разрабатываете концепции, которые могут быть не нужны.
Но для этих текущих проблем мы все еще должны предоставить решения с помощью документации. Когда ваш вариант использования становится более сложным, когда вы собираетесь создать что-то более сложное, тогда вы понимаете, что вам нужен маршрут. Затем вы начинаете листать документы и обнаруживаете, что я действительно могу сделать это с помощью маршрутизации.
В то же время маршрута не требуется. И, если вы хотите, вы можете создать маршрут, потому что вы можете видеть, как построен маршрут Vue, и его основная реализация очень проста, поэтому, если вы хотите, вы можете быть на пути к его созданию.
недостаток
Это не идеально, потому что нам как посреднику нужно взвесить все за и против.
Так что, во-первых, даже несмотря на то, что мы будем внедрять новые модули (интегрировать маршрутизатор, vuex и т. д.), мы по-прежнему будем нести ответственность за их поддержку (маршрутизатор, vuex и т. д.)
Итак, мы разделили проблему объединения стороны обслуживания под большим объемом ответственности, если мы хотим что-то кардинально изменить, мы должны обеспечить согласованность всей экосистемы.
Это бремя обслуживания почти такое же, как и большой объем ответственности, в том числе потому, что мы предоставляем эти готовые решения.
Наша экосистема может быть не такой разнообразной, как небольшие обязанности. Потому что маленькие обязанности любят задавать вопросы сообществу. В нашем случае многие пользователи остались довольны нашим решением и им не пришлось тратить время на поиск ответов самостоятельно.
Это проблемная зона ответственности, я надеюсь, что вы сейчас понимаете, и я думаю, что это самая фундаментальная разница между реактивным, Vue и угловым углом.
Это его точное позиционирование, но также и определение наших различных групп пользователей.
Много раз мы сознательно решали, где расширяться. Как дизайнеры фреймворков, мы знаем, что ориентируемся в разных областях. Это хорошо, потому что на разных этапах разным разработчикам нужны разные решения, а наличие спецификации, охватывающей весь основной фреймворк, гарантирует, что каждый получит то, что хочет.
В-четвертых, механизм рендеринга
Хорошо, теперь давайте поговорим о механизме рендеринга.
То есть, как вы используете фреймворк для выражения своей структуры пользовательского интерфейса и как фреймворк отображает.
Во-первых, это очень сложно в операционном плане, это не что-то одно, это много слоев.
Проще говоря, думайте об этом как о JSX и шаблонах, а именно о функциях динамического рендеринга и сложных выражениях Vue, основанных на статических строках. Кроме того, есть выразительность и нативная производительность, а также планирование во время выполнения и предварительная оптимизация.
У некоторых людей может быть очень сильное мнение по этому поводу, но я лично думаю, что они очень похожи по своей природе, это просто разные стратегические выражения одной и той же основной идеи.
Возможно, это скорее технический компромисс.
С одной стороны, конечно, JSX React и все реактивоподобные библиотеки, использующие VDOM, вроде pre-act, stencil, infernal и т.д.
С другой стороны, есть решения на основе шаблонов. Я расскажу о Vue позже, но более репрезентативными решениями на основе шаблонов являются Svelte, а затем Ember.
Как видите, логотип на самом деле является логотипом glimmer.js, то есть glimmer — это механизм рендеринга в Ember, который также является движком рендеринга Angular.
В основном они основаны на шаблонах и компилируют шаблоны в относительно низкоуровневые инструкции для рендеринга контента.
1. Преимущества JSX/VDOM
Теперь поговорим о некоторых преимуществах JSX и VDOM.
Самое главное, что нам нравится в JSX или VDOM, это то, что они обладают полной выразительностью JavaScript.
Вам не нужно заботиться о грамматике, у вас есть язык в вашем распоряжении, вы можете получить полный опыт, вы можете делать все, что хотите.
Мало того, вы можете строить сколь угодно сложную логику на своих компонентах.
Он действительно мощный и неограниченный, и из-за этой функции React нравится многим.
Это также позволяет вам рассматривать слой представления как данные при рендеринге компонентов. Он что-то вернет, узел возврата представляет текущее состояние узла VDOM, эти данные можно использовать во многих интересных местах.
Нам полезно строить тестовые сценарии, вы можете получить снимок на основе виртуального дома, вы можете отрендерить его на цель, которую нужно заменить, что мы и делали, например, отрисовывать его на терминал, PDF , Canvas, WebGL и все, что вы можете придумать, что вы можете визуализировать.
Потому что представления — это данные, а с данными можно делать что угодно.
2. Недостатки JSX/VDOM
В настоящее время сам ВДОМ действительно дорог.
Если подумать, когда мы только появились, многие думали, не так ли это медленно? Ответ: Да, мы медленные, но достаточно быстрые!
Однако с чисто технической точки зрения вы выполняете много лишней работы. Рассмотрим этот простой шаблон, который выполняет большую часть работы, просто обновляя в нем привязку одного сообщения.
Мы должны обойти весь узел VDOM и выполнить diff в процессе, рекурсивно проходя вниз, пока вы не обновите его каким-либо образом.
Следовательно, стоимость отличия стандартного VDOM зависит от общего размера представления, а не от количества узлов, которые могут измениться.
Даже если у вас есть только один узел, можно запустить алгоритм Diff для этого VDOM.
Именно динамическая природа функции рендеринга затрудняет ее оптимизацию.
Под динамическим я подразумеваю, что вы можете написать такой код.
Вы можете использовать цикл for для создания массива дочерних элементов, затем передать его своему родителю, а затем делать все, что хотите, что означает, что вы можете сначала создать родителя, а затем передать его в его элементы Добавить дочерним элементам для внесения изменений.
Когда вы используете JavaScript, компилятор не может удержать все, что может произойти, потому что JavaScript очень динамичен.
Мы много пробовали в этой области, но нам по своей сути трудно обеспечить безопасную оптимизацию таким образом.
Дело не в том, что вы можете просто делать достаточно условных прогнозов, чем больше вы предсказываете намерения пользователя, тем легче будет оптимизировать код, что слишком сложно для Javascript.
В конце концов, решение React для этой части состоит не в том, чтобы сосредоточиться на ускорении самого VDOM, а в том, как улучшить воспринимаемую производительность.
Итак, React представил концепцию runtime-планирования concurrent time slicing, но эта схема runtime-планирования, весь файбер, почти такая же, как мы управляем собственным стеком, вроде входа и выхода из рендеринга, все выполняется долго.
Это означает, что всякий раз, когда вы загружаете React, вы должны загрузить весь необходимый код для обработки сложного планирования времени выполнения.
Это похоже на загрузку нескольких JavaScript-файлов по 20, 30 КБ.
Это, в свою очередь, немного повлияет на загрузку инициализации.
3. Преимущества шаблона компиляции
С другой стороны, если вы скомпилируете свой код рендеринга в шаблоне, он обычно создает более прямую инструкцию рендеринга и имеет лучшую собственную производительность. И вот почему: Шаблоны по определению являются очень ограниченным языком, и вы можете написать их только определенным образом.
Например, когда вы пишете такой код, мы сразу можем вам сказать, что порядок этих тегов p не изменится, id не изменится, классы не изменятся, изменится только это.
Статические (скомпилированные) и очень ограничительные на самом деле позволяют компилятору больше предугадывать ваши намерения, тем самым давая ему больше возможностей для оптимизации.
Давайте посмотрим, что делает SVELTE при компиляции кода.
Все остальное статично, может измениться только имя, этот p — функция обновления, единственное, что она делает — обновляет его (имя) при изменении имени.
Сравнивая SVELTE с тем, что делает алгоритм VDOM Diff, он только быстрее на порядок.
Таким образом, в зависимости от стратегии, компиляция шаблона или общий подход, основанный на компиляции, также может облегчить базовый план времени выполнения, поскольку ему не нужно все сложное планирование времени выполнения, чтобы попытаться заставить все выглядеть быстрее, потому что он и так быстр сам по себе.
Таким образом, SVELTE может создавать очень легкие выходные данные, не требуя тяжелой базовой среды выполнения для учета всех возможных вариантов поведения во время выполнения.
4. Недостатки шаблонной компиляции
Теперь давайте рассмотрим недостатки компиляции шаблонов. Очевидно, вы ограничены синтаксисом шаблона и теряете выразительную мощь JavaScript.
Итак, когда вы хотите создать действительно сложный компонент, вы задаетесь вопросом, насколько хорошо я могу сделать это в шаблоне, но компилятор этого не поддерживает.
К сожалению, если вы идете по пути полной компиляции, резервного варианта нет, потому что чем ниже уровень вывода компиляции, тем сложнее вам на самом деле подключить к нему свои пользовательские действия.
Так же, как компилятор opa, вы не можете углубиться в сборку, чтобы понять, почему это происходит, точно так же, как вы не можете использовать C для отладки своего ассемблерного кода.
Более легкая среда выполнения, более легкая базовая среда выполнения и, возможно, более подробный вывод для каждого шаблона. Потому что, когда вы пытаетесь сгенерировать максимально эффективный код, иногда вам приходится кодировать больше информации непосредственно на выходе.
Например, код, сгенерированный SVELTE, фактически создает все элементы в императивной форме, вставляя строку за строкой, и у них есть единственная функция для операции обновления.
Напротив, на основе VDOM результат таков, что вам нужна только одна строка, и эта (одна строка) является просто выражением, которое возвращает структуру VDOM.
При компиляции во время выполнения возникает стоимость компиляции во время выполнения.
Таким образом, для производственного варианта использования, скорее всего, вам нужно, чтобы пользователь заранее скомпилировал, что является жестким требованием для этапа сборки, что неизбежно, либо на лету, либо перед сборкой Компиляция, которая включает в себя все node.js цепочки инструментов, к которым мы уже более или менее привыкли. Но хорошо для новичков, если вы можете избежать этого.
Итак, опять же, Vue находится посередине, и я хочу еще раз подчеркнуть, что это не означает, что Vue — лучший.
Однако уникальность механизма рендеринга Vue заключается в том, что если вы фактически объедините шаблоны в VDOM, то у нас может быть как VDOM, так и компиляция шаблона.
Таким образом, мы можем в полной мере воспользоваться обоими.
Мы провели тесты производительности: на этапе компиляции генерируются специальные оптимизации, функции рендеринга мы не делаем, об этом я расскажу подробнее позже.
В версии vue2.x мы фактически не использовали эту возможность в полной мере, и текущая производительность VDOM в vue 2.x посредственная.
Но я расскажу о том, что 3.0 делает с этим, чтобы сделать его быстрее.
Есть и выразительность, можно пропустить слой шаблона и сразу перейти к функции рендеринга, напрямую используя JavaScript для выполнения сколь угодно сложной логики.
Поэтому, когда вы чувствуете, что ограничены шаблонами, это дает вам выход.
Недостатком является то, что, хотя сейчас мы действительно быстры, мы, вероятно, никогда не почувствуем себя быстрее, чем SVELTE. Потому что вывод SVELTE — это обычный JavaScript. Однако, чтобы быть совместимым с написанными от руки функциями рендеринга, Vue по-прежнему необходимо поддерживать VDOM, поэтому константы необходимы. С другой стороны, это также создает разногласия, т.е. какой из них я должен использовать?
Таким образом, многие пользователи могут иметь доступ к функции рендеринга, но никогда не использовали ее.
Теперь давайте рассмотрим то, что мы делаем с файлами, компилируем шаблоны Vue в виртуальный дом, который работает быстрее, чем обычный виртуальный дом.
Это то, что мы только что обсудили, изменится только один узел этого шаблона. В идеале нам просто нужно обновить строку сообщения напрямую, структура узла статична и никогда не меняется, есть только один динамический узел.
Итак, если мы изучим этот шаблон, мы увидим, что это очень простой пример.
Это становится немного сложнее, когда у нас есть что-то вроде v-if, которое мы называем структурными директивами в JSX, которые эквивалентны троичным выражениям, которые возвращают разные результаты в зависимости от условий.
Теперь это создает динамическую структуру узла, поскольку узел может или не может существовать.
Чтобы обработать этот простой алгоритм VDOM Diff, предполагая, что список узлов изменился, нам нужно сравнить два подмассива.
Но если мы попытаемся разбить его, то увидим, что v-if разбивает шаблон на два вложенных блока.
Давайте подумаем об этом, если вы думаете о самом v-if как об узле, внешний блок будет иметь статическое содержимое узла, структуру узла.
Внутри v-if тоже статично. У нас есть два статических блока, внутри каждого блока вам не нужно выполнять операцию diff для порядка узлов, единственное, что вам нужно сделать, это сгладить массив внутри блока.
Точно так же для каждой итерации v-for мы также можем думать о ней как о статическом блоке.
Итак, если у вас есть больше похоже на V-IF, V-для встроенной формулировки, вы просто разделите в дополнительный вложенный код блока.
Итак, мы получаем то, что я называю деревом блоков, которое является просто игрой.
Но дерево блоков — это список блоков вложенных блоков, потому что каждый блок имеет полностью статическую структуру узлов, поэтому нет необходимости использовать рекурсию на нижний уровень для сравнения подсписка.
В каждом блоке у вас есть только один узел плоского массива, который может измениться, и мы предоставляем другие организационные подсказки. Например, если узел имеет только одну привязку динамического класса, у нас есть ярлык, где вы можете просто установить класс напрямую, а затем продолжить, не изменяя реквизиты.
Поэтому для Diff одного и того же шаблона будут очевидные различия между версией vue2.x и версией vue3.x. В версии vue2.x нам нужно выполнить полную операцию Diff, в версии vue3.x мы просто используем один плоский массив (содержащий динамический текстовый узел), и единственное, что вам нужно сделать, это сравнить, изменился ли текст. .
В связи с этим мы сделали простой бенчмарк (бенчмарк), сделав 1000 v-for list итераций, каждый блок имеет 12 dom-узлов, всего 12000 dom-узлов, каждая итерация будет динамически связывать какие-то классы или текст.
Затем делаем 4000 динамических привязок на странице и обновляем ее. Мы сделали 100 запусков, в текущей версии 2.6 время обновления составляет 36 мс, а в текущей версии 3.0 с использованием новой стратегии компиляции это занимает всего около 5,4 мс, что более чем в 6 раз быстрее, чем раньше.
Обратите внимание, что (данные) только этот тест. Реальных приложений у вас может быть другое количество, но более-менее оно будет быстрее, что является ориентиром.
5. Статус
Потом в госмеханизме у меня может не быть времени особо вникать в этот вопрос, может это тема для другого разговора.
6. Резюме
Но если подытожить, когда вы пытаетесь спроектировать фреймворк, где самое приятное?
Возможно, этот вопрос следует переформулировать. Существует ли идеальный баланс? Это единственный идеальный баланс или даже лучший баланс для JS-разработчиков в целом?
Потому что, как и все мы, мы пытаемся оптимизировать что-то конкретное и необычное, что мы создаем.
Преимущество SVELTE, например, заключается в создании очень легкого кода, когда вы создаете что-то маленькое. Он также очень быстрый и потребляет очень мало памяти, поэтому его можно использовать даже как встроенное устройство.
Но если в вашем собственном случае у вас может быть более сложная реализация, у вас больше компонентов, вам нужна выразительность JavaScript, а также вам нужна большая производительность от шаблонов, то (в этом случае) вы можете использовать Vue. Если вас не волнует какая-то экстремальная производительность и вы говорите, что мне просто нравится экосистема React, вы можете использовать React.
Вы также можете выбрать их все (кадры). Я думаю, хорошо, что домен фреймворка может быть похож на многомерное пространство с множеством сущностей, которые постоянно меняются, это все равно, что думать о каждом фреймворке как о сущности, пытающейся найти баланс. Я уверен, что у нас всегда будет много людей, пытающихся выяснить, как лучше поступить.
Как разработчик, вы можете перемещаться между этими сущностями, и тогда вас может привлечь одна из них, а иногда вы можете просто прыгать и пытаться найти ту, которая подходит вам лучше всего. Я знаю, что это хорошо.
Но пользователю очень сложно найти правильный путь в этом многомерном пространстве.
Но если вы хотите выбрать правильный фреймворк, сложность заключается в том, что вы должны понимать некоторые внутренние компромиссы, которые делает фреймворк, вы должны знать, в каком направлении движется фреймворк, и знать, согласуется ли он с тем, что вы хотите. строительство.
Надеюсь, темы, затронутые в этом выступлении, помогут вам, когда вы попытаетесь выбрать фреймворк в будущем или когда будете рассказывать другим, как выбирать фреймворк.
Благодарю.