company_banner

Поиск лучшего фронтенд-инструмента 2021 года

Автор оригинала: Chameera Dulanga
  • Перевод
Любой, кто начинает карьеру в сфере разработки программного обеспечения, скорее всего столкнётся с задачей выбора первого языка, фреймворка или набора инструментов. Уверен, каждому из вас это знакомо. Ответ на вопрос о том, что нужно изучать самым первым, найти не так уж и просто. Всё дело в том, что в индустрии программирования существует очень много языков и вспомогательных инструментов. Для того чтобы облегчить выбор инструментов тем программистам, которые нацелены на фронтенд-разработку с использованием JavaScript, я решил рассказать о трёх популярных JS-инструментах.



Речь пойдёт об Angular, React и Vue. Сначала я приведу материалы некоторых исследований, что поможет нам понять «расстановку сил» на арене современной веб-разработки. А потом расскажу о преимуществах и недостатках этих инструментов.

Исследование Stack Overflow



Сведения о веб-фреймворках и библиотеках из исследования Stack Overflow 2019 года

В исследовании Stack Overflow 2019 года можно найти сведения о популярности фреймворков и библиотек. Здесь библиотека React и фреймворк Angular занимают, соответственно, вторую и третью строчки рейтинга. В похожем исследовании 2018 года Angular был выше React. Но если рассмотреть результаты опроса профессиональных разработчиков, то и в 2019 году Angular тоже окажется выше React. А вот Vue, несмотря на то, что этот фреймворк активно развивается, находится в рейтинге лишь на седьмой позиции.

Данные проекта NPM Trends



Сравнение React, Vue и Angular с использованием проекта NPM Trends

Вышеприведённый график построен с использованием возможностей проекта NPM Trends. Здесь показано изменение количества загрузок соответствующих пакетов с течением времени. В частности, на нашем графике представлены данные за 6 месяцев 2020 года. Тут хорошо видно то, что React, по исследуемому показателю, значительно обходит конкурентов. А количество загрузок Vue, с другой стороны, постепенно растёт и сейчас находится в районе полутора миллионов.

NPM Trends позволяет анализировать не только количество загрузок пакетов из NPM, но и данные соответствующих проектов, взятые с GitHub. На следующем рисунке показаны сведения о репозиториях интересующих нас фронтенд-инструментов.


Сведения о репозиториях React, Vue и Angular

Исследование State of JavaScript


Воспользовавшись результатами исследования State of JavaScript 2019 года, можно продолжить сравнение интересующих нас инструментов. На следующем рисунке показан отчёт, содержащий сведения об отношении респондентов к React, Vue и Angular. Они, оценивая фреймворк или библиотеку, могли выбирать разные варианты ответов. Например, среди них есть такие: «Использовал и буду использовать», «Слышал и хотел бы изучить», «Никогда не слышал».


Отношение респондентов исследования State of JavaScript к фреймворкам и библиотекам

Как видно React и Vue обходят Angular по показателю, характеризующему вариант ответа «Использовал и буду использовать».

Angular



Angular (по данным State of JavaScript 2019)

Для меня Angular — это фреймворк, с которого я начинал моё путешествие в мир разработки ПО. И я не жалею о том, что выбрал именно этот фреймворк. Angular, в сравнении с другими рассматриваемыми здесь инструментами, можно счесть немного более зрелым, чем они. Вокруг него сформировалось более крупное сообщество. Помимо того, что этот фреймворк является частью знаменитого стека MEAN, он ещё и даёт разработчику немало замечательных возможностей. Это, например, двусторонняя привязка данных, внедрение зависимостей, архитектура MVC, Angular CLI, поддержка TypeScript, поддержка директив и так далее.

Но в последние несколько лет, по мере роста популярности конкурентов, вроде React и Vue, Angular потерял часть былой популярности. Причиной этого стало то, что Angular — достаточно «тяжёлый» фреймворк. Он не соответствует ожиданиям программистов по многим показателям. Это и особенности выхода его новых версий, и ограниченная поддержка SEO, и сложности в его изучении. Именно поэтому в наши дни фронтенд-разработчики всё чаще выбирают Vue или React. Но Angular всё ещё используется во многих популярных веб-проектах. Это, например, проекты Guardian, Upwork, PayPal, Sony. Речь идёт о больших серьёзных сайтах, на которых Angular хорошо себя показал.

К Angular стоит присмотреться в следующих ситуациях:

  • Разработка крупномасштабных проектов.
  • Необходимость применения масштабируемой архитектуры.
  • Заинтересованность в использовании TypeScript.
  • Создание приложений, работающих в режиме реального времени.

React



React (по данным State of JavaScript 2019)

React, по данным исследования State of JavaScript, три года подряд занимает первые места во всех рейтингах. Библиотека React была выпущена Facebook в 2013 году. Цель создания React заключалась в разделении пользовательского интерфейса на набор компонентов, что должно было упростить процесс разработки. Одним из преимуществ React является возможность использования этой библиотеки для разработки нативных приложений. Среди других сильных сторон этой библиотеки можно отметить большое сообщество, поддержку со стороны Facebook, обширную экосистему, высокую производительность, механизмы многократного использования компонентов, поддержку SEO-механизмов.

Правда, иногда обновления React могут вызывать некоторые разногласия и споры в среде разработчиков, так как им приходится что-то менять в своей работе для того чтобы избежать проблем с совместимостью. Среди других минусов React отмечают применение JSX и недостаточно подробную документацию.

Вот ситуации, в которых можно прибегнуть к React:

  • Создание одностраничных или кросс-платформенных приложений.
  • Разработка небольших приложений корпоративного класса.

Vue


Vue — это проект, который появился сравнительно недавно. Он неожиданно превратился из обыкновенного фреймворка в один из самых любимых программистами инструментов веб-разработки.


Vue (по данным State of JavaScript 2019)

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

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

  • Разработка маленьких и нетребовательных к ресурсам приложений (вроде Grammarly).
  • Создание интеллектуальных и высокопроизводительных проектов.
  • Разработка веб-приложений на ранних стадиях их выхода на рынок.

Итоги


Если сделать выводы из вышесказанного, то получится, что лучшим фронтенд-инструментом, тем самым, который стоит изучить в 2021 году, является React. За ним следует Vue. Но высоки шансы того, что вместо Vue следом за React можно будет поставить Angular. Этот фреймворк существует дольше Vue. Непохоже, что в 2021 году Angular исчезнет. Поэтому, если вы являетесь Angular-разработчиком, то я советую вам, готовясь к 2021 году, приступить к изучению React.

Как вы думаете, какие веб-инструменты будут особенно востребованными в 2021 году?

RUVDS.com
VDS/VPS-хостинг. Скидка 10% по коду HABR

Похожие публикации

Комментарии 71

    +3

    Поиск лучшего фронтенд-инструмента 2021 года… и ни слова о технических и потребительских качествах инструмента. В этом весь фронтенд.

      +5
      Но у Vue есть и недостатки. Например — не очень хорошая приспособленность к поддержке крупномасштабных проектов и небольшое сообщество.

      Сообщество давно уже большое. А мнение о «не очень хорошей приспособленности к поддержке крупномасштабных проектов» — это вообще фраза которую многие повторяют бездумно, в том числе и автор топика. Что же такого интересно в нем не хватает для крупно масштабных проектов?
        –2

        В принципе, того же, чего и остальным представленным тут инструментам:


        • богатой системы стандартных компонент
        • высокой степени настраиваемости компонент
        • простоты шаринга компонент между приложениями
        • простоты разработки частей приложения разными командами
        • толерантности к ошибкам реализации связанных модулей
        • низких требований к профессионализму разработчика для обеспечения высокого уровня качества
        • поддержки высокой доступности по умолчанию
        • централизованной системы сбора аналитики
          +1
          Как понимаю по вашему сообщению — все эти инструменты не подходят. Но приведите пример того что подходит всему этому списку требований, если знаете такой.
            –5

            Ну, $mol подходит по всем пунктам кроме пока что последних двух.

              0

              А разве то что присутствует в $mol можно назвать богатой системой стандартных компонент? Я бы сказал что это минимальный набор, который непонятно как расширять…

                0

                Каких компонент вам не хватает?
                Вся разработка на $mol основана на расширении компонент так-то.

                  0

                  Разработка мол может и основана на расширении, но чтобы ее расширять надо дорабатывать. Тот же vue.js + vuetify дает набор компонентов значительно лучше и удобнее. И все это в два клика расширяется нормальными графиками chartjs и например табличкой от ag-grid. И все работает без танцев с бубном, у них единый подход к взаимодействию, построенный на vuejs. Вот эта парадигма мне больше напоминает расширение. Для $mol это все ручками делать?

                    0

                    Вы не ответили на вопрос.

                      0

                      Нормальные графики и грид это не ответ? :)
                      Верстка под мобильный по умолчанию хотя бы в Демке тоже была бы полезна :)


                      Карты от гугла например как добавить?

                        0

                        Чем графики не нормальны?
                        Датагрида действительно пока нет. Как его нет и почти в любом "наборе".
                        Интерфейс вполне себе адаптируется под широкий диапазон размеров экранов.
                        Какая вам разница какой провайдер карт? Яндекс выбран так как не требует api-key для каждого сайта. Планируется и от него отказать в пользу кастомной реализации, использующей osm.

                          0
                          Графики это не только lineChart. Это еще и Bar и Bubble всякие Pie и т.д. Плюс когда я захожу в ваше демку и вижу там вот такие картинки, куда то съехавшего интерфейса:
                          image
                          image

                          то даже разбираться почему так случается уже не хочется.

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

                          Карты — для разных стран, где используется сайт нужны свои. В России и окрестности лучше работает Яндекс, где то Гугл, а где то действительно OSM. Например если давать в Европе или Азии выбрать свой адрес по картам Яндекса, то точность будет так себе :) Так что нужны все возможные провайдеры в общем случае. а еще есть политические моменты когда Яндекс блокируют и карты не работают :)

                          И это только начало. Хочется и select со множественным выбором из коробки и нормальный datetime picker…
                            0
                            Это еще и Bar и Bubble всякие Pie и т.д.

                            bar и bubble(dot) есть. По поводу pie рекомендую почитать это: https://habr.com/ru/company/otus/blog/424647/


                            вижу там вот такие картинки, куда то съехавшего интерфейса

                            Спасибо, уже починил. Как видите, багрепорты — это не больно.


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

                            Есть, присмотритесь. Вообще, одна из основных идей $mol как раз в том, что прикладнику не надо "адаптировать интерфейс". Он обычно сам адаптируется.


                            Карты — для разных стран, где используется сайт нужны свои.

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


                            есть политические моменты

                            Такие моменты надёжно решаются лишь через собственный прокси.


                            Хочется и select со множественным выбором из коробки

                            Пожалуйста: https://mol.js.org/app/demo/-/#demo=mol_select_list_demo


                            и нормальный datetime picker…

                            Доработал: https://mol.js.org/app/demo/-/#demo=mol_date_demo


                            И это только начало.

                            Продолжайте.)

                              0
                              По поводу pie рекомендую почитать это: habr.com/ru/company/otus/blog/424647


                              Т.е. приходит ко мне бизнес и говорит — я хочу пирог. А я ему такой — вы ничего не понимаете, вот смотрите что на хабре умные люди пишут :-) Идите нафиг учится :)

                              Есть, присмотритесь. Вообще, одна из основных идей $mol как раз в том, что прикладнику не надо «адаптировать интерфейс». Он обычно сам адаптируется.


                              Если все само, то почему демо не работает нормально на телефоне?

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


                              Мы не предлагаем. Мы так делаем и очень давно. Самый стандартный пример — Россиянам показываем яндекс, Украинцам и американцам гугл и т.д. Как без этого в мультинациональном приложении — не понимаю.

                              Пожалуйста: mol.js.org/app/demo/-/#demo=mol_select_list_demo


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

                              Доработал: mol.js.org/app/demo/-/#demo=mol_date_demo


                              А time так где? а выбор диапазона дат/времени есть? или по старинке все двумя селектами?

                              Продолжайте.)


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

                              На самом деле откуда растет ваша идея абсолютно понятно. Просто и быстро создавать приложения. Еще бы к этому делу приделать визуальный конструктор и нормальный дизайн — хороший продукт выйдет. Но для очень простых сайтов. Как только вы сталкиваетесь с большим продуктом и реальными требованиями бизнеса, то такой подход требует очень больших затрат на доработку по каждой небольшой хотелке.
                                0
                                Т.е. приходит ко мне бизнес и говорит — я хочу пирог. А я ему такой — вы ничего не понимаете, вот смотрите что на хабре умные люди пишут :-)

                                Именно так. Учитесь разговаривать с бизнесом. И решать его проблемы, а не просто делать как попросили.


                                почему демо не работает нормально на телефоне?

                                Что именно не нормально?


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

                                В этом нет нужды, если пользователи не идиоты.


                                И стандартный множественный выбор работает несколько по другому и сильно удобнее вашего прочтения.

                                Нет никакого "стандартного" множественного выбора. Если вы говорите о v-select, то это даже не смешно. Чтобы убрать элемент придётся искать его глазами в выпадающем списке, где даже поиска не предусмотрено.


                                А time так где?

                                А время проще и быстрее клавиатурой набрать, чем вспоминать в какой части циферблата находится нужное число.


                                а выбор диапазона дат/времени есть?

                                Это как-нибудь в другой раз.


                                Ну и в продолжении, дизайн Vuetify того же можно использовать из коробки и будет красиво и современно.

                                У material design очень много недостатков. Самый большой — оформление инпутов в виде подчёркивания. Из-за чего даже опытные пользователи порой не замечают куда можно вводить, путая подчёркивание с разделителями. Эта мода вскоре пройдёт.


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

                                Как раз таки подход $mol позволяет легко и просто дорабатывать хоть свои, хоть чужие компоненты. Что я вам сегодня и продемонстрировал. Это попросту невозможно в "большой тройке". Именно поэтому на них любой yне совсем тривиальный компонент вырождается в монстра с сотней пропертей как у того же v-select. На них крайне сложно делать ортогональные компоненты, из которых можно было бы собирать интерфейсы как из кирпичиков.

                                  0
                                  Вы знаете. На этом я закончу разговор с вами :)
                                  Это похоже на разговор слепого с глухим :)

                                  Если у вас нет пользователей идиотов, и они готовы делать лишний клик для выбора нескольких элементов, то я искренне вам завидую :) удачи :)

                                  И да, ваша демка на айфоне выглядит так. Видимо так задумано и так удобно?
                                  image
                                    0
                                    лишний клик для выбора нескольких элементов

                                    Я это уже починил. Вы слишком торопитесь с выводами.


                                    Видимо так задумано и так удобно?

                                    У вас открыто боковое меню, которое сдвинуло страницу вправо. Если так у вас отображается сразу при загрузке, значит баг. Свайпните влево.

                                      0
                                      Я это уже починил. Вы слишком торопитесь с выводами.


                                      Нет, не починили. Чтобы выбрать 2 элемента надо сделать минимум 4 клика, тогда как в нормальном можно обойтись тремя. И при увеличении количества вариантов разница будет множится, так как после каждого выбора вы закрываете всплывающее окно.

                                      У вас открыто боковое меню, которое сдвинуло страницу вправо. Если так у вас отображается сразу при загрузке, значит баг. Свайпните влево.


                                      Я их тех идиотов, которые не могут догадаться о таком «красивом» и интуитивно непонятном решении :) А если это баг и оно должно быть скрыто, то становится непонятно как его вызвать вообще :)

                                      И странно, что я за полчаса просмотра вашего замечательного фреймворка уже нашел 3 бага :)
                                        –1

                                        Да я тоже поторопился. Запушить забыл. Сейчас уже выкатилось.


                                        Свайпом оно вызывается, как обычно.


                                        Ничего странного и уж тем более смешного на самом деле. Он развивается на голом энтузиазме нескольких человек.

                                          0

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

                                            0

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

                                              +1

                                              Мелких багов? Когда основные элементы вообще не работают как надо? И это еще даже к разработке не приступили, а посмотрели демо?
                                              Еще раз удачи вам, мы живем в разных мирах и делаем разный софт… видимо даже для жителей разных планет /э:) этот разговор бесполезен в таком ключе :)

            0
            .
              0

              Компоненты есть в сторонних наборах — например vuetify

                0

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

                  0

                  У всех трех компоненты не встроены и это правильно. Берете понравившийся набор и работаете.


                  из разных наборов плохо совместимы друг с другом
                  что конкретно имеется ввиду?
                    0
                    Зачем совмещать наборы из разных компонент? Если вам не хватает компоненты в каком-то наборе, сделайте её сами. Это вообще не сложно.
                    Естественно, что они не будет совместимы, ведь это разные наборы.
                      0

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


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

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


                        легко — vuejs + Vuetify + vue-chartjs + vue_yandex_map + aggrid
                          0

                          Перевожу на человеческий:


                          • Берём фреймворк "для крупномасштабных проектов".
                          • Добавляем набор компонент на нём.
                          • Добавляем биндинг к тормозной библиотеке графиков, написанной на своём собственном фреймворке, которая ничего не знает про систему реактивности фреймворка и не подхватывает тему из набора компонент.
                          • Добавляем биндинг к библиотеке карт, написанной на своём собственном фреймворке со своей библиотекой компонент, которая не подхватывает тему из нашего набора компонент.
                          • Добавляем биндинг к библиотеке датагридов, написанной на своём собственном фреймворке со своей библиотекой компонент, которая не подхватывает тему из нашего набора компонент и ничего не знает про систему реактивности фреймворка.
                          • Тратим кучу времени на приведение всего этого лоскутного одеяла к божескому виду.
                          • Получаем тормозящего монстра, грузящего мегабайты кода на клиент: 4 разных фреймворка; 4 разные реализации тултипа, выполненные в разном дизайне; 3 разные реализации кнопки/поля ввода/чекбокса/и тп, выполненные в разном стиле; и так далее.

                          И это мы ещё даже не начали писать собственно прикладную логику..

                            0
                            Выполняем следующие команды:

                            vue create hello-world
                            vue add vuetify
                            npm install vue-chartjs chart.js --save
                            npm install vue-yandex-maps --save
                            npm install --save ag-grid-community ag-grid-vue vue-property-decorator

                            Окружение готово, заняло не больше 10 минут. Работает сразу, все в божеском виде и никакого лоскутного одеяла не видно. Chartjs, так же как и aggrid прекрасно работают с реактивностью, никаких биндингов «добавлять» не надо. Тема по умолчанию у них совпадет :) Кнопка есть только одна из vuetify. Тултипы возможно и есть разные в гриде и графиках, но при желании все НЕ СЛОЖНО приводится к единому виду.

                            Вес указанного набора в сжатом виде около 350Кб (Мы такое запихиваем в контроллеры на ATMega и STM).
                              0
                              Chartjs, так же как и aggrid прекрасно работают с реактивностью,

                              Речь не о том, что оно не работает, а о том, что работает оно не оптимально. Реактивность Vue умеет оптимизировать потоки данных. На биндингах вся эта оптимизация обламывается.


                              никаких биндингов «добавлять» не надо.

                              ag-grid-vue, vue_yandex_map, vue-chartjs — это и есть биндинги к библиотекам.


                              все в божеском виде и никакого лоскутного одеяла не видно

                              Это просто не правда.


                              Вес указанного набора в сжатом виде около 350Кб

                              Напомню, что это вы ещё не написали ни строчки прикладного кода, а время загрузки уже 5с на 3G.

                                0
                                Это просто не правда.


                                Почему? Потому что не совсем оптимально написано? Да, возможно. Но позволяет это делать удобно, быстро менять какие то части. Сегодня мы используем такой грид или datetime picker, а завтра вышла новая библиотека и мы перешли на нее. Просто и без танцев с бубнами в виде переделки фреймворка. Или взяли и разработали свой со своим блэкджеком. Не зря ведь в том же VUE логика отделена от графических элементов. Есть свобода для маневра. Хочешь простой интерфейс берешь какой нибудь Buefy, нужен сложный — Vuetify. при этом логика у тебя остается единой. У нас даже есть приложения где используются 2 UI библиотеки одновременно. Одна для рабочих мест на складах, вторая для офисных работников. Нижний слой логики у них один. А возможно появится и 3-й UI на этом проекте для открытого сайта. Там свои требования, в том числе и к скорости загрузки первой страницы.

                                Вы же предлагаете делать только так как вы решили и только это считаете правильным. При таком подходе вам очень сложно будет продавать слона. Может быть в этом проблема того, что продукт не становится популярным?

                                Напомню, что это вы ещё не написали ни строчки прикладного кода, а время загрузки уже 5с на 3G.


                                По сути, когда мы реализуем нормальное бизнес приложение с полнофункциональными гридами, пользовательским интерфейсом и графиками — кардинально меньше у вас не получится. Да и грузится это пользователю только в первый раз. И да, львиную долю (около половины) из этих 350 килобайт занимает шрифт Roboto, который сильно хотят дизайнеры и иконки material icons, хоть и в урезанном нами формате :) Ваш продукт как в этом случае будет себя вести? :)
                                  0
                                  Почему?

                                  Перечитайте сообщение, которое я цитировал.


                                  При таком подходе вам очень сложно будет продавать слона.

                                  Вы наивно полагаете, будто я вам что-то продаю. Опуститесь на землю, вы не пуп земли, а я не корпорация добра. Я прежде всего делюсь идеями. Экономить вам деньги — не в моих интересах.


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

                                  Получится. Вот, например, портал https://mol.hyoo.ru/ весит всего 140кб. А там все моловские компоненты со всеми их демками и ещё несколько приложений.


                                  из этих 350 килобайт занимает шрифт Roboto

                                  Который на Андроиде уже есть, а вы грузите ещё раз.

                                    0
                                    Вы наивно полагаете, будто я вам что-то продаю. Опуститесь на землю, вы не пуп земли, а я не корпорация добра. Я прежде всего делюсь идеями. Экономить вам деньги — не в моих интересах.


                                    Странно, а зачем тогда Фреймворк, если не денег экономить? просто для души? :-) Ну тогда вопросов нет :)

                                    Который на Андроиде уже есть, а вы грузите ещё раз.


                                    Андроидом мир не ограничивается, Еще есть другие мобильные платформы и десктопы :-) Если вы их не учитывает во фреймворка, то это очень странно.

                                    Получится. Вот, например, портал mol.hyoo.ru весит всего 140кб. А там все моловские компоненты со всеми их демками и ещё несколько приложений.


                                    И что я вижу при первом заходе? Потрясающе:

                                    image
                                      0

                                      Мне-то он экономит деньги и, главное, время.


                                      А на iOS пользователи привычны к другим шрифтам.


                                      Он ещё в разработке.

                                        0

                                        Вы предлагаете на одном сайте для ios, android и для разных десктопов делать разные шрифты? Это же сколько дизайнеров надо? :))

                                          0

                                          font-family: system-ui


                                          С вас месячная ставка дизайнера.

                                            0

                                            Такой дизайнер мне нафиг не нужен :) а бизнес с которым я работаю будет гнать такого нечистыми тряпками по улице :) потому как выглядеть будет отвратительно. Но у вас все такое…

              0

              Если допилят в этом году, то я бы поставил на Rome

              • НЛО прилетело и опубликовало эту надпись здесь
                  0
                  Сейчас и React и Vue и даже Svelte поддерживают TypeScript, так что перевод очень поверхностной статьи
                    +2

                    Насколько я понимаю, в Angular в основе лежат Observables (лучше всего их постигать на примере RxJS, там хорошая дока), там с ними приходится довольно плотно работать.


                    Рискну предположить, что это и есть причина того, почему у Angular больше соотношение «работал раньше, больше не хочу». Сложность. Observables, при всей их концептуальной красоте, для обывателя значительно сложнее в постижении, чем… их отсутствие. Вокруг них, как вокруг регулярных выражений (к примеру), у стандартных инженеров витает аура «какая-то непонятная хрень, ну ее, лучше напишу пару ифов и циклов»; очень жаль, конечно, что так (вещь-то хорошая), но что поделать.


                    Также Observables являются боковой веткой в теме асинхронности, на которую, например, JS решил НЕ делать ставки (ставку сделали на AsyncIterables, которые pull, а не push — резонно заключив, что backpressure проще осознать на стороне читателя, а не писателя). В AsyncIterables тоже полно проблем, конечно, но сложность (и порог вхождения) у них ниже.

                      –2

                      Рискну предположить, что при всей своей могучести, создание компонентов в Angular — боль. По сравнению с Реактом (да почти с кем угодно).


                      Невозможность сделать компонент без обертки в виде хост-элемента (привет от Flexbox), невозможность динамически навешивать директивы (что до безумия усложняет создание своих компонентов и директив на базе стандартных), так себе поддержка typescript (до сих пор нетипизированные let-переменные в ng-template — хотя с каждым релизом все лучше и лучше становится, надо признать).


                      И к слову об observable — либо 100500 дублирующихся | async в шаблоне, либо ручные подписки, либо создать новый вложенный "синхронный" компонент (а как мы помним, создавать компонты — боль).

                        +1
                        Невозможность сделать компонент без обертки в виде хост-элемента

                        Вы про то, что для конкретного компонента нужен селектор? Типа такого:


                        <my-component></my-component>

                        Это вы называете проблемой?


                        невозможность динамически навешивать директивы (что до безумия усложняет создание своих компонентов и директив на базе стандартных)

                        Вы об этом?


                        <my-component [customDirective]="dynamicValue"></my-component>

                        Когда нужен больший уровень динамичности?


                        так себе поддержка typescript (до сих пор нетипизированные let-переменные в ng-template...

                        Есть такое. А еще есть слабо-типизированный модуль реактивных форм, это действительно немного странное упущение разработчиков. Хотя, если вспомнить уровень развития TypeScript на момент релиза Angular 2 (сентябрь 2016 г.), тогда еще не было дефолтных значений для дженериков, а потому на тот момент строгая типизация несколько усложнила бы работу с реактивными формами. Сейчас с этим значительно проще, и наверное поэтому Angular roadmap имеет планы улучшить тут положение дел.

                          +1
                          <my-component></my-component>

                          Да, об этом. Дело не в селекторе как таковом, а в том, что это именно отдельный DOM-элемент. Это усложняет стилизацию, завязанную на прямое отношение родитель-ребенок. Flexbox — яркий пример, где флекс-элементы должны быть непосредственно вложены во флекс-контейнер. В Реакте у меня такой проблемы не было, потому что компонент реакта существует только в virtual dom, а в реальный ДОМ попадает только контент, который этот компонент рендерит.


                          <my-component [customDirective]="dynamicValue"></my-component>

                          Не совсем.
                          Хочу сделать кастомный элемент-ссылку. В зависимости от типа ссылки он будет рендерить или [routerLink]="link", или [href]="link". [routerLink] — директива, ее нельзя динамически включить/выключить.


                          Или делаю кастомный компонент-кнопку. В зависимости от инпута, она должна быть mat-raised-button или mat-stroke-button. Опять же, mat-raised-button — директива, ее динамически не повесишь. Приходится в темплейте дублировать разметку для каждого случая. В реакте это бы выглядело как-то так


                          const ButtonComp = props.raised ? RaisedButton : StrokeButton;
                          return <ButtonComp {...buttonProps}>;

                          А теперь усложняем — хочу композит, который будет или ссылкой, или кнопкой (и покажет промежуточный диалог). Получили комбинаторный взрыв в темплейте.

                            0
                            В angular есть шаблоны(ng-template). Которые позволяют отрендерить нужный шаблон в зависимости от условия, передавать через инпуты и многое другое. Для ряда случаев можно использовать ng-container. Вариации использования много. Ваши претензии исходят из отсутствия глубокого понимания возможностей фреймворка или привычки писать под react.
                            Можно долго холиварить по поводу что лучше, что хуже. Тут надо исходить из требований и объема. Лично для меня уже сложилось мнение, что для чего-то простого, небольшого сайта — лучше svelte. Для чего-то посложнее, но не более — react. Если требуется сделать сложную, большую систему — лучше angular. Одним из простых причин выбора для последнего DI, без него сложно строить сложную систему максимально просто.
                            Насчет vue ничего не могу сказать толкового, не изучал особо, честно и желания нет.
                              0
                              В angular есть шаблоны(ng-template)

                              Они (1) многословные (это вкусовщина, конечно, можно игнорировать), (2) только для контента внутри элемента. Все атрибуты (в моем примере с mat-raised-button / mat-stroke-button) на каждую кнопку все равно придется дублировать.


                              Можно возразить, конечно, что проблема не в Ангуляре, а в Material (ну в самом деле — что мешало сделать одну параметризированную директиву mat-button="raised", как сделали в имплементации под реакт). Но пока что имеем то, что имеем.


                              Да, я понимаю, что мои претензии исходят из привычки любую проблему решать композицией компонентов (в реакте). Но более элегатного способа решения моих проблем я не нашел. Может, вы подскажете, как сделать динамическую кнопку из моей (не-)гипотетической задачи выше? Так, чтоб без дублирования кода.

                                0
                                В варианте с кнопками столь же изящного варианта нет, как минимум из коробки. Самый простой вариант из коробки и возможно наиболее правильный — это объявить шаблоны. Далее использовать NgTemplateOutlet для вывода нужного шаблона в зависимости от условия. Даю + за react).
                                Так к слову mat-raised-button — это не директива, а компонент. Просто она хостится не на новый тип тэга, а на существующую
                                  0

                                  Угу, так и сделали в итоге. Шаблон для содержимого кнопки, и продублировали объявление самой кнопки с ее атрибутами/обработчиками для каждого варианта.


                                  Могу еще пару примеров накидать из реального проекта. Типовые, казалось бы, задачи по расширению существующих компонентов приходится решать обходным путем.

                              0

                              Ах да, действительно. Это я уже на автомате даже не думаю о подобной динамичности, знаю, что она отсутствует на данный момент в Angular, иду сразу обходными путями. А так — да, хорошо бы иметь возможность, например, добавить динамично ту же директиву [routerLink]="link" в HTML-код преобразованный с Markdown-кода.

                                0
                                директиву [routerLink]="link" в HTML-код преобразованный с Markdown-кода.

                                Ха! Мы в итоге написали свой мини-парсер для двух-трех тэгов маркдауна (ссылки, базовое форматирование). И ангуляр-компонент, который умеет рендерить структуру данных с выхода этого парсера.


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

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

                                  Здесь пайпы хорошо подходят. В моем случае это элементарний пайп:


                                  import { Pipe, PipeTransform } from '@angular/core';
                                  import { DomSanitizer, SafeHtml } from '@angular/platform-browser';
                                  import { Marked } from '@ts-stack/markdown';
                                  
                                  @Pipe({ name: 'mdToHtml' })
                                  export class MdToHtmlPipe implements PipeTransform {
                                    constructor(protected sanitizer: DomSanitizer) {}
                                  
                                    transform(value: string): SafeHtml {
                                      return this.sanitizer.bypassSecurityTrustHtml(Marked.parse(value || ''));
                                    }
                                  }

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


                                  <div [innerHtml]="markdownText | mdToHtml"></div>
                                    0

                                    Эм, я думал, задача — навесить директив внутрь полученного html.


                                    Отрендерить html как есть — тривиально (что отлично продемонстрировано вашим примером)

                                      0

                                      Получается мы друг-друга не поняли.


                                      Мы в итоге написали свой мини-парсер для двух-трех тэгов маркдауна (ссылки, базовое форматирование). И ангуляр-компонент, который умеет рендерить структуру данных с выхода этого парсера.

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

                                        0

                                        А, сорри :). Я имел в виду, что поскольку этот наш компонент принимает на вход не html, а распарсенную структуру, он знает, как рендерить каждый тип блока (ссылка, выделение, простой текст). И при рендеринге блока типа "ссылка" использует routerLink. Примерно так


                                        <a *ngIf="block.type === 'link' [routerLink]="block.path">...</a>
                                        <ng-container *ngIf="block.type === 'text'>{{block.text}}</a>

                                        Кстати, сразу вспомнил про еще одну насущную проблему с TS в шаблонах — ngIf/ngSwitch не поддерживают type narrowing. Привет type assertions.

                                    0
                                    Мы используем дефолтный github.com/jfcere/ngx-markdown он много всего поддерживает, но в итоге получается довольно много весит(для нас это не критично)
                                    И из за этого пришлось вешать обработчик клика через renderer2.listen, что в общем то тоже не красиво, но зато дешево написать обработчик :)
                                  0
                                  По поводу Флекс бокса не особо понятно. Оставляю пример из своего проекта
                                       <section class="d-flex flex-wrap justify-content-center">
                                            <jobs-contract-card
                                              *ngFor="let job of jobsMatches"
                                              class="col-12 col-md-6 col-xl-4 mb-3 mb-xl-0"
                                              [job]="job"
                                              [navigateTo]="'/jobs/view/' + job.id"
                                            ></jobs-contract-card>
                                        </section>
                                  


                                  Как вы можете видеть, я поместил компонент в флекс-контейнер. Компонент работает как и ожидалось, тоесть как дочерний элемент.
                                    0

                                    Сложности начинаются, когда надо внутренности jobs-contract-card завернуть, например, в ссылку. Но так как между ссылкой и section будет ещё один промежуточный элемент jobs-contract-card, то привет костыли в css.

                                      0
                                      можно попробовать компонент с атрибутным селектором. Примером может служить кнопки из material
                                        0

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

                                          0

                                          Да, именно так.
                                          Директивы не могут навешивать другие директивы, из-за чего невозможно сделать новую директиву как композицию из двух имеющихся.
                                          Например, кастомная директива ссылки на сущность, которая принимает сущность как инпут и навешивает routerLink и matTooltip (или даже просто routerLink плюс класс для стандартной стилизации)
                                          Приходится делать компонент-обертку над <a>.

                                            +1

                                            Уж не хотите ли вы сказать, что ангуляр дураки проектировали? Вы не должны этого хотеть!

                                              0

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


                                              В моем идеальном мире ангуляр скрещивается с реактом (компоненты пишем на jsx; инфраструктура и DI из ангуляра) :)

                                                0
                                                Не очень понимаю направление ваших мыслей. Директивы представляют собой методы расширения. По своей сути они несут в себе все те же правила создания и использования. Это не плохо и не хорошо
                                        0

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

                                    0

                                    Либо реализовать suspense-api на базе mobx и форкнуторго mobx-angular. Тогда про асинки со стримами можно забыть как про страшный сон.

                                    +1
                                    Согласен, Observables сложные по началу для понимания. Но я как только начал их понимать и как с этим рабоать, мне было за радость их использовать. Это прям серьезно такая магия в виде декларативного кода, в то время пока разрабы на Реакте используют всякие Lodash, сложные логические конструкции, мы на ангуляре испольуем уже готовые операторы в библиотеке RxJs
                                    0
                                    vue очень хорош
                                      0

                                      Blazor. Net круче всех

                                        0
                                        Vue — это проект, который появился сравнительно недавно. >
                                        Разница в релизах с реактом меньше года.
                                        Хочется больше конкретики. Что, почему, какие выводы и т.д.

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

                                        Самое читаемое