company_banner
21 декабря 2015 в 17:24

Цена использования фреймворков перевод

Не так давно мне довелось выступать на конференции FFConf с докладом «Вам следует использовать <впишите нужную библиотеку/фреймворк>, это самое лучшее!». И основные мысли я решил изложить в публикации, в надежде, что это спровоцирует в профессиональной среде более широкую дискуссию о «стоимости» современных фреймворков на мобильных устройствах.

Для желающих обратиться к оригиналу моего выступления вот видео:



и слайды презентации: speakerdeck.com/paullewis/framework-here-its-the-bestestest.

Преимущества фреймворков


В начале года я писал о зависимости производительности фреймворка React от увеличения размера дерева, которым он оперирует (TL;DR: чем оно крупнее, тем больше задействуется вычислительных мощностей). Я получил немало откликов на эту публикацию, варьирующихся в очень широком диапазоне — от признательных и конструктивных до ярко негативных. Благодаря этой обратной связи я собрал дополнительные сведения, которые в большей или меньшей степени можно отнести ко всем фреймворкам:
  • Фреймворки приятны и удобны в использовании. Я не знаю ни одного разработчика, который искал бы пути потруднее и поскучнее. Да, эргономика и комфорт однозначно важны.
  • Фреймворки позволяют быстрее создавать MVP. Это особенно важно для небольших, малоопытных компаний и организаций. Быстрый старт может сыграть определяющую роль в успехе продукта.
  • Фреймворки помогают обходить особенности и баги платформы. Сегодня это уже не столь актуально, поскольку в последние годы браузеры стали куда больше соответствовать стандартам. Но вспомните, какая это была боль во времена IE5 и 6, а также ранних версий Firefox, Safari и Chrome.
  • Если я знаю [вставьте название фреймворка], значит, мне за это будут платить. Ваше владение новинками и лучшими фреймворками может сыграть большую роль при поиске работы.

Причём важнейшим фактором оказалось удобство использования — явно или неявно его отметило большинство разработчиков. Это собирательное мнение можно сформулировать так: «Если мне будет проще жить, я смогу сделать для пользователей кое-что получше». Вроде бы звучит неплохо. Но, как мне кажется, при такой позиции из виду упускается много важных моментов.

Комфорт разработчика и нужды пользователя


Нельзя забывать, что у пользователей есть свои нужды. В частности, такие:
  • Сайты и приложения должны загружаться быстро.
  • Их интерфейсы должны работать плавно.
  • Они не должны быть слишком «тяжёлыми» для телефона.
  • Они не должны «ломаться».
  • В них должен быть необходимый набор функций.

Возникает неувязка: с одной стороны — удобство и комфорт разработчиков, с другой — пользовательские нужды. А поскольку фреймворки не бесплатны в плане использования ресурсов, то всё это необходимо как-то увязать друг с другом, нравится нам это или нет.

Небольшое отступление


Здесь я предлагаю исключить из рассмотрения отдельные библиотеки. Ведь если с ними возникают какие-то проблемы, то их можно заменить другими. Не нравится, как библиотека задаёт формат даты? Просто подключи ещё какую-нибудь. А вот сменить фреймворк не так просто. Зачастую это требует пересборки всего приложения. К тому же фреймворки занимают куда больше места и вовлечены в приложения гораздо шире и глубже.

«Стоимость» кода


У каждой разработки есть своя «цена». Но я считаю, что каждый фреймворк вносит свой уникальный вклад в общую «стоимость».

image

Тот волшебный момент, когда фреймворк сообщает тебе о чём-то нерекомендуемом (недопустимом). Вероятно, сообщение выдала Java. Странно.

  • Изучение. Вам приходится тратить время на изучение фреймворка: как писать под него «идиоматический» код, какие здесь используются шаблоны, практики и способы выполнения разных операций. Никакой разницы по сравнению с самой веб-платформой. Там тоже нельзя просто взять и начать использовать, приходится решать одну проблему за другой.
  • Снова изучать. Однажды в ходе разработки вы увидите в консоли предупреждение о чём-то недопустимом, какой-то устаревшей операции и предложение обновить код. В таких случаях обычно приходится вычислять, что же в ваших действиях не понравилось новой версии фреймворка. И это может повлечь за собой обновление проектов, выпущенных со старыми версиями.
  • Отладка. Как и любое ПО, фреймворки содержат баги. К этому нужно быть готовым, даже если вы напишете собственный вариант. А сложность отладки фреймворка обычно попадает в диапазон от «трудно» до «невозможно». Обнаружив какую-то проблему, вы можете попытаться сваять патч своими руками, пока баг не будет официально пофиксен в очередной версии фреймворка.

Пользователи тоже «платят» свою цену:
  • Время. Сколько времени займёт загрузка того, что переслали по проводам?
  • Полоса пропускания. Какая ширина канала нужна для работы?
  • Ресурсы процессора (аккумулятора). Насколько интенсивно используется процессор? Коррелируют ли друг с другом потребление вычислительных ресурсов и заряда аккумулятора?
  • Частота кадров. Как часто обновляется экран (ведь пользователям нравится плавность работы интерфейса)?
  • Память. Сколько памяти потребляет ваш продукт? Приходится ли выгружать из памяти другие приложения? Может быть, даже ценой их падения?

Данные на стол


Учитывая всё сказанное, я предлагаю обсудить измерение некоторых из этих стоимостей. Возможно, общими усилиями нам удастся придумать, как лучше всего достигнуть компромисса по выбранным моментам. Начну со времени начальной загрузки фреймворков на смартфонах. Для тестирования я выбрал TodoMVC. Для меня это MVP веб-приложение, а с точки зрения пользователя все варианты функциональности получаются идентичными.

image

Начальная загрузка


Я измерял следующие параметры: время, полосу пропускания и использование ЦПУ. Тесты проводились на Nexus 5 и iPhone 5S.

image

Я решил измерить, сколько времени уходит у каждого фреймворка:
  • на оценку и исполнение полезной JavaScript-нагрузки,
  • обработку и помещение в модель первичного набора данных.

Стоимость применения стилей, макетов, заливки и прочего я игнорировал, поскольку она не должна сильно меняться в разных реализациях TodoMVC. Также я не измерял продолжительность передачи данных.

Методология


Для загрузки страниц на Nexus 5 я применял WebPagetest. Для каждого прогона создавался таймлайн-файл, который затем обрабатывался в Big Rig. Результаты с iPhone я снял и обработал самостоятельно, поскольку профилирование JavaScript в Safari, судя по всему, не поддерживает экспорт трассировок и таймлайнов.

image

Использование Big Rig

Между прочим, поэтому я и создал Big Rig — хотелось облегчить всем нам обработку данных подобного рода.

Воспроизведение теста


Если вы хотите протестировать самостоятельно, например на устройстве с запущенным Chrome, то следуйте этому алгоритму:
  • Установите Big Rig CLI: npm install -g bigrig.
  • Зайдите на WebPagetest.
  • В качестве своего местоположения выберите Даллес (Dulles).
  • В качестве браузера выберите Nexus 5 — Chrome (или Beta/Dev).
  • На закладке с настройками Chrome поставьте галочку «Capture Dev Tools Timeline».
  • Запустите тест.
  • Загрузите таймлайн-файл слева от результатов.
  • Запустите bigrig --file /path/to/timeline.json --pretty-print.

Вот пример того, как это делаю я:



Результаты


Мною получены такие данные:
Фреймворк Размер Время начальной загрузки Nexus 51, 3 Время начальной загрузки iPhone 5S2, 3
Polymer v1.1.4 41 Кб5 409 мс 233 мс
Polymer 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 преобразован; production-сборка]4, 6 160 Кб 174 мс 118 мс
Backbone v1.2.2 [включая jQuery и Underscore] 139 Кб 248 мс 168 мс
Ember v1.10.0-beta.3 580 Кб 1,992 мс 1,440 мс
Vanilla 16 Кб 50 мс 33 мс

Примечания:
  1. Тесты выполнены на Nexus 5 с запущенным Chrome 47.
  2. Тесты выполнены на iPhone 5S с запущенным Safari 9.
  3. Начальная загрузка включает в себя обработку данных первичного списка задач.
  4. Вырезана JSX Transformer. JSX-файлы преобразованы с помощью Babel.
  5. За исключением Web Components Polyfill (12 Кб).
  6. Использована минифицированная production-сборка React.

С моей точки зрения, выводы однозначны: на мобильных устройствах использование фреймворков сопряжено с серьёзным ростом нагрузки, особенно в сравнении с написанием обычного JavaScript. Наилучшие результаты показал Polymer 1.2.2, но даже он оказался в три раза медленнее «ванильки». React по скорости сравним с Polymer, но у меня есть вопросы относительно его масштабируемости.

Чтобы уж совсем прояснить ситуацию, отмечу:
  • В случае с React я самостоятельно преобразовывал JSX, поскольку TodoMVC этого не делает. Вместо этого в него включена библиотека JSX Transformer. Чтобы выполнение этой библиотеки не влияло на результат, я её выпилил и протестировал получившуюся «кастомную» версию. К сожалению, в этом случае я использовал не минифицированную версию React, поэтому пришлось тестировать третий вариант.
  • Представленные в таблице результаты не включают в себя продолжительность передачи данных. Я измерял только время начальной загрузки фреймворка в JavaScript, вплоть до финальной отрисовки интерфейса. Обратите внимание, что некоторые фреймворки в TodoMVC не минифицированы. Если у вас есть желание, можете изучить дискуссию относительно объёмов передачи данных на сайте Filament Group.

Возможные возражения


Вероятно, какие-то моменты проведённого тестирования могут вызвать возражения, на которые необходимо дать ответ:
  • «TodoMVC не идиоматичен». Я проверял это утверждение. Насколько я понимаю, каждая реализация является идиоматичной. А когда это не так, фреймворк анализирует необходимые вычислительные ресурсы для каждого файла.
  • «TodoMVC не отражает мои сценарий». Возможно. Но готов поспорить, что в вашем случае «стоимость» ещё выше, чем у TodoMVC. Пол Айриш не так давно исследовал производительность мобильной версии сайта Reddit и обнаружил, помимо прочего, что на мобильных устройствах загрузка компонентов React занимает 22 секунды!
  • «У наших пользователей нет Nexus 5 / iPhone 5S». Это тоже вполне реально. У меня была возможность провести тесты на хороших устройствах, и я могу себе представить, что многие пользователи не обладают дорогими и мощными смартфонами. Так что в действительности ситуация со временем загрузки ещё хуже.
  • «В следующей версии <вставьте название фреймворка> ситуация будет лучше». Допускаю. Но это вряд ли поможет тем, кто уже пользуется вашими продуктами на предыдущих версиях фреймворка.

Вопрос на $64 000


И неизбежно возникает вопрос: а нужно ли использовать фреймворк? Я не могу дать на него ответ. Это должно быть целиком ваше собственное решение. Существует миллион причин, почему вам позарез нужен фреймворк. Вот мои собственные мысли по этому поводу:
  • Фреймворки облегчают реализацию идей и концепций. Именно благодаря им можно понять, какие подходы работают, а какие — нет. Это стимулирует процесс улучшения программных продуктов на уровне платформы. С этой точки зрения фреймворки представляются мне некими тестовыми площадками, на которых можно испытывать будущие нововведения в рамках платформ. С их помощью можно понять, какие возможности обретёт мобильный веб ближайшего будущего.
  • Фреймворки являются инверсией контроля. Выше я исключил из рассмотрения библиотеки, потому что их можно легко переключать. Фреймворки же контролируют жизненный цикл приложения, дают вам точку входа для начала работы вашего кода. Да, вы отвечаете за сам код, но вы не контролируете ситуацию целиком.
  • Фреймворки дороги при использовании на мобильных устройствах. По крайней мере, по сравнению с базовыми языками. И с моей точки зрения — недопустимо дороги. Но у каждого своё представление о границах допустимости.

Да, фреймворки предлагают разработчику немалый комфорт. Но я не могу отделаться от мысли, что лучше вложиться в собственные знания и навыки в рамках самой веб-платформы. Фреймворки приходят и уходят, они словно приливы и отливы интернета, помогающие реализовать и отточить идеи и шаблоны. Но если вы однажды обнаружите, что ваш любимый фреймворк больше не работает или какой-то важный баг так и не пофиксили, то способность разобраться в устройстве платформы окажет вам неоценимую услугу.

В сухом остатке


Я как-то писал, что комфорт разработчика менее важен, чем нужды пользователей. Я всё ещё верю в это. Хоть меня тоже привлекает лёгкая жизнь, я не хочу создавать плохо работающие продукты. И не хочу, чтобы пользователи платили за них высокую «цену». Сейчас меня волнует скорость начальной загрузки фреймворков на мобильных устройствах. Но это лишь первый шаг. Есть и другие метрики: использование памяти, длительная нагрузка на ЦПУ, частота смены кадров. В целом нам нужно искать менее затратные для пользователей решения.

Если нам удастся реализовать быстро загружаемые фреймворки, потребляющие мало памяти и работающие с большим фреймрейтом, да ещё и обеспечивающие комфортность разработки, то это было бы идеально. Но до той поры я бы предпочёл использовать обходиться без фреймворков, по крайней мере в мобильном сегменте.
Автор: @AloneCoder Paul Lewis
Mail.Ru Group
рейтинг 586,53
Строим Интернет

Комментарии (58)

  • 0
    Жаль, что микрофреймворки типа riot и mithril не тестировались.
    С тяжеловесами на мобилах и так всё понятно.
  • +2
    А так же интересен был бы тест VueJS
    • +1
      Мы тут как раз сейчас их гоняем в тестах на todomvc: http://habrahabr.ru/post/272139/#comment_8696687
  • +12
    Nexus 5 и iPhone 5S? Нет, это неадекватно. Если вы хотите выпускать действительно массовое приложение, то надо тестировать на 2-ядерных смартфонах с 512 МБ ОЗУ, вдобавок с установленным (и работающем в фоне) среднестатистическим набором приложений (например, Facebook, VK, какой-нибудь антивирус, сервисы Google, несколько игр с сервисами оповещений и пр. и пр.)

    P.S. Спасибо большое за статью, может быть, хоть кому-нибудь она откроет глаза на нынешнее JS-безумство.
  • +4
    Vanilla-vanill-ой, все нужно примерять к задачам, к команде людей которые работают с этим кодом.
    Есть профессионалы, которые могут написать структурированный Vanilla-код, который будет хорошо работать, но когда к одному и тому же коду причастно большое количество людей разного проф. уровня — фреймверки являются необходимой абстракцией, которая в большинстве случаев не даст сделать приложение тормознутым (я сейчас о реакте, у разработчика забирают возможность напрямую манипулировать DOM, отдают эту работу виртуальному дереву и реакту — он и принимает решение что обновлять, а что нет). Используя VanillaJS ты обязательно должен помнить о множестве мест, где может упасть производительность, или есть соблазн обновить весь контейнер, а не всего несколько элементов в нем.
    Я за VanillaJS, но когда уверен, что для задачи этого достаточно или необходимо, когда код будет сопровождаться компетентными людьми.
    • +3
      которая в большинстве случаев не даст сделать приложение тормознутым

      Хочу добавить, что не только не дадут сделать приложение тормознутым, а еще помогут структурировать код.

      Поэтому и нужно искать компромис между скоростью Vanilla, структурированностью и безопасностью, либо красотой, для некоторых лаконичностью. Каждый фреймверк решает что то одно хорошо, другое так себе, а с третьим все совсем плохо.

      Обучение фреймверку — это не плохо. Это уже написанная документация и сообщество разработчиков. А кто сделает документацию к вашему VanillaJS?
  • –4
    Всеми руками за! Отличная статья! Давно пора трезво смотреть на эту моду! Подпишусь под каждым словом!
    Но я не могу отделаться от мысли, что лучше вложиться в собственные знания и навыки в рамках самой веб-платформы.

    Именно! Лично я предпочитаю изучению хода мыслей других разработчиков, изучение основ самого web-a!
    Изучение.
    Снова изучать.

    И причём ты ни когда не сможешь сказать со 100% увереностью что ты отлично разбираешься в этом фреймворке,
    если ты его только сам не разрабатываешь.
    На доскональное изучение уходят месяцы. Лучше открыть w3c.org и понять где корни ошибок и т.п.

    Хочу добавить что каждый фреймворк накладывает свой угол зрения и он уже того, что можно создать с помощью нативного web-а(который еще и гибче)

    Справедливости ради скажу, что я не участвую в проектах со 100+ количеством разработчиков, для которых создаются данные фреймовки. Но они создаются для узкого круга задач (Да, да, а вы думаете гугл/телеграм заботиться о ваших архтектурах?) И в тех проектах где действительно прменим фреймворк стоит задуматься о написании своей системы.

    Слишком сильно Angular & React размаркетингован!
    • +6
      > в тех проектах где действительно прменим фреймворк стоит задуматься о написании своей системы
      Не стоит. Если применим фреймворк — его надо применять. Ничего не может быть хуже своего фреймворка, который разрабатывается одним-двумя человеком и вследствие этого, а также отсутствия полноценной команды его разработки: 1. забагованный, 2. незадокументированный, 3. тормозной, 4. с кривой архитектурой.
      Особенно плохо, если фреймворк разрабатываетя внутри компании и никуда наружу не показывается, это вообще мрак. Видел такое не раз…
      • 0
        Конечно я согласен, что где применим, там надо применять!
        Но, уж слишком тонкая грань между удобством первого старта и жёсткостью разросшегося приложения.
        Надо уметь их готовить. А на это уходит время не одного проекта. А за это время мода успеет поменяться.
        (Backbone->Angular->React)
        На моей практике либо приложение на столько маленькое, что тянуть ради него фреймворк как из пушки по воробьям, либо она такое большое, что со всеми фреймоврками и библиотеками порог входа несколько месяцев для ознакомительного изучения их всех. А когда начинают появляться в них баги… или заказчик хочет того, что с фреймворком ой как сложно сделать. (Например Lazy-loading для Angular 1.2) вот тогда сильно задумываешься о том, стоит ли оно того?
        • +1
          Предлагаю не гоняться за модой, которая изменчива, а сосредоточиться на базовых принципах, которые в современных фреймверках практически идентичны, только пишутся по-разному.

          В основном, в UI-фреймверках типа Angular все вертится вокруг дата-биндинга. В React+Flux это тот же дата-биндинг только вид сбоку. Есть Store, есть Component — задача программиста правильно прикрутить компонент к стору чтобы данные из стора правильно выводились в компонентах, а любые изменения в компонентах сразу попадали в стор.
          Исключительно мое мнение, что в Ангуляре этот процесс максимально пытаются скрыть от разработчика, в чем и кроется дьявол. :)

          Тоже самое можно наблюдать и в Backbone — те же компоненты, тот же биндинг, только описывать связи и контролировать поведение компонентов сложнее.

          На данный момент для меня золотой серединой является Реакт. Пока что для работы приятнее не нашел. Смотрел и Riot и VueJS (конечно на каждом из них сделал пару мелких поделок).
          • –1
            Посмотрите ещё RactiveJS, возможно не пожалеете)))
            • 0
              Я посмотрел, и пока не понимаю в чем профит, расскажите чем он отличается от Реакта, Ангуляра, в чем его основные преимущества, фишки?
        • +1
          С фреймворками нормальный разработчик так или иначе уже знаком, в том и прикол, что абстракции общепринятые, а не изобретённые местным архитектором. Некоторые фреймворки (я сейчас не будут тыкать пальцем) правда имеют слишком много мнения о том, как должен выглядеть ваш код и накладывают столько ограничений, что жизнь они и правда сильно осложняют, но по-моему ответ прост: не пользуйтесь ими, если ограничения вам существенны.
          Не надо смотреть на то, что сейчас в моде: проект забросили — это одно дело (что кстати и произойдёт с внутренним фреймворком через год), проект вышел из моды — да и чхать, если при этом он поддерживается, баги фиксятся, всё устраивает.
      • 0
        «видел» и «вообще мрак» — это вы хватили — повторное использование кода как бы вполне нормальная практика ;-)
    • +3
      Хороший пример: Есть Вася и есть Петя. Вася знает почему этот тег не применим в данном месте, а Петя не знает. Но например Петя знает то, что не знает Вася. Фреймверки позволяют Васе и Пети не сидеть и разбираться во всех нюансах применения тех или иных тегов или стилей. (Я конечно не спорю, что знать все — очень и очень хорошо.) Но кушать что-то нужно, поэтому берут прослойку, которая убирает пробелы в знаниях Васи и Пети, и предлагает решать задачи более высокого уровня, например заняться логикой добавления товаров. И в этом нет ничего плохого. Тем более, что любой другой, например Женя прийдет и у него будет с чего начать (документация, stackoverflow, код разбит на общепринятые сущности).
      • 0
        Согласен! WordPress, Drupal хоть и не фреймоврки, но очень удобные инструменты для Вась и Петь!
        А вот с Женей вопрос спорный. Будет ли написан код Васей и Петей так, как этого предлагают разработчики фреймворков? Сколько времени нужно Жене на изучение всех фреймворков и библиотек? А хватит ли запала и т.п.
        Соглашусь еще раз для менеджеров фреймворки могут быть и выгодны. но для кода и для разработчика, как специалиста, вряд ли.
        • 0
          Почему вы так уверены, что один человек способен написать идеальный код? Нет, конечно для этого человека этот код будет идеальным, в меру его способностей и гениальности, но поймут ли этот код другие разработчики, которым вдруг прийдется поддерживать его код?
          А вот насчет Жени, разве ему будет проще разбираться с кодом у которого нет ни документации и структура, и компоненты в каком-то самобытном формате, который не описан в интернете?
        • 0
          Как раз для разработчика как для специалиста фреймворки выгоднее. Вася и Петя с Angular/React смогут есть и наконец-то думать о такой возвышенной материи, как выполнение непосредственной задачи. Женя же придумывает так или иначе свой фреймворк на ваниле и остается единственным специалистом в нем. Хорошо если работодатель будет не против того, что бы он поделился им на github.

          Для ловкого менеджера ситуация выглядит иначе: порог вхождения в наш BicycleEnterpriseFramework высок, зато куда потом от нас денется разработчик с опытом разработки в нем? И ситуация в такой компании конечно же не здоровая.
          • +2
            Для менеджера ситуация выглядит как человекогод, потраченный на написание фреймворка и ещё один на его отладку.
            > куда потом от нас денется разработчик с опытом разработки в нем?
            Да куда угодно: фреймворки с хорошей документацией изучаются за месяц усердной работы. А вот куда компания денется с тонной зависимого кода на этом г… не и высоким порогом входа — это хороший вопрос.
            • 0
              Да все верно, я о том что компания выбравшая такой путь нездорова (либо имеет большие ресурсы). С точки зрения программиста работа там не несет профитов, если только не хочется набить руку в низкоуровневой разработке на своем языке. Но если рынок хочет React-разработчика (с 10 летним опытом желательно :)), то у того программиста просто отнимают время. Как опыт хорошо, как индустрия — не каждому автозаводу нужны изобретатели колеса на должность проектировщика приборной панели.
          • 0
            Это 5 :)
          • 0
            Сложность изучения любого велосипеда многократно меньше сложности изучения крупного приложения. Иными словами знание фреймворка тут мало чем помогает так как есть груда кода написанного абы как без документации и тп. Если же вы сейчас возразите, что надо код приложения хорошо структурировать, комментировать, документировать, то «свой велосипед» как часть этого приложения будет также хорошо структурирован и документирован. А если вы загляните в потроха популярных «готовых фреймворков», то ужаснётесь как там всё запутано и неподдерживаемо. Собственно, хороший программист сделает хороший фреймворк под задачу. А плохой и на готовом фреймворке наговнокодит так, что разобраться будет невозможно. Фреймворки — не серебрянные пули, а всего-лишь набор подходов. Иногда удачный, иногда не очень, и зачастую пишутся они не слишком квалифицированными программистами.
            • 0
              Окей, фреймверки — набор паттернов, это да. Иногда этот набор помогает писать, если программист читает документацию и хотя бы немного понимает что там написано. Ну и помогает писать в таком духе, как пишет другой программист на том же фреймверке.
              Да есть такие, которые пишут свои решения, например у нас есть подобный пример. Но здесь все зависит от человека, «хорошего программиста». Он написал свой велосипед, и он вполне неплох. Но так как это разработка фирмы, и фреймверк и код фреймверка, то возникает большой соблазн менять код ядра, вместо правки модулей. Так вот когда фреймверк общественный и мэйнтайнеры не дураки — они твой код завернут и пошлют куда подальше.
              Я к чему, написать это одно — а как жить с этим добром одному?
              • 0
                На самом деле это замечательно, когда можно менять код ядра, а не ждать по пол года принятия пул реквеста, потом ещё пол года следующей стабильной версии. И то далеко не факт, что примут, ведь изменение может сломать совместимость с каким-нибудь матёрым ынтырпрайзом. В этом как раз плюс своего решения — если видишь, что что-то сделано плохо — просто берёшь и делаешь хорошо. А чтобы не бояться рефакторинга рекомендую писать тесты ;-)

                Я ещё не видел двух похожих приложений на ангуляре сложнее приветмира. Где-то всё в один шаблон сваливают, где-то его приправляют директивами меняющими дом, где-то на компоненты разбивают, где-то скопы изолируют, а где-то мучаются с их наследованием, где-то состояния хранят в сервисах, где-то прямо в контроллерах, а где-то велосипедят модель с ленивой загрузкой. Вы нигде не найдёте туториала как на ангуляре запилить большое сложное приложение, но когда такое пилишь, сталкиеваешься с проблемами, которые в данном фреймворке либо не решены, либо решены криво. Вот и костыляют кто во что горазд.

                Я ещё раз подчеркну: коробочные фреймворки (где «всё включено») позволяют человеку с низкой квалификацией быстро создать что-то типовое. Но для профессионала они являются лишь обузой, так как ставят ему не типовые задачи. И для этих задач куда важнее гибкость, чем жёсткие рамки.
                • 0
                  Случаи когда мэйнтайнер личного фреймверка забухал или сроки прижали и в ядро пропихнули откровенную ересь? Постепенно в закрытых фреймверках ядро обрастает кучей мусора. Что со временем снижает разработку, если процессы в команде не налажены или дали сбой.
                  Что хотел сказать, что разработка своего решения, хорошего решения — всегда сопряжено с культурой, принятой в команде. И если в команде высокая культура кодирования — большой шанс получить на выходе хороший фреймверк для внутреннего использования. Но чаще всего получается так что мейнтайнер сменяет мейнтайнера, в ядро льется откровенный мусор, файловая структура теряет былую красоту и изящность. Это кстати может случится и с командами, работающими с открытыми решениями. Все упирается в интеллектуальный и культурный уровень людей.
                  Но фреймверки — это как пример более цивилизованной разработки, сборник решений опять же от людей с какими то культурными ценностями. Не все фреймверки одинаково хороши, но и игнорировать их не стоит.
                  • 0
                    Когда смотришь в исходные коды многих фреймворков складывается ощущение, что мейнтейнеры не просто бухали, а постоянно устраивали оргии с индусами :-)
                    • 0
                      Welcome, продемонстрируйте здесь или здесь индусов и бухих мейнтайнеров.
                      Лично мое мнение, что код вполне ясен и можно даже пробовать самому слать PR.
                      У меня впечатление, что вы сложили мнение о ВСЕХ фреймверках по какому-то одному продукту, но их даже не два, их гораздо больше.
                      Например, во Флюксе я понял что к чему буквально в первый же день. Это достаточно банальный ивент-деспетчер. Но конечно, если я ощущаю трудности с пониманием как оно работает, то скорей всего это или действительно не-внятно написанный код фреймверка или просто не тот фреймверк, который мне нужен, ну или конечно я сам виноват, что не мой уровень.
                      • 0
                        Пожалуйста:
                        Первый дриньк: https://github.com/facebook/react/blob/master/src/isomorphic/classic/element/ReactDOMFactories.js
                        Второй дриньк: https://github.com/facebook/react/blob/master/src/renderers/dom/client/ReactBrowserEventEmitter.js#L84
                        А теперь на брудершафт:
                        https://github.com/facebook/flux/blob/master/examples/flux-todomvc/js/actions/TodoActions.js
                        https://github.com/facebook/flux/blob/master/examples/flux-todomvc/js/stores/TodoStore.js

                        Сон разума рождает чудовищ. Но вы правы, конкретно эти две библиотеки не так плохи как многие другие фреймворки. А флюкс — вообще нечто тривиальное.
                        • 0
                          В реакте есть что то от божественного объекта, при работе с DOM, но могу заверить, что функция перерендера дерева и поиск дифа с изменениями это не совсем тривиальная, но идея проста и работает как часы, поэтому это я реакту простил. В противовес могу сказать, что в достаточно сложном коде практически не работаю на прямую с DOM, а реакт вполне эффективен при работе с большим деревом.
                          • 0
                            Я и не говорил, что реакт тривиален. Я бы сказал, что реакт сильно переусложнён и мог бы быть реализован куда проще. Например: https://github.com/patrick-steele-idem/morphdom

                            Концепция «перерендериваем всё дерево на каждый чих» — порочна. Даже если это «легковесное» дерево. Собственно бенчмарки на простом идеоматичном примере не радуют: http://nin-jin.github.io/todomvc/benchmark/
                            И да, я в курсе про костыли типа shouldComponentUpdate. Не от хорошей жизни они добавлены.
                            • 0
                              Предполагаю, что описание вьюхи сильно усложнится при использовании данной библиотеки, но а выглядит симпотично.
    • +1
      Написали свой фреймворк. Как раз напоминал Реакт, только компоненты назывались контролами(наследие WebForms :)) ну и без jsx, просто фрагментами дом втыкал. Потом поняли, что ресурсов уйма нужна. Выкинули и переписали все на Ангуляре. Проще, быстрее, решает задачи, которые стоят(админская консоль сервера), плюс для фул стек разработчиков знакомый DI. Смысла писать своё не вижу, если фреймворк решает ваши задачи.
  • 0
    Возникает неувязка: с одной стороны — удобство и комфорт разработчиков, с другой — пользовательские нужды.

    Не возникает. Удобство и комфорт разработчикам нужны, чтобы быстро и качественно удовлетворять пользовательские нужны. По крайней мере в коммерческой и близкой к ней разработке.
  • –1
    Да в деньги всё упирается. Если есть деньги — пишут своё. Денег нет — используют тот фреймворк, который знают.
    • 0
      Весьма справедливое замечание, за что вы минусуете человека? Ведь очевидно, что приложение из которого выкинут весь балласт в виде лишних абстракций будет работать быстрее. И конечно это замедлит разработку и удорожит ее.
      • 0
        А из чего следует, что если есть деньги, то их тратят в ускорение работы приложения или другие оптимизации? Больше не на что потратить? Это к вам.

        А Pilat, кстати, утверждает другое вообще, что если есть деньги, то пишут свои абстракции, а не используют чужие.
        • 0
          Я имел ввиду вот что: написать приложение, на своём фреймворке или на чужом, — разница не такая большая. Проблемы наступают потом, когда всё это надо поддерживать. И если нет денег на поддержку, то единственный выбор — использование чужого фреймворка, возможно принимая в нём участие. А поддержка — это развитие, исправление ошибок, оптимизация для новых устройств с новыми возможностями или ограничениями, обучение специалистов. Вот тут нужны деньги.

          Ну а писать свой фреймворк вообще приятное занятие для программиста. Я одних ORM'ов столько на перле встречал…
  • +2
    Но до той поры я бы предпочёл использовать обходиться без фреймворков, по крайней мере в мобильном сегменте.

    Если кому-то так важна производительность в мобильном сегменте, то нужно не js-фреймворк выбирать, а писать мобильное приложение на соответствующем языке. В противном случае, пофиг на чем писать. 200—500 мс, даже 1 с это не те цифры над которыми нужно задумываться. Тем более js развивается, а производительность мобильных устройств неуклонно растет.

    Какой-то мрачный вывод у статьи. В общем, используйте, что хотите и не думайте над производительностью. Лучше над качеством своего кода подумайте.
    • +1
      1 секунда на UI то не те цифры над которым надо задумываться, да правда что-ли?
    • +1
      Согласен. 250-500, пофиг. На сетевые задержки уходит больше всего времени.
      • 0
        А вы сеть на UI гоняете?
        • +1
          Странный вопрос. Мой ответ звучит так. Оптимизация 100мс — цена этому, отказ от фреймворка, как я понял из статьи. Результат самописной выдумки намного страшнее в будущем. И эти 200-500мс блекнул на фоне задержек сети
          • –2
            Мой посыл: 200-500мс на мобилке не могут блёкнуть — это серьёзный продолб, если на UI. А кто сказал про 100мс? Даже фрэймворки иногда не обязательно использовать, чтобы увидеть адские тормоза. Например, можно заюзать на одной View под WinPhone 5-8 стандартных WPF-конвертеров и наслаждаться лютыми тормозами на UI. Иногда не то что фрэймворки тормозят, иногда то, что из пакета тормозит.
            Если решились на самописное, то писать надо правильно. Кто по вашему разрабатывает фрэймворки, не люди? Нормальная команда может осилить практически любой фрэймворк (в пределах разумного).
            • –1
              Тут проще мобильное приложение написать, которое будут моментально работать, чем содержать команду, которая будет поддерживать всё это js-ное говно без фреймворков
  • 0
    Такое чувство что человек который пишет статью работает один. Как быть если это не мобильная версия сайта, а команда фронтов из 15 человек? Хотя знаю! Нужно чтоб на проект пришёл очередной выдумщик и написал свой уникальный Фреймворк, уволился через год, и все остальные остались жить с этим дерьмом!
    • 0
      Не удивительно, что он уволился, раз остальные разработчики не просто не участвовали в разработке фреймворка, но даже считали это занятие «дерьмом». Думаю, если бы вы больше обсуждали друг с другом подходы к разработке, то смогли бы выработать решение, которое бы устраивало всех или хотя бы все понимали что как и почему работает, а ему не пришлось бы искать других попутчиков.
      • 0
        То есть заказчик говорит: ну где проект, а команда из 15-ти человек сидит в это время и решает что выбрать: for или map?
        Если проект и время позволяет, а инвестор готов платить за развитие своего фреймверка и понимает за что платит, то да. Но обычно заказчик не понимает зачем убивать огромное количество времени на изобретение такого же инструмента, которым пользуется его конкурент.
        Да и не весь опенсорс отвратителен, можно за пол года перепробовать с пяток решений, последить за сообществом и принять решение что использовать.
        Я это к чему, что не любой бизнес готов платить, и не всему бизнесу нужно делать собственный велосипед.
        Это как болезнь молодых стартапов, у них нет прибыли, а они уже тратятся на большой офис и на огромную команду девелоперов, и сидят обсуждают какие у кого обязанности, вместо того чтобы пилить продукт который будет приносить деньги.
        Пусть пишут те, которые уже получили деньги и у кого есть время на разработку своего решения, если их что то не устраивает в текущем. Я бы не советовал всем подряд писать свои решения.
        • +1
          На «изобретение» такого же инструмента время тратить не стоит, а вот изобретение инструмента лучше, чем у конкурента позволяет его обогнать. И наём ещё большего числа людей ему не поможет. Вы ошибаетесь, полагая, что написание своего фреймворка — это дополнительная большая трата денег, потому как не учитываете сколько денег уходит в трубу из-за использования неэффективных инструментов. Далеко ли вы уйдёте в неудобных сапогах?

          А я бы советовал не бояться, а писать свои решения. но только если это свои оригинальные решения насущных проблем, а не повторение уже существующих решений.

          • 0
            Написание своего фреймворка и своего приложения на нём вместо написания приложения на нативном джсе всегда будет дольше и дороже.

            Вообще садиться целенаправленно писать свой фреймворк имеет смысл в коммерческой разработке исключительно в ситуации, когда планируется непосредственно с помощью фреймворка (а не приложений на нём) зарабатывать деньги. Это необходимое условие. В иных случаях свой фреймворк должен не целенаправленно писаться, а выкристаллизовываться из существующих приложений как способ устранения дублирующегося кода.
            • 0
              Написание любого приложения сопряжено с написанием фреймворка (набор правил, соглашений, библиотек). Даже если вы используете в качестве базиса уже существующий фреймворк, вы его будете дополнять, расширять, строить свои более высокоуровневые абстракции. А вот «целенаправленно писать фреймворк» в отрыве от написания приложения (да хотя бы даже демонстрационного в случае разработки фреймворка как самостоятельного продукта) — это очень странный кейс.

              И да, я всегда стараюсь писать обобщённые решения. Полноценная библиотека для работы с домом пишется за вечер, занимает не более 500 строк, имеет простое лаконичное апи и хорошо структурированный код. Это не такая уж сложная задача как может показаться при взгляде на кошмарный код jQuery.

              А без энтропии, постоянных мутаций и горизонтального переноса генов не будет эволюции ;-)
              • 0
                Не путайте разработку приложения с нуля и разработку приложения с использованием стороннего для приложения (пускай и собственной разработки той же команды) обобщенного фреймворка. Как минимум, если какое-то решение было неудачным, то вносить синхронные изменения нужно будет в два проекта. А если вы называете «написанием фреймворка» создание архитектуры приложения в принципе, то у нас очень большая разница в терминах. В любом проекте крайне желательно разделять обязанности по модулям, слоям, прочим архитектурным и языковым сущностям и т. п., но созданием фреймворка является вынос в отдельный проект инфраструктурных и прочих модулей и еже с ними, которые будут вызывать основной код приложения, передавая ему свои абстракции над средой выполнения.

                И не путайте библиотеки и фреймворки — фреймворк вызывает ваше приложение (максимум нужно самому написать загрузку, инициализацию и запуск фреймворка, запустить бутстрап процесс), а ваше приложение вызывает библиотеки (вызов коллбэка, переданного фреймворком в приложение или приложением в библиотеку, за полноценный вызов не считаем, это детали апи полноценного вызова). Иными словами, фреймворк диктует какие апи должно приложение реализовывать, а библиотека — какие использовать.
                • 0
                  В вашей терминологии любая библиотека с обратными вызовами (а это практически любая js-библиотека) — это фреймворк :-D

                  На самом деле грань между фреймворком и библиотекой очень тонка и сей терминологический спор не имеет какого-либо смысла.
                  • 0
                    (вызов коллбэка, переданного фреймворком в приложение или приложением в библиотеку, за полноценный вызов не считаем, это детали апи полноценного вызова)
          • +1
            Вы всегда пишете свою операционную систему и свою библиотеку для работы с DOM?
            Я предлагаю думать головой, когда стоит задача выбрать фреймверк. И начинать писать только после того как все попробовал и есть понимание что тебе необходимо. Да и например тот же Флюкс и Реакт это взаимозаменяемые штуки, чего не скажешь о монолитном Ангуляре. Есть хорошие и плохие решения.
            Если смотреть на всю массу прогоаммистов, то наверное процентов 20 действительно неплохо понимают что происходит и смогут написать более изящное решение, чем может предложить рынок. Предлагать каждому писать свое решение — предложение увеличить энтропию.
  • 0
    Прорекламирую свой недавний доклад на тему сложности в ui через призму конечных автоматов. В этом докладе я обстоятельно и подробно разбираю тему «зачем нужны фреймворки» www.youtube.com/watch?v=SduoWEXqeAg&feature=youtu.be&t=4h53m26s
    • 0
      Что ж так категорично про разработчиков? Есть особенности во фронтовой части, на бэкенде тоже все по своему. У кого то опыта больше у кого то меньше.
      • 0
        Особенности везде есть это да.
  • 0
    Очень интересная точка зрения, много справедливо в той или иной мере. Но мне кажется иногда переводчики слишком цеплялись за иронию Пола :)

    Добавлю важную штуку существует огромное множество фремворков/библиотек и многие стремятся холиварить Angular 1/2/N лучше Backbone 1/N но есть еще лучше React 1/N вот с ним «заживем то». Они все хороши. Главное в них мне кажется, если немного добавить идеологии Пола:
    Используя фремворк/библиотеку мы находим сильные/слабые ее стороны улучшаем/используем best practice (лучшие практики) и за счет них технология эволюционирует, а с ней и мы. Ну и конечно если технология эволюционирует то и продукты наши тоже. Все остаются в выигрыше не только разработчики но и конечные пользователи.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка