1:28 - keynote - complexity in software Complexity in GUI, history of struggle with accidental complexity 5:42 - bad days - thick client 7:24 - good days - server side rendering 10:33 - why SPA? 12:01 - history of web tradeoffs goes on Complexity and how we fought it. 13:25 - Sad present. Why so much pain making GUI 13:34 - object hell 18:48 - distributed systems (hell) 19:24 - How to deal with it 24:04 - db on server (bye OOP) 26:31 - ClojureScript 33:58 - db on client 37:45 - client-server state sync 39:19 - view model - UI as data 41:43 - test your UI as data 47:12 - a thought on the next step in complexity reduction - one new crazy idea 49:47 - recap + QA 52:38 - build tools? 50:35 - what for async? 50:53 - purity 54:30 - Switching to FP worth it? In every case? For those who's been hyped by 'one crazy idea for the next step of complexity reduction' - here is a Clojure app, built on this architecture: github.com/andrewzhurov/brawl-haus#mindset Efforts put in giving a good mindset on the topic as part of documentation. "Propagate state down to clients, down to end-nodes, reactively, being driven by clients" Thanks much for the talk, blows my mind!
Работал с программистом Oracle SQL. Он за последние 15 лет ничего нового не учил. Делал изо дня в день однотипные задачи. Хорошо ли это ? Может и да. Вокруг его базы delphy-приложения сменяли одно другое, умирали, 1С эволюционировало с 7.х до 8.х а он писал одни и те же SELECT FROM и был и остаётся уважаемым специалистом.
Жалко не затронуто автором, как он относится к реализации бизнес-логики бэкэнда в DB (в хранимках и т.п.). В энтерпрайз системах это очень часто встречается.
- хранимки практически невозможно тестировать - у хранимок сложности с git - в последнее время очень мало спецов, которые адекватно могут править и писать хранимки + вычисления происходят рядом с данными, уменьшая нагрузку на сеть - вычисления происходят рядом с данными, увеличивая нагрузку на CPU в энтерпрайзе много легаси, от которого нереально избавиться, хранимки как правило это самое легаси, минусов у хранимок явно больше, да и если брать в расчет плюс - сеть в современных ДЦ как правило 10Гбит, а вот cpu явно не хватает, как следствие репликации и шардинг, а в случае шардинга хранимка с некоторой вероятностью все равно задействует сеть
vue и реакт нужны инструменты проектирования приложений а не просто набор модулей. Уточнение бекенда сведение его только к бизнес-логике это необходимость и неизбежность. Клиент может быть написан на чем угодно и их может быть овер 1000
Так и понял что все кончится чем-то вроде кложура, когда докладчик начал рассказывать что "классическое" "все на сервере" приложение у них получилось проще и лучше чем SPA + API
Он сказал что сложность меньше, но ничего не говорил про то что UI лучше, в его случае сложный UI не требовался, по этому SPA было не нужно. SPA это дорого, медленно, требует большого числа разработчиков. Если у тебя стандартная команда 3+2+1 то ты не выберешь spa без крайней необходимости.
Github`ом очень неудобно пользоваться. Лично для меня ситуацию как-то смягчает octotree. Я думаю, что там где структура и геометрия гуя не меняется, должно быть SPA.
Николай, вы давайте друзьям слайды прочитывать! :) А то замыленным взглядом не замечаете смешные опечатки :) "No silver bullit"... хорошо не bullshit :)
Походу автор изобрёл JSF с хранением дерева компонентов на сервере. Каждый компонент хранит состояние, значение и имеет свой lifecycle. В теории похожие тесты в JSF тоже можно было писать. На практике JSF плохо прижился.
![Александр Соловьев / Functional Reactive Programming & ClojureScript [ru]](/img/n.gif)
1:28 - keynote - complexity in software
Complexity in GUI, history of struggle with accidental complexity
5:42 - bad days - thick client
7:24 - good days - server side rendering
10:33 - why SPA?
12:01 - history of web tradeoffs goes on
Complexity and how we fought it.
13:25 - Sad present. Why so much pain making GUI
13:34 - object hell
18:48 - distributed systems (hell)
19:24 - How to deal with it
24:04 - db on server (bye OOP)
26:31 - ClojureScript
33:58 - db on client
37:45 - client-server state sync
39:19 - view model - UI as data
41:43 - test your UI as data
47:12 - a thought on the next step in complexity reduction - one new crazy idea
49:47 - recap + QA
52:38 - build tools?
50:35 - what for async?
50:53 - purity
54:30 - Switching to FP worth it? In every case?
For those who's been hyped by 'one crazy idea for the next step of complexity reduction' - here is a Clojure app, built on this architecture:
github.com/andrewzhurov/brawl-haus#mindset
Efforts put in giving a good mindset on the topic as part of documentation.
"Propagate state down to clients, down to end-nodes, reactively, being driven by clients"
Thanks much for the talk, blows my mind!
Интересно и по делу. Спасибо!
Чувствуется просто тонны опыта у докладчика.
Работал с программистом Oracle SQL. Он за последние 15 лет ничего нового не учил. Делал изо дня в день однотипные задачи. Хорошо ли это ? Может и да. Вокруг его базы delphy-приложения сменяли одно другое, умирали, 1С эволюционировало с 7.х до 8.х а он писал одни и те же SELECT FROM и был и остаётся уважаемым специалистом.
Жалко не затронуто автором, как он относится к реализации бизнес-логики бэкэнда в DB (в хранимках и т.п.). В энтерпрайз системах это очень часто встречается.
- хранимки практически невозможно тестировать
- у хранимок сложности с git
- в последнее время очень мало спецов, которые адекватно могут править и писать хранимки
+ вычисления происходят рядом с данными, уменьшая нагрузку на сеть
- вычисления происходят рядом с данными, увеличивая нагрузку на CPU
в энтерпрайзе много легаси, от которого нереально избавиться, хранимки как правило это самое легаси, минусов у хранимок явно больше, да и если брать в расчет плюс - сеть в современных ДЦ как правило 10Гбит, а вот cpu явно не хватает, как следствие репликации и шардинг, а в случае шардинга хранимка с некоторой вероятностью все равно задействует сеть
Доклад о сложности которую преодолевает лисп и фп. Палец вверх.
Да печаль с опечатками и оговорками. Никита написал DataScript, а не Datomic за это ему большой respect
vue и реакт нужны инструменты проектирования приложений а не просто набор модулей. Уточнение бекенда сведение его только к бизнес-логике это необходимость и неизбежность. Клиент может быть написан на чем угодно и их может быть овер 1000
Так и понял что все кончится чем-то вроде кложура, когда докладчик начал рассказывать что "классическое" "все на сервере" приложение у них получилось проще и лучше чем SPA + API
Он сказал что сложность меньше, но ничего не говорил про то что UI лучше, в его случае сложный UI не требовался, по этому SPA было не нужно. SPA это дорого, медленно, требует большого числа разработчиков. Если у тебя стандартная команда 3+2+1 то ты не выберешь spa без крайней необходимости.
Github`ом очень неудобно пользоваться. Лично для меня ситуацию как-то смягчает octotree. Я думаю, что там где структура и геометрия гуя не меняется, должно быть SPA.
Николай, вы давайте друзьям слайды прочитывать! :) А то замыленным взглядом не замечаете смешные опечатки :) "No silver bullit"... хорошо не bullshit :)
Походу автор изобрёл JSF с хранением дерева компонентов на сервере. Каждый компонент хранит состояние, значение и имеет свой lifecycle. В теории похожие тесты в JSF тоже можно было писать. На практике JSF плохо прижился.
кто-то не знает про No Silver Bullit ?)
neead moar bullit!