Выбор JS-фреймоврка для крупного проекта

Аверин Сергей, Acronis ПРО ЧТО ДОКЛАД

• Как выбирали новый веб-фреймворк – Немного о компании – Бекграунд – Задача – Исследование существующего кода – Выбор на что смотреть – Техническая оценка вариантов – Переделка одного из вариантов «под себя» – Сравнение пилотных проектов – Оценка затрат на внедрение

2 3 Про компанию

4 МАСШТАБ

• 5 000 000 пользователей • 500 000 из них — корпоративные • 700 сотрудников в 17 разных офисах • Выпускаем много разного софта: – коробочный под Windows, – корпоративный с веб-интерфейсами, – cloud-продукты с веб-интерфейсом.

5 ВЕБ Все отделы делают веб-часть по-разному

6 Проблема

7 ПРОБЛЕМА

• Много разных технологий для веб-части • Фронтенд пишут не только JS-разработчики • Нет возможности подключить к работе верстальщика • Качество кода сильно отличается • Текущие технологии устарели

8 Задача

9 КУРС

• Толстый клиент на JS/HTML/CSS • Единая технология во всей компании • Библиотека UI-компонентов • Возможность работать разработчикам разных уровней • Код должен быть понятен backend-разработчикам

10 Оценка

11 ЧТО ИМЕЕМ?

• Dojo • Сайт acronis.com — rich-client там не нужен • 1.x • RoR+jQuery • ExtJS 4

12 ЧТО НЕ ТАК С EXTJS? Индексная страница документации содержит:

395 классов

13 8 уровней наследования

14 класс с 201 методами

15 16 17 ~1% DOM-дерева главной

18 Кастомный UI компонент

19 layouting

20 layouting

21 deep in layouting code…

22 deep in layouting code…

23 Рафик, где мой трафик?

24 Ладно с фреймворком понятно, а само приложение?

25 ПОЛЕЗЛИ В КОД ПРИЛОЖЕНИЯ

• Мало комментариев • Жесткая связность • Нет границы между Controller и View

26 М С V State, BizLogic State, BizLogic State, BizLogic, Ui logic

Server API View

Model Controller Child View Child View SubController

SubController2 M+CV

27 ПОЛЕЗЛИ В КОД ПРИЛОЖЕНИЯ

• Мало комментариев • Жесткая связность • Нет границы между Controller и View • Publish/Subscribe — вроде как правильный паттерн, но не работает.

28 29 30 ВОПРОС НА ЗАСЫПКУ

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

31 32 Выводы…

33 Выводы… 34 НАСТОЯЩИЕ ВЫВОДЫ

• Очень сложный фреймворк • Запутаный получившийся код • Мегабайты кода • Нельзя подключить обычных верстальщиков • Виноват ли фреймворк? — частично

35 КУДА НАПРАВИТЬ УСИЛИЯ?

• нужен проще UI слой • менее связная архитектура • четкое разделение зон отвественности (языков, технологий) • больше границ и правил для программистов • и код, в котором просто разобраться среднестатистическому разработчику.

36 Процесс выбора

37 «Хорошие художники копируют, великие художники воруют.» Пабло Пикассо

…ЧТО НАМ ПОДСКАЖЕТ ИНТЕРНЕТ?

38 ЧТО НАМ ПОДСКАЖЕТ ИНТЕРНЕТ?

Angular, backbone, , Ember, polymer, Aurelia, React, Vue, Mercury, Dojo, Knockback.js, CanJS, Mithril, Ampersand, , Flight, TroopJS, Batman, Spine, YUI, ExtJS, , Kendo UI, OpenUI5, Webix, Echo3, Enyo

39 Кол-во строк кода GITHUB

Angular

Backbone

Dojo

React

ExtJS

Yahoo UI

Ember

Meteor

Kendo

Polymer

Knockout

0 700 000 1 400 000 40 КОНФЕРЕНЦИИ 2015

Connect JS, US Frontporch.io, US Midwest JS, US FullStack, UK WebTech Conference, DE 30

22,5

15

7,5

0 Angular React Ember Backbone Polymer Aurelia Meteor Кол-во докладов по фреймворкам

41 ТРЕНДЫ

42 ТРЕНДЫ

43 CODEANYWHERE(CLOUD IDE)

44 РЫНОК ВАКАНСИЙ

500

375

250

125

0 Angular React Ember Backbone ExtJS Knockout Meteor

Кол-во резюме Кол-во вакансий

45 ЧТО СМОТРИМ:

• AngularJS • Ember • Knockout • Backbone.js + проекты-расширения • React + Flux • Dojo • ExtJS 6 =)

46 : ЧТО НЕ ПОДОШЛО

• Backbone • Ember • Knockout • Dojo • ExtJS 6

47 • Версия 1.* • Хорошая модульность • Нет единого стиля разработки • Трудно дебажить • Многовато «магии» • Сложно интегрировать с новыми технологиями • Код будет несовместим с версией 2.*

48 Посмотрели 2.* • Аж три языка — TypeScript, Javascript и Dart. • Вот это выглядит как то, что надо. • Сильно лучше версии 1.* • Окей, надо разбираться…

49 + Понятный data flow + Структурность, понятный data flow, изолированность компонент + Когда-то в будущем будет популярным мейн- стримом - Собственные шаблоны с кодом - Все приложение работает как дерево компонентов, как таковых Controller’ов нет - Непонятно, когда же оно зарелизится

50 + Не фреймворк, а UI-библиотека + структурность + понятный data flow, изолированность компонент + нет какого-то магического синтаксиса (кастомных атрибутов, фильтров) + понятная и простая возможность тюнинга производительности ? и даже серверный рендеринг

51 + Архитектура, но не фреймворк + one-way data flow, синхронная обработка + Как приложение делится на независимые блоки с помощью денормализации — понятно + Единый Event Bus (Dispatcher) и уникальные события — круто. - Как обеспечивается динамика — непонятно - Смешение концепций — Store’ы и хранят данные и реализуют бизнес-логику…

52 • Кода от самого Facebook считай, почти нет. • Посмотрели реальные фреймворки — fluxxor, DeLorean, ReFlux.js, Este.js: – уже лучше, но все еще нет динамики – видно общий прогресс стандартизации в виде ES6, npm- модулей, изоморфности и т. д. – с разработкой веб-приложений беда… невозможно, например, создать два instance’а одного Store’а, чтобы они не воевали друг с другом. – нет интернационализации – нет примеров тестов

53 Попутно прониклись Typescript

54 TYPESCRIPT

Шанс уменьшить «креативность» разработчиков разных отделов

55 КОНТРАКТЫ

56 ИНТЕРФЕЙСЫ

Стандартизирует код + клей между разными частями приложения

57 А ТАКЖЕ

• Дженерики • Декораторы • Составные типы

58 В ИТОГЕ?

• Вопросов стало только больше =) • «Серебряной пули» нет. В этом плане ExtJS «держит удар». • Хотим фреймворк с Typescript!

59 Сфокусируемся

60 ВЕРНЕМСЯ К ЗАДАЧЕ

• JS-кодеры должны писать код, верстальщики — делать шаблоны • Нужен проще UI слой, понятнее архитектура, четкое разделение (языков, технологий), больше границ, правил и стандартов. • На Typescript • Не являющийся монолитным монстром все-в-одном

61 ПОРТИРУЕМ FLUX

• Взяли за основу Flux+React фреймворк Este.js, как наиболее инновационный. • Плавно переписывали, пока за три захода от него не осталось ничего, кроме конфига сборщика.

62 Трудности

63 1. STORE’Ы

• Разные зоны ответственности • Store -> область хранения данных (Store) и отдельно логика (Controller) (сообразно тому, куда идет развитие Flux)

64 М С V State, BizLogic State, BizLogic State, BizLogic, Ui logic

Server API View

Model Controller Child View Child View SubController

SubController2

Примерно как было 65 М С V Dispatcher

Server API Action

Store Controller ViewViewView Isolated block

Store SubController ChildChild ViewView Isolated block

Store SubController2 ChildChild ViewView Isolated block Data BizLogic Ui logic Примерно как станет 66 2. JSX

• JSX — это опять мешанина кода и HTML. • Обратили внимание на wix-react-templates • Написали свой похожий

67 Шаблон

68 JS-код шаблона

69 UI-компонент

70 2. JSX

• Появился TSX • Второй вариант — ограничить применение кода в шаблонах, создав свои теги в TSX (это JSX в Typesript)

71 3. ДИНАМИКА

• Нет динамического создания Store’ов и View-компонент. • Как организовать независимую работу двух одинаковых блоков на одной странице?

72 Что получилось?

73 ПОЛУЧИЛОСЬ:

• Хороший ООП с интерфейсами и дженериками • С dependency injection • Только две внешние библиотеки — React и lodash • Можно поменять что угодно • С нормальной сборкой

74 6 vs.

Битва «пилотов»

75 БИТВА «ПИЛОТОВ»

• Обрезанная копия существующей админки «с нуля»: – ExtJS 6 + TypeScript – Flux + React + Typescript

• Сложности: – анимации – кастомный скроллбар – интерфейс меняется для узких экранов – мобильная версия – JSON-REST API с авторизацией

76 ЦИФРЫ*

ExtJS6 demo Flux+React demo

PRODUCTION BUILD 1,45 MB 336 KB JS CODE SIZE

PRODUCTION BUILD 345 KB 19.9 kB CSS CODE SIZE

# OF HTML DOM NODES 841 301

LOAD TIME 1.54 s 0,59 s (PRODUCTION, NO CACHE)

LOAD TIME 1.42 s 0,58 s (PRODUCTION, CACHE)

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 24.2 Mb 11.8 Mb (GOOGLE CHROME)

* В реальном проекте разница в объемах кода и скорости инициализации будет меньше 77 ПЛАНЫ • Изучаем 2.0 beta • Запиливаем первый боевой мини-проект, выбираем, что лучше

78 Переход

79 ТЕХНОЛОГИЯ МИГРАЦИИ

• Варианты: – Новые проекты пишем на новом стеке. – Старый код не трогаем, новый встраиваем целыми страницами, как iframe. – При модификации старого кода — или правь, как есть, или портируй.

80 81 СПАСИБО! ВОПРОСЫ?

Слайды, @ryba_xek предыдущие доклады: ryba.xek http://averin.ru/slides/ [email protected] http://slideshare.net/rybaxek

82