Не знаю откуда такие цифры, если использовать webpack.watch, то все ускоряется на порядок.
У меня проект, где react собирается из исходников (это 500кб кода), несколько входных точек и общие модули выделяются в отдельный файл, дев-сборка (без минификации) происходит за 3с. Сборка с минификацией и с дедупликацией за 12с. После этого watch отрабатывает за 200мс любое сохранение.
То что нативные проходят тесты a+, не говорит о том что в обратную сторону тоже сработает.
.done есть в вышеупомянутом bluebird, смотреть в секции Error handling
Тот же метод есть в других популярных библиотеках, например Q — promise.done
По факту он является стандартом, это способ не остаться с пустым экраном при необработанном исключении. Нативные же промисы проектируются так, чтобы обойтись него.
К сожалению, горячей замены Promises/A+ на нативные Promises не получится из-за различий в апи.
А если использовать их в одной цепочке то возникают проблемы с обработкой ошибок — Promises/A+ требуют вызова
.done(), в то время как у нативных такого нет.
Другими словами, если вы используете bluebird, то придется им пользоваться до конца.
Есть заявление о стабильности от разработчиков iojs: github.com/iojs/io.js/issues/725, из которого следует что обратную совместимость ломать не будут.
На основном сайте iojs.org/en/es6.html говорится что будут добавляться только стабильные улучшения из V8.
Так что да, текущую версию можно считать стабильной на столько же, сколько и сам v8.
То есть реакт не подходит, если есть требование чтобы страницы для клиентов рендерились на сервере. В статье же написано что «Реакт можно использовать для подачи статичной разметки, без клиентского кода вообще.»
С 5 пунктом я бы поспорил.
Дело в том, что реакт рендерится на сервере крайне неэффективно.
Оба метода, которые преобразуют компонент в строку (renderToString и renderToStaticMarkup) на каждую ноду вызывают свое преобразование. А вызов функции это более-менее затратная операция.
Я проверил на синтетическом тесте, в сравнении с *любимым шаблонизатором* jsperf.com/react-rendertostring/7 — строится список из 100 элементов, у реакта производительность в десятки раз ниже.
Я пока в самом начале пути освоения реакта, но меня это настораживает. А еще больше настораживает что информации об этом не так много.
Да уж, думал сначала что комментарии полны сарказма, селектор давно уже не новый.
Помню его еще по этой табличке совместимости, как один из немногих css3 селекторов, которые хоть немного поддерживались.
Обидно, что из-за кое-какого браузера всё новое хорошее в css пришлось так надолго отложить.
Покажите мне пожалуйста, как вы с помощью CSS собираетесь превратить текст в ссылку? И какое это имеет отношение к дискуссии?
Что будет с вашим селектором ul.news > li > span, когда некоторые даты в HTML коде станут ссылками на все новости в этот день, например.
Насчёт угадывания – вроде слабоумных нет. ul – список, li – элемент списка. Коль скоро всё это имеет класс news, очевидно, речь идёт о контейнере списка новостей и его элементах. Какие с этим сложности?
Насчёт span меня справедливо поправили в этой ветке, что точнее пользоваться тегом H3, к примеру. Тег а говорит нам о том, что речь идёт о ссылке. Какие проблемы могут быть с пониманием этих простых вещей?
ul.news {}
ul.news > li {}
ul.news > li > span {}
ul.news > li > a {}
ul.news > li > a.hot {}
/* угадайте что есть что, и как сделать некоторые даты ссылкой, когда об этом попросят через полгода */
У меня проект, где react собирается из исходников (это 500кб кода), несколько входных точек и общие модули выделяются в отдельный файл, дев-сборка (без минификации) происходит за 3с. Сборка с минификацией и с дедупликацией за 12с. После этого watch отрабатывает за 200мс любое сохранение.
Может это потому что в png применяется сжатие по умолчанию, а для css оно применится только при передаче по сети?
bower update jquery
Плюс, имея исходник в bower или npm, можно сделать свою сборку, взяв только нужные модули.
И более того, даже если не исключать ненужное, можно добиться меньшего размера при сборке.
Например, webpack рекомендует собирать reactjs из npm.
.done
есть в вышеупомянутом bluebird, смотреть в секции Error handlingТот же метод есть в других популярных библиотеках, например Q — promise.done
По факту он является стандартом, это способ не остаться с пустым экраном при необработанном исключении. Нативные же промисы проектируются так, чтобы обойтись него.
А если использовать их в одной цепочке то возникают проблемы с обработкой ошибок — Promises/A+ требуют вызова
.done()
, в то время как у нативных такого нет.Другими словами, если вы используете bluebird, то придется им пользоваться до конца.
На основном сайте iojs.org/en/es6.html говорится что будут добавляться только стабильные улучшения из V8.
Так что да, текущую версию можно считать стабильной на столько же, сколько и сам v8.
Другими словами: яндекс не умеет индексировать ajax (да и просто сгенерированные на клиенте) страницы.
Дело в том, что реакт рендерится на сервере крайне неэффективно.
Оба метода, которые преобразуют компонент в строку (renderToString и renderToStaticMarkup) на каждую ноду вызывают свое преобразование. А вызов функции это более-менее затратная операция.
Я проверил на синтетическом тесте, в сравнении с *любимым шаблонизатором*
jsperf.com/react-rendertostring/7 — строится список из 100 элементов, у реакта производительность в десятки раз ниже.
Я пока в самом начале пути освоения реакта, но меня это настораживает. А еще больше настораживает что информации об этом не так много.
в симпсонахна хабреhabrahabr.ru/post/136395/
Помню его еще по этой табличке совместимости, как один из немногих css3 селекторов, которые хоть немного поддерживались.
Обидно, что из-за кое-какого браузера всё новое хорошее в css пришлось так надолго отложить.
ul.news > li > span
, когда некоторые даты в HTML коде станут ссылками на все новости в этот день, например.Не угадали, в вашем примере
<span>
был датой, а<a>
заголовком. habrahabr.ru/post/150306/#comment_5092480Никак, эту проблему решает gzip
стало:
Мы же не длиной меряемся, надеюсь. Важны такие параметры, как скорость разработки, простота поддержки, читаемость кода и отсутствие багов.