У Jinja2 есть конструкция macro, которая выглядит как функция. Определяется так:

{% macro hello_world(a, b, c=None, d='test') %}
Hello World {{ a }} {{ b }} {{ c }} {{ d }}
{% endmacro %}

Далее мы ее можем вызвать:

{{ hello_world(1, 2, 3, d='Hi')

У Jinja2 есть API для получения и вызова макросов как функций. Например так: github.com/mitsuhiko/jinja2/blob/master/jinja2/environment.py#L1036

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

Почему это лучше:
1. Формальное определение функции с соответствующей проверкой аргументов, документацией и т.п.
2. На самом деле прослойка не нужна — Jinja2 уже умеет все из коробки. Разве что надо шаблон загрузить, получить модуль из него и вызывать макросы как обычные функции

Очень неплохая идея, но вот синтаксис не очень.

Было бы отлично если бы тег работал аналогично {% macro foo() %} — т.е. определялся как функция, был список аргументов и т.д. При этом macro уже есть и получить список доступных макросов из шаблона можно используя доступный API.

А зачем в бенчмарке, в update(), render()? Оно же два раза будет перерисовывать. Хотя, похоже, на результат оно не сильно влияет.

В концепцию реакта отлично ложится:

1. Компонент для потока. Рисует информацию об одном потоке.
2. Нужен какой-то простой маршрутизатор сообщений. Компоненты потоков подписываются на события из этого роутера и получают «свои» обновления
3. Вебсокет клиент кидает входящие данные в роутер
4. Компоненты получают новые данные, обновляют свое состояние
5. Обновление состояния автоматически запускает render() для компоненты
6.…
7. Профит

Backbone и React живут параллельно. От Backbone мы используем Collection, Model и Router.

Архитектура приложения типовая three-tier: сверху у нас UI, по середине слой Business Logic, снизу Data Access). Компоненты React просят что-то у BL, тот считает или просит у DA.

Да, у нас тоже есть realtime update — сервер может что-то пушнуть. Сделано через обычный shared state (который спрятан в BL). Компонента React подписывается и когда что-то приходит — ее уведомляют. Построено поверх событий Backbone. В нашем конкретном случае модели для обновлений не используются — сообщения обрабатываются в BL и передаются отдельными объектами.

А вот если нужно хранить историю (например список текущих уведомлений, который глобален для клиента) — то коллекция как синглтон и подписка на ее события. Как только добавляется новое событие (будь то результат AJAX запроса или пришло из вебсокета или кто-то из UI убрал) — подписчики об этом узнают. И да, детали спрятаны в BL и для этого всего есть нормальный API.

Для всяких AJAX запросов — обычные коллекции и модели Backbone. Для React написан небольшой mixin, который умеет слушать .change() события для моделей (и автоматически отписываться если уходит из Virtual DOM) за счет чего получается реактивность.

Ну и насчет вопроса про пересоздавать. Если кратко — React вообще все равно что за данные и откуда они приходят. Если более развернуто: React ожидает что метод render() вернет дерево компонент. Каждый раз — целое дерево компонент. В идеале, render() это чистая функция от аргументов компоненты и внутреннего состояния компоненты.

В связи с этим, если надо отрисовать массив из 10 элементов, внутри которого меняется только 1 элемент, render() каждый раз будет возвращать все 10. И React уже сравнивает что именно поменялось, по сравнению с предидущей версией DOM и обновляет только то что нужно. А, поскольку, виртуальный DOM это просто структуры данных JS, то работает это все достаточно быстро. Это совершенно не отличается от подхода в том-же AngularJS, разве что более явно (с соответствующими плюсами, так как можно оптимизировать).

Как ни странно — все как раз наоборот. Это по собственному опыту где-то на 150 KOC с помощью React+Backbone.

React отвечает только за представление. Используется JSX (с препроцессором, понятно), который похож на HTML, но не совсем. Так как все бьется по компонентам, в большинстве случаев получается древовидная иерархия (а не граф), что хорошо влияет на структуру проекта. Ну а поскольку все в изолированных компонентах — их легко тестировать. Очень легко.

Добавляем backbone (модели+роутинг), require для зависимостей, etc и получаем отличный фреймворк под свои задачи.

У нас есть верстальщик, который максимум что может это подключить плагинчик jQuery. Т.е. не программист вообще. Но вот HTML пишет хорошо. И его получилось очень быстро обучить следующему алгоритму:

1. Делает обычную HTML верстку для страницы включая CSS
2. Он связывается с фронтендщиком, они обговаривают логическую иерархию компонент (как бить кусок HTML на части)
3. Разбивает свою же верстку на компоненты в соответствии с иерархией и отдает фронтендщику без логики
4. Фронтендщик добавлет логику

Так вот, я хочу сказать что конвеер отлично работает. Код остается читабельный — находить ошибки очень легко, учитывая доступный плагин для Chrome Dev Tools. Из за иерархии компонент можно легко найти что за что отвечает. Без каши из scope, без отдельного DSL для шаблонов (JSX не считается — он только теги оборачивает, все остальное в JS). И самое главное — приложение все же пишет программист, который понимает что такое производительность, качество кода и тестируемость.

Думаю следующий вопрос — а как это все поддерживать? Да очень просто. Если изменения небольшие (CSS класс добавить, например) — это может сделать и верстальщик. Если что-то больше, то смотри пункты выше.

И что я хочу добавить, после 50 KLOC проекта на AngularJS — React это просто чудо.

Поправка: отдал свои годовые дивиденты (~$3m), а не выручку.

Стоило бы еще написать о самом Маркусе и всяких интересных историях о жизни его компании: как он отдал годовую выручку команде, про modding community (благодаря чему Minecraft не устаревает при относительно редких обновлениях), про ежегодный MineCon (7500 билетов за $150 были проданы, в среднем, за три часа) и так далее.

Почти ничем не отличается — gevent использует greenlet, который является выдранным hard switching mode из stackless.

Единственное, но очень важное отличие между stackless и greenlet — у stackless есть soft switching который сильно быстрее и сильно надежнее.

Вот тут есть немного: www.stackless.com/pipermail/stackless/2009-September/004268.html

Самое веселое — у него тот же Flask-Admin, но без батареек.

Почтальон сможет отстреливаться, стремно.

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

Их просто отстреливать будут по дороге.

Стоит добавить, что для второго питона есть PyPy и торнадо на нем отлично работает. В отличие от gevent. И разница в производительности там существенная.

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

Но, в среднем, питоновский код медленнее на тройке. Например Django медленнее где-то на 7%. Шаблонизаторы еще медленнее — до 20%.

У нас и так gulp :-)

watchify у нас только как один из слоев, там еще reactify используется и так далее.

Ага, понял. Т.е. смысл как раз что бы файлы отдельно лежали.

В принципе, у нас нормально watchify прижился с source maps во время разработки.

Чем она лучше watchify?

Я использую. Работает быстро, для разработки есть еще watchify (https://github.com/substack/watchify). Он висит в фоне, следит за изменениями в зависимостях и очень быстро пересобирает бандл.

HDMI-CEC лучше отдельного пульта попкорна. Ну и завалялась отдельная небольшая usb клавиатура, которую просто подключил к usb разъему для крайних случаев.

Покупал за $35 напрямую у RS Components (на сайте rpi есть ссылка) с доставкой в Киев. VAT не добавляется, так как за пределами Евросоюза. Доставка — DHL, $8. В пересчете на рубли, вышло всего лишь ~1370 рублей. Доставили за неделю.

С самого начала используется вместе с OpenELEC как медиацентр и IPTV приставка без носителя — просто стримит все или с домашних компъютеров или из Интернета. Подключение по шнурку, так как с WiFi начинает подтормаживать воспроизведение видео.

До этого был Popcorn Hour A-200 и, честно говоря, малинка и XBMC сильно-сильно лучше.