Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Javascript-
фреймворки:

должен остаться
только один
Сергей Аверин
Про что доклад
Как выбирали новый веб-фреймворк
1. Немного о компании
2. Бекграунд
3. Задача
4. Исследование существующего...
3
Про компанию
4
Масштаб
• 5 000 000 пользователей
• 500 000 из них — корпоративные
• 700 сотрудников в 17 разных офисах
• Выпускаем много ...
Веб
Все отделы делают веб-часть по-разному
6
Проблема
7
Проблема
• Много разных технологий для веб-части
• Фронтенд пишут не только JS-разработчики
• Нет возможности подключить к...
Задача
9
Курс
• Толстый клиент на JS/HTML/CSS
• Единая технология во всей компании
• Библиотека UI-компонентов
• Возможность работа...
Оценка
11
Что имеем?
• Dojo
• Сайт acronis.com — rich-client там не нужен
• Angular 1.x
• RoR+jQuery
• ExtJS 4
12
Что не так с ExtJS?
• Индексная страница документации содержит:
13
395
классов
8 уровней наследования
14
класс с 201 методами
15
16
17
18
~1% DOM-дерева главной
19
Кастомный UI компонент
layouting
20
layouting
21
deep in layouting code…
22
deep in layouting code…
23
Вы еще помните,

что эта секция называется
«Производительность фронтенда»?
24
Рафик, где мой трафик?
25
Ладно с фреймворком понятно, а
само приложение?
26
Полезли в код приложения
• Мало комментариев
• Жесткая связность
• Нет границы между Controller и View
27
State, BizLogicState, BizLogic State, BizLogic, Ui logic
Model
View
Child View
SubController
SubController2
Child
View
Con...
Полезли в код приложения
• Мало комментариев
• Жесткая связность
• Нет границы между Controller и View
• Publish/Subscribe...
308 событий, ~18 вызовов
31
Вопрос на засыпку
Чего обычно нет в коде приложений с жесткой
связностью и плохим разграничением зон
отвественности?
32
33
34
Полезли в код приложения
Выводы…
35
Полезли в код приложения
Выводы…
Настоящие выводы
• Очень сложный фреймворк
• Запутаный получившийся код
• Мегабайты кода
• Нельзя подключить обычных верст...
Куда направить усилия?
• нужен проще UI слой
• менее связная архитектура
• четкое разделение зон отвественности (языков,
т...
Второй вывод
«производительность фронтенда»:
Улучшаем производительность фронтенд-разработчиков
(технологии + стандарты)
П...
Процесс выбора
39
…что нам подскажет интернет?
«Хорошие художники копируют,
великие художники воруют.»
Пабло Пикассо
40
Что нам подскажет интернет?
Angular, backbone, meteor, Ember, polymer, Aurelia,
React, Vue, Mercury, Dojo, Knockback.js, C...
Github
42
Кол-во строк кода
Angular
Backbone
Dojo
React
ExtJS
Yahoo UI
Ember
Meteor
Kendo
Polymer
Knockout
0 700 000 1 400...
Конференции 2015
43
0
7,5
15
22,5
30
Кол-во докладов по фреймворкам
Angular React Ember Backbone Polymer Aurelia Meteor
Co...
Тренды
44
Тренды
45
Codeanywhere(cloud IDE)
46
Рынок вакансий
47
0
125
250
375
500
Angular React Ember Backbone ExtJS Knockout Meteor
Кол-во резюме Кол-во вакансий
Что смотрим:
• AngularJS
• Ember
• Knockout
• Backbone.js + проекты-расширения
• React + Flux
• Dojo
• ExtJS 6 =)
48
<cut />: что не подошло
• Backbone
• Ember
• Knockout
• Dojo
• ExtJS 6
49
Версия 1.*
• Хорошая модульность
• Нет единого стиля разработки
• Трудно дебажить
• Многовато «магии»
• Сложно интегрирова...
Посмотрели 2.0.0-alpha
• Аж три языка — TypeScript, Javascript и Dart.
• Вот это выглядит как то, что надо…
• …только шанс...
Не фреймворк, а UI-библиотека
• структурность
• понятный data flow, изолированность компонент
• нет какого-то магического ...
Архитектура, но не фреймворк
+ one-way data flow, синхронная обработка
+ Как приложение делится на независимые блоки с
пом...
• Кода от самого Facebook считай, почти нет.
• Посмотрели реальные фреймворки — fluxxor, DeLorean,
ReFlux.js, Este.js:
• у...
Попутно нашли…
55
Typescript
Шанс уменьшить «креативность» разработчиков разных
отделов
56
Контракты
57
Интерфейсы
58
А также
• Дженерики
• Декораторы
• Составные типы
59
В итоге?
• Вопросов стало только больше =)
• «Серебряной пули» нет. В этом плане ExtJS «держит
удар».
• Хотим фреймворк с ...
Сфокусируемся
61
Вернемся к задаче
• JS-кодеры должны писать код, верстальщики — делать
шаблоны
• Нужен проще UI слой, понятнее архитектура...
Портируем Flux
• Взяли за основу Flux+React фреймворк Este.js, как
наиболее инновационный.
• Плавно переписывали, пока за ...
Трудности
64
1. Store’ы
• Разные зоны ответственности
• Store -> область хранения данных (Store) и отдельно
логика (Controller) (сообра...
State, BizLogicState, BizLogic State, BizLogic, Ui logic
Model
View
Child View
SubController
SubController2
Child
View
Con...
67
Ui logicData BizLogic
Isolated block
Isolated block
Isolated block
Child View
Child View
View
Server API
Store
Store
St...
2. JSX
• JSX — это опять мешанина кода и HTML.
• Обратили внимание на wix-react-templates
• Написали свой похожий
68
69
Шаблон
70
JS-­‐код  шаблона
71
UI-­‐компонент
3. Переводы (i18n)
• Все Flux-фреймворки обошли эту тему стороной
72
73
Шаблон
4. Динамика
• Нет динамического создания Store’ов и View-компонент.
• Как организовать независимую работу двух одинаковых
...
Что получилось?
75
Получилось:
• Хороший ООП с интерфейсами и дженериками
• С dependency injection
• Только две внешние библиотеки — React и ...
Битва «пилотов» 77
vs.6
Битва «пилотов»
Обрезанная копия существующей админки «с нуля»:
• ExtJS 6 + TypeScript
• Flux + React + Typescript
Сложнос...
Цифры*
ExtJS6 demo Flux+React demo
PRODUCTION BUILD
JS CODE SIZE
1,45 MB 336 KB
PRODUCTION BUILD
CSS CODE SIZE
345 KB 19.9...
Переход
80
Оценка работы над UI
А что понадобится?
• 60 простых
• 15 сложных
81
82
Оценка работы над UI
• 10% = 2000 строк кода HTML+CSS+TS
• Заняло 4 дня 1 человека
83
Технология миграции
Варианты:
1. Новые проекты пишем на новом фреймворке.
2. Старый код не трогаем, новый встраиваем
«неза...
85
Спасибо!
Вопросы?
86
@ryba_xek
ryba.xek
Слайды,
предыдущие доклады:
http://averin.ru/slides/
http://slideshare.net/rybaxek...
You’ve finished this document.
Download and read it offline.
Upcoming SlideShare
Стартап: формирование технической команды
Next
Upcoming SlideShare
Стартап: формирование технической команды
Next
Download to read offline and view in fullscreen.

10

Share

Javascript-фреймворки:
 должен остаться только один

Download to read offline

Рассказ от tech-менеджера о том, как мы в Acronis выбирали фреймворк в условиях, когда любое более-менее важное технологическое решение сразу затрагивает с десяток команд, несколько сотен человек и права «случайно все сломать» нет.

В докладе пойдет речь о том, что производительность фронтенда — это больше про слаженную работу команды, про понятный и масштабируемый код, чем про сухие циферки. Но циферки тоже будут.

1) Какие у нас были проблемы с текущим фреймворком — UI, архитектура, код.
2) Как измеряли, что примерно стоит брать (исследование популярности).
3) Что рассматривали.
4) На пути к демо-проекту, какие были сложности (то, что уперли идею с Typescript, собственный компилятор шаблонов, четыре Flux-фреймворка и все плохи).
5) Два пилотных демо-проекта: цифры.
6) Оценка трудоемкости перехода.

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

Javascript-фреймворки:
 должен остаться только один

  1. 1. Javascript- фреймворки:
 должен остаться только один Сергей Аверин
  2. 2. Про что доклад Как выбирали новый веб-фреймворк 1. Немного о компании 2. Бекграунд 3. Задача 4. Исследование существующего кода 5. Выбор на что смотреть 6. Техническая оценка вариантов 7. Переделка одного из вариантов «под себя» 8. Сравнение пилотных проектов 9. Оценка затрат на внедрение 2
  3. 3. 3
  4. 4. Про компанию 4
  5. 5. Масштаб • 5 000 000 пользователей • 500 000 из них — корпоративные • 700 сотрудников в 17 разных офисах • Выпускаем много разного софта: • коробочный под Windows, • корпоративный с веб-интерфейсами, • cloud-продукты с веб-интерфейсом. 5
  6. 6. Веб Все отделы делают веб-часть по-разному 6
  7. 7. Проблема 7
  8. 8. Проблема • Много разных технологий для веб-части • Фронтенд пишут не только JS-разработчики • Нет возможности подключить к работе верстальщика • Качество кода сильно отличается • Текущие технологии устарели 8
  9. 9. Задача 9
  10. 10. Курс • Толстый клиент на JS/HTML/CSS • Единая технология во всей компании • Библиотека UI-компонентов • Возможность работать разработчикам разных уровней • Код должен быть понятен backend-разработчикам 10
  11. 11. Оценка 11
  12. 12. Что имеем? • Dojo • Сайт acronis.com — rich-client там не нужен • Angular 1.x • RoR+jQuery • ExtJS 4 12
  13. 13. Что не так с ExtJS? • Индексная страница документации содержит: 13 395 классов
  14. 14. 8 уровней наследования 14
  15. 15. класс с 201 методами 15
  16. 16. 16
  17. 17. 17
  18. 18. 18 ~1% DOM-дерева главной
  19. 19. 19 Кастомный UI компонент
  20. 20. layouting 20
  21. 21. layouting 21
  22. 22. deep in layouting code… 22
  23. 23. deep in layouting code… 23
  24. 24. Вы еще помните,
 что эта секция называется «Производительность фронтенда»? 24
  25. 25. Рафик, где мой трафик? 25
  26. 26. Ладно с фреймворком понятно, а само приложение? 26
  27. 27. Полезли в код приложения • Мало комментариев • Жесткая связность • Нет границы между Controller и View 27
  28. 28. State, BizLogicState, BizLogic State, BizLogic, Ui logic Model View Child View SubController SubController2 Child View Controller Server API М С V M+CV 28
  29. 29. Полезли в код приложения • Мало комментариев • Жесткая связность • Нет границы между Controller и View • Publish/Subscribe — вроде как правильный паттерн,
 но не работает. 29
  30. 30. 308 событий, ~18 вызовов
  31. 31. 31
  32. 32. Вопрос на засыпку Чего обычно нет в коде приложений с жесткой связностью и плохим разграничением зон отвественности? 32
  33. 33. 33
  34. 34. 34 Полезли в код приложения Выводы…
  35. 35. 35 Полезли в код приложения Выводы…
  36. 36. Настоящие выводы • Очень сложный фреймворк • Запутаный получившийся код • Мегабайты кода • Нельзя подключить обычных верстальщиков • Виноват ли фреймворк? — частично 36
  37. 37. Куда направить усилия? • нужен проще UI слой • менее связная архитектура • четкое разделение зон отвественности (языков, технологий) • больше границ и правил для программистов • и код, в котором просто разобраться среднестатистическому разработчику. 37
  38. 38. Второй вывод «производительность фронтенда»: Улучшаем производительность фронтенд-разработчиков (технологии + стандарты) Получаем производительность фронтенд-продуктов 38
  39. 39. Процесс выбора 39
  40. 40. …что нам подскажет интернет? «Хорошие художники копируют, великие художники воруют.» Пабло Пикассо 40
  41. 41. Что нам подскажет интернет? Angular, backbone, meteor, Ember, polymer, Aurelia, React, Vue, Mercury, Dojo, Knockback.js, CanJS, Mithril, Ampersand, Knockout, Flight, TroopJS, Batman, Spine, YUI, ExtJS, Google Web Toolkit,
 Kendo UI, OpenUI5, Webix, Echo3, Enyo 41
  42. 42. Github 42 Кол-во строк кода Angular Backbone Dojo React ExtJS Yahoo UI Ember Meteor Kendo Polymer Knockout 0 700 000 1 400 000
  43. 43. Конференции 2015 43 0 7,5 15 22,5 30 Кол-во докладов по фреймворкам Angular React Ember Backbone Polymer Aurelia Meteor Connect JS, US Frontporch.io, US Midwest JS, US FullStack, UK WebTech Conference, DE
  44. 44. Тренды 44
  45. 45. Тренды 45
  46. 46. Codeanywhere(cloud IDE) 46
  47. 47. Рынок вакансий 47 0 125 250 375 500 Angular React Ember Backbone ExtJS Knockout Meteor Кол-во резюме Кол-во вакансий
  48. 48. Что смотрим: • AngularJS • Ember • Knockout • Backbone.js + проекты-расширения • React + Flux • Dojo • ExtJS 6 =) 48
  49. 49. <cut />: что не подошло • Backbone • Ember • Knockout • Dojo • ExtJS 6 49
  50. 50. Версия 1.* • Хорошая модульность • Нет единого стиля разработки • Трудно дебажить • Многовато «магии» • Сложно интегрировать с новыми технологиями • Код будет несовместим с версией 2.* 50
  51. 51. Посмотрели 2.0.0-alpha • Аж три языка — TypeScript, Javascript и Dart. • Вот это выглядит как то, что надо… • …только шансов на скорый релиз нет. • …и везде в документации написано «предварительно»… …«может поменяться»… 51
  52. 52. Не фреймворк, а UI-библиотека • структурность • понятный data flow, изолированность компонент • нет какого-то магического синтаксиса (кастомных атрибутов, фильтров) • понятная и простая возможность тюнинга производительности • и даже серверный рендеринг 52
  53. 53. Архитектура, но не фреймворк + one-way data flow, синхронная обработка + Как приложение делится на независимые блоки с помощью денормализации — понятно + Единый Event Bus (Dispatcher) и уникальные события — круто. - Как обеспечивается динамика — непонятно - Смешение концепций — Store’ы и хранят данные и реализуют бизнес-логику… 53
  54. 54. • Кода от самого Facebook считай, почти нет. • Посмотрели реальные фреймворки — fluxxor, DeLorean, ReFlux.js, Este.js: • уже лучше, но все еще нет динамики • видно общий прогресс стандартизации в виде ES6, npm-модулей, изоморфности и т. д. • с разработкой веб-приложений беда… невозможно, например, создать два instance’а одного Store’а, чтобы они не воевали друг с другом. • нет интернационализации • нет примеров тестов 54
  55. 55. Попутно нашли… 55
  56. 56. Typescript Шанс уменьшить «креативность» разработчиков разных отделов 56
  57. 57. Контракты 57
  58. 58. Интерфейсы 58
  59. 59. А также • Дженерики • Декораторы • Составные типы 59
  60. 60. В итоге? • Вопросов стало только больше =) • «Серебряной пули» нет. В этом плане ExtJS «держит удар». • Хотим фреймворк с Typescript! 60
  61. 61. Сфокусируемся 61
  62. 62. Вернемся к задаче • JS-кодеры должны писать код, верстальщики — делать шаблоны • Нужен проще UI слой, понятнее архитектура, четкое разделение (языков, технологий), больше границ, правил и стандартов. • На Typescript • Не являющийся монолитным все-в-одном 62
  63. 63. Портируем Flux • Взяли за основу Flux+React фреймворк Este.js, как наиболее инновационный. • Плавно переписывали, пока за три захода от него не осталось ничего, кроме конфига сборщика. 63
  64. 64. Трудности 64
  65. 65. 1. Store’ы • Разные зоны ответственности • Store -> область хранения данных (Store) и отдельно логика (Controller) (сообразно тому, куда идет развитие Flux) 65
  66. 66. State, BizLogicState, BizLogic State, BizLogic, Ui logic Model View Child View SubController SubController2 Child View Controller Server API М С V Примерно как было 66
  67. 67. 67 Ui logicData BizLogic Isolated block Isolated block Isolated block Child View Child View View Server API Store Store Store М С V ViewView Child View Child View Dispatcher Controller SubController2 SubController Action Примерно как станет
  68. 68. 2. JSX • JSX — это опять мешанина кода и HTML. • Обратили внимание на wix-react-templates • Написали свой похожий 68
  69. 69. 69 Шаблон
  70. 70. 70 JS-­‐код  шаблона
  71. 71. 71 UI-­‐компонент
  72. 72. 3. Переводы (i18n) • Все Flux-фреймворки обошли эту тему стороной 72
  73. 73. 73 Шаблон
  74. 74. 4. Динамика • Нет динамического создания Store’ов и View-компонент. • Как организовать независимую работу двух одинаковых блоков на одной странице? 74
  75. 75. Что получилось? 75
  76. 76. Получилось: • Хороший ООП с интерфейсами и дженериками • С dependency injection • Только две внешние библиотеки — React и lodash • Можно поменять что угодно • С нормальной сборкой 76
  77. 77. Битва «пилотов» 77 vs.6
  78. 78. Битва «пилотов» Обрезанная копия существующей админки «с нуля»: • ExtJS 6 + TypeScript • Flux + React + Typescript Сложности: • анимации • кастомный скроллбар • интерфейс меняется для узких экранов • мобильная версия • JSON-REST API с авторизацией 78
  79. 79. Цифры* ExtJS6 demo Flux+React demo PRODUCTION BUILD JS CODE SIZE 1,45 MB 336 KB PRODUCTION BUILD CSS CODE SIZE 345 KB 19.9 kB # OF HTML DOM NODES 841 301 LOAD TIME (PRODUCTION, NO CACHE) 1.54 s 0,59 s LOAD TIME (PRODUCTION, CACHE) 1.42 s 0,58 s TIME UNTIL FIRST API REQUEST 0,405 s 0,168 s JS INIT TIME (GOOGLE CHROME) 0,345 s 0,158 s PRODUCTION BUILD MEMORY USAGE (GOOGLE CHROME) 24.2 Mb 11.8 Mb * В реальном проекте разница в объемах кода и скорости инициализации будет меньше 79
  80. 80. Переход 80
  81. 81. Оценка работы над UI А что понадобится? • 60 простых • 15 сложных 81
  82. 82. 82
  83. 83. Оценка работы над UI • 10% = 2000 строк кода HTML+CSS+TS • Заняло 4 дня 1 человека 83
  84. 84. Технология миграции Варианты: 1. Новые проекты пишем на новом фреймворке. 2. Старый код не трогаем, новый встраиваем «независимыми блоками» — как iframe или кастомный UI-компонент для ExtJS. 3. При модификации старого кода — или правь, как есть, или портируй. 84
  85. 85. 85
  86. 86. Спасибо! Вопросы? 86 @ryba_xek ryba.xek Слайды, предыдущие доклады: http://averin.ru/slides/ http://slideshare.net/rybaxeks@averin.ru
  • ViktorLobanov1

    Nov. 22, 2015
  • ViktorLobanov

    Nov. 21, 2015
  • volyihin

    Nov. 15, 2015
  • vital76

    Nov. 9, 2015
  • AlexanderPetrov1

    Nov. 6, 2015
  • mesilov

    Nov. 5, 2015
  • yurikhrustalev

    Nov. 5, 2015
  • AlexanderMikhalev

    Nov. 5, 2015
  • MikhailUsachev

    Nov. 5, 2015
  • ssuser5a2151

    Nov. 4, 2015

Рассказ от tech-менеджера о том, как мы в Acronis выбирали фреймворк в условиях, когда любое более-менее важное технологическое решение сразу затрагивает с десяток команд, несколько сотен человек и права «случайно все сломать» нет. В докладе пойдет речь о том, что производительность фронтенда — это больше про слаженную работу команды, про понятный и масштабируемый код, чем про сухие циферки. Но циферки тоже будут. 1) Какие у нас были проблемы с текущим фреймворком — UI, архитектура, код. 2) Как измеряли, что примерно стоит брать (исследование популярности). 3) Что рассматривали. 4) На пути к демо-проекту, какие были сложности (то, что уперли идею с Typescript, собственный компилятор шаблонов, четыре Flux-фреймворка и все плохи). 5) Два пилотных демо-проекта: цифры. 6) Оценка трудоемкости перехода.

Views

Total views

1,683

On Slideshare

0

From embeds

0

Number of embeds

8

Actions

Downloads

11

Shares

0

Comments

0

Likes

10

×