Проект RealWorld: сравнение фронтенд-фреймворков

Original author: Jacek Schae
  • Translation
Материал, перевод которого мы предлагаем сегодня вашему вниманию, представляет собой обновлённую, с учётом положения дел в 2018 году, версию статьи об исследовании фреймворков, которая была опубликована в декабре 2017.

image

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

  • Реальные задачи. RealWorld — это приложение, функционал которого выходит за рамки стандартного «списка дел». Подобные приложения обычно очень просты, они не отражают всё то, что необходимо в настоящих программах.
  • Стандартизация. Каждый вариант приложения соответствует определённым требованиям. В частности, эти требования описывают серверное API, статическую разметку и характеристики приложения.
  • Поддержка экспертов. Приложения либо написаны специалистами высокого класса, либо проверены ими.

При подготовке этого исследования были учтены замечания к его предыдущей версии. В частности, раньше не изучался фреймворк Vue, теперь же он имеется в списке. Стоит отметить, что здесь задействована версия Angular, применяемая для разработки, но использование в приложении продакшн-версии этого фреймворка — лишь вопрос времени.

Фреймворки


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


Фреймворки, включённые в исследование

Анализируемые характеристики


В ходе исследования приложений, разработанных с использованием различных фреймворков, учитывались следующие характеристики:

  • Производительность приложения. Сколько времени нужно для того, чтобы приложение загрузилось, вывелось на экран и оказалось бы готовым для работы с ним?
  • Размер готового приложения. Каков размер приложения? Тут сравнивались лишь размеры скомпилированных JS-файлов. Во всех вариантах использовались одни и те же CSS-правила, соответствующие материалы загружались с CDN. Везде применялась одна и та же HTML-разметка. Программный код, подготовленный средствами всех фреймворков, компилировался или транспилировался в JavaScript, в итоге сравнивались лишь размеры итогового JS-файла или файлов.
  • Количество строк кода приложения. Сколько строк кода надо написать для того, чтобы создать приложение RealWorld, соответствующее предлагаемым требованиям? Тут стоит отметить, что в некоторые варианты приложения включены второстепенные дополнительные функции, но это не слишком сильно влияет на итоговый результат. В ходе анализа исследовалась только папка src/ каждого из приложений.

Производительность


Здесь мы пользовались таким показателем, как первое значимое отображение страницы (First Meaningful Paint), полученным с помощью инструмента Lighthouse, который поставляется вместе с Chrome.

Чем быстрее будет выведена страница приложения — тем лучше оно будет воспринято пользователями. Средство Lighthouse также позволяет измерять показатель первой интерактивности (First Interactive), но он пока находится на стадии бета-тестирования и практически идентичен для всех вариантов приложений, поэтом тут мы ограничились именно показателем первого значимого отображения страницы.


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

Если рассмотреть полученные результаты, то можно сказать, что все они достаточно хороши и на практике заметить разницу между ними будет очень непросто.

Размер приложения


Здесь мы анализировали объём переданных данных, полученный средствами вкладки Network инструментов разработчика Chrome. Учитывалось всё то, что передаётся с сервера, включая заголовки и тело ответа. Чем меньше файл готового приложения — тем быстрее он загружается, и тем меньше времени нужно на его разбор в браузере.

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


Размер передаваемых данных в килобайтах. Чем он меньше — тем лучше.

Можно заметить, что лидерами по данному показателю являются Svelte, Dojo 2, AppRun и Crizmas MVC. Об ELM пока сложно сказать что-то определённое, особенно учитывая данные по размеру кода программ, которые мы рассмотрим ниже. Кроме того, интересно было бы взглянуть на то, как в подобном сравнении покажет себя Hyperapp. Возможно, нам удастся исследовать этот фреймворк в следующий раз.

Количество строк кода


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


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

Чем меньше строк кода нужно для того, чтобы создать приложение — тем меньше вероятность сделать что-то неправильно. Кроме того, проекты, представленные меньшим объёмом кода, легче поддерживать.

Итоги


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

Уважаемые читатели! Какими соображениями вы руководствуетесь, выбирая фреймворки для фронтенд-разработки?

RUVDS.com
1,372.38
RUVDS – хостинг VDS/VPS серверов
Share post

Comments 54

    +2
    Статьи по теме: habrahabr.ru/post/348964
      +1
      Вопрос к минусующему, а в чем, собственно, проблема? Это не ссылка на какой-то «левый» материал или сайт. Просто цикл статей на ту же тему — проект RealWorld. То что это мои статьи не исключают их вероятной полезности для читателей, которые заинтересованы в данной теме. Поэтому считаю, что данная ссылка вполне адекватное дополнение к этой статье.
      0
      Процитирую из исходного материала
      This is a RealWorld Comparison and not a benchmark in a vacuum

      Но я не нашел упоминания какой бэк-енд быд испопьзован. Или я плохо поискал?
        0
        В проекте есть спецификации и для фронтенда и для бекенда. Поэтому участвуют в нем разработчики и фреймворки с обоих сторон.

        Фишка в том, что если вы фронтендер, тогда вам предоставляют готовый рабочий бекенд с API и спеку к нему. Если же вы бекендер, тогда вам также предоставляют спеку для бекенда и готовый фронтенд на AngularJS.

        Я очень подробно описывал эти нюансы в своей вводной статье на данную тему.
          0
          Это я знаю. Я про то что на одном ли бэк-енде сравнивались фронт-енды в этой статье. Если да, то тогда график производительность имеет смысл.
            0
            Конечно на одном. Говорю же готовый полностью рабочий бекенд с апи. В спеках есть ссылка.
              0
              И на каком из?

      +2
      Эх, а EmberJS нету(
        +2
        Есть issue в репозитории, т.е. кто-то начал проект на Ember, но похоже не закончил. Быть может нужна ваша помощь? ;)
        –2
        Сайт https://realworld.io/ не открывается — редирект на страницу проекта на GitHub. Таких статьей на тему сравнения разных фреймворков в Интернете полно.
        Не нужно такое переводить, думаю что человек умеющий программировать может читать статьи на английском. Лучше бы сделали своё исследование и выложили результаты.
          –3
          Для тех, кто не хочет тратить месяцы на выяснение какой же фреймоворк на самом деле лучший, ответ:
          Vue.js
          — Самый простой в изучении
          — Лучшая CLI
          — Лучшая документация
          — Позволяет воплощать сложные концепты новичкам в веб разработке
          — Имеет отличный роутер страниц
          — Имеет отличный способ хранения данных Vuex
          — Использует template тэги для HTML (при использовании .vue файлов)
          — Имеет отличный визуальный фрэймворк компонентов Vuetify
          — Огромное количество примеров в интернете
          — Дает возможность с легкостью контролировать поток данных (выполнять различные действия на всех этапах жизненного цикла компонентов)
            +1

            Ответ «никакой фреймворк» принимается?

            –3
            Прошу прощения, если ошибаюсь, но, довольно редко попадаются проекты, сделанные на этих фреймворках, популярные с точки зрения безоговорочного успеха в плане поисковой оптимизации… Шаблонизаторы, типизаторы, прочие новшества, а SEO в глубоком пролете. Проблема, что с идеями самих проектов или проблема технологического характера? Как по мне — нужно еще один параметр сравнения добавить и тогда точно вывалится React со своим JSX.
              0
              Думаю, что JSX тут совершенно не при чем, если, конечно, я вас правильно понял и вы только про SEO говорите.

              В любом случае, моя реализация не будет в пролете точно, ознакомьтесь если интересно:
              Разработка изоморфного RealWorld приложения с SSR и Progressive Enhancement.
                0
                Интересен пример живого успешного проекта на этом примере :) Есть ли что-то, что находится по ключевым словам со страницы хорошо?
                  0
                  А у вас разве есть какие-то сомнения в том, что если проект полностью рендерится на сервере, отдает правильные мета-теги для каждой страницы, для навигации и форм используются канонические элементы HTML и даже полностью поддерживает работу с выключенным JS в браузере, то он будет хорошо индексироваться поисковиками? У меня сомнений нет. Далее все зависит уже от самого контента.

                  Если вас в принципе интересуют успешно работающие и известные всем изоморфные приложения, тогда первое что приходит в голову это наверное Flickr и Airbnb. Из менее известных вам, например, GoCardless сделан на React/Next с использованием JSX. Только как я уже писал, JSX тут вообще не при чем)))
                    –2
                    > если проект полностью рендерится на сервере
                    > и даже полностью поддерживает работу с выключенным JS
                    > У меня сомнений нет.

                    У меня тоже, но тогда при чем тут React?
                      0
                      У меня тоже, но тогда при чем тут React?

                      React отрабатывает как на сервере так и на клиенте. Если клиент не поддерживает JS, нет проблем т.к. рендер дублируется на сервере. Если клиент поддерживает JS, при внутренних переходах он получает не всю страницу отрендеренную на сервере страницу, а только данные для рендера и уже клиент сам отрисовывает страницу, тем самым в том числе уменьшая объём передаваемых данных. Если кратко — это один и тот же код на React.
                        –4
                        Эх. Раньше были просто страницы для печати отдельно. Я возможно старомоден, но, с точки зрения здравого смысла, отдавайте нормальную статику для всех и JSON для клиента… Зачем реакт? Пока вы собираете на коленке свои прослушки с пердуксами нормальный разработчик пишет приложение на нативе в три раза быстрее, имхо.
                          +1
                          Какие еще «страницы для печати»? В чем принципиальная разница делать сайт на том же PHP или Perl (классика) или же на NodeJS?

                          Зачем реакт? Пока вы собираете на коленке свои прослушки с пердуксами нормальный разработчик пишет приложение на нативе в три раза быстрее, имхо.

                          Могу с вами поспорить. Если хотите, можем и пари заключить))) Вот манифест моей реализации RealWorld приложения:

                          «Манифест» проекта:

                          1. Соответствовать спецификации проекта RealWorld;
                          2. Полностью поддерживать работу на сервере (SSR и все прочее);
                          3. На клиенте работать как полноценное SPA;
                          4. Индексироваться поисковиками;
                          5. Работать с выключенным JS на клиенте;
                          6. 100% изоморфного (общего) кода;
                          7. Для реализации НЕ использовать «полумеры» и «костыли»;
                          8. Использовать максимальной простой и общеизвестный стек технологий;
                          9. Размер итогового бандла не должен превышать 100Кб gzip;
                          10. Количество строк кода приложения не должно превышать 1000 loc.


                          Сколько вы такое будете на нативе писать?

                            –2
                            > Сколько вы такое будете на нативе писать?

                            Пари заключать не будем — некогда. А напишу, в принципе, скажем, за неделю. НО:

                            > Соответствовать спецификации проекта RealWorld; — это мне не нужно
                            > 100% изоморфного (общего) кода; — это кудрявое как логотип хабра(могу показать как отрастет на заднице, а то щас его не видно почему-то) мне тоже не нужно.

                            С остальным согласен, но, опять же, строк кода может быть и больше.
                              +2
                              Пари заключать не будем — некогда. А напишу, в принципе, скажем, за неделю.

                              Все так говорят, но без пари это только слова.))))

                              > Соответствовать спецификации проекта RealWorld; — это мне не нужно

                              А вы всегда своему заказчику/работодателю так говорите, когда он вам приносит спецификацию нового проекта? Даже интересно стало, как вы дали оценку «за неделю» если фактически отбросили ТЗ?

                              > 100% изоморфного (общего) кода; — это кудрявое как логотип хабра(могу показать как отрастет на заднице, а то щас его не видно почему-то) мне тоже не нужно.

                              Интересно, как вы без изоморфного кода выполните пункты про SSR, SPA и SEO? Будете клиент и сервер писать полностью отдельно? А как же DRY?

                              p/s То что у вас там где-то отрастает вы, пожалуйста, своей жене показывайте. Если она у вас конечно имеется. У нас тут как бы достаточно уважаемый IT ресурс, а не клуб любителей красноречивых аллегорий.
                        0
                        Вы прикалываетесь да? Ну либо даже не заглянули в ту ссылку, которую я вам прислал. Если действительно интересно как все это работает, то можете прочитать мой туториал. Там конечно не React, а Ractive используется, за то все очень подробно и доходчиво объяснено.
                    +1
                    Там дальше в ветке пошел какой-то троллинг тупостью, поэтому просто оставлю здесь результаты сравнения скорости рендеринга серверным реактом и типичными нодовскими шаблонизаторами.
                    TLDR React 16.3 в продовом режиме лишь незначительно (2-3%) проигрывает Nunjucks.
                      0
                      Спасибо за ссылку. Никогда еще не слышал о Nunjucks. Как быстро все меняется однако.
                      Скорость серверного рендеринга по моему мнению это даже не решающий фактор, если включено кэширование. Важнее какое ощущение от работы приложения будет на девайсах, особенно на мобильных и при слабом интернет. Поэтому я выделил бы такие критерии как 1) просто наличие серверного рендеринга для быстрой закгрузки певой страницы а не прорисовки ее Ява-Скриптом 2) Наличие code splitting, чтобы не тянуть весь Ява-Скрипт одним бандлом при той же самой первой загрузке которая и без того тяжелая если нет серверного рендеринга 3) Скорость работы приложения. Например в планах react в этом году сделать очень много в плане работы на слабых девайсах и при медленном интернете см. доклад Дэна Абрамова с русскими субтитрами опубликованными на Хабре habrahabr.ru/post/350816
                    0
                    React с JSX не вывалится. Ведь главная проблема JS фреймворков в плане SEO была именно из-за того, что поисковые боты их не могли индексировать т.к. они рендерятся на клиенте (для этого нужен JS и немного иная логика робота), но у крупных поисковиков уже умеют как пару лет, а у остальных получаем индексирование с серверным рендерингом. В мире React для этого есть хороший фреймворк NextJS.
                      –2
                      В мире SEO больше нет поддержки Ajax. Это от Google. Преимуществ нет.
                        0
                        В мире SEO больше нет поддержки Ajax. Это от Google. Преимуществ нет.

                        Кто вам такую чушь сказал? Google как начал использовать робота основанного на Chrome так и использует, да некоторые фишки он не поддерживает т.к. на данный момент основан на Chrome 43. Но вся остальная поддержка JS и выливающихся остаётся.

                        А потом fetch запросы на клиенте упрощают жизнь в первую и непосредственную очередь для пользователей, а не роботов. А для роботов и пользователей без JS мы сами отрисовываем страницу.
                          0
                          Я с Вами согласен в той части что Google может индексировать страницы которые рендерит клиент. Но что--то мне подсказывает что это очень затратная операция и он делает это не для всего инетернет. Во всяком случае низкий рейтинг страниц которые рендерятся на стороне клиента (а не на сервере) эта та реальность с которой я столкнулся. Псле перевода приложения с бэкбона на серверный riot.js за три дня тот же самый сайт попал на 3-ю страницу в google а еще через неделю на первую. При всех прочих абсолютно равных условиях.
                            0
                            Но что--то мне подсказывает что это очень затратная операция и он делает это не для всего инетернет.
                            Ну там всё по уму сделано, чтобы минимизировать затраты во первых ускорены во много раз часы т.е. Date.now() через 1 реальную секунду будет отличаться в несколько раз больше чем на секунду. А ещё функция Math.random() возвращает заранее просчитанные дискретные значения. Вообщем там всё сделано, чтобы минимизировать затраты.

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

                            Ну это не главное на самом деле, просто ветка пошла с того, что если добавить «дополнительные критерии», то React с JSX выпадет из рейтинга. Под этими «дополнительными критериями» подразумевалось в том числе и SEO. Так вот это сильно ошибочное утверждение т.к. есть опять таки тот же riot.js и как я указывал несколько выше NextJS, позволяющие делать универсальные приложения одинаково работающие как на клиенте, так и на сервере. Да даже без них есть ряд сервисов кеширующих клиентский рендер (на базе Chrome).
                              0
                              Да кэшировать рендер это очередная мало помогающая штука. Я его юзаю т.к. у меня на поддержке есть несколько проектов. Там проблема такая что если кэшировать контент навечно то главные страницы например с новостями быстро становятся неактуальными. Если же отдавать их без кэширования то рендеринг новым hеadless Chrome или же phantom.js прохзодит за 10 секунд миимум а то и все 20 что совтественно снижает рейтинг до минус бескнечности.

                              Если же делать «по умному» то есть запускать своего робота чтобы он опрашивал страницы на для того чтобы они отбавались поисковым ботам уже из кэша то тут дргуая проблема. Как я уже говорил это затраты по времени и по ресурсам тк мы фактически на сервере на котором может быть предположим 2 или 4 Гб памяти всего запускаем чуть рлегченный Chrome.

                              Я так это подробно объясняю потому что это все как бы для меня очень актуально т.к. проекты уже не переделаешь готовые а начинается СЕО-оптимизация и тут одни проблемы.
                    0
                    Как раз именно React и Vue предоставляет инструменты для создания изоморфных приложений которые рендерятся и на сервере и на клиенте и не имеют с точки зрения СЕО никаких протвопоказаний.
                    +1

                    Еее, ещё одна бесполезная мерялка!


                    Реальные задачи. RealWorld — это приложение, функционал которого выходит за рамки стандартного «списка дел». Подобные приложения обычно очень просты, они не отражают всё то, что необходимо в настоящих программах.

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


                    Почему число строк кода, необходимое для создания приложения — это важный показатель?

                    Да нипочему. Бойлерплейт у того же ангуляра или редукса довольно большой, но особой логики сам код при этом не несёт. Описания модулей или mapDispatchToProps однотипны, но съедают много строк. А писать можно и в одну строчку с тренарными операторами и кучей стрелочных функций. Вроде и одна строка, но ошибиться там гораздо легче, чем в подробно расписанной простыне.


                    Ну и про серверный рендеринг ничего не упомянули, хотя это умеют многие и это ускоряет отображение.

                      0
                      А на демо немного усложнённый (но всё ещё простой) туду-лист, также далёкий от реальных задач.

                      Вряд ли энтузиасты будут делать что-то еще более сложное. Все же люди делятся своим опытом и делают это бесплатно. И кстати вполне себе клон блого-социальной сети и основной функционал присутствует. Может у вас есть более «реальные» примеры?

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

                      Да нипочему. Бойлерплейт у того же ангуляра или редукса довольно большой, но особой логики сам код при этом не несёт.

                      Не согласен, все же важно нужно тебе писать этот «бойлерплейт» или нет. От кол-ва строк кода как минимум будет зависеть то, сколько времени его надо писать, а значит и проект в целом.

                      Ну и про серверный рендеринг ничего не упомянули, хотя это умеют многие и это ускоряет отображение.

                      Реализация Svelte/Sapper по-идее должна быть с SSR (не проверял), потому как Sapper — он как бы для изоморфности (аля Next.js реактовский).
                      0
                      Это уже настолько избитый вопрос, как требования к джуну, сколько времени нужно на то, чтобы стать сениором, или typescript vs flow. Каждый раз люди измеряют коней в вакууме, каждый раз приводят субъективные аргументы и так далее. У всех есть свои минусы и плюсы, раскрывающиеся как правило в специфичных случаях. На этапе вхождения тут всё ± однолико. От этих плюсов и минусов можно отталкиваться, при старте проекта, в зависимости от его специфики. И такие моменты было бы неплохо осветить.
                      На вероятность ошибки влияет не столько количество бойлерплейта, сколько возможность языка/фреймворка дать эту ошибку допустить. Сам «бойлерплейт» предполагает гибкость решения, это компромисс, за который мы расплачиваемся. На данный момент в сети тучи пакетов, уменьшающих этот бойлерплейт. Кто-то на опыте пишет свои велооптимизаторы, не все так плохо.
                        –2
                        Вы так говорите, как будто знаете какой-то более надежный и универсальный способ оценки. На мой взгляд пока человечество не придумало ничего лучше, чем сравнение. Поэтому да, все познается в сравнении.

                        И если по поводу проектов уровня Todolist я, пожалуй, соглашусь, что все ± однолико. То проект уровня RealWorld вполне себе достаточен, чтобы заглянуть в исходники реализаций и понять какая из них вам близка и более понятна. А также понять как на том или ином инструменте реализуются основные задачи, с которыми сталкиваются разработчики. В этом цель данного проекта и, как мне кажется, он с ней справляется.
                        0

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

                          –2
                          А вы видимо предпочитаете Angular?
                            0

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

                              0
                              Ну чтож, не угадал, так не угадал.)))) Странно, что аж 2-х человек мое предположение задело настолько, что не поленились поставить минус. Не думал что одно только упоминание Angular вызывает столько негативных эмоций.
                                0

                                Странно, что вы продолжаете писать про Angular мне. У меня негативные эмоции вызывает только то, что в индустрии синтетические и маркетинговые пузомерки играют незаслуженно высокую роль, и часто являются основанием для выбора стека, вместо взвешенного инженерного подхода. А потом, бывает, смотришь в код какого-то проекта и фейспалмишь от того, что люди делают приложения на Реакте, как это делалось бы на Ангуляре: создают компоненты на всё состояние экрана и вообще не в курсе про декомпозицию представлений, ради которой Реакт и создавался. У всех рассматриваемых вами экосистем есть своя концепция и история, их эволюция обусловлена какими-то значимыми факторами, о которых вы не пишите ничего, но которые и должны быть определяющими в конечном итоге. За каждую возможность приходится чем-то платить, и если бы вы составили таблицу "что вы получаете" VS "чем вы жертвуете" для каждого случая — в этом был бы какой-то смысл.

                          +1
                          Итого: победил AppRun (±), а тем временем бизнес пишет в основном на «реактах и ангулярах». И в статье ни слова о том как так получилось. Отличное сравнение!
                            0
                            Посмотрел на реализацию AppRun. Работет действитеьно очень быстро и гладко (нет этих вот традиционнах «прелоадеров» которые записают на пару секунд). Ну а почему раельно пользуются два (а теперь иже три вместе с Vue) фреймверка/библиотеки — это скорее уже из области экономики. Есть готовые специалисты, есть надежда что фреймерки будут развиваться и поддерживаться. Хотя это только надежда. Мы все помним как Oracle чуть не съела сначала Java а потом MySQL.

                            Интересно другое что вцелом проект Real World посвое направленности не вызывает холливара и как раз наоборот кажется подтверждает что все средства хороши по своему. И для разрабортчиков дают возможность заглянуть в код «а как это будет на Elm» (кстати очень сложно это будет на Elm но работет очень хорошо)
                              +1

                              Я бегло посмотрел на исходники. Есть два аналогичных компонента ArticleList:



                              Видно, что для оформления файлов на React используется более размашистный code-style, больше переносов строк. Для более честного сравнения по числу строк нужно во всех исходниках использовать одинаковый code-style.


                              Кроме того, в AppRun в этом компоненте собраны в кучу список и preview одной статьи, в React они вынесены в отдельные модули. Больше модулей — больше размер финального бандла, независимо от выбранного фреймворка.


                              В общем, есть вопросы к объективности данного сравнения.

                                0
                                В качестве ремарки — переносы сток, насколько я понял, не учитывались в loc.

                                Насчёт различной декомпозиции, тут, пожалуй, соглашусь. Однако надо учитывать, что разные фреймворки именно склоняют разработчиков писать сообразным образом. Проще говоря, иногда в условном Реакте просто приходится выделять компоненты там где в других фреймворка этого делать не надо. И т.д.
                                  0
                                  переносы сток, насколько я понял, не учитывались в loc.

                                  Из статьи:


                                  Подсчёт количества строк кода приложения выполнялся с помощью cloc. Обработаны были только файлы, находящиеся в папке src. Пустые строки и комментарии не учитывались.

                                  То есть не учитывались пустые строки, а вот такой фрагмент:


                                  return (
                                    <div>
                                      {

                                  спокойно считается за три строки.

                                    0
                                    Да, пожалуй, вы правы. Перепутал с пустыми строками.

                            Only users with full accounts can post comments. Log in, please.