Upload
basisjs
View
2.026
Download
1
Embed Size (px)
DESCRIPTION
Использование компонентного подхода это тяжеловесно, медленно, не гибко. Так ли это? Доклад с фестиваля 404, Самара, 13 октября 2013 Видео: https://www.youtube.com/watch?v=QpZy0WW0Ig4
Citation preview
Компонентный подход:cкучно, неинтересно, бесперспективно
Роман ДворновOstrovok.ruСамара, 2013
2
Немного о себе
• Работаю в Ostrovok.ru
• Ранее руководилвеб-разработкой в ПС Единый кошелек
• Автор и мейтейнер фреймворка basis.js
3
Веб-приложения
4
Это практично, удобно и воcтребовано
5
Все больше сайтов становятся SPA*
6
* Single page application
Как делать?
7
jQuery style
8
Zepto, KnockoutJS, etc.
Предназначены для декорация сайтов, а не для разработки приложений
9
Да, можно использовать для приложений
10
Но лучше не стоит ;)
11
Работа «мечты»
12
MVC
13
Определены роли и разделена
ответственность
14
Примерно так
15
(из википедии)
Каждый понимает по-своему
16
Не определен подход к декомпозиции
17
Много вопросов
18
• Как поступать со сложносоставными моделями?
• Как разбивать большие view на части?
• Часто не понятно, кто должен отвечать за функциональность
Пример
19
Это все одно view
20
В цифрах
• 1 JavaScript файл на 4500+ строк
• 150+ методов
• 150+ свойств
21
22
«Это может случиться даже с лучшими из нас»
23
24
Понять и простить...
Компонентный подход
25
«Component-based software engineering (CBSE) ... is a reuse-based approach
to defining, implementing and composing loosely coupled independent components
into systems...»
26
http://en.wikipedia.org/wiki/Software_component
Слабые связи и декомпозиция
27
Обычный подход
28
list
item
item
item
item
item
Компонентный подход
29
list item
item
item
item
item
Обычный подход
30
window
form
field
field
button panel
button button
Компонентный подход
31
window formfield
field
button panel
button button
Фреймворки
32
Компонентные фреймворки
33
• Dojo Toolkit
• qooxdoo
• YUI
• Ext.js (Sencha)
• Google Closure
Преимущество
34
Недостатки• Сложные – необъятное API, много классов, свойств и пр.
• Большой объем (ext-all.js min ~1.5 MB)
• Медленные• Сложно кастомизировать, переопределять поведение и стили
• Слишком большие для простых приложений
35
Эти факторы сформировали
негативное отношение к компонентному походу
36
Фреймворки меняются к лучшему, но недостаточно сильно, чтобы изменить устоявшееся мнение
37
Почему так получилось?
38
Время появления фреймворков
• Dojo Toolkit – 2004
• qooxdoo – 2005
• YUI – 2006
• Ext.js – 2007
39
Не было понимания как делать веб-приложения, но был опыт разработки
desktop-приложений
40
Desktop IDE
41
Borland Delphi 6
Особенности• Для отрисовки нужно работать с GDI и другими системными API
• Управление памятью• Компилируемые языки и статическая типизация
• Для упрощения множество классов были объеденены в единое целое и представлялись одним компонентом
42
Настройка компонент
43
Сложность отрисовки
44
Много свойств, отвечающих за внешний вид
Разработчики фреймворков не стали изобретать новых подходов
45
Сложности перевода
46
• Отсутсвие в javascript приватных свойств (private, protected etc), getters/setters*→ большое количество свойств и сложное API
• В javascript используется прототипное наследование→ эмуляция классической модели в ущерб производительности
* стандартизированы только в ES5
Наследство
• Подходы к построению API, именованию
• Структура компонент• Большие компоненты• Стилизация в коде
47
Эти факторы определили первоначальный вид компонентных фреймворков
48
А сейчас большинству мешает тяжелоенаследие
49
Все ли так плохо?
50
1. Сложность
51
Основа компонент
52
Фреймворк Класс Кол-во свойств
qooxdoo qx.ui.core.Widget 538
ext.js Ext.Component 391
YUI Y.Widget 180
Google Closure goog.ui.Containergoog.ui.Control
164172
basis.js basis.ui.Node 126
Dojo dijit._Widget 87
Строим дерево
53
Ext.js
• Больше часа, чтобы разобраться
• Примеры не помогают
• Вручную дерево не построить, только через store или «хитрым» методом, найденым методом научного тыка
54
Google Сlosure
• ~20 минут чтобы разобраться
• Помог пример• +15 мин чтобы оптимизировать и уменьшить время вдвое (можно манипулировать узлами)
55
qooxdoo
• Не взлетел Потребовалась "помощь из зала"• Чтобы сделать приложение надо использовать инструменты на python (!)
• Примеры в скомпилированом виде
• Примеров мало
56
Dojo
• Очень сложно• Запутанная документация и примеры• Кое как получилось построить дерево, но не получилось разобраться как его менять
57
basis.js
• Ну вы понимаете ;)
• Есть примеры• Документация пишется (готово ~30%)
• Сам интерфейс – большое дерево
• Можно быстро собрать собственное дерево используя basis.ui.Node
58
basis.ui.Node• listener, состояние, синхронизация, подписка
• хранение данных, привязка данных• управление дочерними узлами• сортировка, группировка• selection, disabled/enabled
• взаимодействие с шаблоном59
2. Размер сборки
60
Практически все фреймворки используют модульность и систему
зависимостей
61
В сборку попадает только то, что используется
в проекте
62
Сравниваем
63
TodoMVC
• Ext.js – 1.2 MB фреймворк + уже неважно ;)
• YUI – 300 KB
• Dojo – 298 KB
• basis.js – 152 KB
• Google Closure – 55 KB
64
TodoMVC
• Ember.js – 403 KB
• Knockback – 197 KB
• jQuery (+handlebars) – 133 KB
• backbone.js – 132 KB
• AngularJS – 83 KB
• KnockoutJS – 52 KB
65
3. Производительность
66
Построение дерева
67
Фреймворк 100 листьев 2000 листьев
qooxdoo 131* ms 3024* ms
Ext.js 52 ms 859 ms
Google Closure 13 ms 216 ms
basis.js 3 ms 68 ms
* не включает рендеринг
TodoMVC
68
100 todo 1000 todo
AngularJS 125 ms 1491 ms
Backbone.js 53 ms 523 ms
Knockout 39 ms 489 ms
vanilla 23 ms 1882 ms
jQuery 20 ms 184 ms
basis.js 8 ms 95 ms
Заключение
69
Все еще нет четкого понимания как должны быть устроенны веб-приложения
70
Веб-приложения – это не просто сайт, но и desktop практикинеэффективны
71
jQuery, knockout, Backbone.js, AngularJS,
Ember.js и др.
72
Становятся все больше и сложнее, приводят к неэффективным
решениям
Ext.js, Dojo, YUI, Google Closure, qooxdoo и др.
73
Становятся лучше, меньше размер сборки, быстрее, но по прежнему сложные, высокий порог входа
Изучайте компонентный подход!
74
Используйте
75
Творите
76
Это круто! ;)
77