Какие проблемы решают интерфейсные фреймворки? В чем уникальное очарование Vue среди множества фреймворков? Почему основная идея, лежащая в основе этого, называется инкрементной? Насколько хорош Vue? Какие улучшения были внесены в недавно выпущенный Vue2.0? Какое сотрудничество Vue и Weex?
20 октября 2016 г. Ю Юйси, основатель Vue Technology LLC и автор Vue.js, выступил с речью под названием «Vue 2.0 — прогрессивное интерфейсное решение» на конференции QCon в Шанхае, подробно изложив вышеперечисленные проблемы.
Во-первых, зачем нужна структура 1. Существуют фреймворки, помогающие нам справляться со сложностьюСуществует много интерфейсных фреймворков, так зачем нужен фреймворк? Мое личное мнение,Фреймворки существуют, чтобы помочь нам справиться со сложностью. Когда нам нужно решить какие-то фронтенд-инженерные задачи, эти задачи будут иметь разную сложность. Если вы имеете дело с очень сложными требованиями с помощью слишком примитивных инструментов, это сильно повлияет на вашу производительность. Таким образом, сама структура должна помочь нам абстрагировать некоторые повторяющиеся и проверенные шаблоны в пакет API, который был разработан для вас, чтобы помочь нам справиться с этими сложными проблемами.
2. Сам фреймворк имеет сложностьОднако сам фреймворк также усложняет работу. Я считаю, что когда вы исследуете различные фреймворки или изучаете различные фреймворки, вы столкнетесь с проблемой кривой обучения — некоторые фреймворки заставят людей какое-то время не знать, с чего начать.
Вот абстрактный вопрос, т.Сложность создаваемого приложения по сравнению со сложностью используемого фреймворка.
Далее, даСобственная сложность решаемой проблемы по сравнению со сложностью используемых инструментов.
Сложность инструмента можно понимать как инвестиции, которые мы делаем, чтобы справиться с внутренней сложностью проблемы. Почему это называется инвестициями? Это потому, что если вы инвестируете слишком мало, вы не сможете добиться эффекта масштаба и не получите разумной отдачи. Это похоже на стартап-компанию, привлекающую венчурный капитал, очень важный вопрос, сколько инвестиций. Если проблема, которую нужно решить, сама по себе очень сложна, и вы решаете ее с помощью слишком примитивного инструмента, вы столкнетесь с проблемами, когда инструмент слишком слаб, а производительность страдает.
Наоборот, если решаемая задача несложная, но вы используете очень сложную структуру, то это эквивалентно использованию ножа, чтобы убить курицу.Вы столкнетесь с побочными эффектами, вызванными сложностью инструмента, а не только потеря самого инструмента.Это также увеличит различные проблемы, такие как затраты на обучение, затраты на запуск и реальную эффективность разработки.
«Выберите правильный инструмент для работы» — в зарубежных странах при обсуждении с разработчиками некоторых вопросов выбора фреймворка каждый скажет эту фразу — все зависит от сцены. Потому что по сравнению с нативной разработкой или режимом настольной разработки фронтенд-разработки у него есть своя уникальность, и он не так фиксирован, как есть. В Интернете приложения могут иметь множество форм, и разные формы веб-приложений могут иметь совершенно разную степень сложности. Вот почему я говорю о сложности инструмента и сложности приложения.
5. Как посмотреть на сложность фронтенд-фреймворкаНынешняя фронтенд-разработка становится все более и более инженерной, и практические задачи, которые нам нужно решать, тоже другие. Анализируем следующий рисунок.
нам может понадобиться в любом случаеВозможности декларативного рендеринга, и хотите максимально избежать ручных операций или переменныхимперативная операция, надеясь сделать операцию обновления DOM как можно более автоматической, и она должна автоматически обновляться до правильного состояния при изменении состояния; нам нужносистема компонентов, который делит большой интерфейс на более мелкие управляемые блоки;Маршрутизация клиентов—— Это для одностраничных приложений. Если вы этого не сделаете, вам это не нужно. Если вам нужно сделать одностраничное приложение, вам нужно иметь URL-адрес, соответствующий состоянию приложения, и вам нужно решение для маршрутизации;Крупномасштабное государственное управление- Когда приложение простое, для решения проблемы может потребоваться очень простое сопоставление состояния и интерфейса, но когда приложение становится большим, при совместной работе нескольких человек оно будет включать совместное использование между несколькими компонентами, несколькими компонентами. изменить одно и то же состояние, и как сделать так, чтобы такое крупномасштабное приложение могло по-прежнему работать эффективно, что включает в себя проблему управления крупномасштабным состоянием, конечно, также включает в себя ремонтопригодность иинструменты для сборки. Теперь, если вы посмотрите на будущее интерфейса, когда HTTP2 станет широко распространенным, это может привести к революции в инструментах сборки. Но на данный момент, особенно в сетевой среде Китая, упаковка и инженерное строительство по-прежнему являются очень важным и неизбежным звеном.
2. Основной анализ структурыДавайте рассмотрим проблемы, решаемые некоторыми существующими основными фреймворками, от меньшего к большему. Это число предназначено не для оценки качества фреймворка, а для того, чтобы увидеть, сколько контента он охватывает с точки зрения дизайна.
-
чистый шаблонизатор: По крайней мере, это чистый шаблонизатор, только сопоставление состояния с интерфейсом.
-
Реагировать и Вью: На самом деле, оба они очень сосредоточены только на отображении состояния на интерфейс и компонентов.
-
Backbone: Это даст вам дополнительные архитектурные рекомендации, например, позволит вам наслаивать.
-
Angular: Он делает больше вещей, у него есть своя маршрутизация, они будут включены в него.
-
Ember: По сравнению с Angular, Ember делает это более тщательно. Ember верит в соглашение, а не в конфигурацию. Он спроектирует и упакует все для вас, и вы сможете использовать его из коробки.
-
Meteor: Meteor - это просто крайность, он включает в себя все, от начала до конца, от внешнего интерфейса до уровня данных и базы данных, все упаковано для вас.
Благодаря простому анализу мы можем почувствовать, что,Фреймворк, который делает меньше, не обязательно лучше, чем фреймворк, который делает больше, что отражает компромисс.. Тем не менее, фреймворки, которые делают меньше, могут дать вам больше гибкости, но вам нужно делать больше выбора; фреймворки, которые делают больше, более навязчивы, дороже в освоении и менее гибки. Как только вы выберете интрузивный фреймворк, у вас не будет возможности переключиться на другие решения, которые вы предпочитаете использовать для каких-то мелких деталей.
так,У React и Vue есть общая черта. У них есть свои вспомогательные инструменты. Хотя ядро решает только небольшую проблему, у них есть экосистема и поддерживающие дополнительные инструменты. Когда вы добавляете их один за другим, вы можете быть объединены в очень мощные стеки. которые могут охватывать другие вопросы, охватываемые этими более полными структурами.
Такая схема конфигурации позволяет гибко масштабировать сложность инструмента при построении стека технологий: когда собственная сложность решаемой задачи очень мала, можно использовать только эти самые простые функции ядра; Для более сложного приложения добавьте соответствующие инструменты. Например, маршрутизация необходима только при создании одностраничного приложения; крупномасштабное решение для управления состоянием может потребоваться при создании довольно большого приложения, которое включает многокомпонентное совместное использование состояния и совместную работу нескольких разработчиков.
Чисто сложное одностраничное приложение на самом деле сильно отличается от инженерного стека, который необходимо выбрать для встраивания интерактивного содержимого в статическую страницу, отображаемую серверной частью. Вот почему я думаю,Ядро + экологический стек будет более гибким стеком в общем выборе..
И React, и Vue выбирают этот режим. Команда Facebook сосредоточена только на самом React, но сообщество React очень активно и предлагает множество сторонних решений. Нельзя отрицать, что сообщество React в настоящее время является самым активным сообществом.Многие отличные идеи и задумки, в том числе решения для управления состоянием, впервые были рождены сообществом React. Однако эта активность сообщества приносит и определенную степень побочного эффекта, то есть времена меняются слишком быстро, новая версия выходит через три дня, а раньше были десятки разных решений одной и той же проблемы. Это заставляет тратить много времени на идентификацию выбранных компонентов при построении собственного стека. В то же время, поскольку эти библиотеки во всей экосистеме не планируются и не проектируются единой командой, сложно учесть коллаборацию между разными библиотеками, что приведет к проблемам с обкаткой.
В то же время это также заставляет многих разработчиков жаловаться на «усталость от JavaScript», говоря, что в экосистеме JS слишком много всего. что очень утомляет. Конечно, многие думают, что это проявление процветания экосистемы, но это ставит всех перед проблемой сложного выбора.
Дэн Абрамов, ранее очень активный разработчик в сообществе React, присоединился к команде React. Однажды он написал в Твиттере, что из-за чрезмерной модульности ему очень сложно создать единый интерфейс. Это предложение означает, что каждая часть всего стека экосистемы React исходит от разных разработчиков, и при попытке интегрировать их все вместе возникает множество фрагментарных проблем. Это его эмоции, когда он впервые начал работать над текущим официальным CLI React.Он пытался интегрировать различные вещи от сообщества в одну полку, поэтому он столкнулся со многими такими проблемами. Я вовсе не хочу здесь отрицать процветание экосистемы React, я просто думаю, что есть другой вариант, то есть мы можем сделать прогрессивный фреймворк, а это направление выбирает Vue.
Следующие данные могут отражать статус-кво Vue.js.
-
Некоторое время назад он превысил 30 000 звезд (как показано на рисунке ниже), а общее количество загрузок превысило миллион.
-
Ежемесячное количество пользователей на официальном сайте составляет 260 000 человек, что не должно включать данные по Китаю. Количество еженедельно активных пользователей официального плагина разработчика составляет около 55 000 человек. Эти данные являются наиболее убедительными, на мой взгляд. Пользователи Vue, которые устанавливают и используют плагин разработчика, должны часто использовать Vue в производственной среде.
Соответствующие данные Google Search Trends показаны на рисунке ниже. На рисунке зеленый — это данные Backbone, желтый — Ember, красный — React, а синий — Vue. Видно, что React и Vue быстро развивались за последние два года. Видно, что кривая Vue началась очень рано, она началась в 2013 году, но рост был относительно низким долгое время. Поскольку в то время я все еще работал в Google, Vue в основном работал как личный проект. За последние год или два Vue совершил очень большой прорыв. На этой картинке нет Angular, потому что количество Angular все равно очень велико, если его вставить, то он сломает таблицу.
Эти данные не совсем отражают текущую популярность фреймворка, но имеют определенное справочное значение. Вы можете видеть, что React набирает обороты. Из кривой Vue также видно, что темпы его роста продолжают расти.
2. Vue-позиционированиеВ процессе работы над Vue я все время думал о его позиционировании.Теперь я думаю, что отличие его от других фреймворков заключается в прогрессивной идее, то есть «Progressive» — это слово в английском языке определяется как прогрессивный, шаг шаг за шагом Один шаг, а не то, что вы должны использовать все за один раз.
3. Вью-дизайнДалее вернемся к картинке, которую мы рассматривали ранее:
Vue с точки зрения дизайна,Хотя он может охватывать все на этой картинке, вам не нужно использовать все с самого начала., потому что это не нужно. Это необязательно как с точки зрения обучения, так и с практической точки зрения. Декларативная система рендеринга и композиции включена в основную библиотеку Vue, и существуют специальные решения для маршрутизации на стороне клиента, управления состоянием и инструментов построения. Эти решения независимы друг от друга, и вы можете выбрать любые другие компоненты исходя из ядра, не все из них нужно интегрировать.
4. Реализация VueДалее давайте поговорим об этих конкретных концепциях и о том, как Vue реализует эти концепции в деталях.
(1) Декларативное представление
Почти все фреймворки теперь согласны с этой точкой зрения — DOM должен быть как можно более функциональным отображением в состояние. Состояние — это единственная истина, а состояние DOM — это просто карта состояния данных. Как показано на рисунке ниже, вся логика должна максимально выполняться на уровне состояния.При изменении состояния представление должно автоматически обновляться до разумного состояния с помощью фреймворка, а не выбирать его вручную, когда вы наблюдать за изменением данных элемента, а затем императивно изменять его свойства.
На рисунке ниже пример шаблона для Vue.Если вы не использовали Vue, то можете примерно почувствовать, что это за понятие.
На самом деле Vue похож на Angular с точки зрения синтаксиса шаблонов. В Vue1.0 реализация шаблона аналогична Angular.Как показано на рисунке ниже, шаблон напрямую анализируется в дереве DOM в браузере, а затем проходит по дереву для извлечения различных привязок.
В Vue2.0 принципиально изменена реализация слоя рендеринга, то есть введение виртуального DOM.
С точки зрения архитектуры, Vue2.0 по-прежнему пишет тот же шаблон., (Vue2.0 был выпущен некоторое время назад, конкретные отчеты:Легче и быстрее Vue.js 2.0). В крайнем левом углу синтаксис шаблонов Vue 2.0 и 1.0 в основном совместим.После того, как компилятор Vue скомпилирует шаблоны, он компилирует эти шаблоны в функцию рендеринга.. И когда функция вызывается, она будет отображать и возвращатьдерево виртуального DOM. Это дерево очень легковесно, и его задача — описать состояние интерфейса в данный момент. когда мыПосле того, как у вас есть это виртуальное дерево, передайте его функции исправления, которая отвечает за фактическое применение этих виртуальных DOM к реальному DOM.. Во время этого процесса у Vue есть собственная реактивная система для обнаружения источников данных, на которые он полагается в процессе рендеринга. В процессе рендеринга после обнаружения источника данных изменение источника данных может быть точно воспринято. Затем вы можете повторно выполнить рендеринг по мере необходимости. При повторном рендеринге создается новое дерево, и, сравнивая новое дерево со старым деревом, можно получить окончательные изменения, которые следует применить к реальному DOM. Наконец, изменения применяются с помощью функции исправления.
Основная причина этого в том, что,В браузере JavaScript работает очень быстро в современных движках, но сам DOM очень медленный.. Когда вы вызываете нативный DOM API, браузеру необходимо связаться с нативной реализацией DOM в контексте движка JavaScript, и этот процесс приводит к значительным потерям производительности. Следовательно, важным соображением является то, что трудоемкие операции должны выполняться как можно чаще в чистых вычислениях, чтобы гарантировать, что окончательные расчетные операции, которые должны фактически касаться реального DOM, будут минимальными.
Смотри нижефункция рендеринга.用过React的开发者可能知道,React是没有模板的,直接就是一个渲染函数,它中间返回的就是一个虚拟DOM树。 JSX实际就是一套用于让我们更简单地去描述树状结构的语法糖。
Как показано на рисунке ниже, в Vue 2.0 видно, что когда, например, шаблон слева скомпилирован Vue, он станет тем, что справа.
Эта функция аналогична функции, которая создает фиктивный элемент, мы можем дать ему имя, описать атрибуты и, возможно, другие данные, которые он должен иметь. Тогда этот последний параметр представляет собой массив, содержащий дочерние элементы виртуального элемента. В общем, компилятор 2.0 делает именно это.
В то же время в Vue2.0 пользователи могут пропустить слой шаблона, чтобы вручную написать функции рендеринга, а также имеется дополнительная поддержка JSX. У шаблонов и JSX есть свои плюсы и минусы с точки зрения предпочтений разработчика и преимуществ разработчика. Шаблоны ближе к нашему HTML, позволяя нам более интуитивно думать о семантической структуре и лучше сочетать написание CSS. JSX и функции прямого рендеринга, поскольку они являются настоящим JavaScript, обладают всеми возможностями самого языка, могут делать сложные логические суждения и выборочно возвращать конечную структуру DOM, которую нужно вернуть.
Итак, в Vue2.0 оба являются необязательными. В большинстве случаев используются шаблоны, но в тех случаях, когда требуется сложная логика, используются функции рендеринга.В маршрутизации и внутренней практике Vue2.0 используется большое количество функций рендеринга для создания сложных абстрактных компонентов., такие как компоненты анимации перехода и компоненты ссылок в маршрутизации, реализуются с функциями рендеринга, сохраняя при этом собственную систему отслеживания зависимостей.
Как показано на рисунке ниже, отслеживание зависимостей Vue проходит через ES5.Object.definePropertyреализация метода. Например, мы даем ему нативный объект, Vue просматривает свойства этого объекта данных, а затем выполняет преобразование свойств. Каждое свойство преобразуется в геттер и сеттер. В то же время у каждого компонента будет соответствующий объект-наблюдатель, который отвечает за запись того, какие свойства данных используются при рендеринге текущего компонента.
Например, когда A.B используется в функции рендеринга, это вызовет соответствующий геттер. Конкретные моменты всего процесса рендеринга следующие:
-
Когда используется свойство данных, срабатывает геттер, и свойство записывается наблюдателем как зависимость.
-
Когда вся функция будет визуализирована, каждый используемый атрибут данных будет зарегистрирован.
-
Когда соответствующие данные изменяются, например, присваивается новое значение, сеттер будет запущен, чтобы уведомить объект данных об изменении соответствующих данных.
-
В это время соответствующий компонент будет уведомлен о том, что его зависимость от данных изменилась и требует повторного рендеринга.
-
Соответствующий компонент снова активирует функцию рендеринга, чтобы сгенерировать виртуальный DOM для обновления DOM.
Такой процесс сильно отличается от некоторых основных фреймворков, таких как React. В React, когда компонент сложный, вам нужно использоватьshouldComponentUpdateЗаймитесь оптимизацией. Однако у него также есть свои подводные камни, такие как обеспечение того, чтобы компоненты ниже компонента не зависели от внешнего состояния. Хотя в большинстве случаев этого достаточно, очень сложно оптимизировать этот процесс при столкновении с очень сложными приложениями и узкими местами в производительности.
Как показано на рисунке ниже, благодаря наличию в Vue системы отслеживания зависимостей, при изменении каких-либо данных каждый компонент Vue точно знает, нужно ли его перерисовывать, поэтому ручная оптимизация не требуется. При рендеринге этих компонентов с помощью Vue данные изменяются, и соответствующие компоненты в основном устраняют необходимость ручной оптимизации.
(2) Компонентная система
Я считаю, что практически все современные фреймворки идут по пути компонентизации, и веб-компоненты используют эту практику на уровне спецификации. Основные фреймворки имеют разные пакеты, ноОсновная идея та же, сопоставляя структуру пользовательского интерфейса с соответствующим деревом компонентов.,Как показано ниже.
В Vue связь между родительским и дочерним компонентами осуществляется через свойства. Односторонняя передача от родителя к дочернему; и если дочерний компонент хочет иметь побочные эффекты в родительском компоненте, ему необходимо отправлять события. Это формирует базовую модель связи родитель-потомок, и есть дополнительные решения, когда задействовано крупномасштабное управление состоянием, о которых будет сказано позже.
После того, как компоненты Vue введены в инструмент сборки,Концепция компонента одного файла, как показано на рисунке ниже, является этим файлом Vue. В одном и том же файле Vue вы можете одновременно написать шаблон, сценарий и стиль и поместить три вещи в одну. При этом однофайловые компоненты Vue принципиально отличаются от Web Components, которые реализованы на основе инструментов сборки. Преимуществом этого является возможность сборки для большего анализа этих однофайловых компонентов и использования отдельных процессоров в каждом языковом блоке, как будет обсуждаться позже.
(3) Маршрутизация клиентов
При создании приложения с очень высокой сложностью интерфейса у него будет много состояний, очевидно, что такое приложение не может обновлять страницу в качестве обратной связи после каждой операции. Это требует, чтобы приложение имело несколько сложных состояний, и эти состояния также соответствуют URL-адресам. Существует важная функция, называемая глубокими ссылками, то есть, когда пользователь просматривает URL-адрес, а затем передает его другому человеку или копирует его для повторного открытия, приложение должно напрямую отображать состояние, соответствующее URL-адресу. Это означает, что существует сопоставление между URL-адресом приложения и состоянием дерева компонентов, и за декларативное соответствие этого сопоставления отвечает маршрутизация на стороне клиента.
Если вы хотите реализовать такой маршрут самостоятельно, это кажется очень простым, используйте хэш для его моделирования, и вы сможете быстро сделать очень простой маршрут самостоятельно. Но на самом деле маршрутизация на стороне клиента включает в себя гораздо более сложные вопросы, как показано на рисунке ниже.
Может быть несколько разных выходов для маршрутов на одном уровне, сложные правила сопоставления URL-адресов и т. д. Если эти задачи реализуются одна за другой сами по себе, сложность очень высока. Vue в основном имеет соответствующие решения (router.vuejs.org). С помощью Webpack также можно реализовать ленивую загрузку на основе маршрута.Когда компонент, соответствующий пути, упакован, он будет разделен на другую часть и будет загружен только при доступе к маршруту. Есть соответствующие решения, а также примеры.
(4) Управление статусом
Когда дело доходит до управления состоянием, оно, по сути, превращает все приложение в цикл, как показано на рисунке ниже. Когда Facebook впервые предложил концепцию Flux, она тоже была очень расплывчатой, а официальную реализацию было сложно использовать. Поэтому сообщество провело различные исследования. Три элемента на рисунке представляют собой односторонний поток данных: состояние управляет визуализацией представления, а действия пользователя в представлении генерируют действия, которые изменяют состояние и вызывают повторную визуализацию представления.
Один компонент Vue на самом деле уже имеет такую структуру. Но когда несколько таких компонентов совпадают, возникает проблема. У каждого компонента есть свое состояние, но не обязательно однозначное соответствие между состоянием всего приложения и компонентов. Это состояние может быть глобальным состоянием. Так где именно государство? Большинство решений состоит в том, чтобы извлечь это состояние из дерева компонентов и поместить его в глобальное хранилище. Vuex тоже это делает, но он специализирован для Vue. Мы видим, что крайний левый компонент — это компонент Vue, в большинстве случаев эти компоненты больше не имеют приватного состояния, а получают состояние из глобального Store. Действия С Mutations сложнее объяснить в одном-двух предложениях, вообще говоря, когда меняется состояние приложения, его нужно явно запускать через Mutations, а Actions отвечает за асинхронность и другие побочные эффекты. Так как Мутации будут записаны, мы можем отправить эти записи в инструмент для анализа и даже отката. Это позволяет нам лучше понимать изменения состояния в больших приложениях при обнаружении ошибок. Дополнительные сведения см. также в официальной документации (vuex.vuejs.org).
(5) Инструменты сборки
Что касается инструментов сборки, у Vue есть официальный глобально установленный vue-cli. Здесь опечатка. После глобальной установки мы можем использовать команду vue для создания нового проекта.Разница между интерфейсом командной строки Vue и другими интерфейсами командной строки заключается в том, что существует несколько необязательных шаблонов, как простых, так и сложных. Минималистская конфигурация, более быстрая установка и быстрый запуск. Он также имеет более полный шаблон, охватывающий все, включая модульное тестирование, однако он также более сложен, что, в свою очередь, предполагает выбор правильного уровня сложности в зависимости от варианта использования. После создания всех шаблонов скрипты сборки выполняются через npm скрипты.При установке зависимостей npm в Китае немного застрял.Можно использовать пряжу Или рекомендуется использовать зеркальный источник Taobao npm, который может значительно повысить скорость установки.
Упомянутый ранее однофайловый компонент, как показано на рисунке ниже, поддерживает любой процессор и горячую перезагрузку из коробки, поэтому все компоненты поддерживают горячую перезагрузку. При внесении изменений страница не будет обновляться, но сам компонент будет перезагружен сразу же, не влияя на текущее состояние всего приложения. CSS также поддерживает горячую перезагрузку. Давайте посмотрим на нижний левый угол. При использовании этого препроцессора нам нужно только добавить функцию с ограниченной областью действия. Vue будет имитировать эффект CSS, анализируя и переписывая шаблон и код CSS. В то же время однофайловые компоненты также поддерживают ленивую загрузку.Компонент с ленивой загрузкой и его зависимости будут упакованы в дополнительный пакет, который будет загружаться только тогда, когда он используется, что также очень полезно для скорости загрузки первый экран.
Как показано на изображении ниже, сам инструмент разработчика также написан на Vue.
Используя его, вы можете увидеть древовидную структуру компонентов нашего текущего приложения.
Нажмите на компонент, чтобы увидеть текущее состояние компонента. Также возможно отправить этот компонент на консоль. В то же время этот инструмент разработчика также имеет панель Vuex.Если вы используете Vuex, каждая операция будет записана, и вы сможете переключаться между записанными состояниями. Кроме того, он также поддерживает отправку снимка состояния текущего приложения другому человеку.Этот человек может импортировать состояние, которое вы отправили в свою консоль, и сразу же перейти к состоянию, в котором вы были раньше. Это полезно для воспроизведения некоторых ошибок или для описания текущего состояния.
Vue2.0 был выпущен не так давно, некоторые технические детали были рассмотрены в предыдущей статье.
По сравнению с 1.0, Vue2.0 имеет следующие улучшения.
1. Зажигалка
Для сжатия размера Vue1.0 у Vue2.0 есть версия, которая содержит только среду выполнения, и все шаблоны были завершены во время компиляции. На основе этой версии Vue, vue-router и vuex (все версии 2.0) на рисунке ниже складываются вместе, что имеет тот же размер, что и основная библиотека Vue1.0.
2. БыстрееVue2.0, возможно, является одним из самых быстрых фреймворков. Это основано на результатах независимого стороннего тестирования. Если вы заинтересованы, вы можете перейти по ссылке (http://stefankrause.net/js-frameworks-benchmark4/webdriver-ts/table.html), чтобы просмотреть ее. Этот тест является относительно комплексным тестом, который достаточно полно охватывает различные операции, а также обновление и удаление в больших списках. Видно, что Vue2.0 является не только большим улучшением по сравнению с Vue1.0, но также имеет очевидные преимущества в производительности по сравнению с другими фреймворками.
На следующем рисунке показана схема архитектуры Vue2.0, и здесь не будет подробно обсуждаться реализация всей архитектуры.
Vue2.0 также поддерживает рендеринг на стороне сервера, а рендеринг на стороне сервера поддерживает потоковый рендеринг. Поскольку HTTP-запросы также являются потоковыми, результаты рендеринга на стороне сервера Vue могут быть переданы непосредственно в возвращаемый запрос. Таким образом, контент может быть представлен пользователю в браузере раньше, а с помощью разумной стратегии кэширования производительность рендеринга на стороне сервера может быть эффективно улучшена. На следующем рисунке показано связанное содержимое Vue2.0 и рендеринга на стороне сервера. В основном все функции интегрированы вместе. Заинтересованные студенты могут искать здесь 2.0, который можно использовать в качестве справочного приложения.
В дополнение к рендерингу на стороне сервера существует также собственный рендеринг, который здесь относится к проекту Alibaba Weex.
На архитектурном уровне путем компиляции исходного файла Weex (аналогично однофайловому формату сборки Vue) и его запуска. Операции узлов интерфейса являются абстрактными, и эти абстрактные операции будут отправляться различным целевым механизмам для фактического рендеринга и поддерживать iOS, Android и Интернет.
Теперь Vue и Weex сотрудничают, и Vue 2.0 официально станет средой выполнения JavaScript Weex. Такое сотрудничество позволяет использовать компоненты Vue, соответствующие функциональным пересечениям, на разных платформах.
Front-end top — это вертикальное сообщество, посвященное фронтенд-технологиям. Приглашаем всех фронтенд-инженеров присоединиться!
Рекомендуются статьи, связанные с Vue:
-
Автор Vue.js Юкси Ю присоединяется к проекту Weex в качестве технического консультанта
-
Легче и быстрее Vue.js 2.0 по сравнению с другими фреймворками
Работа по пожертвованию книги сообщений на этой неделе все еще продолжается, вы можете продолжать уделять внимание крахмалу!
Перейти к получению преимуществ:Эксклюзивные преимущества для фронтенд-инженеров
Нужно ли продолжать учиться на архитектора?
Если вы хотите иметь более широкое техническое видение, приходите на ArchSummit! 100+ практических кейсов, 1500+ технических экспертов, Facebook, Twitter, LinkedIn, Ali, Tencent, Baidu, Sina, Didi и других известных предприятий, чтобы поделиться своим практическим опытом первой линии.
ArchSummit Скидка 20% на регистрацию, нажмите на ссылку, чтобы прочитать исходный текст для деталей.
www.archsummit.com/bj2016/index.html?utm_source=infoqwechath5
вперед конец Из верхСледите за развитием клиентской части Делитесь передовыми технологиями Продолжайте учиться и совершенствоваться Поднимайтесь вперед вершина