За и против Решений Facebook против Веб-Компонентов (Полимер)

Каковы основные преимущества Facebook React над предстоящим Веб-компоненты и наоборот (или, возможно, сравнение яблок с яблоками будет соответствовать этим обсуждением в ЕС и главной страницей React, основными преимуществами Реакта являются:

  • Развязка и усиление сцепления с использованием модели компонентов.
  • Абстракция, композиция и выразительность
  • Виртуальный DOM & Синтетические события (что в основном означает, что они полностью переделали DOM и систему событий)
    • Включает современные события событий HTML5 в IE 8
    • Отверстие на стороне сервера
    • Тестируемость
    • Привязки к SVG, VML и <canvas>

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

Вот некоторые вещи, о которых я think не хватает, что веб-компоненты позаботятся о вас. Исправьте меня, если я ошибаюсь.

  • Поддержка собственного браузера (чтение «гарантировано быстрее»)
  • Напишите скрипт на языке сценариев, напишите стили на языке стилизации, напишите разметку на языке разметки.
  • Инкапсуляция стиля с использованием Shadow DOM
    • React вместо этого имеет это , что требует написания CSS в JavaScript. Не красиво.
  • Двусторонняя привязка
504 голоса | спросил CletusW 25 Jam1000000amSat, 25 Jan 2014 04:47:13 +040014 2014, 04:47:13

6 ответов


649

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

Большинство ваших проблем - это действительно вопрос мнения и личных предпочтений, но я постараюсь ответить как можно объективнее:

Собственный или скомпилированный

  

Напишите JavaScript в ваниле JavaScript, напишите CSS в CSS, напишите HTML   в HTML.

В тот же день были горячие дебаты о том, следует ли писать native  Ассамблеи вручную или использовать язык более высокого уровня, такой как C, чтобы компилятор генерировал код сборки для вас. Еще до этого люди отказывались доверять ассемблерам и предпочитали писать собственный машинный код вручную ( и я не шучу ).

Между тем, сегодня есть много людей, которые пишут HTML в Haml или Jade , CSS в Sass или Меньше и JavaScript в CoffeeScript или TypeScript . Это здесь. Оно работает. Некоторые люди предпочитают это, некоторые не делают.

Дело в том, что в не нет ничего принципиально неправильного написания JavaScript в ванильном JavaScript, CSS в CSS и HTML в HTML. Это действительно вопрос предпочтения.

Внутренние и внешние DSL

  

 Инкапсуляция стиля с использованием Shadow DOM   Вместо этого вместо этого есть ответ, который требует написания CSS в JavaScript. Не очень.

Довольно или нет, это, безусловно, выразительно. JavaScript - очень мощный язык, гораздо более мощный, чем CSS (даже включая любые препроцессоры CSS). Это зависит от того, предпочитаете ли вы внутренние или внешние DSL для таких вещей. Опять же, вопрос предпочтения.

(Примечание. Я говорил о встроенных стилях в React на который ссылался исходный вопрос.)

Типы DSL - объяснение

Обновление: Â Читая мой ответ спустя некоторое время после его написания, я думаю, что мне нужно объяснить, что я имею в виду здесь. DSL - это язык, специфичный для домена , и он может быть либо внутренним (с использованием синтаксиса хоста язык, такой как JavaScript, например, React без JSX, или как встроенные стили в React, упомянутые выше), или он может быть внешним (с использованием другого синтаксиса, чем язык хоста), как в этом примере, будет включать CSS (внешний DSL) внутри JavaScript).

Это может сбивать с толку, потому что в какой-то литературе используются разные термины, чем «внутренние» и «внешние» для описания таких типов DSL. Иногда вместо «внутреннего» используется «встроенный», но слово «внедренное» может означать разные вещи - например, Lua описывается как «Lua: расширяемый встроенный язык», где встроенный не имеет ничего общего со встроенным (внутренним) DSL (в этом смысле это совершенно наоборот - внешний DSL), но это означает, что он встроен в тот же смысл, что, скажем, SQLite - это встроенная база данных. Существует даже eLua , где «e» означает «встроенный» в третьем смысле - что он предназначен для встроенные системы ! Вот почему мне не нравится использовать термин «встроенный DSL», потому что такие вещи, как eLua, могут быть «DSL», которые «встроены» в два разных смысла, не будучи вообще «встроенным DSL»!

Чтобы усугубить ситуацию, некоторые проекты вносят еще больше путаницы в микс. Например. Плоские шаблоны описываются как «без DSL», в то время как на самом деле это просто прекрасный пример внутренней DSL с синтаксис вроде: map.where('href').is('/').insert('newurl');

Это было сказано, когда я писал: «JavaScript - очень мощный язык, гораздо более мощный, чем CSS (даже включая любые препроцессоры CSS). Это зависит от того, предпочитаете ли вы внутренние или внешние DSL для таких вещей Опять же, вопрос предпочтения. Я говорил об этих двух сценариях:

Один:

/** @jsx React.DOM */
var colored = {
  color: myColor
};
React.renderComponent(<div style={colored}>Hello World!</div>, mountNode);

Два:

// SASS:
.colored {
  color: $my-color;
}
// HTML:
<div class="colored">Hello World!</div>

В первом примере используется то, что было описано в вопросе: «писать CSS в JavaScript. Не очень». Второй пример использует Sass. Хотя я согласен с тем, что использование JavaScript для написания CSS может быть не очень красивым (для некоторых определений «довольно»), но есть одно преимущество этого.

У меня могут быть переменные и функции в Sass, но они лексически охвачены или динамически охвачены? Являются ли они статически или динамически типизированы? Сильно или слабо? Как насчет числовых типов? Какие значения являются правдивыми и являются ложными? Могу ли я иметь функции более высокого порядка? Рекурсия? Хвост звонит? Лексические замыкания? Они оцениваются в порядке или порядке? Есть ли ленивая или нетерпеливая оценка? Являются ли аргументы для функций переданными по значению или по ссылке? Они изменяемы? Неизменный? Стойкие? Что относительно объектов? Классы? Прототипы? Наследование?

Это не тривиальные вопросы, и все же я должен знать ответы на них, если я хочу понять код Sass или Less. Я уже знаю эти ответы для JavaScript, поэтому это означает, что я уже понимаю каждый внутренний DSL (например, встроенные стили в React) на тех самых уровнях, поэтому, если я использую React, тогда мне нужно знать только один набор ответов на эти (и многие аналогичные ), а когда я использую, например. Сасс и Руль, тогда мне нужно знать три набора этих ответов и понять их последствия.

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

Надеюсь, я объясню, что изначально означало немного.

Связывание данных

  

Двунаправленная привязка

Это действительно интересный предмет, и на самом деле это также вопрос предпочтения. Двусторонняя не всегда лучше, чем односторонняя. Речь идет о том, как вы хотите моделировать изменчивое состояние в своем приложении. Я всегда рассматривал двусторонние привязки как идею, которая несколько противоречит принципам функционального программирования, но функциональное программирование - не единственная парадигма, которая работает, некоторые люди предпочитают такое поведение, и оба подхода, похоже, на практике работают очень хорошо. Если вас интересуют детали проектных решений, связанных с моделированием состояния в React, то смотрите разговор Пита Ханта (связанный в вопросе) и разговор Тома Очино и Jordan Walke , которые объясняют это очень хорошо, на мой взгляд.

Обновление: См. также еще один разговор Пита Ханта: Будьте предсказуемы, Неправильное: функциональное программирование DOM .

Обновление 2: Стоит отметить, что многие разработчики утверждают, что против двунаправленного потока данных или двусторонней привязки, некоторые даже называют его анти-шаблоном. Возьмите, к примеру, архитектуру приложения Flux , которая явно избегает модель MVC (которая оказалась трудно масштабируемой для крупных приложений Facebook и Instagram) в пользу строго однонаправленный поток данных (см. Хакерский путь: переосмысление разработки веб-приложений в Facebook от Tom Occhino, Jing Chen и Пит Хант за хорошее введение). Кроме того, много критики против AngularJS (самая популярная веб-инфраструктура, которая свободно основана на модели MVC, известная для двух -средняя привязка данных) включает аргументы против этого потока двунаправленных данных, см.

Обновление 3: Еще одна интересная статья, которая прекрасно объясняет некоторые из проблем, рассмотренных выше, - это Деконструкция потока ReactJS - Не используя MVC с ReactJS автор Микаэль Брассман, автор RefluxJS (простая библиотека для архитектуры приложений с однонаправленным потоком данных, вдохновленная Flux).

Обновление 4: Ember.js в настоящее время уходит от двухсторонних данных привязка и в будущих версиях по умолчанию будет односторонней. Смотрите: Будущее Ember беседует Стефан Пеннер из Симпозиума Эмбергартена в Торонто 15 ноября 2014 года.

Обновление 5: См. также: Дорога к Ember 2.0 RFC - интересная дискуссия в запросе на тягу Тома Дейла :

«Когда мы разработали оригинальный шаблонный слой, мы решили, что сделать все привязки данных двусторонним, не было очень вредно: если вы не установите двустороннюю привязку, это де-факто односторонний связывание!

С тех пор мы поняли (с некоторой помощью наших друзей в React), что компоненты хотят иметь возможность раздавать данные своим детям, не опасаясь наводящих мутаций.

Кроме того, связь между компонентами часто наиболее естественно выражается как события или обратные вызовы . Это возможно в Ember, но доминирование двунаправленных привязок данных часто приводит людей вниз по пути использования двусторонних привязок в качестве канала связи . Опытные разработчики Ember не делают (обычно) эту ошибку, но это легко сделать ». [выделено курсором]

Native vs. VM

  

Поддержка собственных браузеров (чтение «гарантировано быстрее»)

Теперь, наконец, что-то, что не является вопросом мнения.

На самом деле, это совсем наоборот. Конечно, «родной» код может быть написан на C ++, но как вы думаете, на чем написаны движки JavaScript?

На самом деле двигатели JavaScript поистине поражают оптимизацией, которую они используют сегодня, - и не только V8, но и SpiderMonkey, и даже Chakra светит в эти дни. И имейте в виду, что с компиляторами JIT компилятор не только является настолько родным, насколько это возможно, но есть также возможности оптимизации времени выполнения, которые просто невозможно сделать в любом статически скомпилированном коде.

Когда люди думают, что JavaScript медленный, они обычно означают JavaScript, который обращается к DOM. DOM медленный. Он является родным, написанным на C ++, и все же он медленный, как черт, из-за сложности, которую он должен реализовать.

Откройте консоль и напишите:

console.dir(document.createElement('div'));

и посмотрите, сколько свойств содержит пустой элемент div, который даже не привязан к DOM. Это только свойства первого уровня , которые являются «собственными свойствами», то есть. не унаследован от цепи прототипа:

  

align, onwaiting, onvolumechange, ontimeupdate, onsuspend, onsubmit, onstalled, onshow, onselect, onseeking, onseeked, onscroll, onresize, onreset, onratechange, onprogress, onplaying, onplay, onpause, onmousewheel, onmouseup, onmouseover, onmouseout, onmousemove , onmouseleave, onmouseenter, onmousedown, onloadstart, onloadedmetadata, onloadeddata, onload, onkeyup, onkeypress, onkeydown, oninvalid, oninput, onfocus, onerror, onended, onempt, ondurationchange, ondrop, ondragstart, ondragover, ondragleave, ondragenter, ondragend, ondrag, ondblclick , oncuechange, oncontextmenu, onclose, onclick, onchange, oncanplaythrough, oncanplay, oncancel, onblur, onabort, spellcheck, isContentEditable, contentEditable, externalText, innerText, accessKey, hidden, webkitdropzone, draggable, tabIndex, dir, translate, lang, title, childElementCount , lastElementChild, firstElementChild, children, nextElementSibling, previousElementSibling, onwheel, onwebkitfullscreenerror, onwebkitfullscreenchange, ons electstart, onsearch, onpaste, oncut, oncopy, onbeforepaste, onbeforecut, onbeforecopy, webkitShadowRoot, набор данных, классList, className, внешнийHTML, innerHTML, scrollHeight, scrollWidth, scrollTop, scrollLeft, clientHeight, clientWidth, clientTop, clientLeft, offsetParent, offsetHeight, offsetWidth, offsetTop, offsetLeft, localName, prefix, namespaceURI, id, style, attributes, tagName, parentElement, textContent, baseURI, ownerDocument, nextSibling, previousSibling, lastChild, firstChild, childNodes, parentNode, nodeType, nodeValue, nodeName

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

Я имею в виду серьезно, onvolumechange свойство на каждом отдельном узле? Это ошибка? Нет, это всего лишь DOM уровня 0традиционная версия модели событий одного из обработчиков событий, в которой должна поддерживаться всеми HTML-элементами , как атрибутами контента, так и атрибутами IDL "[выделение добавлено] в Раздел 6.1.6.2 спецификации HTML по W3C - никак не вокруг него.

Между тем, это свойства первого уровня fake-DOM div в React:

  

реквизиты, _owner, _lifeCycleState, _pendingProps, _pendingCallbacks, _pendingOwner

Вполне разница, не так ли? На самом деле это весь объект, сериализованный в JSON ( LIVE DEMO ), потому что эй вы действительно можете сериализовать его в JSON, поскольку он не содержит никаких круговых ссылок - что-то немыслимое в мире родного DOM ( где он просто выбросит исключение ):

{
  "props": {},
  "_owner": null,
  "_lifeCycleState": "UNMOUNTED",
  "_pendingProps": null,
  "_pendingCallbacks": null,
  "_pendingOwner": null
}

Это в значительной степени главная причина, по которой React может быть быстрее, чем собственный DOM-браузер, потому что ему не нужно реализовывать этот беспорядок .

См. эту презентацию Стивена Лашера , чтобы узнать, что быстрее: родной DOM, написанный в C ++ Â или поддельный DOM, полностью написанный на JavaScript. Это очень честная и интересная презентация.

Обновление: Ember.js в будущих версиях будет использовать виртуальный DOM, сильно вдохновленный Реагируйте, чтобы улучшить производительность. Смотрите: Будущее Ember беседует Стефан Пеннер из Симпозиума Эмбергартена в Торонто 15 ноября 2014 года.

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

Update

Через два месяца после публикации этих ответов были некоторые новости, которые здесь актуальны. Поскольку Я только что написал в Twitter , последняя версия Текстовый редактор Atom , написанный GitHub в JavaScript, использует реакцию Facebook, чтобы получить лучшую производительность, даже если Ядро Atom ) и гарантировано имеют поддержку веб-компонентов, поскольку он поставляется со своим собственным веб-браузером. Это всего лишь очень недавний пример проекта реального мира, который мог бы использовать любую другую оптимизацию, как правило, недоступную для веб-приложений, и все же он решил использовать React, который сам написан на JavaScript, для достижения максимальной производительности, хотя Atom не был построен с Реагтом для начала, так что это не было тривиальным изменением.

Обновление 2

Существует интересное сравнение Тодда Паркера с помощью WebPagetest , чтобы сравнить эффективность TodoMVC примеров, написанных на Угловая, Магистральная, Эмбер, Полимер, CanJS, YUI, Нокаут, Реакт и Шиштин. Это самое объективное сравнение, которое я видел до сих пор. Важно то, что все соответствующие примеры были написаны экспертами во всех этих рамках, все они , доступный на GitHub и может быть улучшен любым, кто думает, что некоторые из кода могут быть оптимизированы для работы быстрее.

Обновление 3

Ember.js в будущих версиях будет включать в себя ряд функций React, которые обсуждаются здесь (включая виртуальные DOM и однонаправленная привязка данных, чтобы назвать лишь несколько), что означает, что идеи, возникшие в Реактировании, уже переносятся в другие структуры. Смотрите: The Road to Ember 2.0 RFC - интересная дискуссия в запросе на вытаскивание Тома Дейла (Дата начала : 2014-12-03): «В Ember 2.0 мы будем принимать« виртуальную DOM »и модель потока данных, которая охватывает лучшиеидеи из React и упрощают связь между компонентами ».

Кроме того, Angular.js 2.0 реализует много обсуждаемых здесь концепций.

Обновление 4

Мне нужно подробно рассказать о нескольких проблемах, чтобы ответить на этот комментарий Игова Калу:

  

"нецелесообразно сравнивать React (JSX или выход компиляции) с   простой JavaScript, когда React в конечном итоге сводится к простому JavaScript.   [...]   Какую бы стратегию не применяли React для DOM-вставки, можно применять без   используя React. Тем не менее, это не добавляет особых преимуществ, когда   учитывая эту особенность, отличную от удобства ».   (полный комментарий здесь )

В случае, если это было недостаточно ясно, в части моего ответа я сравниваю эффективность работы непосредственно с native DOM (реализован как хост-объекты в браузере) по сравнению с подделкой React /virtual DOM (реализовано в JavaScript). То, что я пытался сделать, это то, что виртуальный DOM, реализованный в JavaScript , может превосходить реальный DOM, реализованный на C ++ и не , что React может превзойти JavaScript (что, очевидно, не будет имеют смысл, поскольку написан на JavaScript). Я хотел сказать, что «родной» код на C ++ не всегда гарантирован быстрее, чем «не-родной» JavaScript. Использование React для иллюстрации этой точки было всего лишь примером.

Но этот комментарий затронул интересную проблему. В некотором смысле это правда, что вам не нужны никакие фреймворки (React, Angular или jQuery) по какой-либо причине (например, производительность, переносимость, функции), потому что вы всегда можете воссоздать то, что делает каркас для вас, и изобретать колесо - если вы можете оправдать стоимость, то есть.

Но - как Дэйв Смит красиво положил его в Как пропустить момент при сравнении производительности веб-инфраструктуры : «При сравнении двух веб-фреймворков вопрос не может . Мое приложение работает быстро с каркасом X. Вопрос будет мое приложение будет быстрым с каркасом X. "

В мой ответ 2011 года на : Каковы некоторые эмпирические технические причины не использовать jQuery . Я объясняю аналогичную проблему, что невозможно написать переносимый код DOM-манипуляции без библиотеки jQuery, но люди редко это делают.

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

Обновление 5

React + Performance =? статья Paul Lewis с июля 2015 показывает пример, где React медленнее, чем ванильный JavaScript, написанный вручную для бесконечного списка изображений Flickr, что особенно важно для мобильных устройств. Этот пример показывает, что каждый должен всегда проверять производительность для конкретного случая использования и конкретных целевых платформ и устройств.

Благодаря Кевину Лозанье для привлекая мое внимание .

ответил rsp 3 Mayam14 2014, 05:46:22
14

Еще один ответ в одном пункте:

  

Напишите JavaScript в ваниле JavaScript, напишите CSS в CSS, напишите HTML   в HTML.

Ничто не мешает вам писать Javascript, например, в CoffeeScript, TypeScript, ClojureScript или что-то еще. Это исключительно вопрос предпочтения.

HTML - это лучший DSL для статических HTML-документов. Но он не обеспечивает ничего для динамического HTML. И в браузере лучшим языком для динамического HTML является Javascript, а не чистый HTML с ad-hoc Javascript DOM-манипуляцией или языком шаблонов, например Handlebars, которые не являются даже половиной языков.

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

ответил DjebbZ 4 J0000006Europe/Moscow 2014, 20:30:14
14

Полимер потрясающий. Реакция потрясающая. Это не одно и то же.

Полимер представляет собой библиотеку для создания обратных совместимых веб-компонентов.

React - это V в MVC. Это вид, и ничего больше. Не по себе, по крайней мере.

Реагирование не является основой.

React + Flux + Node + (Gulp или Grunt) более сопоставим с каркасом, но 3 из этих вещей не являются частью реакции вообще.

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

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

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

ответил Robotsushi 10 ThuEurope/Moscow2015-12-10T06:41:18+03:00Europe/Moscow12bEurope/MoscowThu, 10 Dec 2015 06:41:18 +0300 2015, 06:41:18
13

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

  

Попытка сравнить и противопоставить Реагировать с WebComponents неизбежно приводит к очевидным выводам, потому что две библиотеки построены для решения различных проблем. WebComponents обеспечивают надежную инкапсуляцию для повторно используемых компонентов, в то время как React предоставляет декларативную библиотеку, которая поддерживает DOM в синхронизации с вашими данными. Эти две цели являются взаимодополняющими; инженеры могут смешивать и сочетать технологии. Как разработчик, вы можете использовать React в своих WebComponents или использовать WebComponents в React или оба.

ответил Erik Allik 1 AMpFri, 01 Apr 2016 08:09:33 +030009Friday 2016, 08:09:33
6

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

фрагмент из примера полимера:

 <script>
   Polymer({
     counterChanged: function() {
       this.$.counterVal.classList.add('highlight');
     },
 ...

Весь смысл Реагирования - уменьшить сложность, исключив логику мутаций. Вместо этого вы наивно восстанавливаете виртуальный DOM и позволяете алгоритму diff React определить, что нужно изменить в реальном DOM.

ответил limscoder 24 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 24 Sep 2014 01:28:40 +0400 2014, 01:28:40
5

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

Производительность

Людям нравится утверждать, что преимущество React заключается в том, что он полностью повторно изобретает всю DOM и модель событий, а существующая стандартная DOM тяжелая и дорогая, а что - нет, но в конце концов я не нашел производительность React лучше, чем то, что я могу получить из хорошо написанного приложения Backbone или Polymer. Фактически, в большинстве моих профессиональных опытов производительность React на самом деле была немного хуже. Это не значит, что Реакт медленный ... Это просто не тот выбор производительности, который мы все думали, прежде чем мы получили его.

В ответе rsp он указывает, что модель DOM React для div больше намного , чем родной DOM div, и это, безусловно, верно. Однако для того, чтобы React был полезным, этот «виртуальный» div должен в конечном итоге стать реальным div. Таким образом, в моем мировоззрении это не вопрос React div и родной div. Это React div + родной div или только родной div. Накладные расходы на версию DOM от DATA являются нетривиальными, и если стандарты когда-либо снижают некоторые из этих ненужных атрибутов и позволяют гораздо более легким создавать собственные DOM-узлы, вдруг это накладные расходы выглядят очень дорого.

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

Реагирует на повторную сборку всей DOM с использованием собственной модели, а затем использует ее для значительной оптимизации производительности. Представление превращается в виртуальную DOM, и это проецируется в реальный DOM. Когда есть изменения, и представление должно быть обновлено, представление снова будет повторно отображено в виртуальную DOM, и это дерево отличается от предыдущего дерева, чтобы определить, какие узлы должны быть изменены в реальной DOM, чтобы отразить это изменение в представлении. Хотя это очень продуманный подход к эффективному обновлению DOM, есть надстройка в сохранении всех этих виртуальных деревьев DOM и их различие, чтобы определить, что нужно изменить в реальном DOM. В настоящее время эти накладные расходы сильно компенсируются преимуществами производительности, но по мере того, как внутренний DOM со временем улучшается, масштаб сдвинется в другом направлении. Я беспокоюсь о том, как приложения React могут возрасти, и если через 3 года они будут намного медленнее, чем те, которые касаются DOM более непосредственно. Этот виртуальный подход DOM является немного кувалдой, а другие библиотеки, такие как Polymer, смогли реализовать очень эффективные подходы к работе с DOM гораздо более тонким способом.

Обновление для производительности: Одна из библиотек, которые я наткнулся на некоторое время назад, делает то, что я считаю лучшей работой по управлению обновлениями DOM. Это инкрементная библиотека Google Dom, и я думаю, что тот факт, что она работает с dom на месте и не нуждается в создании «виртуальной копии», - это гораздо более чистый подход, при этом значительно меньше затрат памяти. Подробнее здесь: http://google.github.io/incremental-dom/#about

Декларативные и императивные компоненты

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

Но как только вы идете взять эти компоненты и использовать их вне Реагента, все становится намного более грязным. Поскольку компоненты Reactсделанные в тегах, полностью за пределами того, что предоставляют веб-стандарты, ничего, кроме React, не знает, как дать вам декларативный способ потребления этих компонентов. Если я хочу поместить компоненты React в существующее представление Backbone, в котором используются шаблоны Handlebars, вы должны отобразить фиктивный div в своем шаблоне с классом или идентификатором, который вы можете использовать в качестве дескриптора, а затем написать императивный JavaScript, чтобы найти этот фиктивный div и mount ваш компонент в него. Есть приложение Express.js, использующее серверные шаблоны? Ну, это та самая песня и танец. Страница JSP? Вы смеетесь, но есть много приложений, которые все еще используют их. Если вы не какой-то стартап без существующего кода, вам придется написать какую-нибудь сантехнику, чтобы повторно использовать компоненты React во многих приложениях. Между тем, Polymer достигает компонентов через стандарт Web Components, и, используя спецификацию Custom Element, Polymer может создавать компоненты, которые браузер только изначально знает, как их потреблять. Я могу поместить компонент Polymer в JSP-страницу, шаблон Express.js, представление ASP.NET, представление Backbone ... внутри компонента React. Буквально где угодно вы можете использовать HTML, вы можете потреблять полимерный компонент. Люди, которые разрабатывают для повторного использования, ищут веб-стандарты, потому что стандарты - это контракт, который позволяет легко сделать вещи совместимыми друг с другом. YouTube сохраняет все больше и больше материалов в Polymer (источник: http://react-etc.net/entry/youtube-is-being-rebuilt-on-web-components-and-polymer ), и я могу только представить себе основанный на стандартах аспект Поэтому причиной является полимер. Этот проигрыватель YouTube в середине страницы YouTube может быть превращен в компонент, который использует источник контента как свойство, и вдруг любой, кто хочет встроить проигрыватель YouTube на свою страницу, может буквально использовать тот же самый код, который использует YouTube. , и они могут сделать это просто, вставив тег на свою страницу.

Резюме

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

ответил Dogs 28 +03002016-10-28T14:28:14+03:00312016bEurope/MoscowFri, 28 Oct 2016 14:28:14 +0300 2016, 14:28:14

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132