Не так давно мне представилась возможность выступить на конференции ФФКонф с сообщением «Вам следует использовать , это лучшее!" И основные мысли я решил изложить в публикации, в надежде, что это спровоцирует более широкую дискуссию в профессиональном сообществе о «стоимости» современных фреймворков на мобильных устройствах.
Для тех, кто хочет обратиться к оригиналу моего выступления, вот видео: и слайды презентации: peakerdeck.com/paullewis/framework-here-its-the-bestestest .
Преимущества фреймворков В начале года я писал о зависимости Производительность фреймворка React от увеличения размера дерева, с которым оно работает (TL;DR: чем оно больше, тем больше вычислительной мощности используется).
На эту публикацию я получил довольно много откликов, варьирующихся в очень широком диапазоне – от благодарных и конструктивных до резко отрицательных.
Благодаря этому отзыву я собрал дополнительную информацию, которая в большей или меньшей степени применима ко всем фреймворкам:
- Фреймворки хороши и просты в использовании.
Я не знаю ни одного разработчика, который бы искал более сложные и скучные пути.
Да, эргономика и комфорт, безусловно, важны.
- Фреймворки позволяют быстрее создавать MVP. Это особенно важно для небольших, неопытных компаний и организаций.
Быстрый старт может сыграть решающую роль в успехе продукта.
- Фреймворки помогают обойти особенности и ошибки платформы.
Сегодня это уже не так актуально, поскольку в последние годы браузеры стали гораздо более совместимыми со стандартами.
Но помните, какой это была боль во времена IE5 и 6, а также более ранних версий Firefox, Safari и Chrome.
- Если я знаю [вставьте название фреймворка], то мне за это заплатят. Ваше свободное владение новейшими и лучшими платформами может иметь большое значение при поиске работы.
Это коллективное мнение можно сформулировать так: «Если мне будет легче жить, я смогу сделать что-то лучше для пользователей».
Звучит как хорошая идея.
Но мне кажется, что эта позиция упускает многие важные моменты.
Комфорт разработчика и потребности пользователей Нельзя забывать, что у пользователей есть свои потребности.
В частности, это:
- Веб-сайты и приложения должны загружаться быстро.
- Их интерфейсы должны работать плавно.
- Они не должны быть слишком «тяжелыми» для телефона.
- Они не должны «ломаться».
- Они должны иметь необходимый набор функций.
А поскольку фреймворки не бесплатны в плане использования ресурсов, все это нужно как-то увязать друг с другом, хотим мы того или нет. Небольшое отступление Здесь я предлагаю исключить из рассмотрения отдельные библиотеки.
Ведь если с ними возникнут проблемы, их можно заменить на другие.
Не нравится, как библиотека устанавливает формат даты? Просто подключите еще один.
Но изменить рамки не так-то просто.
Это часто требует перестройки всего приложения.
Кроме того, фреймворки занимают гораздо больше места и гораздо шире и глубже задействуют приложения.
«Стоимость» кода Каждая разработка имеет свою «цену».
Но я считаю, что каждый фреймворк вносит свой уникальный вклад в общую «стоимость».
Тот волшебный момент, когда фреймворк говорит вам о чем-то нерекомендованном (недопустимом).
Java, вероятно, сгенерировал сообщение.
Странный.
- Изучение.
Приходится тратить время на изучение фреймворка: как писать для него «идиоматический» код, какие шаблоны, практики и методы выполнения различных операций здесь используются.
Никакой разницы по сравнению с самой веб-платформой.
Там тоже нельзя просто взять и начать пользоваться; вам придется решать одну проблему за другой.
- Учиться еще раз.
Однажды во время разработки вы увидите в консоли предупреждение о чем-то недопустимом, какой-то устаревшей операции и предложение обновить код. В таких случаях обычно приходится разбираться, что в ваших действиях не понравилось новой версии фреймворка.
А это может повлечь за собой обновление проектов, выпущенных более старыми версиями.
- Отладка.
Как и любое программное обеспечение, фреймворки содержат ошибки.
К этому нужно быть готовым, даже если вы пишете свою версию.
А сложность отладки фреймворка обычно находится в диапазоне от «сложно» до «невозможно».
Если вы обнаружите проблему, вы можете попробовать сделать патч самостоятельно, пока ошибка не будет официально исправлена в следующей версии фреймворка.
- Время.
Сколько времени займет загрузка того, что было отправлено по проводу?
- Пропускная способность.
Какая ширина канала нужна для работы?
- Ресурсы процессора (батареи).
Насколько интенсивно используется процессор? Коррелируют ли вычисления и потребление батареи друг с другом?
- Частота кадров.
Как часто обновляется экран (ведь Пользователям нравится плавность интерфейса.
)?
- Объем памяти.
Сколько памяти потребляет ваш продукт? Приходится ли выгружать другие приложения из памяти? Может быть, даже ценой их падения?
Возможно, совместными усилиями нам удастся выяснить, как лучше всего достичь компромисса по выбранным пунктам.
Начну с начального времени загрузки фреймворков на смартфонах.
Для тестирования я выбрал TodoMVC. Для меня это MVP веб-приложение, и с точки зрения пользователя все варианты функционала идентичны.
Бутстрап
Параметрами, которые я измерял, были время, пропускная способность и загрузка процессора.
Тесты проводились на Nexus 5 и iPhone 5S. 
Я решил измерить, сколько времени занимает каждый фреймворк:
- для оценки и выполнения полезной нагрузки JavaScript,
- обработка и размещение первичного набора данных в модели.
Методология
Чтобы загрузить страницы в Нексус 5 Я использовал WebPagetest. Для каждого запуска создавался файл временной шкалы, который затем обрабатывался в Большая Буровая Установка .Я сам захватил и обработал результаты с iPhone, поскольку профилирование JavaScript в Safari, похоже, не поддерживает экспорт трассировок и временных шкал.
Использование большой установки
Кстати, именно поэтому я создал Big Rig — я хотел, чтобы всем нам было проще обрабатывать такого рода данные.
Игра в тест
Если вы хотите протестировать себя, например, на устройстве под управлением Chrome, то следуйте такому алгоритму:- Установите интерфейс командной строки Big Rig: npm install -g bigrig.
- Идти к Веб-страницатест .
- Выберите Даллес в качестве своего местоположения.
- Выберите Nexus 5 – Chrome (или Beta/Dev) в качестве браузера.
- На вкладке настроек Chrome установите флажок «Захватить временную шкалу инструментов разработчика».
- Запустите тест.
- Загрузите файл временной шкалы слева от результатов.
- Запустите bigrig --file /path/to/timeline.json --pretty-print.
| Рамки | Размер | Время загрузки Nexus 5 1, 3 | Время загрузки iPhone 5S 2, 3 |
|---|---|---|---|
| Полимер v1.1.4 | 41 КБ 5 | 409 мс | 233 мс |
| Полимер v1.2.2 | 47 КБ 5 | 155 мс | 232 мс |
| AngularJS v1.4.3 | 324 КБ | 518 мс | 307 мс |
| React v0.13.3 [JSX не конвертирован] | 311 КБ | 1,201 мс | 1,463 мс |
| React v0.13.3 [JSX преобразован с помощью Babel] 4 | 162 КБ | 509 мс | 282 мс |
| React v0.13.3 [JSX преобразован; производственная сборка] 4, 6 | 160 КБ | 174 мс | 118 мс |
| Backbone v1.2.2 [включая jQuery и Underscore] | 139 КБ | 248 мс | 168 мс |
| Эмбер v1.10.0-бета.
3 |
580 КБ | 1,992 мс | 1440 мс |
| Ваниль | 16 КБ | 50 мс | 33 мс |
- Тесты проводились на Nexus 5 под управлением Chrome 47.
- Тесты проводились на iPhone 5S с Safari 9.
- Начальная загрузка включает обработку исходных данных списка задач.
- JSX Transformer вырезан.
Файлы JSX, конвертированные с помощью Babel.
- Исключая веб-компоненты Polyfill (12 КБ).
- Была использована минимизированная производственная сборка React.
React по скорости сравним с Polymer, но для меня есть вопросы по его масштабируемости .
Для полной ясности ситуации отмечу:
- В случае с React я конвертировал JSX сам, поскольку TodoMVC этого не делает. Вместо этого он включает библиотеку JSX Transformer. Чтобы убедиться, что выполнение этой библиотеки не повлияло на результат, я вырезал ее и протестировал полученную «кастомную» версию.
К сожалению, в данном случае я использовал неминифицированную версию React, поэтому мне пришлось протестировать третий вариант.
- Результаты, представленные в таблице, не включают продолжительность передачи данных.
Я измерял только начальное время загрузки фреймворка в JavaScript, вплоть до окончательного рендеринга интерфейса.
Обратите внимание, что некоторые фреймворки в TodoMVC не минифицированы.
При желании вы можете изучить обсуждение объёмов передачи данных на сайте Filament Group .
Возможные возражения
Вероятно, некоторые аспекты тестирования могут вызвать возражения, на которые необходимо ответить:- «TodoMVC не является идиоматическим» .
Я проверил это заявление.
Насколько я понимаю, каждая реализация идиоматична.
А когда это не так, фреймворк анализирует необходимые вычислительные ресурсы для каждого файла.
- «TodoMVC не отражает мой сценарий» .
Может быть.
Но готов поспорить, что в вашем случае «стоимость» даже выше, чем у TodoMVC. Пол Айриш недавно исследовал производительность мобильной версии сайта Reddit. и обнаружил, среди прочего, что на мобильных устройствах компоненты React загружаются 22 секунды!
- «У наших пользователей нет Nexus 5/iPhone 5S» .
Это тоже вполне реально.
У меня была возможность провести тесты на хороших устройствах, и я могу представить, что у многих пользователей нет дорогих и мощных смартфонов.
Так что на самом деле ситуация со временем загрузки еще хуже.
- «В следующей версии ситуация будет лучше.
” .
Я признаю это.
Но вряд ли это поможет тем, кто уже использует ваши продукты на предыдущих версиях фреймворка.
Это должно быть полностью ваше собственное решение.
Существует миллион причин, по которым вам отчаянно нужен фреймворк.
Вот мои собственные мысли по этому поводу:
- Фреймворки упрощают реализацию идей и концепций.
Именно благодаря им можно понять, какие подходы работают, а какие нет. Это стимулирует процесс совершенствования программных продуктов на уровне платформы.
С этой точки зрения фреймворки кажутся мне своего рода испытательными площадками, на которых можно тестировать будущие инновации внутри платформ.
С их помощью вы сможете понять, какие возможности появятся у мобильного Интернета в ближайшем будущем.
- Фреймворки — это инверсия контроля.
Выше я исключил библиотеки из рассмотрения, поскольку их можно легко переключать.
Платформы контролируют жизненный цикл приложения, предоставляя вам точку входа для начала работы над кодом.
Да, вы несете ответственность за сам код, но вы не полностью контролируете ситуацию.
- Фреймворки стоят дорого при использовании на мобильных устройствах.
По крайней мере, по сравнению с базовыми языками.
А с моей точки зрения дороги неприемлемы.
Но у каждого свое представление о пределах дозволенного.
Платформы приходят и уходят, как приливы и отливы в Интернете, помогая реализовывать и совершенствовать идеи и шаблоны.
Но если вы однажды обнаружите, что ваш любимый фреймворк больше не работает или не исправлен какой-то важный баг, то умение разобраться в устройстве платформы окажет вам неоценимую услугу.
Нижняя граница Я когда-то писал, что комфорт разработчика менее важен, чем потребности пользователей.
Я все еще верю в это.
Хотя меня также привлекает легкая жизнь, я не хочу создавать плохо работающие продукты.
И я не хочу, чтобы пользователи платили за них высокую «цену».
Что меня сейчас беспокоит, так это начальная скорость загрузки фреймворков на мобильных устройствах.
Но это только первый шаг.
Есть и другие метрики: использование памяти, длительная загрузка процессора, частота кадров.
В общем, нужно искать решения, менее затратные для пользователей.
Если нам удастся реализовать быстрозагружающиеся фреймворки, которые потребляют мало памяти и работают с большой частотой кадров, а также обеспечивают комфортную разработку, то это будет идеально.
Но до тех пор я бы предпочел использовать без фреймворков, по крайней мере, в мобильном сегменте.
Теги: #Разработка веб-сайтов #Тестирование веб-сервисов #Тестирование мобильных приложений #JavaScript #производительность #веб-разработка
-
Zune Отстает От Конкурентов
19 Oct, 24 -
Выпущен Twitter Bootstrap 3 Rc 1
19 Oct, 24 -
Скрытые Файлы В Mac Osx
19 Oct, 24 -
Личкрафт 0.3.0
19 Oct, 24 -
Хромбуки В России
19 Oct, 24
