Я видел ваш скриншот в презентации, но если обратите внимание на вот этот слайд, то сможете увидеть, что описанный вариант не является единственным. Разумеется, никакого DOM'а там нет, т.к. нет ни браузера, ни его объектной модели. Но это не должно исключать возможности писать на HTML-подобном синтаксисе с последующей трансляцией на нативные компоненты. Как я уже говорил в статье, React Native придерживается идеологии «Learn once, write anywhere», что должно распространяться не только на веб или мобильные приложения отдельно, но и облегчить переход от одного к другому.
Мне тоже интересно, как они планируют создать поддержку кастомных элементов, но к сожалению, об этом пока нет ни слова.
Да, они действительно пишут обертки из React -> Native, но я думаю, что публичный релиз состоится только после того, как они покроют все элементы на обоих платформах.
Насколько я понимаю, код может быть одинаковым, но в докладе автор говорит о том, что разные платформы имеют свою специфику, и идеологически не правильно делать UX на Android схожим с iOS.
Вы всегда можете рендерить React через React.renderToString на сервере без костылей, а в качестве абстракций для роутинга, работы с данными и прочим взять любые импонирующие вам решения.
Согласен. React — это View, которое не должно запрашивать данные с сервера. В зависимости от архитектурных решений, фрейморков/библиотек, которые стоят за React, данными занимаются модели, ActionCreator'ы/Хранилища, сервисы или аналогичные уровни абстракции.
В общем, рискну резюмировать: если вы собираетесь делать SPA, то используйте angular.js, будет быстро и просто: готовые архитектурные решения, высокоуровневое API, можно быстро развернуть из yeoman.io, вам де-факто нет необходимости лезть «под капот». Хотите рендерить с бэка и использовать JS только для свистулек/анимашек/прочего используйте jQuery, но имейте ввиду, что при больших объёмах jQuery ваш клиентский код превращается в лапшу, которую невозможно поддерживать (в меру отсутствия архитектурных решений со стороны библиотеки).
Если вы не планируете строить *реально большое приложение*, то проблемы, описанные в статье не будут вас трогать ни коем образом. У любых библиотек/фреймворков есть свои недостатки. И да, сравнивать jQuery с Angular'ом некорректно. Вы же не сравниваете php библиотеки и фреймворки?
Только, чтобы никого не смущать, надо внести правки, о которых указал lega в код React. Я сделал это тут. Действительно, angular выигрывает в производительности на этом тесте. Но было бы неплохо приблизить тест к реальным условиям, а именно:
— Добавить условие при обновлении (например, обновлять только чётные строки)
— Изменить дописывание в <li> на что-то более, например на <li><span class="first">{{ first }}</span></li> при заполнении и на <li><span class="first">{{ first }}</span>, <span class="second">{{ second }}</span></li> после обновления
— Удалять часть DOM-элементов (например, кратных 3)
— Добавить обработчики на <li> элементы
Лично мне было бы интересно сравнить выбранные библиотеки/фремворки на таком бенче, как считаете?
Согласен, был неправ по поводу setTimeout(callback, 0) -> callback.call(null), однако поменяв этот кусок обратно, и просто убрав jQuery (который там вообще ни туда, ни суда, т.к. React в дефолтной конфигурации никак не зависит от него), у меня всё равно получается у ангуляра 3321мс на filling и 747мс на update для 10000 на раб. машине против 1589мс на filling и 727мс на update у React. И кстати, имеет смысл сравнивать не только время, но и размер памяти, выделяемый при этом сравнении. У меня angular съедает на 50% памяти больше (37,8Мб у React против 57.1Мб у Angular).
Выводы из этого сравнения:
В рамках тестирования на моей рабочей машине
— angular медленнее в первоначальном рендеринге данных на 100%
— angular и react одинаковы в скорости обновления этих данных
— angular съедает на 50% больше памяти, чем React
В заключение хочу сказать, что если бы часть данных оставалась такой же (т.е. не изменялась бы при операции update), то React показал бы более производительный результат за счёт своего diff-алгоритма.
Я немного поправил ваш пример для React.js, сравните ещё раз. На самом деле, я думаю можно ещё быстрее + было бы неплохо привести какой-нибудь более «толстый» пример (чтобы показать разницу в обновлении данных)
Ну, если речь идёт о C++ (в коем я, увы, несведущ), то 3-х минутный поиск в гугле выдал мне вот это решение. Или есть причины, почему оно не подходит? (т.к. на мой взгляд оно выглядит намного лаконичней и читабельней). Или решение автора производительней?
По-моему, если называть переменные своими именами и класть их в логически правильные контейнеры, то проблем не возникает и без комментариев. На худой конец, если очень хочется, то создайте обычный JS файл и изливайтесь мыслью по древу — это будет намного понятнее читать, чем предложенный автором транслятор (меня, лично, напрягает бесконечное количество разнообразных слэшей).
По-моему проблемы, описанные вами в статье отчасти уже поднимались на англоязычных ресурсах (как уже заметил один из комментаторов), а отчасти являются вашим субъективным мнением. На самом деле большая часть проблем, поднятых вами действительно существует, но среди них нет ни одной неразрешимой.
Меня немного удивила позиция по поводу поддержки клиентского кода серверными программистами. Вы считаете, если человек знает Python (например), то он должен разбираться в JS фреймворках и наоборот? Такие утверждения, по своей сути, являются колыбелью быдлокодинга: «Давайте наймём Васю, он знает Python и если что, сможет поддерживать фронтенд часть».
По поводу серверного рендеринга и т.п: если вам нужен информационный сайт, который будет индексироваться поисковиками, то использование ангуляра было, как вы говорите, непродуманным решением №1. Что касается скорости рендеринга, то я немного не понял: генерируя страницу на стороне сервера, вы просто подставляете параметры в шаблон, рендерит её всё равно браузер. Да, вы можете закешировать страницу, с подставленными в неё значениями, но скорость рендеринга от этого не изменится, вы просто уберете время на процессинг шаблона (что на современных клиентских машинах, пусть даже на мобильных устройствах) занимает сотые доли секунды. Но если хотите и это оптимизировать, можете взглянуть в сторону appcache и кешировать то же самое на стороне клиента, тем самым убрав с сервера часть расходов процессорного времени и памяти.
Всего должно быть в меру. Некоторое время назад, я очень дорожил «чистотой» своего кода, что сводилось к довольно высоким затратам на проект (и более того, те, кто сейчас продолжают мою работу, идут по тому же пути). Сейчас, несколько пересмотрев свои взгляды, могу сказать, что если мы говорим о работе, то я выдаю результат ASAP, порой действительно не вдаваясь в глубокое проектирование. Однако когда я прихожу домой и открываю свои проекты, я скрупулёзен и педантичен в каждой строчке своего кода. Просто стоит разделять программирование «для себя» и «процесс разработки продукта, приносящего деньги» для заказчика. Это не значит, что в коде для клиента всё должно быть тяп-ляп, просто избавьте себя от рефакторинг-ононизма до момента релиза продукта, это сэкономит вам кучу времени, заказчику — затраты, а компании принесет деньги.
Прошу прощения, написал не подумав: в манифесте node-webkit можно использовать ключ node-remote (более подробно тут), в котором указывается маска адресов / сайтов, которые могут использовать node-webkit скоуп (тема на github по этому поводу).
При таком подходе теряется возможность использовать скоуп node-webkit. Получается, что вы просто показываете сайт в милом окошке, все плюшки node-webkit придется забыть.
Спасибо за развернутый ответ! Хоть вопрос и выглядит несколько саркастичным (за что я уже поплатился), он таковым не является. Мне правда интересно, как видят язык программисты из других областей, <имхо>но я всё же считаю излишним описывать каждую спецификацию со стороны программистов других областей (представьте, какой каламбур будет, если JS программисты будут описывать новые спецификации C++ и т.п.)</имхо>.
По поводу взгляд на JS со стороны Haskell-программиста: к сожалению, не напишу из-за слабого знания последнего. Однако, если вам интересно почитать про функциональное программирование на JS, то на хабре уже есть несколько статей на эту тему.
Есть у ECMA-6 и Java/C# что-то общее помимо классов (которые являются синтаксическим сахаром поверх прототипного наследования) и лямбд? Вы пишете про сравнение с точки зрения Java/C# программиста, а упоминание данных ЯП я вижу только в двух местах.
Хром, к примеру, не поддерживает большинство вещей из списка, если не включен флаг Enable Experimental JavaScript. Выход — использовать Traceur, компилятор из ES 6 в ES 5.
Ситуация за год не изменилась.
Ну и как-бы в 2014 ES6 API уже можно начинать использовать
Это мнение автора или чем-то обоснованная позиция? Так как если вы посмотрите на traceur и его дату создания, то он существовал ещё с 2011 года (хоть и поддерживал далеко не всё), что позволяло ещё в тех годах использовать вышеописанные в статье фичи новой спецификации.
<имхо>Мне нравится статья и как она написана (за мелкими исключениями), но либо вы опоздали с её публикацией (на год), либо сделали не на то акцент (потому что выглядит как дополнение к предыдущей статье). И извините за прямолинейность и не сочтите за оскорбление.</имхо>
Да, но разве вы исследуете какие-то новые API с момента прошлогодней публикации?
Объясните мне, в чём разница взгляда на спецификацию со стороны JavaScript-программиста и Java/C# программиста? Может стоит написать ещё несколько обзоров с точки зрения Python / Ruby / Haskell программистов?
Да, они действительно пишут обертки из React -> Native, но я думаю, что публичный релиз состоится только после того, как они покроют все элементы на обоих платформах.
Если вы не планируете строить *реально большое приложение*, то проблемы, описанные в статье не будут вас трогать ни коем образом. У любых библиотек/фреймворков есть свои недостатки. И да, сравнивать jQuery с Angular'ом некорректно. Вы же не сравниваете php библиотеки и фреймворки?
— Добавить условие при обновлении (например, обновлять только чётные строки)
— Изменить дописывание в
<li>на что-то более, например на<li><span class="first">{{ first }}</span></li>при заполнении и на<li><span class="first">{{ first }}</span>, <span class="second">{{ second }}</span></li>после обновления— Удалять часть DOM-элементов (например, кратных 3)
— Добавить обработчики на
<li>элементыЛично мне было бы интересно сравнить выбранные библиотеки/фремворки на таком бенче, как считаете?
setTimeout(callback, 0)->callback.call(null), однако поменяв этот кусок обратно, и просто убрав jQuery (который там вообще ни туда, ни суда, т.к. React в дефолтной конфигурации никак не зависит от него), у меня всё равно получается у ангуляра 3321мс на filling и 747мс на update для 10000 на раб. машине против 1589мс на filling и 727мс на update у React. И кстати, имеет смысл сравнивать не только время, но и размер памяти, выделяемый при этом сравнении. У меня angular съедает на 50% памяти больше (37,8Мб у React против 57.1Мб у Angular).Выводы из этого сравнения:
В рамках тестирования на моей рабочей машине
— angular медленнее в первоначальном рендеринге данных на 100%
— angular и react одинаковы в скорости обновления этих данных
— angular съедает на 50% больше памяти, чем React
В заключение хочу сказать, что если бы часть данных оставалась такой же (т.е. не изменялась бы при операции update), то React показал бы более производительный результат за счёт своего diff-алгоритма.
И да, отдельный респект за перевод картинок, получилось очень качественно.
Спасибо.
Меня немного удивила позиция по поводу поддержки клиентского кода серверными программистами. Вы считаете, если человек знает Python (например), то он должен разбираться в JS фреймворках и наоборот? Такие утверждения, по своей сути, являются колыбелью быдлокодинга: «Давайте наймём Васю, он знает Python и если что, сможет поддерживать фронтенд часть».
По поводу серверного рендеринга и т.п: если вам нужен информационный сайт, который будет индексироваться поисковиками, то использование ангуляра было, как вы говорите, непродуманным решением №1. Что касается скорости рендеринга, то я немного не понял: генерируя страницу на стороне сервера, вы просто подставляете параметры в шаблон, рендерит её всё равно браузер. Да, вы можете закешировать страницу, с подставленными в неё значениями, но скорость рендеринга от этого не изменится, вы просто уберете время на процессинг шаблона (что на современных клиентских машинах, пусть даже на мобильных устройствах) занимает сотые доли секунды. Но если хотите и это оптимизировать, можете взглянуть в сторону appcache и кешировать то же самое на стороне клиента, тем самым убрав с сервера часть расходов процессорного времени и памяти.
По поводу взгляд на JS со стороны Haskell-программиста: к сожалению, не напишу из-за слабого знания последнего. Однако, если вам интересно почитать про функциональное программирование на JS, то на хабре уже есть несколько статей на эту тему.
Есть у ECMA-6 и Java/C# что-то общее помимо классов (которые являются синтаксическим сахаром поверх прототипного наследования) и лямбд? Вы пишете про сравнение с точки зрения Java/C# программиста, а упоминание данных ЯП я вижу только в двух местах.
Ситуация за год не изменилась.
Это мнение автора или чем-то обоснованная позиция? Так как если вы посмотрите на traceur и его дату создания, то он существовал ещё с 2011 года (хоть и поддерживал далеко не всё), что позволяло ещё в тех годах использовать вышеописанные в статье фичи новой спецификации.
<имхо>Мне нравится статья и как она написана (за мелкими исключениями), но либо вы опоздали с её публикацией (на год), либо сделали не на то акцент (потому что выглядит как дополнение к предыдущей статье). И извините за прямолинейность и не сочтите за оскорбление.</имхо>
Объясните мне, в чём разница взгляда на спецификацию со стороны JavaScript-программиста и Java/C# программиста?
Может стоит написать ещё несколько обзоров с точки зрения Python / Ruby / Haskell программистов?