На этой неделе свежий взгляд на построение сложнейших динамичных систем, клеймление react и прочих модностей. На связи @YodaPunk

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

Не думаю кого-то переубедить, но расчитываю помочь тем кто чувствует, что "что-то здесь не так"

Меня зовут Глеб Арестов, с октября 2009 в свободное от работы время занимаюсь эволюционным развитием seesu.me

Интерфейс seesu.me построен на лучших принципах(!) проектирования интерфейсов, но в целом оно пока далеко от того, что я хочу сделать

Работаю в компании еврохим, мы тут пишем на node.js, mysql и oracle. Почётно награждён (РЕАЛЬНО)! ;)

Увлекаюсь проектирование интерфейсов (Джеф Раскин рулит!) и p2p системами.

. @ponitozhekoni почетная грамота от компании :) вообще, я рассчитывал, что никто не спросит

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

. @axique да, чуть позже предложу восстание против императивного программирования, и против того которое делает вид что оно не императивное

В качестве завершения знакомства мои две супер полезные заметки:

habrahabr.ru/post/211659/ — Три правила проектирования интерфейсов с высокоскоростным пользовательским взаимодействием

habrahabr.ru/post/210558/ — Список оптимизаций рендеринга DOM, реализуемых на уровне Javascript фреймворка

План ~

. @blia не использую :( потому что понимаю какие на каких идеях они построены и есть с чем сравнить. ВСЕ ПЛОХО

По многочисленным просьбам (их пока две) клеймлю уже сегодня. Но коротко

angularjs: мы любим сайд эффекты, мы целые приложения пишем на сайд эффектах, dirty checking, digest вот это все.

. @jsunderhood давайте вызывать все функции подряд пока все не утрясется!

. @justusebrain предлагаю обсудить идеи дедушки Раскина где-нибудь в четверг, пятницу pic.twitter.com/ds78U1cyNw

React. Архитектору не нравится придуманные синтаксисы, но он предлагает JSX youtube.com/watch?v=-DX3vJ…

Петеру не нравится указывать зависимости данных, но потом они предлагают flux(!), чтобы, прости господи, поправить счётчик сообщений #react

У #emberjs насморк (уходит память на учёт зависимостей), давайте ампутируем голову — говорит архитектор #react youtube.com/watch?v=-DX3vJ…

Помните: когда у вас настоящая декралативность вам вообще не нужен такой промежуточный этап как Virtual DOM #react

. @as_Crazy а как же функция render()? Её результат - virtual dom. Императивно собирается ручками. Вполне себе кишками наружу.

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

Что такое декларативность по вашему? Зачем она вообще нужна?

. @as_Crazy да, результат функции декларативен, но сама функция императивна

. @freiksenet_ru @as_Crazy лететь!

Результат функции react render

Тело функции react render без JSX (<?php>)

SQL (в большинстве случаев)

Запросы в Datomiс

. @alexeyraspopov нет

.@jsunderhood у тебя есть реальный опыт использования Angular, React и Ember?

@oaleynik @jsunderhood ну html же декларативный, вот хочется такого же, только для динамеского DOM, а не статического

@jsunderhood как результат может быть императивным или декларативным?

. @justusebrain Легко. Функция вернёт функцию. Cмысл вопросов — напомнить что результат выполнения функции и её тело - совсем не одно и тоже

Пока я тихонечько, начиная с октября 2009 года, никого не трогая, писал код seesu, в моду вошел backbone, angular, появился react.

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

Беспомощно пытался организовать код с помощью ООП и events driven model

ДЕЛАЛ ВЫВОДЫ. Выводы про программирование, организацию кода, про проектирование интерфейсов. (МНОГО ИХ. ВЫВОДОВ)

САМЫЙ ГЛАВНЫЙ ВЫВОД (метафорой, а потом нормально):

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

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

Разработчик: состояния, взаимосвязи состояний и сущностей, чистые вычисления. Система: наблюдение, актуализация/вызов конкретных вычислений.

Это я описал новейший секретный, ЗАПРЕЩЕННЫЙ КОНВЕНЦИЕЙ ООН, архитектурный подход «Декларативное Целеполагание». arestov.github.io/declarative-go…

@jsunderhood сравнение jsx с пхп многое про вас проясняет

. @as_Crazy не с php а с его возможностью перемешивать нормальный код и html

Функция. Императивно гененирирует SQL выражения для запроса. Может кардинально менять структуру (Императивная же) и даже таблицу выборки.

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

Неявные (императивные в данном случае) взаимосвязи, зависимости - зло

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

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

@jsunderhood ты пробовал эрланг?

. @iamstarkov пока нет. Стоит?

@jsunderhood если ты хочешь параллельности, то думаю да

Про декларативное целеполагание и динамизм в seesu у меня вот докладик был wsd.events/2015/05/22/pre…

@jsunderhood Thanks for the mention. Would you like to discuss upgrading your company's CI from Jenkins? :)

Делал для себя, но может кому пригодится архив твитов @cssunderhood и @jsunderhood за прошлую неделю anarion.info/tws/

. @Anarion_tw @cssunderhood jsunderhood.ru !

Кто как реализовывал обработку событий свайпа на JS? Подскажите библиотеки, велосипеды. @cssunderhood rt plz

Декларативность в шаблонах это суперважно по двум причинам: А) оптимизации производительности Б) Лаконичный, эффективный код.

Декларативный шаблон - это возможность выяснить какие структуры, поля используются в нем. pic.twitter.com/2sRAAxlC6e

Имея эту информацию и декларации о том как конкретно DOM зависит от данных можно реагировать непосредственно на изменения данных.

При изменении данных атомарно менять DOM, без промежуточных абстракций, дорогих сравнений virtual dom, нагрузки наGC pic.twitter.com/ksFqqDVz9U

Декларативный шаблон - это возможность вычислить все комбинации DOM дерева

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

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

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

А потом маркировать эти ветки помощью нового css свойства "contain", как доступные браузеру для тяжёлых оптимизаций

Анализ можно провести один раз, например, при компиляции кода или при первом запуске приложения.

@jsunderhood у нас есть свой шаблонизатор для этого github.com/monkberry/monk…, вот бенчи vs React monkberry.github.io/benchmark/

@jsunderhood можно практический пример или демку?

. @alexeyraspopov насколько я знаю анализ тяжёлых изменений в DOM пока никто не сделал

Давайте дальше про декларативные шаблоны! Имея информацию о том как используются структуры данных в шаблоне вы можете:

1) автоматически анализировать и отображать список внешних ресурсов, необходимых для отображения шаблона, пример seesu.me/o/#/catalog/Pi…

2) вы можете сгенерировать один запрос, который соберёт все поля объекта и его вложенностей в том числе для списков

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

Так ведь планируется поддерживать graphql код?

А ведь можно просто использовать декларативные шаблоны и автоматическую генерацию запросов

@jsunderhood не понимаю с чего бы вы не можете провести такой же анализ render метода?

. @as_Crazy ответ на этот вопрос кроется в функции shouldComponentUpdate

Давайте про декларативные шаблоны и сервер!

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

Приложение при первом запуске спрашивает сервер "как эффективней получить такую-то структуру"?

Он отвечает: по урлу api/struc4368/. Когда необходимо приложение дёргает этот урл.

Тем временем сервер записывает каждый такой сгенерированный урл и мониторит производительность

Если надо серверный программист вмешивается достраивает индексы, докручивает код под эту структуру и код летает

. @freiksenet_ru а кто сказал что обязательно использовать graphql?

@jsunderhood Твой компонент может не знать как устроен твой graphql ендпоинт. Ты в пузыре где ты контроллируешь и бакенд и фронтенд.

@jsunderhood В команде такого не будет и никто не будет писать API под твой генератор.

. @freiksenet_ru ну а если сам напишу? Корпоративная бюрократия это проблема, согласен

shouldComponentUpdate нужна чтобы лишний раз не вызывать render

Потому что из самой функции render непонятно как она использует данные и влияет на результат

JSX не делает код декларативным. Это просто сахар, что бы не писать самому вызовы React.createElement

JSX компилируется в обычную императивную функцию. Где первой распростhанённой проблемой при анализе станет цикл

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

@jsunderhood "можно написать хуево" это не аргумент. Идиоматично не делать никаких side-effects в рендере.

. @freiksenet_ru тогда остаётся вопрос с циклами/forEach/map/etc и композицией функций, что вполне идиоматично

@jsunderhood @freiksenet_ru так надо анализировать результат (vdom) а не саму функцию

. @andreypopp @freiksenet_ru и как из vdom понять каким образом используются структуры данных, как вычислить комбинации дерева?

Свёл воедино про реакт и декларативные шаблоны arestov.github.io/declarative-go…

@jsunderhood @freiksenet_ru еще с шаблонами как у тебя в примере стоит вопрос usability? Что если не хватит выразительности? Как расширять?

. @andreypopp @freiksenet_ru проектировать нехватающие средства выразительности

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

.@freiksenet_ru @andreypopp основная проблема с seesu.me/o не реализованные декларативные шаблоны, а сервисы, ломающие свои API

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

@jsunderhood вот написал немножк pastebin.com/AuMP7LPk

. @sevaisnotcow вопрос о жизнеспособности декралативности не стоит. Есть seesu.me/o. Работает. Хочется ещё больше эффективности

Почему лаконичный, анализируемый код важен для меня?

В seesu.me тонна различных страниц, она наполняется примерно 40 запросами к разным сервисам (last.fm, discogs, hypem)

В seesu.me используются интерфейсные подходы, которые вынуждают делать систему с высокой степенью динамизма.

Помимо этого с я самого начала стремился делать супербыстрое приложение.

Помимо тонны оптимизаций рендеринга habrahabr.ru/post/210558/ и производительности самого js научился и другим трюкам habrahabr.ru/post/211659/

Но чтобы ориентироваться в коде в одиночку и не сойти с ума остро встаёт вопрос об лаконичности, выразительности, анализирумемости кода

Если кто-то готов пройтись по 100 шаблонам и прописать там источники данных, то я нет. (last.fm требует аттрибуции)

Если кто-то готов вручную написать императивный код для 40-ка запросов и раздуть код ещё больше, то я нет.

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

Что делать если ты хочешь быстрый рендеринг интерфейса и у тебя десятки шаблонов, но 25 мая 2013 ещё не наступило?

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

@jsunderhood и гораздо эффективнее во вьюхе описывать "зависимость" от локальных данных, а запросы за удаленными данными делать в отдельном>

. @sevaisnotcow не предлагаю запросы засовывать во вьюхи

@jsunderhood @sevaisnotcow Потому что только в волшебном мире у тебя контроль за бакендом и можно туда свалить всю логику обработки данных.

. @freiksenet_ru @sevaisnotcow так ведь для этого есть модели

. @sevaisnotcow знаком с реальным миром как никто. В seesu.me используется тонна сервисов. Все неподконтрольны

@jsunderhood @sevaisnotcow Их ты в своем примере не показал.

. @freiksenet_ru @sevaisnotcow ну мы же шаблоны осбуждаем

@jsunderhood приложение, делающее порядка 40 запросов с натяжкой можно назвать быстрым. почему не вынести data fetching логику на сервер?

. @a_kovalev 1) это не одновременные запросы, а количество точек соприкосновения с сервисами

. @a_kovalev 2) api часто ограничивают количество запрос с одного IP. надо делать с клиента

@freiksenet_ru @jsunderhood @sevaisnotcow а вот, кстати, было бы очень любопытно посмотреть, как модели будут реализовывать такую абстракцию

. @twenty Сложные состояния
wsd.events/2015/05/22/pre…

. @twenty Сложные состояния на основе связанных моделей
wsd.events/2015/05/22/pre…
wsd.events/2015/05/22/pre…

. @twenty Связь состояний модели и тем, что можно получить от обычного сервера
wsd.events/2015/05/22/pre…

А вы сами то как считаете, какие крутые оптимизации могли бы быть в шаблонизаторах? Как сделать код эффективнее и лаконичней?

@jsunderhood Для начала — отказаться от шаблонизаторов!

. @Semenov а какой профит?

Есть хотя бы один язык программирования, который мог быть ответить на вопрос "откуда берётся это поле, как оно вычисляется и попадает сюда?"

. @jsunderhood задаёте это вопрос, а вам полное дерево зависимостей в ответ

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

. @alexeyraspopov это так решил?

@rubyunderhood @jsunderhood собственно, для какого-нибудь ember / handlebars наверное можно сделать трейсинг до метода или поля объекта.

Возможности и ограничения какого ЯП позволяют **инструментам** ответить на вопрос «Откуда это поле? Как оно вычислялось?»

Функциональный п-д позволяет избегать сайд эффекты => можно машинно анализировать причинно следственные связи в коде

В ФП -"- причинно-след. связи => предотвр-ется запись в один объект двумя потоками => можно параллелить прям так!

Datomic может сам принимать решение об оптимизациях, параллелизме. Clojure не может.

@jsunderhood может, но не принимает :) Слишком геморно оптимизатор писать

Чистая функция которая может вернуть ответ одной или другой структуры по прежнему чистая?

Я о такой функции говорил pic.twitter.com/4EwKVXugA6

Что насчёт такой функции? pic.twitter.com/W4X9sUtS3U

Сегодня в @jsunderhood иллюстрация, иногда лучше сначала осилить хаскель, а потом рассуждать про чистоту :(

. @freiksenet_ru а что это даст?

Сегодня в @jsunderhood очередная скандальная иллюстрация чего-то

Поговорим про динамизм в программных система, а также о застое и legacy подходах

Как вы можете заметить seesu насыщена динамизмом arestov.github.io/declarative-go…

Вот писал я код я искал — как же организовывают такое всякое сложное? И за годы не нашел :(

Когда я понял в чем проблема (динамизм, постоянно меняющеся взамосвязанные части) понял почему не нашёл

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

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

У ребят «которые знают» не было и не могло быть опыта столкновения с насыщеными динамизмом системами

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

Когда пришло осознание, что ребята «которые знаю» вовсе не знают, организовывать код стало проще

Если старые подходы всем хороши, проблемы осознаны и решены, то чем занимается создатель нашумевшего lightTable?
chris-granger.com/2014/03/27/tow…

Почему опаснейший Chris Granger занимается инструментом для явного указания взаимосвязей? chris-granger.com/2015/08/17/ver…

arestov.github.io/declarative-go… Нет «они» не знают :(

С реактивным программирование и cassowary проблема в том, что сборка взаимосвязей императивная и крайне сложно анализируется

По моему удобно писать как-то так. Пускай кто-то другой развешивает свои watchers или потоки, не важно что внутри pic.twitter.com/BUTY5e581F

Почти как ember.js только расход памяти меньше на каждый экземпляр, можно оптимизировать как css (справа налево). Анализировать можно

Good ideas come from anywhere. If you're not actively listening to many programming languages and communities - doing it wrong.

Не перестаю делать попытки стриминга музыки из торрентов

Сначала был utorrent, но API был жутко медленный, а потом они его вообще закрыли pic.twitter.com/IITbCgPHwe

Потом peer-flix и webtorrent, но они жутко жрут память и вообще глючат при активном использовании. А так - работает pic.twitter.com/fn1BwbYEn8

Решил писать свой торрент клиент, чтобы без каши .on('event-name', ...)

В webtorrent сейчас течёт память в основном из-за утечек через удалённые, но не отписанные от событий объекты.

Писал исправления, но автор не стал ни принимать их, ни исправлять сам

Ещё, обе библиотеки блочат приложение потому что в основном процессе считаю хеши файлов, синхронно

Ну допустим эти детские болезни мы победим и стриминг из торрентов будет. Но как мы будем строить настоящие p2p сети, mesh интернет?

Мы что, только plain текстом и файлами будем делиться как fireChat? Надеюсь, что нет

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

Может быть можно делиться мини приложениями для просмотра этих структур, написанных на scala? Так чтобы они запускались без разрешения

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

Если нужна одна функция, которая должна вернуть, скажем, html,
то и js module сойдёт, который не может ни reqire ни имеет доступа к global

@jsunderhood но nodejs module (CJS) умеет и в require и в globals

. @iamstarkov я имел ввиду: запускать код внутри какой-нибудь sandbox npmjs.com/package/node-s… Забрать доступ к require и global

@jsunderhood но зачем когда есть сэндбоксинг и пермишены?

Почему плохой? В тред призывается @jsunderhood.

@bytecheg @rubyunderhood не надо angular пробовать, он плохой

12:02

Открыт приём докладов на конференцию о React в Амстердаме, 16 апреля — goo.gl/forms/WBd5Yr9M…

Жмём RT! pic.twitter.com/i48oPEAEzZ

MDK ищет frontend-разработчика. Подробности здесь: moikrug.ru/vacancies/1000… @jsunderhood