Gutenberg: Выбор фреймворка JavaScript для Гутенберга (~ WordPress)

Мой голос за VueJS

Я выбираю VueJS

У Vue отличное сообщество, и он должен стать лучшим выбором.

Угловой JS

Проголосую за VueJS. Как указано выше, он удобен для новичков и успешно используется с Laravel. Это делает его идеальным выбором.

Я также буду голосовать за Vue JS

Обратите внимание, что просто крик «Я предпочитаю Vue» или «Я хочу XY» на самом деле не помогает при принятии решения. Если вы хотите проголосовать, я бы предложил использовать реакции смайликов или что-то в этом роде, вместо того, чтобы загромождать поток, который мог бы действовать как место для документирования результатов при оценке различных фреймворков.

Я выберу Vue. Легче учиться и адаптироваться. К тому же он менее спорен, чем Preact.

К вопросу о «зависимости ключевого человека», возникающем время от времени, разве не это то, что представляет собой каждый плагин функции WordPress или неизвестная технология? Куп построил старую обработку мультимедиа, Уэстон проделал тонну работы с настройщиком, Матиас и еще несколько человек работают над Гутенбергом, почти каждое серьезное изменение в WordPress, которое произошло за последние несколько лет, было связано с небольшой группой людей. или понимая это.

Я мог бы смотреть на это неправильно, но «зависимость ключевого человека» от любого выбора кажется отвлекающим маневром. С усыновлением полностью исключается зависимость ключевого человека. WordPress когда-то также был ключевым проектом (Майк и Мэтт). Я считаю, что это слабый аргумент в пользу отказа от усыновления.

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

Чтобы добавить к комментарию @swissspidy , показывать, а не рассказывать - это тоже может помочь. Если люди решительно относятся к замене, продемонстрируйте изменение и то, как будет выглядеть код в ветке (так же, как # 2734 делает для Preact). Независимо от того, какое окончательное решение будет принято, Гутенбергу будет лучше исследовать, чем загромождать обсуждение.

Я бы проголосовал за VueJS! Это, безусловно, самый простой способ адаптировать сообщество.

Я думаю, что веб-компоненты (без Polymer, но с lit-html или аналогичными, если требуется виртуальный DOM) следует серьезно рассмотреть. Использование платформы и стандартов намного лучше, чем любая библиотека или фреймворк! Образует надежную и безопасную в будущем структуру компонентов, которая, естественно, совместима со всеми фреймворками. (Vue, Angular, React - хотя сейчас в разной степени: https://custom-elements-everywhere.com/)

• https://blog.revillweb.com/why-web-components-are-so-important-66ad0bd4807a
• https://medium.com/@velmu/go -long-on-web-components-b1e0689f64e4

Я рад помочь этому проекту опробовать Vue или веб-компонент, если это необходимо.

Также ознакомьтесь с PR # 2463 для Gutenberg _ "Совместимость блоков без привязки к платформе (Vanilla, Vue)" _

Я бы предложил склоняться к Vue.js по нескольким причинам.

1. Подтвержденный послужной список в рамках PHP-фреймворка Laravel.
2. Кажется, его легко подобрать и принять, чтобы больше людей могли внести свой вклад.
3. Если мы уходим от React, давайте сделаем это чистым и определенным отходом от него (использование Preact кажется, будто мы цепляемся за него (React) в некотором смысле).

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

Похоже, что Vue имеет большую динамику и лучшую поддержку сообщества, чем Preact. Он решает больше проблем (поскольку идет с управлением состоянием) и требует более мягкого обучения. Документация отличная.

Меня беспокоит то, что Preact слишком похож на React, чтобы чувствовать себя юридически безопасным (патенты React могут распространяться на Preact), и слишком не похож на React, чтобы быть простым портом (есть _достаточно_ различий, чтобы сломать вспомогательные библиотеки, плагины и т. Д.).

Vue полностью детка !!

• [x] [Gitlab] (https://about.gitlab.com/2016/10/20/why-we-chose-vue/)
• [x] [HN] (https://news.ycombinator.com/item?id=14410190)
• [x] [PixelJets] (http://pixeljets.com/blog/why-we-chose-vuejs-over-react/)

Github Stars -> Здесь
Был бы в восторге от разработчиков WordPress, если бы Vue.js 🖖

Со временем у Vue появилось большое сообщество, плюс регулярные обновления / обновления фреймворка.

PS. присоединяйтесь к https://chat.vuejs.org, чтобы получить потрясающий опыт работы с сообществом .. там есть несколько действительно крутых разработчиков :)

@jbreckmckye Я не хочу сорвать разговор, но вы понимаете, о чем идет речь в патентной статье? Речь идет о защите Facebook от патентных исков со стороны других компаний. Например, допустим, моя компания производит умные холодильники, и мы используем реакцию в пользовательском интерфейсе. Допустим, у нас есть патент на это, а затем FB начинает нарушать этот патент ... если мы подадим иск, мы больше не сможем использовать реакцию.

Это не имеет ничего общего с патентами в React (что я даже не уверен, что у facebook есть ... иначе preact, vue и кто-либо другой с аналогичной структурой уже получил бы иск)

Как участник ядра Vue.js, я хотел бы решить проблему фактора шины. Мы знаем, что в настоящее время этот вопрос очень часто поднимается, и сейчас мы принимаем меры для решения некоторых проблем.

1) Учетная запись Vue.js org для npm, чтобы нам было проще публиковать в команде
2) Внутреннее управление деталями для поддержания работы (веб-сайты и т. Д.)
3) Инициализация открытого коллектива для привлечения участников и поддержки растущего сообщества. https://medium.com/the-vue-point/vue-is-now-on-opencollective-1ef89ca1334b
4) Экосистема Vue стремительно выросла, и все больше и больше вкладов в репозиторий ядра поступает от самого сообщества. https://www.youtube.com/watch?v=993X1kiisFE
5) Посмотрев на официальные репозитории Vue, вы увидите, что на самом деле многие из них теперь активно поддерживаются другими членами основной команды, а не Эваном.

В целом, Vue.js быстро растет, а «коэффициент шины» значительно снизился. Как отмечает @philiparthurmoore , Эван всегда будет

Кажется, здесь много поклонников VueJS. Кто-нибудь действительно перенес большую кодовую базу с React на Vue? На что похож путь миграции?

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

@patrickgalbraith На самом деле это неправильная причина для рассмотрения Preact. Его следует оценивать по достоинству, а не потому, что на него легче перейти. Я вижу следующие проблемы с Preact

• Меньшее сообщество по сравнению с VueJS
• Запахи кода - переход на очень похожую библиотеку может привести к неправильным практикам (по очевидной причине, что это более быстрый путь)
• Придерживаться Preact все равно что придерживаться React (читайте в ветке)

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

@ blake-newman Спасибо, что заглянули и прояснили это. 💯

Его следует оценивать по достоинству, а не потому, что на него легче перейти.

Ага. Это долгосрочное решение.

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

Поскольку проект все еще находится на начальной стадии, как @ahmadawais , это не проблема.

Также Vue, React и Preact имеют очень похожие парадигмы. Вы можете легко переключаться между ними, различия будут.

Есть также, хотя, вероятно, не совсем практичные в данном случае инструменты, которые могут помочь миграционному миру. https://github.com/SmallComfort/react-vue

Хотя это не сравнение одних и тех же инструментов, эта статья поднимает важные вопросы, которые следует учитывать. https://medium.com/unicorn-supplies/angular-vs-react-vs-vue-a-2017-comparison-c5c52d620176

@ blake-newman, правда ли, что это только ранние стадии, хотя на разработку уже более 6 месяцев? Также имейте в виду, что Калипсо тоже больше двух лет.

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

Трафарет тоже выглядит многообещающе.

https://github.com/ionic-team/stencil-starter

Мое мнение таково, что эти два момента являются веским аргументом в пользу Vue:

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

На мой взгляд, оба являются двумя столпами проекта WordPress.

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

Это реальный риск, когда у проекта мало финансирования, И он написан в основном одним человеком (менее шести месяцев назад). Его количество Patreon в последнее время действительно уменьшилось. Если главный парень говорит, что он, возможно, не сможет работать над этим, если финансы не совпадают, тогда финансы представляют собой очень реальный риск. Выбор фреймворка для большого, долгосрочного проекта в зависимости от того, сможет ли один (крутой) разработчик заплатить арендную плату за SF, - это большое дело.

Конечно, Vue могли бы щедро поддержать другие компании, но это трудно понять.

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

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

я голосую за Vue

• простой api / вы можете выучить самые простые вещи менее чем за неделю
• простая реализация потока через vuex
• быстрые результаты: P
• растущее сообщество
• Массачусетский технологический институт

Еще одно голосование за Vue по всем указанным выше причинам. Приношу свои извинения всем, у кого активированы почтовые уведомления!

@ michaelbdavidson7 , Vue, в конечном итоге, получит вклад Эвана, а кампания Patreon должна была поддержать его, чтобы он делал еще больше отличной работы с Vue. Он не получает достаточно через Patreon и берется за другую работу, я не думаю, что это ставит под угрозу Vue. Как предположил @ blake-newman (основной участник Vue) (и сам Эван пару месяцев назад), Vue больше не зависит от одного человека. Насколько WordPress не зависит от одного человека. У нас есть Мэтт, да, но WordPress может продолжить работу в каком-то воплощении без Мэтта (извините, Мэтт;)). То же верно и для Vue (извините, Эван;)).
@ahmadawais, который, как мне кажется, не совсем точен в отношении «зависимости ключевого человека».

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

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

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

@ michaelbdavidson7 Цель была достигнута, чтобы Эван работал над ним на постоянной основе. Дополнительная цель состоит в том, чтобы помочь ему в дальнейшем и частично в сообществе. Таким образом, рождается открытая коллективная кампания, единственная цель которой - поддержать сообщество.

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

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

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

Vue является устойчивым, и я не говорю от имени Эвана, но я уверен, что он очень доволен нынешней ситуацией с финансами.

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

У Vue.js есть открытая проблема с доступностью . Беглый взгляд на Preact, и я мало что вижу; можно ли предположить, что применима документация от React?

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

Если вам нужен простой переход только из-за лицензии, вы можете рассмотреть вариант InfernoJS. https://github.com/infernojs/inferno предлагает почти такой же API с меньшими размерами и более быстрым временем выполнения. Имеет лицензию MIT. Я один из сопровождающих inferno и могу помочь с переходом.

@Havunen, спасибо, что

Для контекста автора Inferno нанял Facebook.

Голосую за markoJS http://markojs.com/

Гутенберг использует некоторые новые функции React 16, то есть порталы и, возможно, фрагменты , которые не поддерживаются ни Inferno, ни Preact, так что это может быть принято во внимание при разговоре о React-подобных библиотеках, если использование этих функций критично для Гутенберга.

Я бы посоветовал DIO 8 в основном потому, что на данный момент он ближе всего к React 16 с точки зрения API.

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

Я не уверен, что они точно такие же, но для порталов есть vue-portal, разработанный @LinusBorg , одним из членов основной команды vue :)

@youknowriad Меня нанял Facebook. @Havunen и команда, стоящая за Inferno, отлично справляются без меня. Работа, которую они делают над Inferno, потрясающая, и проект стоит проверить Inferno, если у вас будет возможность :)

Я один из авторов Marko.js и хотел бы бросить Marko.js на рассмотрение. Некоторые члены нашего сообщества обратились к нам и указали на эту проблему GitHub. Marko.js имеет лицензию MIT с открытым исходным кодом, используется для создания eBay.com и имеет сильное и растущее сообщество. Он привносит ряд хороших идей из React и Vue, но мы приложили много усилий, чтобы сделать вещи проще и быстрее (за счет оптимизации во время компиляции), и мы удалили шаблон везде, где могли. Я просто хотел выделить несколько функций ниже:

Компоненты пользовательского интерфейса

Компонентная модель Марко концептуально очень похожа на React (ввод, состояние, привязка событий, события жизненного цикла, виртуальный рендеринг DOM, изменение / исправление DOM и т. Д.). Переход в Calypso не потребует больших когнитивных затрат. Марко также поддерживает однофайловые компоненты пользовательского интерфейса. Вот как выглядит компонент пользовательского интерфейса Marko:

class {
  onInput(input) {
    this.state = { 
      count: input.count || 0 
    };
  }
  increment() {
    this.state.count++;
  }
}

style {
  .count {
    color:#09c;
  }
}

<div.count>${state.count}</div>
<button on-click('increment')>
  Click me!
</button>

Синтаксис

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

Серверный рендеринг

Я не знаю, насколько это важно для WordPress, но Marko также поддерживает высокопроизводительный рендеринг на стороне сервера под Node.js с поддержкой асинхронного и потокового рендеринга.

Дальнейшее чтение:

• Марко против React
• Рендеринг на стороне сервера с помощью Marko, Preact, Rax, React и Vue
• Почему Марко быстрый?
• 10 потрясающих функций Марко
• Встреча: Создание пользовательского интерфейса - сравнение React, Vue и Marko (от создателя Marko) - Видео | Слайды

Голосую за Марко !! 🙂

Если кто-нибудь из команды WordPress (@ahmadawais? @M? @Swissspidy?) Захочет быстро поговорить, чтобы ответить на любые вопросы о Марко, мы, команда Марко, будем рады это сделать. : call_me_hand: 😸

@ Я прокомментировал это в блоге @m , но хотел опубликовать его здесь в более общедоступной форме:

Я рекомендую экосистему Ember, включая Ember и Glimmer.js.
Для небольших веб-компонентов, таких как добавление редакторов и другое поведение контента, Glimmer обеспечивает отличный опыт и создает добавление веб-компонентов, которые могут работать вне фреймворка.

Для более крупных проектов, таких как Guttenberg и Calypso, где важны маршрутизация, сложное управление состоянием, контроль доступа, управление контентом и многое другое: Ember предоставляет лучший набор инструментов и экосистему.
С большим набором участников: установленные шаблоны, надстройки и система сборки Ember помогают поддерживать производительность и удобство обслуживания приложений по мере масштабирования приложений.
Ember Engines и надстройки in-repo помогают сохранить модульность дополнительных частей приложения и возможность их установки для конечных пользователей.

Ember активно используется другими системами управления контентом, и эти усилия можно использовать, извлекать уроки из них и делиться ими.
Как упоминалось в предыдущем комментарии к блогу @m , Ghost использует Ember в качестве администратора и редактора, но Ember также используется с Drupal headless, Cardstack и контент-компаниями, такими как Conde Nast , Bustle и другими.
Это означает, что общие функции, такие как списки тегов, редакторы на основе компонентов (в частности, редактор Mobiledoc ) и многое другое, доступны как часть экосистемы Ember Addon .

Судя по опыту сообщества и разработчиков, Ember лучше всего подходит для экосистемы Wordpress (как разработчик, проработавший в Wordpress более 5 лет).
В Ember есть множество передовых практик, встроенных, хорошо задокументированных или доступных через аддоны; это уменьшает вопрос «будет ли это работать с моим приложением» и помогает лучше уменьшить возможные ошибки безопасности или производительности.
Ember построен на настраиваемых абстракциях, что означает, что сложность может быть отвлечена от конечных разработчиков, а объем сложного кода может быть ограничен, чтобы сделать настройку легкой и увлекательной.
Аддоны Ember очень похожи на плагины и темы Wordpress, поскольку они обнаруживаются автоматически и имеют конфигурацию по умолчанию из коробки, но могут быть дополнительно настроены для удовлетворения потребностей конечного пользователя.
Существует инструмент для курирования надстроек Ember под названием Ember Observer, который помогает найти самые популярные, лучше всего обслуживаемые и самые стабильные надстройки.

Калипсо и Гуттенберг - крупные амбициозные проекты со зрелыми потребностями. Сообщество Ember предлагает зрелые решения для обеспечения доступности, интернационализации и других требований современных веб-приложений.

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

Я заметил, что было упомянуто о порталах React, и хотел бы добавить еще 2 ¢, что у Ember есть хорошо поддерживаемый надстройка под названием Ember Wormhole для обеспечения этой функциональности, и многие надстройки строятся поверх этого, чтобы обеспечить такие функции, как диалоги, изменение заголовка документа , и больше.

Я бы проголосовал за Марко за его встроенную поддержку асинхронного рендеринга и высокую производительность на стороне сервера. !!!

@ patrick-steele-idem & @mlrawlings - спасибо, что

Я углублюсь в подробности.

Я работал с Ember.js как в очень крупной корпоративной организации, где приложения выполнялись в других приложениях, так и в очень небольшом стартапе с небольшими автономными приложениями. Твердые мнения и условности Ember.js помогли сохранить продуктивную и удобную в обслуживании базу кода по мере роста команд и приложений. Это не только дает возможность совместно использовать код (через движки или надстройки) между проектами, но также позволяет разработчику, который изучил соглашения, быть продуктивным и вносить свой вклад практически в любое приложение Ember.

Самым большим преимуществом Ember является его стабильность без застоя. Без изменения каких-либо наших шаблонов мы получили огромное преимущество в производительности, когда была выпущена новая версия Ember, в которой был полностью переработан движок рендеринга. Уровни абстракции кажутся подходящими для современных полнофункциональных веб-приложений, которые могут расти и нуждаться в масштабировании в далеком будущем.

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

Другие популярные веб-приложения, использующие Ember, не упомянутые @rtablada, включают Twitch.tv , панель управления Heroku , Travis CI и Discourse .

@SaladFork, спасибо за обновление, я начал с того, что назвал в основном компании, занимающиеся управлением контентом.

Вот несколько примеров крупномасштабных приложений Ember с открытым исходным кодом:

• Трэвис Си
• Hospital Run - система EMR (Electronic Medical Record), созданная для автономного использования, особенно в условиях слабой связи в Африке.
• Призрак

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

Я бы проголосовал за Marko за его производительность, гибкость и очень четкий, легко понятный синтаксис!

+1 и для Марко. Хорошо выполнив фронтенд до того, как я начал терять волосы и седеть (ну, давным-давно), это был фреймворк / библиотека фронтенда, которые я искал все эти годы. Это большая причина, по которой я люблю работать на eBay с @ patrick-steele-idem и @mlrawlings .

Marko JS получил мой голос. Чрезвычайно недооценен, учитывая простоту использования и производительность.

Я люблю marko-widget вместе с эффективным marko. просто выдающаяся и бережливая структура. Это быстрее, чем в других фреймворках. Тест здесь

Я голосую за MarkoJS, мы много лет занимались магазином рулей.

Когда мы сделали стратегический шаг к использованию микросервисов и реализации компонентной архитектуры для нашей платформы, мы искали подходящую структуру, которая бы сбалансировала рендеринг на стороне сервера и рендеринг клиента. Мы являемся платформой, на которой размещены объявления на 6 различных рынках, включая развивающиеся рынки, такие как Южная Африка и Мексика, где данные являются большой проблемой, и нам нужен сайт, который действительно соблюдает требования пользователя к просмотру на устройствах, которым несколько лет, и которые также используют меньше данных. Кроме того, пользователь будет перемещаться по сайту вперед и назад, пока не найдет предмет, который ему нравится покупать, а это значит, что нам нужно, чтобы во время навигации пользователя выполнялся действительно быстрый рендеринг на сервере.

После тщательного рассмотрения мы выбрали MarkoJS с учетом того, что он поддерживает:

1. Быстрый серверный рендеринг с хорошей производительностью сервера
2. Выталкивает первый байт как можно скорее
3. Возможность создавать второстепенные компоненты и обрабатывать их асинхронно по мере готовности данных
4. Возможность создания компонентной архитектуры plug and play
5. Максимизируйте рендеринг клиента с такой же или лучшей архитектурой от React / Vue.
6. Тесты на основе компонентов, которые можно использовать не только для тестирования рендеринга, но и для проверки состояния компонента

(История успеха от eBay Ads)

+1 для Angular (НЕ AngularJS).

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

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

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

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

Это означает, что он идеально подходит для создания поверх того, что есть сейчас в WordPress. Любая другая библиотека JS, отображаемая на сервере, скорее всего, потребует node. Vue этого не делает; вы можете зарегистрировать такой компонент, как <gutenberg-editor> и заставить WordPress буквально отправлять <gutenberg-editor> в HTML. Vue может использовать HTML, отправленный WordPress, для загрузки страницы. В этом отношении это немного похоже на веб-компоненты, и для получения серверного рендеринга не требуется другая часть технологии BE.

Это одна из причин, по которой такой фреймворк, как Laravel, выбрал его по умолчанию: его очень легко интегрировать в серверные части, не относящиеся к Node. Я думаю, что WordPress должен принять его по тем же причинам.

Я проголосовал за Vuejs .
Тот же случай с @borantula в его комментарии

Мой технический директор представил команде Vuejs - новичков во Front-end, и они быстро в него вошли, теперь они довольны Vuejs. Моя команда использует WordPress во многих проектах.
В настоящее время мы используем Vuejs и Custom Element для создания внешнего интерфейса для проекта, который использует WordPress в качестве внутреннего интерфейса. Работает очень плавно.

Как сказали @ blake-newman и Evan, Vuejs больше не зависит от одного ключевого человека, поэтому можно сказать, что Минусы, упомянутые

MARKO хорошо работает в нашем веб-приложении. Прогрессивный рендеринг работает как шарм.

Я не могу ничего сказать о Preact или MarkoJS (часто упоминается в комментариях), но я могу поговорить о Vue, поскольку я представил его нашей команде (в основном работая над php + jQuery) год назад, и это постепенно меняет их понимание javascript, выйти из состояния ума jQuery.

Я думаю, что это был бы хороший выбор не только для Гутенберга, но и для долгосрочной цели WordPress - перехода на платформу, более ориентированную на API, с большим количеством javascript в интерфейсах. Это более легкая кривая обучения, а знакомство побудит других разработчиков WP вмешаться.

Я видел, как VueJS процветает в сообществе Laravel и почти стал фактическим выбором для большинства, я считаю, что так же будет и в сообществе WordPress.

Backbone.js

/ с

Я хотел поддержать MarkoJS.

Два года назад я перенес инфраструктуру моей компании с ExpressJS и Jade (теперь PUG) на Marko JS. Моя компания хотела создать сложные и повторно используемые компоненты для всей нашей экосистемы. Разработчикам нужна была скорость и возможность многократного использования. Дизайнеры хотели уменьшить расчетную нагрузку. С тех пор мы не оглядывались назад.

Теперь у нас есть несколько клиентских веб-сайтов, написанных на Marko, а также целая система CMS.

В конечном итоге я выбрал MarkoJS по следующим причинам:

• Быстрый серверный рендеринг даже с такими фреймворками, как Koa и / или ExpressJS
• Обрабатывает асинхронный рендеринг данных страницы
• Возможность создавать компоненты plug and play для более крупной экосистемы
• Лучшая производительность, чем у React / Vue
• Чрезвычайно простой синтаксис шаблона

Я также хотел бы отметить, что команда MarkoJS была в буквальном смысле звездной. @ patrick-steele-idem и @mlrawlings всегда были

👍 для MarkoJS

Preact - это библиотека, совместимая с React-API, что означает, что Preact извлекает выгоду непосредственно из экосистемы React и большого количества доступных пакетов / компонентов OSS. Экосистема Vue намного меньше по сравнению с этим. Документация для сторонних пакетов / компонентов Vue на китайском языке.

Пожалуйста, больше никаких «Я голосую XYZ», они ничего не делают, чтобы добавить в беседу, кроме отправки ненужных ответов людям, подписанным на эту проблему

🔥 Угловой

• ЗА: Самый большой конкурент React
  Для многих. часто возникает вопрос: "Angular или React?" / «Реагировать или угловой?». Сообщество Angular, возможно, является крупнейшим среди альтернатив React и быстро растет.

• ЗА: Множество обучающих ресурсов.
  В дополнение к официальным документам и руководствам по API, Angular, вероятно, имеет самую большую экосистему образовательных материалов, сообщений в блогах, книг и множества видеокурсов, как бесплатных, так и коммерческих, на всех основных обучающих платформах, а также GDE Google, обучающий этому на семинарах и конференциях.

• PRO: хорошо интегрируется с Redux
  Либо напрямую, либо через Ngrx с поддержкой RxJS (при поддержке члена команды Angular)

• PRO: Лучшая в своем классе инструментальная поддержка

  • CLI имеет намного больше возможностей, чем другие

  • Очень хорошая поддержка редактора в VS Code, особенно с языковым сервисом

  • Написано для TypeScript, обеспечивает лучшее взаимодействие с TypeScript

• PRO: многофункциональный, самоуверенный и организованный по умолчанию
  Логическое разделение с помощью модулей Angular (NgModule), а также стандартные функции для форм, HTTP-вызовов, маршрутизации и т. Д. Упрощают другим разработчикам чтение кода и внесение в него своего вклада.

• PRO: Лучшая интеграция с RxJS
  Полезно для многих потоков API и многих потоков событий на одной странице в целом

• PRO: Встроенная система DI (Dependency Injection)
  Полезно для создания точек расширяемости и, возможно, даже системы плагинов, особенно в сочетании с RxJS

• ЗА: Отметьте многие другие поля, которые покрывают другие библиотеки.

  • Библиотеки пользовательского интерфейса с разрешительными лицензиями
    Есть PrimeNg, Angular Material 2, ngx-bootstrap и многие другие ...

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

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

  • Серверный рендеринг
    Уже работает с Node и ASP .NET Core и в наши дни лучше сосредоточивается

  • Тестирование
    Angular предоставляет помощники независимого тестирования от фреймворка модульного тестирования, которые упрощают модульное тестирование. По умолчанию они генерируют тесты из интерфейса командной строки с помощью Jasmine, который можно легко переключить на Jest. Они также предоставляют необязательный Selenium wrapper Protractor, чтобы упростить тестирование E2E (даже если он вам действительно не нужен, я использую Selenium .NET для своих приложений Angular, ничего специфичного для Angular, но они пытаются сделать его еще проще).

  • Поддержка мобильных / PWA
    Google является самым большим сторонником PWA, и поддержка проявляется в Angular CLI уже с Service Workers и Universal (поддержка на стороне сервера), Ionic (поддержка Cordova) и NativeScript (собственные приложения).

• ЗА: Сосредоточьтесь на поддержке браузера
  Благодаря выделенной странице полифилов в документах и ​​вставке (прокомментированных) полифилов по умолчанию в CLI, Angular держит вас в курсе того, какие именно полифилы вам нужны, например, IE <= 11, поэтому вам не нужно загружать полифил гораздо большего размера. установлен без причины. Это потому, что они заботятся о поддержке браузером.

• ЗА: Поддержка крупной компании
  Angular - одна из немногих обсуждаемых здесь библиотек (единственная?), Которую поддерживает большая компания.
  Поддерживая здесь, не просто компания, которая использовала его в нескольких проектах и ​​внесла свой вклад в экосистему, но и будучи официальными сопровождающими, которые платят разработчикам и техническим писателям за то, чтобы они работали полный рабочий день, и инвестируют в лидеров сообщества (GDE и DevRel в случае Google).
  Это PRO, а не CON, потому что он поставляется с лицензией MIT без дополнительных пунктов, без заметок об отзыве или чего-либо еще, что может сбить с толку или пугать некоторых людей.

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

В настоящее время Vuejs стремительно растет. Будет разумным выбором, если Vuejs будет интегрирован в код WordPress.

@cyberwani @thephilip @evoratec и другие.

@ntwb уже ответил на следующий комментарий:

Пожалуйста, больше никаких «Я голосую XYZ», они ничего не делают, чтобы добавить в беседу, кроме отправки ненужных ответов людям, подписанным на эту проблему

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

Vue.

Кстати, за Vue сейчас стоит Alibaba, а также проект Weex Apache, который включает Vue api на мобильных устройствах.

Я бы здесь немного модерировал, слишком много фанатов без четких аргументов

Это последнее предупреждение, следующим шагом будет удаление комментариев ...

Я сам, я не использовал Marko, Preact или Vue.js, я не знаком ни с одним из них, если честно, я хотел бы услышать и прочитать, что сообщество WordPress говорит об этих фреймворках, каждый из них, технические достоинства каждого, окружающая экосистема каждого, инструменты сборки и, наконец, что не менее важно, люди и сообщества, стоящие за этими проектами. 😄

Я не хочу читать «Мой голос за XYZ», если вы хотите добавить голос, прокрутите вверх и добавьте реакцию эмодзи _thumbs up_ к вашей структуре выбора, которая уже упоминалась выше. 👍

Со времени моего предыдущего комментария появилось два новых комментария

С этой целью ... Если ваш комментарий был добавлен после https://github.com/WordPress/gutenberg/issues/2733#issuecomment -329705942 и все, что вы сказали, это _ "Я голосую за XYZ" _ или текст к этому эффект, что ваши комментарии имеют очень высокую вероятность удаления , будущие комментарии того же типа также будут удалены .

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

@ahmadawais У меня есть несколько комментариев.

Миграция Гутенберга с React на ...?

Что касается:

@patrickgalbraith На самом деле это неправильная причина для рассмотрения Preact. Его следует оценивать по достоинству, а не потому, что на него легче перейти. Я вижу следующие проблемы с Preact

• Меньшее сообщество по сравнению с VueJS
• Запахи кода - переход на очень похожую библиотеку может привести к неправильным практикам (по очевидной причине, что это более быстрый путь)
• Придерживаться Preact все равно что придерживаться React (читайте в ветке)

Я думаю, что когда у вас есть проект с нетривиальным количеством строк кода, нужно быть очень осторожным. Инженеры любят переписывать вещи, изучать новые языки и фреймворки, и думают, что они сделают свою работу лучше, если смогут переписать этот код ... Джоэл довольно красноречиво говорил об опасности переписывания много лет назад .
Использование Preact сэкономит вам много времени. Вы можете недооценить время, необходимое для перехода на совершенно новую структуру. Я не уверен, почему вы написали: «На самом деле это неправильная причина для рассмотрения Preact». Как инженер, затраты и время выхода на рынок занимают важное место в списке критериев, которые я использую для оценки и выбора решений.
Если проблема действительно в патенте Facebook, Preact решает ее, сводя к минимуму затраты. Preact более производительный, чем React и даже Vue: меньший размер и более быстрый рендеринг во время выполнения. Проверьте также запись об этом Адди Османи .

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

Почему Vue по-прежнему остается вашим любимым вариантом?

Мне кажется, что третий пункт: «Придерживаться Preact - все равно, что придерживаться React», вероятно, основная причина, по которой вы не решаетесь выбрать Preact. Я ошибся? Что не так с React помимо патента?

Глядя на картину в целом

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

Я думаю, вам нужно посмотреть на свои критерии. Если вы серьезно подумываете о перезаписи и важно сохранить изоморфный рендеринг, MarkoJS кажется

Если бы я начал с нуля и был готов игнорировать экосистему React, MarkoJS был бы очевиден.

Я смотрю выступления, и у MarkoJS, похоже, нет конкурентов . В 40 раз быстрее, чем React, в 10 раз быстрее, чем Vue, и в 6 раз быстрее, чем Preact, - это безумие. В моей книге 30% улучшений не имеют отношения к делу, но если у вас есть улучшение более чем в 10 раз, вам нужно серьезно обратить на это внимание.
Когда у вас есть скромное успешное присутствие и вы можете использовать 10 серверов вместо 100 или 2 вместо 20, это имеет большое значение.

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

Удачи с твоим решением 😃

@ChrisCinelli, это номера

Я из мира Drupal (мы следим за этим выпуском: D), поэтому у меня нет ставки на это. Но, читая комментарии, очевидно, что здесь есть около 5 «лучших» фреймворков, и всем нравится тот, который они выбрали, поэтому они будут его поддерживать.

Фактически, в наши дни скорость не имеет значения. Единственные два фактора, которые следует учитывать: а) действительно ли вы хотите все переписать и б) как будет выглядеть переход для разработчиков React и как будет изучаться победивший fw для новых разработчиков.

Существуют уровни preact-compat, inferno-compat ... для облегчения перехода, но производительность пострадает. С другой стороны, со временем переход будет изящным, не все нужно переписывать сразу. С точки зрения бизнеса, это не проблема. От точки зрения сообщества и будущего это не имеет значения.

Теперь DX там, где все это лежит. Любой, кто имеет опыт работы с реактивным встроенным ПО, не должен иметь проблем с переходом на новый FW просто потому, что концепции такие же, отличается только синтаксис. Но новичок - вот что важно. Насколько сложно / легко быть продуктивным в новой версии fw. Насколько сложно / легко читать и понимать существующий код. И это зависит исключительно от а) хорошей документации и б) сообщества (форумы, SO, чаты, блоги ..).

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

@ntwb: У меня не было мой комментарий удален , но я думаю , удаляющие комментарии, даже те из мальчиков вентилятора, как своего рода цензуры.

Почему:

Если ваш комментарий был добавлен после # 2733 (комментарий) и все, что вы сказали, это «Я голосую за XYZ» или текст с этой целью, ваши комментарии имеют очень высокую вероятность удаления, будущие комментарии того же типа также будут удалены. .

Выше я вижу много комментариев фанатов. Почему они остаются?
Кажется, это двойной стандарт.

Angular, выбор очевиден. Я думаю, что Рой и Мелиджи делают фантастические аргументы и поддерживают их на 100%. WordPress переходит в корпоративную сферу не только с точки зрения использования, но и с точки зрения методологии его разработки.

Я собираюсь дать ссылку на забавный источник: https://vuejs.org/v2/guide/comparison.html и, в частности: «... сложность Angular во многом обусловлена ​​его целью разработки, направленной только на большие, сложные Приложения...". Это простое утверждение попадает в самую точку. WordPress - это надежное комплексное приложение, и его будущее будет продолжаться.

@ChrisCinelli Просто потому, что именно тогда мы просили людей воздержаться от слов «Я голосую за xyz», я понимаю, откуда вы пришли, но я думаю, что удаление этих комментариев было бы плохой формой, мне не нравится тот факт, что я должен был удалить любой из них

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

Ниже приводится цитата из сообщения, написанного патентным поверенным по лицензии React ( жирное выделение скопировано из источника):

Я получил много «ну, тогда давайте просто все будем использовать [здесь альтернативную структуру]». Держать на секунду. Если патенты Facebook охватывают React (дифференцирование, компонентность и т. Д.), Эти патенты, вероятно, охватывают Preact / Vue / et al.

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

Теперь, если я правильно понимаю, WordPress покидает React не потому, что он беспокоится о самой лицензии, а только о необходимости передавать эту лицензию своим пользователям и, следовательно, вносить путаницу и необходимость защищать решение для себя.

Переходя к альтернативе React, может быть меньше защиты, если альтернативная лицензия разрешающая, но также может быть некоторая путаница в WordPress.

WordPress должен решить, стоит ли об этом беспокоиться или нет.

@ChrisCinelli благодарит вас за конструктивную критику. Я приветствую это с распростертыми руками.

Как инженер, я знаю, что стоимость и время стоят на первом месте. Но вот в чем дело. Это не проект конкретного корпоративного предприятия. Цели здесь разные.

Цель состоит в том, чтобы найти JS FW, которое будет полезно для сообщества. Гутенберг еще не запущен. Если бы это сработало, то Preact был бы явным победителем.

Прямо сейчас нам нужно об этом позаботиться:

• JS FW легко адаптировать для более широкого круга пользователей.
• Выбранный нами JS FW должен иметь собственное сообщество и экосистему.
• Подтвержденный опыт использования производственного программного обеспечения FOSS на основе PHP является плюсом. Vue + Laravel
• Выбор JS FW основан на его достоинствах, а не только потому, что его проще перейти на

За 11 лет, которые я провел с WordPress и что как постоянный основной участник, я считаю, что выбор Preact создаст много беспорядка. Кривая обучения уже огромна для разработчиков среднего / нового уровня.

Проведение их через беспорядок совместимости с Preact-React в самом начале этого нового этапа улучшения WordPress может заставить их покинуть сообщество WordPress и изучить что-то другое с аналогичной кривой обучения. (_HINT_: Laravel + Vue вместо WordPress + Preact + React) И, кстати, вы забываете, что происходит с Drupal 8?

Пожалуйста, не удаляйте гражданские комментарии. Очевидно, что существует огромная потребность или желание высказать свое мнение по этому вопросу. Я считаю, что это хорошо, поскольку люди говорят, что им небезразличен WordPress и они хотят, чтобы их услышали. Помните, что сообщество WordPress, а не только его разработчики, были направлены на Github для обратной связи. Если мы действительно, действительно не можем терпеть комментарии +1, тогда добавьте счетчик вверху, который сохраняет имена пользователей.

Если вы просто ищете аргументированное обсуждение, то многие комментарии типа «Я голосую за X, Y или Z» могут показаться просто шумом, но наблюдается четкая картина того, что люди поддерживают Vue.js. Я считаю, что у нас есть сотня или несколько сотен людей, которые будут вносить код в Gutenberg, но десятки тысяч будут писать плагины и темы, которые с ним взаимодействуют. Успех Гутенберга зависит не только от опыта конечного пользователя, но и от опыта разработчиков. Это не единственное, но важная вещь, которая делает WordPress успешным, - это то, что он легко расширяемый.

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

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

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

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

Я добавлю, что с точки зрения конвенций, я создал несколько PWA с> 90 баллами маяка с помощью Ember.

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

Кэш SSR и сервис-воркера, необходимый для высоких оценок Lighthouse, может оказаться очень сложным процессом.
С Ember этот процесс очень прост и требует установки всего лишь нескольких хорошо документированных и поддерживаемых надстроек (для большинства приложений).
По моему опыту Preact поставляется с обеими этими функциями из коробки в Preact CLI, однако существуют популярные (P) соглашения React, которые могут нарушить результаты SSR.
В официальной документации Vue рекомендуется использовать Nuxt.js или следовать полному руководству по SSR ; оба они вводят больше шаблонов, которым необходимо следовать помимо базовой документации Vue.

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

Я не уверен, что «хорошо документировано» в Ember по сравнению с VueJS @rtablada .

Лично у меня возникла бы проблема при запуске Ember по сравнению с Vue или даже React.

@ahmadawais Все забывают, что это решение будет иметь большое влияние, и вы все равно захотите изменить структуру через несколько лет. Итак, вы хотели бы использовать добро современного фреймворка, но не быть привязанным к нему ради жизни и смерти. Звучит невозможно? Это не!

Некоторое время назад у меня была похожая проблема, и после исследований и попыток я нашел решение, которое пытается связать воду с огнем. В двух словах - пользовательские элементы веб-компонента, технология упаковки, которая вам нравится (например, Vue, React, Angular), и предоставление стандартного DOM API.

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

• фреймворк, который вам нравится (но желательно, конечно, только один)
• стандартный DOM API, который могут легко использовать другие компоненты. Вы даже можете манипулировать им через простой JavaScipt

Когда я работал с Vue в то время, я написал адаптер Custom Element для Vue - https://github.com/karol-f/vue-custom-element - чтобы у вас была превосходная совместимость (например, $ emit в Vue отправляет стандартное событие DOM, которое может быть захваченным через простой JS или, например, React / Angular) и совместимость с IE9 +.

Рекомендую взглянуть на такое решение, как и вы:

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

и многое другое.

Такое решение не привязано к Vue - вы можете использовать любой другой фреймворк. Также настраиваемые элементы веб-компонента являются стандартной функцией браузера и никуда не денутся!

С уважением!

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

Цитируя комментарий @dmccan выше, потому что это очень важный момент в поддержке Vue.

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

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

Я вижу, что некоторые люди говорят о предприятии и, следовательно, об Angular, но хотя WordPress может потребоваться некоторая любовь в этой области, я думаю, что решение должно основываться на функциональности и, помимо прочего, на простоте адаптации разработчиков. С обсуждениями, которые мы наблюдали по поводу мета-боксов и тому подобного, мы заставляем авторов плагинов «проверять Гутенберг» свою работу вместо того, чтобы просто отказываться от того, если / когда классический редактор уходит.

Еще несколько моментов, которые стоит упомянуть о библиотеки, встроенные версии и опции приветствуются и наверняка имеют свои уникальные особенности и плюсы)

• PRO Это не обязательно требует транспилятора или принудительного использования, и может напрямую работать в Интернете, как jquery.

Это здорово поможет разработчикам плагинов интегрироваться с пользовательским интерфейсом Wordpress. Они могут прикрепить новый экземпляр vue к любой части страницы как виджет. Также большой проект Wordpress может постепенно адаптироваться к Vue.js без необходимости

• Также поддерживаются

Это может помочь быстрее перенести текущие проекты WordPress с кодом React / JSX на vue.js с меньшими требованиями к изменениям. (есть даже плагин babel: babel-plugin-transform-react-to-vue )

• FACT Vue, как и Preact, и в отличие от Angular / React не является проектом с открытым исходным кодом, принадлежащим такой большой компании, как Google или Facebook.

Это было бы критически важно для ОГРОМНОГО проекта, такого как Wordpress, чтобы избежать потенциальной привязки к поставщику. Если проект с открытым исходным кодом, не принадлежащий компании, кто-то должен запустить его (так что «зависимость от ключевого человека» бессмысленно называть ПРО ).

Голосую за VueJS.
Не потому, что я что-то об этом знаю, а потому, что понятия не имею, как это произносится на английском языке. Однако я использовал Joomla в течение многих лет и все время замечал, что это неправильно.

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

Теперь просто отписываюсь от этого выпуска.

Чтобы сфокусировать обсуждение, я создал здесь задачу: https://github.com/WordPress/gutenberg/issues/2741

Я бы предложил Vue только потому, что Laravel. Многие пользователи WordPress, недовольные выбранным или продолжающимся курсом, перешли на использование Laravel в качестве основного фреймворка CMS, сохранив WP в качестве второго варианта. Preact - это просто клон и массивный уровень совместимости, вроде того, чем была Novell DOS для MS DOS, PC DOS и наоборот.

cu, w0lf.

Vue.js полностью!

Вам непременно стоит посмотреть на Hyperapp .
Плюсы

1. Он очень похож на архитектуру Elm (Модель, Вид, Обновление).
2. Он имеет встроенные Redux, такие как Reducers, которые называются «действиями» (вызываются для обновления модели и, в свою очередь, просмотра).
3. Использует JSX
4. Поощряет дизайн "функционального программирования"
5. Его размер составляет 1 КБ, поэтому его легко загрузить и понять.

Минусы

1. Он все еще новый, как и экосистема. Но вы можете повлиять на это и внести свой вклад.
2. Могут быть проблемы, которые еще не раскрыты.

Принципы блоков Гутенберга хорошо согласуются с принципами веб-компонентов . Это низкоуровневый, независимый от фреймворка и развивающийся стандарт (со зрелыми и проверенными полифилами) - идеально подходит для WordPress.

См. Также: Полимер - Веб-компоненты с добавлением сахара.

Vue - фантастический вариант, и вот почему я так считаю:

Я начал смотреть Vue в начале 2016 года. Мне он понравился, и я хотел определить, будет ли он когда-либо «востребован» или его рост будет чем-то особенным. В то время у него 16000 звезд на Github. Это было круто и все такое, но люди так и не адаптировались к нему среди всей этой ерунды Angular vs React.

Я потерял _все_ свои данные и начал заново 17 сентября 2016 года. Ровно год назад, сегодня. ( Вот мой текущий набор данных. )

За последний год я наблюдал, как популярность Vue растет (с точки зрения упоминаний в Интернете и отслеживания звезд Github) с рекордной скоростью. Vue набрал 40000 звезд за 365 дней. Это в среднем 109 в день. Для сравнения, популярный в мире _React_ вырос с 49 000 до 75 000 за тот же период времени. (71 в день) Vue превзойдет React в ближайшие несколько месяцев по рейтингам пользователей.

Хотя все говорили о том, что рост React был самым невероятным за все время, они не знали, что Vue был настоящим обладателем титула. Они не знали, что Vue растет из-за того, что люди искренне любили его как инструмент, а не из-за какой-либо известной поддержки (Facebook).

Vue был в списке трендов репозиториев Github каждый день уже более года. 99% дней он выше React. 10% дней React не работает.

Все эти крики «используйте Vue, потому что он стал популярнее!» Но я хочу сказать, что Vue вырос, потому что люди искренне любят его, потому что это отличный, интуитивно понятный и мощный инструмент (часто ошибочно представляемый как «отличный для небольших приложений») для приложений любого размера. Но не только инструмент. Vue - это экосистема. Он также имеет огромное поддерживающее сообщество.

Могу я добавить ... файлы .vue - гениальны. Так много инструментов создается для обработки стилей в React, потому что явно что-то не так с модулями CSS и хранением ваших стилей во внешнем файле. (Идк ...) Но у Vue этой проблемы нет. Vue имеет управляющие операторы, встроенные в синтаксис, и (поскольку я видел выше комментарии к настраиваемым элементам) не только хорошо работает с настраиваемыми элементами ... Это _is_ библиотека / фреймворк для логических настраиваемых элементов.

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

Это мои два цента. Теперь я разорен.

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

@ahmadawais :

• Время выхода на рынок важно как для корпоративных проектов, так и для проектов с открытым исходным кодом. Вы можете найти примеры проектов, которые так и не были отправлены, потому что в конечном итоге они заняли слишком много времени и устарели до того, как были отправлены. Несколько проектов были заброшены во время работы над основным релизом.
• Противостояние Preact означает, что «мы допустили ошибку с React по причинам, не связанным с лицензированием». Я думаю, что, говоря «Кривая обучения уже огромна для разработчиков среднего / нового уровня», вы имели в виду, что разработчики WordPress уже потерялись с React. Меня это не удивляет. Но кажется трудным поверить, что Vue, даже если он менее подробный, решит проблемы кривой обучения. Старый движок PHP WP и какой -
  Я не уверен, почему вы видите конкуренцию между Wordpress и Laravel. Возможно, я здесь наивен. Я очень мало знаю об истории Drupal 8.
  С моей точки зрения, Wordpress - это CMS, и она привлекает разработчиков своей большой пользовательской базой нетехнических пользователей и уже встроенными в нее функциями. Существует множество шаблонов, и разработчики могут очень быстро создать новый сайт, который может настраивать не разработчик.
  Laravel - это PHP-фреймворк, который, насколько мне известно, не дает вам многих функций CMS. Разработчик выберет его, потому что ему нужно больше свободы.
• Я не уверен, как несколько успехов с Vue + Laravel также означают, что «Vue хорош для Wordpress». Я думаю, что между PHP и любым JS-фреймворком очень мало внутренней синергии. Я полностью согласен с тем, что важно найти структуру, полезную для сообщества. Если большая часть нынешнего сообщества разработчиков, от которого зависит wordpress, знакомы с Vue и им он нравится, это имеет большой вес в вашем окончательном решении.

С инженерной точки зрения я считаю, что и Marko JS, и Vue - более новые фреймворки. Они многому научились у React и смогли избавиться от многословности в нем. В этом смысле Марко, похоже, удаляет даже больше шаблонного кода, чем Vue. В частности, Марко сохраняет целостный код, который хорошо хранить в одном месте, оставляя в HTML то, для чего нужен HTML, а в Javascript - для чего нужен Javascript. И это также в 10 раз быстрее. Так что помимо того факта, что в последнее время у Vue появилось много поклонников, я не вижу много причин предпочитать Vue Марко.

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

Синтаксис @ bovas85 субъективен, но я не думаю, что есть какие-либо основания в вашем утверждении, что синтаксис Марко "ужасен по сравнению". Действительно, ранние версии Marko имели синтаксис, который был ближе к синтаксису Vue на основе HTML, и выпуск, в котором был представлен текущий синтаксис Marko, был чрезвычайно хорошо принят нашими пользователями.

Мы много продумали синтаксис Marko, чтобы убедиться, что он знаком разработчикам, разбирающимся в HTML и JS, и мы хотели, чтобы он был как можно более простым и мощным с минимальным набором шаблонов. Я думаю, вы обнаружите, что при любом параллельном сравнении шаблон Marko потребует меньше кода (что отлично подходит для удобочитаемости и удобства обслуживания).

Вот документ, который я быстро собрал, чтобы вы могли увидеть обзор различий между синтаксисом Марко и синтаксисом Vue:

Синтаксис: Marko vs Vue

Я связался с ним ранее, но для более подробного сравнения между Marko и Vue (и React) см.:

Встреча: Создание пользовательского интерфейса - сравнение React, Vue и Marko (от создателя Marko) - Видео | Слайды

Что касается производительности, у нас есть несколько тестов, которые вы можете проверить: https://github.com/marko-js/isomorphic-ui-benchmarks

Вот краткий обзор тестов с включенными Marko и Vue:

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

_Node.js ( v8.4.0 ) _

Running "search-results"...

Running benchmark "marko"...
marko x 5,180 ops/sec ±2.09% (87 runs sampled)

Running benchmark "vue"...
vue x 135 ops/sec ±3.81% (68 runs sampled)

Fastest is marko

Running "color-picker"...

Running benchmark "marko"...
marko x 10,206 ops/sec ±0.72% (87 runs sampled)

Running benchmark "vue"...
vue x 1,664 ops/sec ±5.20% (66 runs sampled)

Fastest is marko

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

_Chrome Version 63.0.3218.0 (Официальная сборка) canary (64-бит) _

Running "search-results"...
Running benchmark "marko"...
marko x 351 ops/sec ±1.18% (58 runs sampled)
Running benchmark "vue"...
vue x 206 ops/sec ±1.61% (57 runs sampled)
Fastest is marko

Running "color-picker"...
Running benchmark "marko"...
marko x 7,516 ops/sec ±2.90% (41 runs sampled)
Running benchmark "vue"...
vue x 4,593 ops/sec ±3.03% (54 runs sampled)
Fastest is marko

Это тесты, которые мы создали для Marko.js, поэтому очевидно, что мы относимся к этим результатам с недоверием, но мы приложили все усилия, чтобы быть справедливыми.

Кроме того, просто хотел добавить еще несколько комментариев относительно Marko.js и простоты использования:

Марко всегда стремился к простейшей интеграции с Node.js. После установки пакета marko через npm вот весь код, необходимый для рендеринга шаблона в поток HTTP-ответов:

require('marko/node-require'); // require .marko files!

const http = require('http');
const template = require('./template');

http.createServer().on('request', (req, res) => {
  template.render({
    name: 'Frank',
    count: 30,
    colors: ['red', 'green', 'blue']
  }, res);
}).listen(8080);

Я думаю, что это настолько просто, насколько вы можете себе представить.

Марко также работает с популярными сборщиками модулей JavaScript: http://markojs.com/docs/bundler-integrations-overview/

Вот все, что требуется для рендеринга компонента пользовательского интерфейса Marko верхнего уровня в DOM:

require('./fancy-button')                  // Import the Marko UI component
  .renderSync({ label: 'Click me' })   // Render the button with the provided input
  .appendTo(document.body);         // Mount the UI component to the DOM

@ patrick-steele-idem Согласно http://www.stefankrause.net/wp/?p=431 тестам, markoJs
столь же эффективен, как Vue et al.

Итак, мы можем сделать вывод, что в целом сценарии на стороне клиента Markojs и Vue одинаково эффективны.

Конечно, тест, который я связал, не включает ssr. Так что я не буду это комментировать.

Голосую за Vue. jQuery уже является обязательным требованием для использования WordPress. Люди, знакомые с jQuery, должны быть знакомы с синтаксисом Vue. Идеология DOM не такая уж экстремальная, как что-то вроде Angular. Он опирается на принцип WordPress для удобства пользователя.

Как я предлагал около двух лет назад для Calypso , Mithril.js, использующий HyperScript API, будет хорошим выбором для замены React. Имеет стандартную лицензию MIT.

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

Даже без учета библиотек, отличных от vdom, можно рассмотреть более 25 библиотек vdom (например, inferno.js, maquette и т. Д.) - как и в этом списке, который я составил

Вот несколько технических причин, по которым Mithril.js или другие виртуальные серверы, подчеркивающие (или, по крайней мере, поддерживающие) HyperScript API, являются лучшим выбором.

Лично я считаю, что подходы к созданию пользовательских интерфейсов на основе JavaScript, такие как React JSX или собственный шаблонный подход Angular, или системы шаблонов во многих других системах пользовательского интерфейса, включая Vue, устарели. Почему? Предпочтения и «лучшие практики» для написания сгенерированных на стороне сервера веб-приложений на основе HTML-шаблонов с использованием сложных таблиц стилей CSS (как и для предыдущих плагинов WordPress) становятся «худшими методами» для написания одностраничных веб-приложений. Технические потребности для написания сложных современных одностраничных клиентских приложений отличаются от написания кода, в основном основанного на сервере, из-за возрастающей сложности клиентского кода. Короче говоря, старые «лучшие практики» использования шаблонов и сложных каскадных таблиц стилей просто не масштабируются, что затрудняет сопровождение кода.

Какая новая альтернатива? Современные веб-приложения могут использовать Mithril + Tachyons + JavaScript / TypeScript для записи компонентов в отдельные файлы, где весь код - это просто JavaScript / TypeScript. Такие приложения не обязательно должны быть частично написаны ни на CSS, ни на каком-либо нестандартном варианте HTML, который частично переопределяет язык программирования (плохо). (Ну, может потребоваться небольшой кусочек пользовательского CSS поверх Tachyons или подобных библиотек, но очень мало.)

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

Итак, написав пользовательские интерфейсы с использованием HyperScript (плюс библиотека vdom), вы потенциально можете (с некоторой работой) заменить бэкэнд, такой как Mithril, практически любым другим vdom или даже не-vdom решением. Итак, когда у меня есть выбор, выбор использования HyperScript API - это способ снизить риск того, что в базовых библиотеках есть ошибки или проблемы с лицензированием.

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

Конечно, я знаю, что многие веб-разработчики выросли на настройке HTML и любят шаблоны, похожие на HTML. Таким образом, они любят JSX или что-то еще и с радостью игнорируют, насколько сложно рефакторинг таких вещей, не связанных с кодом, в середине своих приложений или их проверки. Конечно, некоторые IDE улучшают рефакторинг JSX-шаблонов. Но я пришел к веб-разработке с настольных компьютеров и встраиваемых систем, работая с системами, где вы (обычно) создавали пользовательские интерфейсы непосредственно из кода (например, используя Swing, Tk, wxWidgets и т. Д.). Мне нравится идея, что стандартные инструменты могут помочь мне реорганизовать весь код, над которым я работаю, и обнаружить множество несоответствий.

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

Но если мы используем рендеринг на стороне сервера, нам следует внимательно посмотреть на производительность SSR. Похоже, что Calypso стремится создать SSR. И в случае успеха однажды Calypso запустит большинство сайтов на wordpress.com.

Компания платит за ЦП на серверах, а не за ЦП в браузерах. Таким образом, с точки зрения затрат, 10-кратное ускорение времени рендеринга Marko, вероятно, означает, что тот же трафик, который максимум для 10 серверов с MarkoJS, на самом деле займет не менее 100 серверов с Vue.

Если Wordpress сможет это проигнорировать, я с радостью приду работать в компанию, получу 10-кратную рыночную зарплату и буду использовать Vue, который, кстати, я считаю хорошей альтернативой React =)

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

https://hueniverse.com/performance-at-rest-75bb8fff143

@ahmadawais Основная команда Angular здесь - мы выполняем много интересной работы, связанной с разработкой стиля CMS / Widget, включая инвестирование в поддержку Custom Elements (что, на мои деньги, является разумной ставкой на будущее для создания платформ)

Вместо того, чтобы загромождать тему, мы будем рады поговорить с вами в автономном режиме, если у вас есть какой-либо интерес. Напишите мне на robwormald в google dot com. Удачи, я не завидую, что вам пришлось сделать этот звонок ;-)

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

в настоящее время работает над страницей результатов и авторизуется. (новичок в firebase)

PS. Это заняло около часа, чтобы сделать это с помощью Vue 🖖

@vinayakkulkarni Как насчет добавления Mithril.js в свой опрос?

@pdfernhout : 👍

Готово. Я добавил в список MithrilJS.

• [x] VueJS
• [x] Угловой
• [x] Preact
• [x] Эмбер
• [x] Марко
• [x] Inferno
• [x] Аурелия
• [x] Митрихил

Посмотрим, что решат люди ..
PS. @ahmadawais также опрос в твиттере .

Привет. Я поддерживаю ядро ​​Drupal. Как @ivanjaros упомянул в предыдущем комментарии, мы также оцениваем Preact, Vue или что-то еще для некоторых предстоящих частей пользовательского интерфейса администратора Drupal. Мы можем выбрать что-то иное, чем то, что вы выберете, но то, что вы выберете, безусловно, будет, по крайней мере, одним из факторов, которые мы будем учитывать при нашем выборе.

Я уже открыл эти два выпуска Drupal, и их будут еще больше. Просто сделайте перекрестные ссылки на них здесь, если эти вопросы / обсуждения будут вам полезны.

• компоненты, возвращающие несколько корневых узлов
• слоты против реквизита vnode

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

Как автор Vue, я не буду комментировать, какой фреймворк выбрать здесь, поскольку я явно предвзято; но поскольку я видел утверждение, что «Марко в 10 раз быстрее, чем Vue», которое произносили несколько раз, я считаю, что оно заслуживает некоторого пояснения. Я также не хочу превращать обсуждение в технические дебаты, поэтому я записал некоторые мысли в этом смысле для тех, кому интересно.

@ michaelbdavidson7 по поводу финансовых проблем: я работаю над Vue на постоянной основе уже более 1,5 лет, и поддержка Patreon была действительно стабильной. Вместо того, чтобы спекулировать на колебаниях обязательств Patreon, вы можете проверить активность коммитов Vue, чтобы судить сами. Вдобавок: наличие открытого канала финансового участия означает, что WP / Automattic может легко обеспечить устойчивость Vue, став крупным спонсором (сам Мэтт уже является личным спонсором!) - что фактически соответствует интересам обоих проектов.

Я голосую за Vuejs

@ tungbt94 Почему?

Определенно VueJS

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

Мой голос в Preact

Поскольку у меня нет большого опыта ни с чем, кроме React, я не буду взвешивать, какой фреймворк выбрать.
Однако я думаю, что аргумент «большого сообщества» может иметь меньшее значение. Почему? потому что, когда Automattic выберет фреймворк, эта работа получит тысячи новых пользователей. И если я правильно знаю сообщество WP, многие из них также начнут вносить свой вклад в этот фреймворк, и их популярность будет расти.

Учитывая, где сейчас находятся Гутенберг и Калипсо, я по-прежнему считаю, что Preact - лучший инженерный выбор.

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

Если предположить, что звезды Github каким-то образом связаны с сообществом, Vue по-прежнему в 10 раз больше по сравнению с MarkoJ, но, глядя на графики, он быстро изменится.

Vue растет линейно:

Но похоже, что MarkoJs находится в точке перегиба экспоненциального роста:

@ patrick-steele-idem, главный автор MarkoJs , всегда был очень отзывчивым на https://gitter.im/marko-js/marko

Когда люди в конечном итоге выбирают MarkoJs , а на самом деле любое сообщество, мне хочется перефразировать цитату JFK: «Не спрашивайте, что сообщество может для вас сделать - спрашивайте, что вы можете сделать для сообщества».

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

Я подозреваю, что эта проблема помогла большему количеству разработчиков JS сообщить о том, что WordPress движется в сторону большей разработки на основе JavaScript через Gutenberg, чем любое другое сообщение Gutenberg до сих пор.

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

+1 для Марко. Отличная библиотека, которой пользуется наша команда, и которой она очень довольна. Асинхронный рендеринг, сверхбыстрый (рендеринг в строку на сервере и в vdom в браузере), одно- или многофайловые компоненты, и IMO - лучший синтаксис шаблонов.

Пожалуйста @WebReflection «s hyperHTML во внимание.

Мне нравится угловой

Я голосую за Angular

Я выбираю угловой

просто угловатый

Я выбираю угловой

угловатый

Я голосую за Angular

Я голосую за Angular

Если вы хотите проголосовать за фреймворк, было бы неплохо знать точную причину и как это помогает Гутенбергу.

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

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

С таким количеством спама «Я голосуюframework », github вопит за меня.

Я призываю коллег-разработчиков любезно проголосовать за ваш выбор фреймворка на https://vinayakkulkarni.github.io/poll/ https://vinayakkulkarni.github.io/poll/ вместо того, чтобы просто публиковать «Я голосую…»;

Также есть еще одно предложение - заблокировать этот разговор; большинство крупных разработчиков уже высказались по этому поводу.

18 сентября 2017 г., в 20.01, Mingyue [email protected] написал:

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

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub https://github.com/WordPress/gutenberg/issues/2733#issuecomment-330241898 или отключите поток https://github.com/notifications/unsubscribe-auth/AS3FbT23DvVwTLGL61tmK7KtuwZeg ucks5sjn7SgaJpZM4PYie9 .

спасибо @kidwm за упоминание _hyperHTML_, но я думаю, что лучше следовать их указаниям:

Расскажите не только о том, какой JS-фреймворк вам нравится, но и о том, почему

так что позвольте мне попробовать сделать это ...

: zap: hyperHTML :

• ПРОФЕССИОНАЛЬНО : дружелюбный к новичкам и знакомый пользователям P / React (вместо JSX вы пишете шаблонные литералы)
• PRO : быстро и без VDOM; меньшее потребление памяти (удобство для телефонов на развивающихся рынках)
• PRO : не требует инструментов (требуются перенесенные шаблонные литералы только для IE <11)
• PRO : полностью основан на стандартах JS / DOM / HTML, но также совместим с TypeScript
• ПРОФЕССИОНАЛЬНО : вмещается менее 5 КБ (минимальное сжатие) без дополнительных полифиллов или исправлений для браузеров
• PRO : 100% покрытие кода с учетом особенностей IE9
• PRO : использует тот же API, что и его аналог NodeJS ; 100% совместимость с рендерингом на стороне сервера
• PRO : он может использовать существующий DOM без мусора макетов / узлов SSR
• PRO : работает с пользовательскими элементами лучше, чем P / React, его также можно использовать для определения пользовательских элементов.
• PRO : он может делать то, что делают React , Vue.js , Polymer , Angular или Marko , и выигрывает с точки зрения размера / пропускной способности / производительности каждого из них

Теперь, в соответствии с показателями, используемыми до сих пор в этой теме, МИНУСЫ

• МИНУСЫ : даже если он прошел боевое тестирование, полностью протестирован и с замороженным API, это относительно молодой проект (март 2017 г.), поэтому он не может конкурировать с точки зрения популярности, принятия или количества участников.
• МИНУСЫ : сообщество очень помогает, и проект растет, но пока основной технический участник - это я. Я на 100% привержен этому проекту и готов продвигать его как можно больше, плюс я обсуждаю с некоторыми "_bigs_" использование _hyperHTML_ в некоторых из их следующих крупных проектов (я не буду спекулировать дальше хотя, не стесняйтесь игнорировать эту последнюю часть)

: dart: Я искренне верю, что будущее Интернета - в максимально возможном использовании платформы, что определенно лучше, чем 10 лет назад, а благодаря современным спецификациям ECMAScript стало проще писать, читать и поддерживать. _hyperHTML_ представляет "_состояние современного веб-искусства_" с точки зрения потенциала, в то время как все остальные претенденты в этом списке были рождены в эпоху, предшествовавшую полной ES6.

Я понимаю, что размер сообщества, участники и звезды на GitHub важны, но я думаю, что нужно учитывать тесты, кроссбраузерный код и количество ошибок, и я стараюсь, чтобы количество _hyperHTML_ и друзей было близко к ноль (на самом деле это ноль прямо сейчас, за исключением обсуждения, которое не является ошибкой).

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

Конечно, я говорил о своем последнем решении, мои соображения можно считать субъективными, но особенно мое последнее предложение о предоставлении возможности новым решениям было очень общим, не только о моих библиотеках: smiley:

С уважением

Мне нравится угловатый

должен быть угловым и гугл.

я люблю угловатый

Angular - это только настоящий фреймворк!

Я выбираю Angular, а не AngularJs.

Только angular - это настоящий фреймворк!

Я начинаю подозревать, что эти комментарии сделаны ботами.

@OP : Пожалуйста, заблокируйте эту тему.

Я голосую за Angular (НЕ AngularJS).

Angular - это платформа, команда Google проделала огромную работу, чтобы упростить разработку, включая компонент, модуль, маршрутизатор, с помощью внедрения зависимостей, вы можете сэкономить много работы, чтобы упорядочить все зависимости, с помощью angular-cli, вы можете сэкономить много работы, чтобы начать новый проект, вы просто открываете окно, и ваше приложение хорошо скомпилировано с помощью aot, tree shaking и многих других оптимизаций.

TypeScript - еще один отличный инструмент с angular, он предоставляется MicroSoft, иначе вся платформа angular построена с помощью ts. Вы тоже создаете свое приложение с помощью ts! Это отличный инструмент, облегчающий жизнь, когда объем кода становится все больше и больше, вы можете выполнить рефакторинг в среде IDE (например, vscode) одним щелчком мыши. Статическая проверка типов позволяет находить ошибки как можно раньше. TS также обеспечивает хорошую реализацию ООП, вы можете упорядочить и повторно использовать свой код гораздо лучше.

Также есть много компонентов, построенных на основе angular, таких как meterial design2, primeng, и я хочу порекомендовать вам Jigsaw , который создан нашей командой. Он принят продуктом больших данных ZTE China. Теперь он поддерживает все приложения ZTE.

Англар - отличный выбор !!

Всем ботам: 🖕

Вероятно, кто-то написал в сообществе AngularJs. Я думаю, что люди могут игнорировать ветку, если они больше не хотят получать сообщения.

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

Я хотел бы поделиться некоторыми своими мыслями по этому поводу, которые я в основном уже высказал в группе сообщества EmberJS slack, если у вас есть 10 минут, чтобы прочитать обсуждение там, я бы порекомендовал это: https://embercommunity.slackarchive.io / wb-marketing / page-2 / ts-1505456102000189 Там довольно много всего, но я настоятельно рекомендую проверить это, чтобы получить более полное представление о ходе обсуждения.

Мои основные моменты в этом обсуждении заключаются в следующем:

• При сравнении 2-4-недельного всплеска реализации чего-то в рамках Ember с любой другой библиотекой другие библиотеки, как правило, выигрывают в краткосрочной перспективе, но Ember выигрывает для любого долгосрочного проекта.
• При выборе библиотеки или фреймворка важно учитывать не только техническую реализацию, но и аспекты «мягких навыков» (размер сообщества, приверженность поддержке LTS, участие сообщества в основных решениях проекта).
• Ember имеет опыт внесения значительных улучшений в приложения, созданные с использованием ember-cli «под капотом», то есть без необходимости обновлять какой-либо код приложения. Также были случаи незначительных обновлений кода приложения (с включенным модулем кода с использованием таких вещей, как ember-watson ), вы получали значительное повышение производительности и производительности.

Я не хочу вдаваться в подробности в этом комментарии, потому что я с радостью мог бы написать эссе на 10 000 слов по вышеуказанным вопросам. Тем не менее, я хотел бы уделить свое время всем, кто хотел бы обсудить этот вопрос с кем-то, кто имеет «мышление Ember».

Если кто-то из лиц, принимающих решения, захочет поговорить со мной в течение часа, чтобы задать более острые вопросы о более широкой экосистеме Ember, я с радостью сделаю это. Вы можете связаться со мной в моем Twitter (открытые личные сообщения). Возможно, я не являюсь членом основной команды, но я создавал приложения Ember с момента выхода версии 1.0 и прошел все процессы обновления с помощью различных приложений 👍

Я работаю на «Мой eBay» на eBay. Мы только что выпустили наше первое одностраничное приложение . Нам понравился каждый этап разработки с использованием MarkoJS. Как и я, если вам нравится парадигма потокового программирования node, тогда MarkoJS поддерживает потоковую передачу и асинхронный рендеринг. Другие факты о MarkoJS, которые мне понравились:

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

• Очень эффективное делегирование мероприятий

• Быстрая сериализация состояния с сервера в браузер

@vinayakkulkarni Я думаю, что ваша идея хороша, но проблема в том, что я могу оставить более одного голоса, сменив браузер (я не пробовал использовать тот же браузер).

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

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

Vue.js! посмотрите этот проект https://github.com/bstavroulakis/vue-wordpress-pwa

Я выбрал Angular (не AngularJS), у него самое большое сообщество, стабильная и полная экосистема.

Angular очень медленный, а с v4 он основан на машинописном тексте и бесполезен для разработки WordPress.

Выбираю Angular по зрелости платформы

Я бы проголосовал за Vue, потому что его легче изучать и потому что мой любимый фреймворк Ember Js слишком велик для работы, а Glimmer Js все еще слишком нов. :-)

Серверный рендеринг здесь не имеет отношения к разговору.

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

Node не станет частью необходимого стека WordPress

_hyperHTML_ может получать любой контент, отображаемый на стороне сервера, включая PHP. Я сертифицированный инженер Zend, и я уже работал с журналистами / издателями, использующими WordPress, мой намек не был неожиданным.

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

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

@webreflection Я не имел в виду этот комментарий, чтобы придираться конкретно к вам. Это скорее ответ на комментарий выше, в котором подчеркивается «парадигма потоковой передачи» Марко, но он был предназначен для охвата всех комментариев о производительности рендеринга BE.

Посмотреть

@mAAdhaTTah из https://ma.tt/2017/09/on-react-and-wordpress/ :

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

И что еще важнее:

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

Calypso уже использует рендеринг на стороне сервера. См. Https://github.com/Automattic/wp-calypso/blob/master/server/render/index.js#L58

Насколько я понимаю, характеристики SSR имеют значение.

Я тоже люблю угловые！
Реальный фреймворк AngularJS js！

Я голосую за Angular

@chriscinelli Это

Очевидно, что Angular - лучший выбор

Я голосую за Angular

Я голосую за Angular

Я голосую за Vue.js.
Это экономит большую часть времени, особенно при работе со слоем представлений.

Я должен проголосовать за Vue !!!

Бросьте волну угловатой

@trotyl Этот комментарий неприемлем. Я отредактировал ваш комментарий, чтобы удалить его.

о, пожалуйста, не AngularJS
теперь Angular.

@mAAdhaTTah Из википедии:

WordPress был выпущен 27 мая 2003 года его основателями Мэттом Мулленвегом и Майком Литтлом как форк b2 / cafelog.

Хотя WordPress в значительной степени разработан окружающим его сообществом, он тесно связан с Automattic , компанией, основанной Мэттом Мулленвегом.

Это Calypso: https://developer.wordpress.com/calypso/, а Calypso использует SSR.

Как я писал в своем предыдущем комментарии , из сообщения в блоге, в котором Мэтт

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

Однако в далеком будущем, когда разработчики Wordpress привыкнут к Preact (или Vue, или Marko, или другому фреймворку), может появиться новый сумасшедший проект, и они решат обслуживать еще больше частей Wordpress через узел. Это сделает SSR еще более важным. Так что характеристики SSR могут быть даже более важными.

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

Хотя я действительно использую Fastboot (с большим эффектом) с несколькими клиентскими приложениями, поскольку это обсуждение на высоком уровне, я бы порекомендовал обратиться к

@chriscinelli WordPress, проект сообщества, и компания Automattic, по-прежнему являются отдельными организациями. Если Automattic хочет спорить в пользу того или иного из-за SSR, они могут, но это все равно не меняет того, как мы, сообщество WordPress, должны рассматривать выбор фреймворка для ядра WordPress, который не имеет и действительно не может требуется узел для запуска.

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

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

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

Я бы проголосовал за Vue.js

Я старший специалист, учился в Массачусетском технологическом институте и должен быть достаточно умным. Я занимаюсь этим много лет и брал интервью у нескольких разработчиков тут и там. Я знаю, что в сети полно умных людей, но любой, кто думает, что простота Vue сравнима со сложностью Angular, теряет представление о том, что составляет «сложность». Компонентный Javascript, как задумал Google, совершенно нетривиален. Это до смешного сложно. Vue - нет. Vue так же прост, как и PHP. Я говорю очевидное, потому что «Vue легче изучить» даже близко не подходит к описанию того, насколько Vue проще, чем Angular. И вот в чем загвоздка - я думаю, что это намного проще, чем React.

React балансировал между простотой и уровнем Google для обычных людей. Что касается небольших магазинов, я бы сказал, что React достаточно сложен, чтобы бросать вызов небольшим командам. React сложнее, чем, например, PHP / Wordpress. Выбрав React, Wordpress / Automattic повысил требования для входа разработчиков в мир разработчиков Wordpress. Я уверен, что сотни людей закричат: «Реагировать легко» и «Интернет становится умнее», но в конце концов, чем сложнее, тем сложнее.

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

Angular и Vue - это разные вещи

Vue, React, MarkoJS, Inferno, Preact и т. Д. - это библиотеки, охватывающие только уровень представления. Все они, включая Angular, имеют способ декларативно создавать HTML и изменять DOM. Angular хочет предоставить полную структуру для разработки внешнего интерфейса и имеет гораздо больше вещей за пределами уровня представления.

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

Все остальные библиотеки в этом списке учились на React. Они попытались упростить синтаксис, улучшить производительность React, уменьшить размер кода Javascript, необходимого для того же, и добавить некоторые функции поверх него.
Preact проделал огромную работу, чтобы сохранить интерфейс, очень похожий на React, всего лишь в 3 КБ.
Inferno и Marko значительно оптимизировали производительность рендеринга.
Марко и Vue значительно упростили синтаксис, чтобы сократить шаблонный код.
Марко также добавил необязательный синтаксис, подобный Jade / Pug, чтобы код был более СУХИМ, и возможность создавать асинхронные шаблоны, сохраняя все простым и интуитивно понятным для пользователя.

Однако все эти библиотеки, помимо Angular, требуют, чтобы инженеры разработали стратегию и механизмы для получения данных, маршрутизации и т. Д. Redux и его промежуточное программное обеспечение - один из популярных способов, которые Гутемберг использовал для управления уровнем данных.

При переходе с React Гутенбергу не нужно «менять что-то еще». Даже если Angular стремился оставаться агностиком для пользователя, использование его с Redux и Javascript (vs Typescript) не является естественным выбором, несмотря на то, что были разработаны и поддерживаются такие библиотеки, как https://github.com/angular-redux/ng-redux для Javascript доступен. Более того, если посмотреть на результаты голосования до сих пор, кажется, что сообщество Гутенберга категорически против структуры Google. Так что, скорее всего, Angular не будет вариантом.

PHP и любой из этих Javascript-фреймворков - совершенно разные звери.

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

Любое приложение Javascript как минимум на один порядок выше сложности, которую вы можете написать при написании простого кода PHP с добавлением некоторого количества jQuery. Всем современным приложениям Javascript приходится иметь дело с двумя большими монстрами сложности: сохранением состояния и асинхронными потоками . Они смягчаются только неизменностью и async / await в последние годы. По мере роста приложения поток разработки замедляется. Когда вы меняете какой-то код, вам нужно перекомпилировать, перезапустить, и приложение должно снова пройти инициализацию. Было создано огромное количество инструментов для реализации горячих перезагрузок, и даже если они прекрасны, они все еще далеки от совершенства.
Независимо от того, какую библиотеку вы выберете для слоя представления, вам придется столкнуться с дополнительной сложностью.

В PHP вы меняете код, сохраняете файл и можете немедленно перезагрузить страницу без сборки или перезагрузки. Все работает. И что еще более важно, PHP полностью не имеет состояния . Каждый раз, когда вы перезагружаете страницу, у вас остается чистый лист. Даже глобальные переменные имеют чистое состояние с каждым запросом (но это плохой предлог для их использования = P). Я не писал PHP-код несколько лет, но мне все еще не хватает его простоты и опыта разработки. Если вы используете современный фреймворк, такой как CakePHP, Symphony или Laravel, вы не упустите многое по сравнению с другими языками и фреймворками, которые более приветствуются опытными инженерами. Исключение составляет скорость. PHP платит за свою простоту производительностью во время выполнения. Каждый раз, когда вы перезагружаете страницу, весь код нужно запускать заново. Производительность сильно выросла с HHVM и PHP7, но в целом они все еще далеки от того, чего вы можете достичь с помощью node.js.

Заключение

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

В конце концов:

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

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

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

И еще раз удачи с вашим решением 😃

Я отдал свой голос за Vue. Надежный и удобный для новичков. Когда я впервые начал использовать Vue, у меня возникло то чувство, которое у меня было, когда я только начал разрабатывать WordPress. + 💯

@ colorful-tones только для начинающих - этого не достаточно! У каждого проекта есть жизненный цикл, большая часть работы находится в процессе сопровождения.

@ChrisCinelli Несколько пояснений и мнений:

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

Vue имеет официальные библиотеки для маршрутизации, управления состоянием, тестирования, линтинга и многого другого, а также официальный инструмент cli. Все они находятся в рамках организации vuejs, поддерживаются основными участниками и синхронизируются с самим Vue, но самое приятное то, что вам не нужно их изучать или использовать (отсюда и философия «Progressive Framework»). В отличие от React, это фактически делает его официальным фреймворком. Маленький каламбур: все это проще в освоении, быстрее и легче, чем Angular. :улыбка:

Марко также добавил необязательный синтаксис типа Jade / Pug.

.vue files могут использовать любой препроцессор для шаблона, скрипта или стиля (например, pug, typescript, coffescript, sass, stylus ...). Используйте то, что лучше всего подходит для вашего проекта!

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

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

async created () {
  const result = await fetch('/api/items')
  this.items = await result.json()
}

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

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

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

Единственное реальное отличие - это этап сборки, который в настоящее время легко настроить с помощью таких инструментов, как официальный vue-cli или poi . Когда вы сохраняете файл, приложение почти мгновенно готово к обновлению (время сборки очень хорошее и для больших проектов, и, судя по опыту, разработка большого PHP-приложения с использованием фреймворка, такого как Symfony, более болезненна). Кроме того, функция горячей замены модуля является большим плюсом, которого нет в мире PHP (насколько мне известно), и позволяет новому коду быть доступным для тестирования в браузере почти мгновенно даже в больших проектах (если у вас нет дорогостоящие операции, такие как компиляция Sass, но при использовании PHP возникнет такая же проблема). Кстати, Vue очень хорошо поддерживает webpack HMR.

Вам придется столкнуться с дополнительной сложностью.

IMHO, некоторые очень популярные PHP-фреймворки кажутся более сложными и трудными для изучения, чем некоторые внешние библиотеки / фреймворки, такие как Vue. (Верно и обратное.)

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

• Как VueJS / Marko / Angular будет интегрироваться с перетаскиванием? Как будет работать перетаскивание в Гутенберге? При перетаскивании вы клонируете призрачный элемент или используете существующий элемент? Где можно вставить заполнители при отбрасывании блока?

• Как VueJS / Marko / Angular (и его виртуальный DOM) будет работать с Content Editables и DOM Range & Selection API? Кросс-браузерные несоответствия с этим диапазоном и выбором здесь может быть очень сложно исправить.

• В какой степени копирование / вырезание / вставка будет работать в редакторе Гутенберга? Могу ли я выделить текст между несколькими блоками и выполнить вырезание / копирование / вставку? Живут ли редактируемый контент в каждом отдельном блоке или все это содержится в главном контенте?

• Если есть блоки Гутенберга, которые содержат встраиваемые элементы iframe, например, встраивание проигрывателя YouTube или канала Twitter в сообщение блога, перемещение этого блока из одной позиции DOM в другую приведет к перезагрузке iframe. Другие предостережения включают невозможность передачи событий из iframe обратно в редактор (представьте, если вы перетаскиваете элемент блока через редактор, а ваш курсор теперь зависает на межсайтовом iframe, и все перестает работать).

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

Посмотреть

Wordpress является достаточно легким для обучения новых разработчиков, а также имеет большую мощь, если заглянуть чуть глубже, тоже самое можно сказать о Vue
Я буду рад если WP будет использовать этот фреймворк!

My vote is VUE!

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

https://custom-elements-everywhere.com/

Мой голос за VueJS. Замечательный фреймворк, думаю, Laravel это доказал.

WP + Sage 9 (root.io) + VueJS => идеальный стек

Также может быть проблема с Preact.

https://blog.cloudboost.io/3-points-to-consider-before-migrating-away-from-react-because-of-facebooks-bsd-patent-license-b4a32562d268

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

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

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

20 сентября 2017 г. в 23:04 «Друг кодирования» [email protected] написал:

Также может быть проблема с Preact.

https://blog.cloudboost.io/3-points-to-consider-before-
миграция-от-реагировать-из-за-facebooks-bsd-
патент-лицензия-b4a32562d268

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

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

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/WordPress/gutenberg/issues/2733#issuecomment-331045326 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AH2_iHc8Rg54IDHqe8GIyVTdSbcJbZ9Iks5skeBngaJpZM4PYie9
.

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

Отказ от ответственности: я не юрист. Я строго придерживаюсь моего мнения.

@ codingfriend1 эта статья не имеет большого практического значения.

Сделаны три предположения:

1. У Facebook есть патенты, которые достаточно широки, чтобы охватить предварительные требования.
2. Если компания, использующая preact, скажем, ABC, подаст в суд на FB за нарушение патентных прав, то FB будет использовать патенты реагирования для подачи иска на ABC.
3. У патента Facebook есть свои достоинства.

Рассмотрим подробнее все предположения:

1. У Facebook есть патенты, которые достаточно широки, чтобы покрыть преакт.

Доказательств этого до сих пор нет. Помните, что все патенты являются общедоступными. Исходный код Preact является общеизвестным.
Более того, Джейсон Миллер (автор преакта) заявил, что «ни один из Preact не является патентоспособным - это слишком очевидно».

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

1. Если компания, использующая preact, скажем, ABC, подаст в суд на FB за нарушение патентных прав, то FB будет использовать патенты реагирования для подачи иска на ABC.

Это разрушит репутацию Facebook. Хотя я ожидаю, что FB будет бороться изо всех сил, но использование патента React таким образом заклеймит FB как «патентного тролля».

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

1. У патента Facebook есть свои достоинства.

Да, это предположение, а не факт.

Как оказалось, «иметь патент» и «иметь действующий патент» - это две разные вещи.
Я прочитал эту фантастическую статью, в которой суд признал патенты недействительными.

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

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

Заключение:

Имейте в виду, что все три предположения не проверены. Если все они окажутся правдой, - а это технически возможно - тогда «да, использование preact опасно».

Однако на практике шансы на то, что все три предположения верны, слишком малы, особенно предположение 1 и 3 вместе.

Так что до тех пор, пока суд не постановит иное, я бы сказал, что использование preact (и других библиотек vdom) вполне безопасно.

Что касается пункта 1, у Facebook есть патент под названием « Эффективное делегирование событий в скриптах браузера» . Это в основном функция jQuery live() (позже она будет частью on() в jQuery API)!

Однако, независимо от обоснованности предположений, причина того, что WordPress отходит от React, заключается не в том, что WordPress беспокоит Facebook. И я цитирую сообщение с объявлением, указанное в проблеме выше ( выделите мою):

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

Исходя из этого, это восприятие, замешательство и вопросы, которые вызывает патент, оттолкнули WordPress. Я думаю, что то же самое относится и к Preact, как объяснялось в моем предыдущем комментарии .

Что касается пункта 1, у Facebook есть патент под названием «Эффективное делегирование событий в скриптах браузера». По сути, это функция jQuery live () (которая позже станет частью on () в jQuery API)!

Значит ли это, что они вообще придумали идею делегирования мероприятий ?! Я вижу там цитаты, датируемые 1995 годом, что это значит?

@ChrisCinelli относительно того, что вы назвали тем, что «кажется точкой перегиба экспоненциального роста» в случае с Марко.

Я считаю, что это просто вопрос масштаба. Когда проект имеет 5 тысяч или даже 10 тысяч звезд на Github, одно событие, такое как, например, ссылка на верхней странице Hackernews, может принести 1 тысячу звезд в день, что в случае Марко составляет 20% от недавнего числа.

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

Такая ситуация не уникальна для самого Марко, это случилось, например, с Inferno или недавно с MoonJS, который является микрофреймворком, вдохновленным Vue. Можно даже сказать, что Preact, похоже, находится в аналогичной точке из-за того, сколько звезд он получил в последнее время из-за всей драмы о патентах React.

Вы можете наблюдать то, о чем я говорю, на следующем графике из того же источника, что и ваш:

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

Что касается Vue, да, это стабильный рост без больших колебаний. При текущей скорости он должен превзойти React до Рождества. По крайней мере, на Github. :)

А как насчет @aurelia?
Сайт: aurelia.io
@EisenbergEffect создал это.

Для меня это отличный фреймворк!

1. Простые условные обозначения (можно настроить)
2. Обычный HTML
3. Ванильный JS
4. Нет рамочного вмешательства!

Вы даже можете подключить библиотеку по вашему выбору (jQuery, Vue.js, Preact, Ember, HyperHTML и т. Д.), Которую хотите использовать, и научить Aurelia, как ее использовать!

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

Ресурсы для @aurelia :

1. Представляем Аурелию
2. Блог Аурелии
3. Aurelia Docs

Похоже, React повторно лицензируется MIT: https://code.facebook.com/posts/300798627056246

Полагаю, сейчас решение следует отменить.

Холли Молли! React снова в бизнесе. WordPress сделал это? Не уверена! Сейчас 3 часа ночи, и я очень рад этому! Как насчет тебя!

Перенесение React, Jest, Flow и Immutable.js

На следующей неделе мы собираемся перелицензировать наши проекты с открытым исходным кодом React, Jest, Flow и Immutable.js под лицензией MIT. Мы перелицензируем эти проекты, потому что React является основой широкой экосистемы программного обеспечения с открытым исходным кодом для Интернета, и мы не хотим сдерживать прогресс по нетехническим причинам.

Это решение было принято после нескольких недель разочарования и неуверенности нашего сообщества. Хотя мы по-прежнему считаем, что наша лицензия BSD + Patents дает некоторые преимущества пользователям наших проектов, мы признаем, что нам не удалось убедить это сообщество решительно.

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

Этот сдвиг, естественно, вызывает вопросы об остальных проектах Facebook с открытым исходным кодом. Многие из наших популярных проектов пока сохранят лицензию BSD + Patents. Мы также оцениваем лицензии на эти проекты, но каждый проект индивидуален, и альтернативные варианты лицензирования будут зависеть от множества факторов.

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

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

Мой голос вернулся в React . - Вера в человечество восстановлена.

Голосуйте с помощью 👍 вместо похожих комментариев.

Я хочу выразить ОГРОМНОЕ СПАСИБО Wordpress за то, что он принял участие в том, что привело к этому изменению в React lincencing.

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

для массы
для уверенности
для vueJS

Я также выбрал Angular2.0 + (не AngularJS), который имеет самое большое сообщество, сильную команду разработчиков, стабильную и полную экосистему.

@CrazyBBer Где я могу найти данные о самом большом сообществе Angular 2/4? Это поможет мне написать сообщение в блоге.

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

@ahmadawais @gustojs люди на Reddit выразили обеспокоенность тем, что MIT распространяется только на авторские права, поэтому разработчики НЕ будут получать патент на использование React, что, как я полагаю, все еще является проблемой.

Также это утверждение меня действительно беспокоит:

мы признаем, что нам не удалось убедительно убедить это сообщество.

Фактически говоря: «Мы не ошиблись - вы, разработчики, просто нас не поняли».

@ahmadawais : Я все еще думаю, что переход на Vue был бы лучшим выбором, поскольку вы видели прекрасный пример того, насколько непостоянным может быть лицензирование React, сначала у них теперь было BSD + Patents license , они переключились на MIT. Кто знает, в ближайшем будущем они могут снова переключиться на какую-нибудь лицензию / патент, принадлежащую FB, и тогда все будут вывешены сушиться. Vue с самого начала принадлежит Массачусетскому технологическому институту и ​​в большей степени ориентирован на сообщество, чем на крупную корпорацию.

Плюс то, что сказал @ atanas-angelov-dev.

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

Ах! Да ладно, люди, дайте Аурелии шанс!
Он был создан одним из ведущих разработчиков команды Angularjs.
Вы можете перейти от небольшого внедрения к полной структуре, как Vue.js

Даже команда портала
А кто знает ?! они могли бы постепенно мигрировать в Аурелию.

Начни с малого, я знаю, тебе понравится!

Нирмал4Г,
Ваш тезис звучит настолько продажно, что это просто смешно.
На самом деле я считаю, что вся структура имеет те же недостатки, что и эта страница 404, на которую вы напрямую ссылаетесь в своем сообщении.
http://aurelia.io/get-started.html

@ bovas85 Не продавец, я даже не часть этой команды. Они даже не знают, что я использую их фреймворк.

@ cr101 / cc

Не судите книгу по обложке

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

Я считаю, что вся структура имеет те же недостатки, что и страница 404, на которую вы напрямую ссылаетесь в своем сообщении.

Каждая опубликованная мною ссылка никогда не ведет на страницу 404. Это вина GitHub за перенаправление сайта http на https. Теперь это исправлено. Видите, ошибка. Смею вас, назовите мне любой фреймворк, в котором нет ошибок.

Просто с другими фреймворками у вас много избыточных (но полезных) абстракций. Сообщество W3C никогда не использует публичный дизайн фреймворка в своем API, так что вот оно, много абстракций.

Каждая структура настолько ориентирована на обратную совместимость, что теряет прямую совместимость, но Aurelia этого не делает, пока вы придерживаетесь спецификаций HTML W3C и ECMAScript, ваш код JS работает нормально.

_Если нет Аурелии, я бы не отказался от Vue. Это следующая лучшая вещь.

_Это просто вопрос принятия стандарта, а не создания нового способа его изобрести.

@ Nirmal4G, пожалуйста, предоставьте доказательства своих заявлений или избегайте имен. Я с трудом верю, особенно когда дело доходит до LOC, Vue был меньше, чем hyperHTML. Все, что я написал в hyperHTML по сравнению с vue, было меньше LOC, объединяя макет и логику . Хотя я даже не верю в LOC как в метрику, имеющую отношение к чему-либо, чтение недоказанных FUD мне кажется нечестным.

@WebReflection Держите лошадей, я не говорил, что вы хуже Vue. Извините, если я вас обидел.

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

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

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

Очень приятно слышать, что React теперь будет MIT.
Меня очень воодушевляет этот проект, и я с нетерпением жду возможности снова начать использовать WordPress через долгое время, как только React и WP API будут полностью поддерживаться. :)

Подождем и посмотрим, какой будет реальная лицензия на React. MIT или MIT + Патенты ..? ;)

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

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

Vue кажется более подходящим выбором для WordPress.

Facebook удалил 4 элемента из своего набора судебных ловушек. Теперь все они лицензированы MIT:

• Реагировать
• Шутка
• поток
• Immutable.js

Между тем, лицензия Facebook категории X по-прежнему распространяется на:

• React Native
• GraphQL
• Пряжа
• Реле
• Atom IDE
• и, вероятно, что-нибудь еще, сделанное ими из открытых источников

Я по-прежнему говорю: переходите на Vue. Это того стоит в долгосрочной перспективе. В любом случае React никогда не имел для меня никакого смысла для Wordpress. Он настолько сильно внедрен в сообщество PHP, что Vue всегда казался самым разумным выбором (к тому же его не больно использовать, как React).

Между тем, лицензия Facebook категории X по-прежнему распространяется на:

React Native
GraphQL
Пряжа
Реле
Atom IDE
и, вероятно, что-нибудь еще, сделанное ими из открытых источников

@TheJaredWilcurt, извините, но вы, возможно, захотите удалить yarn из этого списка .. yarn не имеет такой лицензии "Facebook Category X" -> https://github.com/yarnpkg/yarn

@ atanas-angelov-dev

Люди на Reddit выразили обеспокоенность тем, что MIT распространяется только на авторские права, поэтому разработчики НЕ будут получать патент при использовании React, что, как я полагаю, все еще является проблемой.

MIT - отличная лицензия. jQuery также имеет лицензию MIT. Надеюсь, ты это знаешь.

@vinayakkulkarni Я по-прежнему думаю, что переход на Vue был бы лучшим выбором, поскольку вы видели прекрасный пример того, насколько непостоянным может быть лицензирование React. Сначала у них была лицензия BSD + Patents, теперь они перешли на MIT. Кто знает, в ближайшем будущем они могут снова переключиться на какую-нибудь лицензию / патент, принадлежащую FB, и тогда все будут вывешены сушиться. Vue с самого начала принадлежит Массачусетскому технологическому институту и ​​в большей степени ориентирован на сообщество, чем на крупную корпорацию.

Это не так. Я прочитал комментарий Самуэля в Facebook по аналогичному вопросу. После того, как вы лицензируете его MIT, вы можете либо разветвить его, чтобы изменить лицензию, либо просто не сможете. Но я не юрист.

Кроме того, лично я считаю, что Facebook сделал это в знак доброй воли, а не для того, чтобы обманывать людей. Это что-то значит для меня.

Кроме того, лично я считаю, что Facebook сделал это в знак доброй воли, а не для того, чтобы обманывать людей. Это что-то значит для меня.

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

У Vue ОЧЕНЬ мягкая кривая обучения и адаптации.
И это с самого начала было основной идеей WordPress.

@ahmadawais Я знаю - MIT так же хорош, как и лицензии, но, и это большое «но», Facebook, очевидно, имеет патенты на React, и хотя MIT позволяет вам использовать код для любых целей, вы все равно можете нарушить права на Facebook патенты (возьмите все это с солью - IANAL)

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

У Facebook, по-видимому, есть патенты на React

Как вы думаете, какая часть React запатентована? (ничто в React не запатентовано, попробуйте сначала провести исследование) показывайте ссылки, а не просто «очевидно» ... это тот вид комментариев, который совсем не помогает. если вы хотите порекомендовать свою любимую библиотеку, сделайте это правильно, показывая ее достоинства, а не просто распространяя FUD.

Зачем изначально переходить на BSD + Patents, если ни одна из React не имеет патентов? Facebook не сказал, что это такое, а что нет.

Зачем возиться с лицензированием в течение 2 лет и вносить изменения только в часть своего портфеля, постоянно заявляя, что они не будут его менять, и сказав «просто разберитесь с этим, нам все равно, используете вы это или нет».

Зачем исключать React Native, GraphQL и т. Д. Из «нового» лицензирования? На что перейдет следующая версия React? Нет никаких гарантий, когда у вас есть двухуровневая лицензия от Facebook, в зависимости от того, кто на это жалуется ...

Что, если часть кода React Native будет перенесена в React. Каково ваше положение, если реализация GraphQL проникает в базу кода ..?

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

Просто используйте библиотеку без багажа, которая уже создана в мире PHP - Vue.

@bjrmatos https://www.google.com/patents/US20170221242 Наверное!

Еще один +1 к Vue. Facebook по-прежнему использует две лицензии в своих проектах. Это не хорошо.

@PericlesSouza, вы явно просто игнорируете большие усилия, которые такие компании, как facebook, прилагают для улучшения вещей и продвижения Интернета, на все ваши вопросы можно ответить, если вы просто прочитаете сообщение об изменении в MIT. Я действительно не знаю, почему вы все еще поднимаете эту иррациональную озабоченность по поводу лицензии MIT, с изменением React находится в том же положении, что и любой другой проект с «истинным открытым исходным кодом» (я не знаю, что вы называете проектом с истинным открытым исходным кодом кстати).

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

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

Удачи команде wordpress в решении, основная проблема с лицензией React BSD + Patents решена, теперь их задача решать.

Итак, Facebook совсем недавно изменил лицензию на React. Означает ли это, что WordPress продолжит использовать React или все еще изменит интерфейсную структуру по умолчанию?

@bjrmatos это совсем не так

практически любая современная структура уже нарушает этот патент

например, hyperHTML не использует виртуальную DOM, он использует непосредственно DOM API (не запатентованный) через регулярные вызовы обратного вызова (не запатентованный) и единственный алгоритм сравнения для преобразования c hildNodes: after в списках узлов основан на расстоянии Левенштейна (не патентоспособен) и наименьшем количестве операций сращивания (непатентоспособен, это я написал, и это ISC ).

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

@noncototient это вопрос на миллион долларов, не так ли? 💯

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

Согласен, сейчас это бессмысленно. Я предлагаю заблокировать эту ветку (или, возможно, только участников). По этому вопросу было получено достаточно отзывов, и теперь он достигает точки, когда это приведет только к неконструктивным аргументам.

Будет ли этот вопрос закрыт?
Кажется, @WordPress сейчас не заинтересован в

Лично мне нравится @vuejs. Но, похоже, сейчас это не имеет значения. 😅

Лично я бы предпочел Vue в любом случае.

Для меня, как и для многих других, никогда не было лицензирования. Это был просто повод уйти от React.

Марко безумно силен и прост. В настоящее время мы завершаем полную переработку динамического интернет-магазина с 50 000 товаров, и он невероятно насыщен и функционален. Иди этим маршрутом и не оглядывайся.

Marko хорош, но Prarko на 100 байт меньше (GZipped) и на 0,01% быстрее в самооптимизированном тесте, поэтому мы должны использовать это вместо этого, даже если никто другой этого не делает. Хотя завтра будет выпущен Plarko с добавленной оптоволоконной связью, что делает все лишним.

Извините, но именно так и ведется остальная часть этой беседы.

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

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

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

Возможно, начнем с простого вопроса, как я делаю в большинстве проектов:

1. Нужны ли нам в рамках SPA?

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

Если нет, задайте следующий вопрос:

1. Действительно ли нам нужен шаблонизатор?

VanillaJS имеет самое большое сообщество на планете и не имеет проблем с лицензированием. Он также соответствует стандартам;) и с модулями ES6 может предложить подходящую основу для разработки ядра с возможностью поддержки плагинов для использования _template_ движков, таких как React, Vue, Preact, Aurelia и т. Д. И т. Д., Что бы ни было выпущено в ближайшие годы, как того требуют разработчики.

Мэтт Малленвег опубликовал свой ответ ...

Я удивлен и взволнован, увидев новости о том, что Facebook собирается отказаться от статьи о патентах, о которой я писал на прошлой неделе. Они объявили, что с React 16 лицензия будет обычным MIT без добавления патента. Я аплодирую Facebook за этот шаг и надеюсь, что использование патентных оговорок будет пересмотрено во всех их проектах с открытым исходным кодом.

Наше решение уйти от React, основанное на их предыдущей позиции, вызвало много интересных дискуссий в мире WordPress. В частности, с Gutenberg может быть подход, который позволяет разработчикам писать блоки Gutenberg (Gutenblocks) в библиотеке по своему выбору, включая Preact, Polymer или Vue, и теперь React также может быть официально поддерживаемым вариантом.

Я хочу поблагодарить всех, кто участвовал в дискуссии до сих пор, я очень ценю это. Активные дебаты и обсуждения в комментариях здесь, а также на Hacker News и Reddit были великолепны для энтузиазма людей и возможности узнать о стольких разных точках зрения; было даже лучше, что Facebook слушал.

→ https://ma.tt/2017/09/facebook-dropping-patent-clause/

@ahmadawais @m

Наше решение уйти от React, основанное на их предыдущей позиции, вызвало много интересных дискуссий в мире WordPress. В частности, с Gutenberg может быть подход, который позволяет разработчикам писать блоки Gutenberg (Gutenblocks) в библиотеке по своему выбору, включая Preact, Polymer или Vue, и теперь React также может быть официально поддерживаемым вариантом.

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

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

[Изменить: удалено из-за оскорбительного заявления]

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

Мир.

👋 Думаю, мы все здесь много обсуждали. Хочу поблагодарить всех, кто уделил достаточно внимания, чтобы поговорить и прокомментировать эту проблему. ИМХО похоже, что все варианты, которые у нас сейчас есть, хорошие.

Если мы получим более качественный независимый от фреймворка API, можно будет использовать любую JS Framework в своих приложениях. С лицензией MIT React имеет такие же сильные позиции для использования в ядре, как и любая другая библиотека с хорошей (совместимой для чтения) лицензией с открытым исходным кодом.

🎯 Если вы пользуетесь определенной фреймворком JavaScript или создали его (основные команды), я предлагаю вам создать реальные примеры для разработчиков WordPress, чтобы люди могли начать играть с идеей использования предпочитаемого фреймворка JavaScript в приложениях на основе WordPress, которые они построить.

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

Через какое-то время мы можем в конечном итоге улучшить программное обеспечение, чтобы упростить его пользователям (~ 30% интернет-сайтов), как это было пару лет назад. Я болею за WordPress, как и все вы!

Ура!

Из комментария Мэтта не совсем ясно, было ли отменено решение об отказе от React.

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

Во-вторых, он не касается двухуровневого лицензирования, которому следует Facebook: React может быть MIT, но React Native будет иметь + (не разглашается) патентов .

Итак .. как насчет компонентов, которые используются обоими?

А как насчет кода React Native, используемого в React? Будет ли Fiber совместно использоваться двумя разными лицензиями? Или код GraphQL попадает в React?

Что произойдет с WordPress, если он пойдет по маршруту React, когда все эти связанные проекты Facebook будут опубликованы под другой лицензией, а затем Facebook решит, что некоторые аспекты React действительно подпадают под действие патента React Native или Fiber Патентный грант?

Серьезно, подумайте об этом очень внимательно. Зачем рисковать, когда есть альтернативы, которые большинство предпочитает использовать, но не имеют этой проблемы - Vue.

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

Придерживайтесь подлинного открытого исходного кода.

@PericlesSouza . Лицензия будет именно такой, как люди здесь представляют из описания сообщения в блоге: стандартная лицензия MIT, не более того. React не зависит от React Native. Части, которые являются общими для обоих, находятся в проекте React, а не в React Native. React и его зависимости, принадлежащие FB, будут доступны в MIT, как только у нашей команды будет время для фиксации изменений. Мы не планируем никаких забавных дел.

@sophiebits

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

«Воображаемые» лицензии не рассматриваются в суде.

Например, можете ли вы категорически заявить, почему Facebook принял патентный грант, какие были (или не были) патенты или почему они говорят, что меняют его сейчас, не говоря «IANAL» (я не юрист)?

Части, которые используются обоими, живут в проекте React, а не в React Native.

Но можно ли сказать это с юридической гарантией? Нет?

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

Какие части удаляются, чтобы разрешить публикацию React под MIT? Какие _не-принадлежащие FB зависимости_, ​​которые предположительно не соответствовали требованиям MIT, вы уже использовали ..? Будут ли юристы Facebook гарантировать, что все действительно соответствует требованиям MIT? Сколько времени потребуется Apache Software Foundation, чтобы сертифицировать это?
.

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

Вы искажаете мои слова. Код, совместно используемый React и React Native, будет лицензироваться MIT. Все, что вы считаете Fiber, будет лицензироваться MIT. React не будет включать и не зависеть от кода, лицензированного BSD + Patents или любого другого патента, который вы так презираете. Мы не удаляем части из React. Единственная известная мне зависимость React, не принадлежащая FB, - это object-assign, которая также находится в MIT.

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

@sophiebits

Я не искажаю ваши слова - и я уважаю как вашу работу, так и вашу готовность заниматься здесь.

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

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

И:

Все, что вы считаете Fiber, будет лицензироваться MIT.

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

Почему React Native в настоящее время предназначен для лицензирования иначе, чем React, если он использует код совместно с React? Разве это не делает (простите за каламбур) лицензию MIT недействительной?

Также отмечу, что вы не упомянули GraphQL. Что еще я пропустил?

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

@sophiebits

Я отмечаю вашу правку в ответ на мои замечания:

React не будет включать и не зависеть от кода, лицензированного BSD + Patents или любого другого патента, который вы так презираете. Мы не удаляем части из React. Единственная известная мне зависимость React, не принадлежащая FB, - это object-assign, которая также находится в MIT.

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

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

И вы забыли IANAL ... :-)

О, на самом деле вы сказали это в полной форме:

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

Снова:

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

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

Отписываюсь сейчас.

Пожалуйста, не сбрасывайте React, Facebook принял решение https://thenextweb.com/dd/2017/09/25/facebook-re-licenses-react-mit-license-developer-backlash/

@vinayakkulkarni Хотя я понимаю, что я чем-то увлечен, это не повод делать такой комментарий, как вы. Общественное пространство (к которому относятся комментарии GitHub) должно быть безопасным местом для всех. Ваша аналогия была оскорбительной и как таковая была отредактирована. В будущем подумайте, пожалуйста, о том, что все пола, все типы людей будут использовать это пространство и как то, что вы говорите, может их оскорбить.

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

Это может быть темой для нового обсуждения, но, к сожалению, лицензия MIT (даже стандартная) не устраняет проблему «неопределенности» с патентами, которая привела к решению WordPress ранее.

Дает ли лицензия MIT вам право использовать запатентованную IP? Прочтите, что говорит по этому поводу юрист: Лицензия MIT, построчно

- Frans Bouma (@FransBouma) 23 сентября 2017 г.

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

Выдача патентов означает, что есть патенты (или что это дает?). Вот только никто даже не знает, что такое патенты. Facebook ничего не сказал, даже когда он их предоставил, и не когда объявил об отмене гранта.

Независимо от того, что я лично или команда WordPress могли бы подумать об этом, похоже, что все еще существует путаница в отношении правовой ситуации (пока не перечисленных) патентов Facebook, которые он имеет на React, и любой, кто его использует [[может - или- может не]] нужно беспокоиться о нарушении, предъявляя иск Facebook сегодня, или просто используя React после новой лицензии.

Опять же, может, а может и нет, проблема в неопределенности, и то, что я предлагаю, не решено.

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

Для этого есть несколько причин, не ограничиваясь тем фактом, что у Vue нет путаницы с лицензированием (которая по-прежнему остается в двухуровневой лицензионной политике Facebook):

1. Vue разработан с нуля для постепенного добавления, с островками функциональности, что позволяет постепенно улучшать кодовую базу.

2. Кроме того, и опционально, он предоставляет официально поддерживаемые решения для управления состоянием и маршрутизации.

3. Он поддерживает несколько процессоров для HTML, предоставляя разработчикам выбор языка шаблонов - HTML, JSX, Pug и т. Д. Или функции рендеринга.

4. Однофайловые компоненты и CSS с ограниченной областью действия (Stylus, SASS, SCSS, PostCSS, компоненты CSS) - самым простым из возможных способов. Буквально просто добавьте атрибут scoped в объявления Style компонентов, и готово.

5. Встроенная поддержка вычисляемых свойств (с мемоизацией) (т.е. без зависимостей, таких как MobX).

   6+. Превосходная производительность React, гораздо более низкая кривая обучения, более высокая степень принятия в сообществе PHP, посмотрите, например, Laravel Mix - вы можете использовать это без использования самого Laravel. Или просто включите Vue через https://unpkg.com/vue и начните кодирование.

Vue просто больше подходит для WordPress.

Реагировать :

76,364 звезды Github
571 Открытые выпуски (!)
4325 Закрытых выпусков
178 запросов Open Pull (!)
5644 закрытых запроса на извлечение

Vue :

68, 246 звезд на Github (траектория должна обогнать React к Рождеству)
62 Открытые проблемы (гораздо больше реагируют на исправление ошибок, добавление запрошенных функций)
5629 закрытых выпусков
17 запросов Open Pull
863 закрытых запроса на извлечение

@Meligy

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

Выдача патентов означает, что есть патенты (или что они выдают?). Facebook ничего не сказал, даже когда он их предоставил, и не когда объявил об отмене гранта.

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

Facebook представил свою лицензию + Patents как агрессивную защиту «чего-то или чего-нибудь», и теперь нас просят поверить, что того же самого «чего-то или чего-то» на самом деле не существует для React, но _ по-прежнему существует_ для React Native и GraphQL и т.

Может ли Automattic пообещать, что они возьмут на себя бремя и будут проводить React, форк, разрабатывать его самостоятельно, когда Facebook снова изменит свою лицензию и мнение о React?

Мне кажется, что Facebook ставит ловушку для WordPress. 25% всех веб-сайтов в мире - это большой улов.

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

Заинтересованные стороны

@PericlesSouza цитирование звезд Github ничего не значит. И то, что эту проблему торопят люди, бросающие нелепые заявления, не означает, что мы должны игнорировать факты: https://npmcharts.com/compare/react , angular, @ angular / core , ember-cli, vue

Vue - не что иное, как отметка на радаре. Подавляющее большинство использует React и наверняка не согласится с вашими пунктами.

@PericlesSouza цитирование звезд Github ничего не значит. И то, что эту проблему торопят люди, бросающие нелепые заявления, не означает, что мы должны игнорировать факты: https://npmcharts.com/compare/react , angular, @ angular / core , ember-cli, vue

Vue - не что иное, как отметка на радаре. Подавляющее большинство использует React и наверняка не согласится с вашими пунктами.

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

Если вы хотите пойти по этому пути, тогда все используют jQuery.

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

https://npmcharts.com/compare/vue-cli , приложение create-response-app

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

Или как насчет использования сайта:

https://w3techs.com/technologies/comparison/js-react , js-vuejs

Что подтверждается статистикой BuiltWith:

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

@PericlesSouza Нет смысла сравнивать vue- cli и create-react -app, поскольку есть и другие очень популярные инструменты сборки для React, такие как Next.js и GatsbyJS .
Многие разработчики React даже не используют CLI, а вместо этого используют свои собственные сценарии сборки Webpack, как это делают Gutenberg и Calypso.

На самом деле экосистема React намного больше, чем у Vue. Возьмем, к примеру, Material UI для Vue.js, который имеет 4339 звезд, а Material UI для React имеет 29 078 звезд.

Встроенный компонент окна выбора, который обеспечивает функциональность, аналогичную Select2, без дополнительных затрат на jQuery: Vue select имеет 1348 звезд, а React select - 8493 звезды.

@PericlesSouza , @drcmda , все эти данные можно оспорить разными способами, даже статистику npm с кликами, если вы добавите AngularCLI и EmberCLI, вы увидите совершенно разные данные, которые ничего не значат:

Источник: https://npmcharts.com/compare/vue-cli , create-react-app, @ angular / cli , ember-cli

Источник: https://w3techs.com/technologies/comparison/js-angularjs , js-react, js-vuejs

Источник: https://insights.stackoverflow.com/survey/2017#technology -frameworks-libraries-and-other-technologies

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

@PericlesSouza @willgm Правила применяются к обоим. Оба считаются одинаково, довольно лицемерно заявляя, что это несправедливо. Бесполезно цепляться за необязательный интерфейс командной строки или наводящие на размышления веб-сайты, подсчитывающие «лайки» и «звезды». Даже stackoverflow очень субъективен, и до сегодняшнего дня я даже не слышал о сайте "builtwith ...", а статистика CLI, ну, хорошо отражает, сколько пользователей используют CLI (большинство - нет).

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

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

И я так понимаю, вы знаете, какой из них лучше подходит. Вы думаете, что 400000 человек, получающих React от npm в день, ошибаются. Vue мог бы конкурировать самостоятельно, на самом деле ему не нужна толпа, спешащая на трекеры проблем.

@PericlesSouza @willgm Правила применяются к обоим. Оба считаются одинаково, довольно лицемерно заявляя, что это несправедливо. Бесполезно цепляться за необязательный интерфейс командной строки или наводящие на размышления веб-сайты, подсчитывающие «лайки» и «звезды».

Нет. React имеет 16 800 зависимых пакетов, которые искажают цифры. NPM признают, что все, что они считают загрузкой, - это код результата 200 при вызове URL-адреса в результате проверки зависимости, или бота, или зеркала, или чего-то еще. Между прочим, они также говорят, что большинство загрузок в Китае, где Vue очень популярен, происходит с зеркал и не учитывается.

Судя по тому, как вы используете язык - «цепляние», «наводящие на размышления веб-сайты», «бесполезно», у вас нет никаких реальных аргументов по этому поводу, тогда как, по запросу команды, я опубликовал положительные стороны использования Vue (см. выше ).

Подсчет звезд - другие делают это, указывая на успех React, но вы осуждаете их ценность, когда они используются для обозначения популярности Vue? Вы также не упоминаете о гораздо большем количестве нерешенных проблем ( 571 ) и весьма примечательном количестве невыполненных запросов на вытягивание ( 178 ), все еще ожидающих ответа от React, что по сравнению с более высокой отзывчивостью сообщества Vue при исправлении ошибок и добавление функций, является серьезным поводом для беспокойства при предложении использования React.

Что подводит меня к:

Подсчет лайков - ну, в этом весь смысл этой ветки, начатой ​​командой и заданной сообществом - я думаю, вам просто не нравится результат. И снова, и это очень убедительно:

Нет. React имеет 16 800 зависимых пакетов, которые искажают цифры.

@PericlesSouza Как вы

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

@dcrmda

Я думаю, он имел в виду, что каждый раз, когда вы устанавливаете пакет, который зависит от React, и он обращается к NPM для проверки версий и зависимостей, этот NPM считает это как download пакета, даже если это не так. скачал.

Если это то, что он имеет в виду, тогда он совершенно прав; NPM прямо заявляет, что они это делают; они описывают свою «методологию» как «намеренно наивную» (они также упоминают, что боты и зеркала могут исказить цифры, поскольку у них нет механизма для определения того, для чего нужен запрос, они просто его считают). А у React больше зависимых пакетов, поэтому этот эффект более выражен.

Что касается множества зависимых пакетов - да, React - более старый фреймворк, в нем их больше, и они вроде как нужны. Я разрабатываю как React, так и Vue, а с Vue вам, как правило, требуется меньше дополнительных пакетов, так как ядро ​​довольно полно, а официальный маршрутизатор и Vuex также следуют философии низкой зависимости. Сам Vue не зависит от каких-либо пакетов, React зависит от некоторых. У них разные подходы в этом отношении.

Другой пример: люди склонны использовать пакет интеграции, скажем, между Bootstrap и React, или использовать библиотеки, такие как стилизованные компоненты, имена классов и т. Д. С Vue в этом обычно не нуждаются, хотя такие проекты тоже существуют. Я считаю, что с Vue намного проще работать, так как я могу получить CSS с компонентной областью прямо из коробки без дополнительных библиотек или конфигурации, и я могу написать свою собственную простую интеграцию с фреймворками CSS по мере необходимости, вместо того, чтобы импортировать всю библиотеку интеграции и затем пытаться дерево -выбрасывать те 75%, которые мне не нужны.

@PericlesSouza, ты пропустил пару очень важных вещей из своего поста «Плюсы Vue»:

Именованные слоты, позволяющие повторно использовать компоненты шаблона, такие как стандартные формы, входы, макеты и т. Д., Что более гибко, чем использование дочерних элементов в Reacts.

Условные компоненты с дополнительной возможностью сохранять локальное состояние Keep-Alive без разрушения неактивного компонента.

HTML-элемент Is - это синтаксис компонента Vue для строковых шаблонов, который предотвращает подъем обработанных HTML-элементов, которые приводят к недопустимому HTML.

Односторонний поток данных с props, но с добавлением значительно упрощенного потока «emit» и «event bus» для уведомления или обновления одноуровневого или родительского объекта. Это может быть полезно для взаимодействия между:

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

Регистрация глобальных и локальных компонентов и настраиваемых директив.

Цепные фильтры в дополнение к вычисляемым свойствам.

Все вышеперечисленное является частью основной библиотеки Vue.

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

@mcquiggd

Да, я был в спешке и не успел составить полный список преимуществ Vue.

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

https://www.npmjs.com/package/fbjs

https://www.npmjs.com/browse/depended/fbjs

Цель

Чтобы Facebook было проще делиться и использовать наш собственный JavaScript.

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

571 Открытые выпуски (!)

Сейчас 338. (Я потратил несколько дней на их уборку.)

В течение последних нескольких месяцев команда React была занята подготовкой новой, в значительной степени обратно совместимой версии React 16 . Это был наш самый крупный выпуск за всю историю, поэтому мы не ответили на трекер, так что мне очень жаль. Оказывается, React 16 также решил кучу этих проблем. :-)

Я хочу отметить, что большинство из оставшихся 338 проблем - это запросы и обсуждения функций. Поиск по ярлыку ошибки дает мне около 60 проблем. А учитывая, что экосистема React на данный момент больше, чем Vue, неудивительно, что люди сталкиваются с большим количеством крайних случаев и несоответствий и начинают больше обсуждений. Они также ожидают, что React будет полифицировать больше несоответствий браузера, поэтому многие ошибки связаны с отсутствием их покрытия. Кроме того, мы храним документацию в том же репозитории, поэтому многие из этих проблем связаны с документами.

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

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

К сожалению, это безосновательный FUD, точка. Я не уверен, какова ваша мотивация для его распространения, но React был перелицензирован как MIT и включает в себя любой код, от которого зависит React (например, fbjs). Здесь нет хитрой схемы.

Вы можете сами убедиться, что лицензия fbjs также была изменена на MIT в https://github.com/facebook/fbjs/commit/c69904a511b900266935168223063dd8772dfc40 за пять дней до вашего комментария. Релиз React 16, вышедший несколько дней назад, не содержит ни одного байта, отличного от MIT.

Тот факт, что другие проекты зависят от fbjs но имеют другую лицензию, совершенно не имеет значения, так же как не имеет значения, что код вашего приложения, вероятно, не MIT, а зависит от Vue.

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

Все это волнующие разговоры.

Я должен спросить - зачем вообще фреймворк / библиотека? Как упоминалось ранее, стандарт веб-компонентов, похоже, предоставляет то, для чего были созданы ReactJS, Vue и другие (поскольку стандарта не существовало).

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

Что предоставляет платформа XXX по сравнению с веб-компонентами платформы?

Действительно захватывающий разговор ...

На данный момент четвертая лицензия для React.

1. Первоначально Apache 2.0. Все должно было быть хорошо, правда? В чем была проблема?
2. Затем BSD + Patents. Без раскрытия того, какие патенты существуют, а какие нет.
3. Потом небольшие поправки, якобы в угоду Google. Без каких-либо подробностей относительно того, почему.
4. Теперь MIT, с неопределенным рефакторингом React, но не для непосредственно связанных проектов, таких как React Native, GraphQL и т. Д. ... и общей зависимостью с общедоступным описанием «Чтобы Facebook было проще делиться и использовать наш собственный JavaScript. В первую очередь это позволит нам отправлять код, не беспокоясь о том, где он находится "

Видимо, не о чем беспокоиться.

[правка удалена Тэмми Листер: подобные личные замечания недопустимы]

@PericlesSouza Вы можете возразить, что нам не следует доверять, потому что раньше лицензии

React - это MIT.
Его зависимость fbjs - это MIT.
Код, который используется в React и React Native (который был и остается в репозитории React) - это MIT.
React, включая все его зависимости, - это MIT.
Приложение Create React не обязательно для использования React, но оно тоже является MIT.
Relay и graphql-js не нужны для использования React, но они тоже MIT.

Мы выпустили React 16.0 с новой лицензией. Проверить это несложно.
Мы также выпустили новую версию React 15.x с лицензией MIT как 15.6.2.
Мы также планируем выпустить все будущие версии React под лицензией MIT.

Добавьте к этому, другой сотрудник Facebook в этой ветке признал, что React (MIT для 16? Зачем <16? 17+? Лучше внимательно посмотрите этот package.json) и общий код React Native, который требует рефакторинга (затем редактирует свой комментарий чтобы удалить это утверждение после того, как я его процитировал).

Я тот инженер. (Ее.)

Вы прокомментировали https://github.com/WordPress/gutenberg/issues/2733#issuecomment -331737418, затем я ответил https://github.com/WordPress/gutenberg/issues/2733#issuecomment -331738521.

Вот исходное содержание наших двух комментариев, записанное в моем почтовом клиенте:

Вот содержание прямо в данный момент:

После того, как я оставил свой комментарий, вы отредактировали свой комментарий, сделав его намного длиннее, включая дополнительный вопрос:

Какие части удаляются, чтобы разрешить публикацию React под MIT?

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

Мы не удаляем части из React. Единственная известная мне зависимость React, не принадлежащая FB, - это object-assign, которая также находится в MIT.

Тогда вы сочли целесообразным сообщить мне об этом в следующем комментарии. Как я смею редактировать свой комментарий, чтобы ответить на вопрос, который вы добавили в свою правку. Я не удалял и не редактировал никаких претензий относительно кода совместного использования React и React Native.

-

Пожалуйста, перестань меня газлайтинг. Это утомительно.

@youknowriad Не ветку ? Я не могу представить себе более продуктивного обсуждения здесь.

Если кто-то еще здесь законно обеспокоен лицензией, не стесняйтесь писать мне в DM, и я сделаю все возможное, чтобы уточнить.

Тогда вы сочли целесообразным сообщить мне об этом в следующем комментарии. Как я смею редактировать свой комментарий, чтобы ответить на вопрос, который вы добавили в свою правку. Я не удалял и не редактировал никаких претензий относительно кода совместного использования React и React Native.

Очевидно, я ответил на ваше изменение, это ваша проблема?

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

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

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

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

@ Брайан-МакБрайд

Вы правильно подметили, и я считаю, что он уже поднимался ранее в этой теме - «почему бы не использовать ванильный javascript», основанный на стандартах, полностью совместимый.

Хм.

Remove references to PATENTS that crept in #11091
Merged  sophiebits  merged 1 commit into facebook:master from sophiebits:nopatentsagain a day ago

https://github.com/facebook/react/pull/11091

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

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

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

Еще одна вещь, которую, я думаю, следует учитывать в проектах свободного программного обеспечения - Facebook выигрывает от использования React.

Но ценности Facebook, как правило, не совпадают с ценностями движения за свободное программное обеспечение - все, от неэтичных манипуляций пользователями до атак на сетевой нейтралитет («Бесплатные основы»), невозможность удалить данные, невозможность заблокировать сбор данных, цензура, огороженный сад , эхо-камеры и многое другое.

[Facebook] - это как когда мой брат заставлял меня бить себя и спрашивал: «Почему ты бьешь себя?» Потом он сказал моей маме, что это не его вина.

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

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

Я считаю, что проекты свободного программного обеспечения всегда должны отдавать предпочтение независимым библиотекам свободного программного обеспечения, когда они доступны. Для WordPress есть множество отличных альтернатив, включая Vue, веб-компоненты, Ember и Mithril. Vue пользуется огромной поддержкой в ​​PHP-сообществе и не имеет никаких этических проблем, поэтому кажется, что он подошел бы. Если это просто для панели инструментов, возможно, стоит взглянуть на что-нибудь даже более интересное, чем JavaScript: Elm .

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

Еще одна мысль для размышления ...

Спасибо всем, кто высказал свое мнение, пытаясь вести уважительный разговор. Я также хотел бы особо поблагодарить @sophiebits , @gaearon , @ blake-newman и всех остальных, представляющих проекты, которые любезно потратили свое время, отвечая на вопросы. Мы очень ценим ваши знания и всегда приветствуем их.

С тех пор разговор перешел на собрания JavaScript в канале Slack # core-js, здесь есть хорошее резюме . Если вы заинтересованы в участии в этих обсуждениях, мы приглашаем вас присоединиться к нам. В качестве альтернативы у нас есть два подхода к взаимодействию, которые могут использовать вклад, тестирование и обратную связь: # 2463 и # 2791.

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

Эта ветка вызвала хорошее обсуждение, но некоторые из них показали неприемлемое поведение и были отредактированы. Важно помнить, что https://wordpress.org/about/etiquette/ относится к любому проекту WordPress, и мы не потерпим нарушений или тех, которые их совершают. Спасибо всем, кто внес свой вклад в беседу вежливо и уважительно.