Фреймворки Javascript: тщетная попытка объективности

Персональный взгляд на текущее состояние фреймворков JavaScript

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

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

В этой версии есть то, чего нет у двух других: честность.

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

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

Я хотел написать эту статью, потому что чувствовал, что выводы, сделанные людьми, радикально отличаются от тех, что делались ранее. Многие думали, что я искренне указываю на недостатки JS-фреймворков. Мне сказали, что я должен «сделать свой собственный», или люди сказали: «Наконец-то кто-то это сказал! Вот почему я не использую фреймворки! »

Я не собираюсь здесь спорить со своим мнением. Они просто такие. Я с удовольствием общаюсь с людьми, но бессмысленно пытаться убедить меня еще раз, что JSX - хорошая идея.

Угловой 1

Angular сейчас занимает интересное место в веб-разработке. Дело в том, что Angular 1 по-прежнему остается коммерческой реальностью. Если вы посмотрите на окупаемость инвестиций (RoI) для технологий, то доходность таких вещей, как Angular, зашкаливает. Хотя количество комментариев и пропаганды стремительно падает, фактическое использование технологий бизнесом выше, чем когда-либо. Его краевые проблемы решены, он имеет широкий спектр инструментов и знаний, хорошо документирован с помощью обучающих и обучающих ресурсов, а также у него огромное количество квалифицированных и опытных разработчиков.

Как и многие люди, Angular был первым фреймворком, которому я научился - не говоря уже о jQuery, который мы по незнанию называли фреймворком. Как и многие люди, мне не очень нравится Angular, но мне он не нравился, прежде чем он стал крутым.

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

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

Для агентств и коммерческих студий разработки, которые создают большое количество небольших приложений за короткие циклы разработки, трудно отказаться от Angular. В этом отношении он немного похож на Wordpress. Это может быть немного неприятно (WP выходит далеко за рамки немного), но так же трудно рекомендовать что-то еще в качестве альтернативы этому варианту использования с каким-либо объективным аргументом.

Несмотря на то, что думают разработчики, вам, вероятно, на самом деле не нужно ничего, кроме OG Angular, для подавляющего большинства приложений. Хотя он и медленный, честно говоря, он достаточно быстр для случая, когда он намного превышает 80%. Несмотря на то, что он старый, клиенты не платят за «современный». Как известное решение известной проблемы, Angular трудно превзойти. И как маркер в резюме, он также исключительно ценен.

Угловой 2

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

У Angular 2 есть сильные и слабые стороны, он же излишне неоднозначный AngularJS. Его синтаксис шаблона сбивает с толку и отталкивает постороннего, и требование иметь чувствительные к регистру свойства HTML вызывает беспокойство. Однако его сильные стороны тоже заметны.

Одно из выдающихся достижений - это наблюдаемые. Angular реализует Microsoft's RxJS Observables, шаблон, который, хотя и труден для понимания (и, честно говоря, вероятно, не подходит для простого доступа к данным), отлично подходит для более живых веб-сокетов и потоковых материалов в реальном времени. Вероятность того, что Observables не принесет никакой пользы вашему приложению, весьма высока, но если оно подходит, то вполне может спасти жизнь.

Angular 2 также использует форк превосходного интерфейса командной строки Ember, который действительно помогает его запустить и запустить, а также помогает создать продуктивный «счастливый путь», а также генерировать множество шаблонов, запускать тесты и т. Д. Webpack - хороший выбор.

Машинопись тоже отличная. При использовании немного менее хаотичных языков, таких как C # или PHP, IDE может многое сделать, чтобы помочь понять, какие функции доступны и как их использовать. В типичных JS-приложениях этого нет, а в среде IDE нет четкого представления о том, как все работает, какие методы доступны и как их вызывать. Машинопись возвращает этот контроль, знания и дисциплину. Он действительно вводит этап сборки, но вам уже придется переносить его повсюду, так каков еще этап сборки?

Одна область, в которой Angular 2 определенно ошибся, - это брендинг. Google поощряет людей называть его именно Angular, как в логотипе выше. Они делают это в значительной степени потому, что хотят, чтобы их выпуски были основными версиями без серьезной реструктуризации, связанной с переходом с 1 на 2. Angular 4 уже находится в стадии бета-тестирования. Однако в этом бренде крайне не хватает актуальной информации. AngularJS - это уже то, что люди называли Angular 1, поэтому попытка провести какое-то различие (например, в этой статье) превращается в путаницу. От этого страдает сам бренд. Https://angularjs.org/ предназначен для OG NG, а новая версия находится в https://angular.io/. Тем не менее, может быть трудно сначала узнать, о какой версии идет речь в том или ином контексте.

Angular 2 - не мой любимый фреймворк. Мне нравится многое из того, что он пытается сделать, но мне кажется, что он сделал много ошибок на своем пути. Тем не менее нельзя отрицать, что с точки зрения коммерческой реальности Angular 2 невозможно игнорировать. Многие компании с устаревшими приложениями Angular обновятся непосредственно до Angular 2.

Если вы выбираете фреймворк специально для ценности резюме, и вам нужно что-то комплексное, не отставайте от последней версии Angular.

Аурелия

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

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

Aurelia также изначально поддерживает Typescript, хотя и немного менее активно, чем Angular 2, рассматривая ES6 и TypeScript как первоклассных граждан.

Еще одна вещь, которая на удивление хороша, - это инструмент командной строки Aurelia. Он все еще находится в стадии бета-тестирования, но по функциональности близок к Ember. К сожалению, многое из этого все еще немного больше ручного, но это хороший шаг в правильном направлении.

Однако Аурелия страдает в двух областях. Первый и наиболее очевидный - это усыновление. Это нетривиальная проблема, и ее нелегко исправить. Найти учебные ресурсы, образцы кода или советы по устранению неполадок гораздо сложнее, чем приложение Angular или React. Найти персонал также сложнее, но, в отличие от некоторых других фреймворков, будет достаточно просто знания ES6 и Typescript.

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

Там, где Аурелия действительно пытается действовать по «стандартам», она иногда делает ошибки. Например, наиболее «стандартным» импортом является SystemJS, на котором основана JSPM, но это не та система импорта модулей, вокруг которой отрасль стандартизирована. NPM с чем-то вроде Webpack - гораздо более распространенный подход. Почти наверняка CLI Аурелии переходит на это, но пока все немного неопределенно.

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

Ember

Я не скрываю, что поддерживаю Ember, но хочу очень быстро сказать почему. Это не потому, что это сложно, сложно или мощно. Потому что в нем легко и быстро развиваться.

В чем Ember действительно выделяется, так это в его рабочем процессе. Все управляется невероятно мощным интерфейсом командной строки, который устраняет или упрощает инструменты сборки, управление зависимостями, тестирование и многое другое. Строительные леса - это одна команда. Выполнение теста - это одна команда, включая модульные тесты, интеграционные и приемочные тесты с полным набором средств тестирования в командной строке. Генерация шаблонов - это одна команда, которая автоматически генерирует тестовые заглушки. Управление зависимостями - это одна команда, которая загружает зависимости npm и bower, импортирует ресурсы и обновляет инструмент сборки для реализации новых требований.

Интересно, что он воспринимается как «сложный». Я не уверен, что это действительно разумный вывод, если взглянуть на него всесторонне. Фактический API фреймворка может быть относительно большим, но его конфигурация или сложность инструментов практически равна нулю. В этом пространстве также не было абсолютно никакого «оттока», что освободило разработчиков Ember от испытаний процессии Grunt, Gulp, Browserify, Webpack.

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

Механизм рендеринга Ember был недавно переписан на TypeScript для значительного увеличения производительности и производительности, и в медленных частях Ember, несомненно, будет происходить тот же процесс.

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

Ember нужно (и будет) становиться быстрее и легче, поскольку основные разработчики уделяют большое внимание производительности мобильных устройств. Стоит отметить, что весь Ember теперь имеет ту же скорость, что и React, с управлением состоянием MobX.

В последнее время у Ember возникли проблемы с приземлением. У него есть несколько удивительных и очень необходимых функций в разработке. Компоненты угловых кронштейнов являются прекрасным примером. Они были реализованы в 2.10, но эта функция была отключена, потому что оказалось, что у нее есть неприятные крайние случаи. Теперь он в подвешенном состоянии. Fastboot упрощает рендеринг на стороне сервера в потрясающе продуманном пакете. Но это в подвешенном состоянии. Svelte Builds находится в подвешенном состоянии. Изменения в подходе к импорту модулей, унифицированному тестированию и другим важным функциям находятся в подвешенном состоянии.

На многие из них есть очень веские причины. Glimmer 2, полная замена движка рендеринга, только что выпущен, и многие из этих функций были задержаны этим. Я очень оптимистичен, что с этим, команда Ember сможет приступить к реализации функций, как будто это конец Крепкого орешка 2.

Я предпочитаю Ember. Причин тому очень много, хватит на целую отдельную статью. Суть его в том, что подход Ember соответствует моему восприятию проблемы, которую я хочу решить с помощью фреймворка. У него есть рабочий процесс, который позволяет мне сосредоточиться на разработке приложений, а не на создании инструментов.

Когда я прихожу к чему-то с Ember, мне кажется, что у меня полный ящик для инструментов. Конечно, коробка «тяжелая», но в ней есть инструменты, которые мне нужны, чтобы делать удивительные вещи. И что наиболее важно, это упрощает сложные вещи.

Метеор

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

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

Это DDP. DDP - это уникальная система PubSub от Meteor для событий и данных. Несомненно, в DPP есть положительные стороны. Поскольку это подсистема pub, она идеально подходит для приложений реального времени. То, для чего он не подходит, совсем ни для чего другого. Все остальные фреймворки JavaScript не зависят от серверной части. Неважно, используете ли вы PHP, Ruby, .NET или Elixir.

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

Еще одна критика: некоторые вещи, которые должны быть легкими, не связаны, в частности, с рендерингом на стороне сервера. Реализация SSR в Ember требует двух простых записей в командной строке. Vue требует простой оболочки для стандартных объектов. Реализация AngularJS, честно говоря, ужасна, но, по крайней мере, хорошо документирована с помощью целого специализированного подсайта.

Это реализация Meteor: ¯ \ _ (ツ) _ / ¯

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

Необъяснима и идея с двумя маршрутизаторами. Найти образец кода Meteor сложно, но у того, что есть, всегда есть одна общая черта: огромный файл router.js. Я не уверен, является ли «Fat Router» официальным антипаттерном, но, возможно, так и должно быть.

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

Реагировать

React интересен с точки зрения индустрии. Долгое время это была единственная альтернатива Angular. В частности, это был современный вариант, и большинству разработчиков казалось, что это путь вперед. Его структура, основанная на «компонентах», когда-то была новой и революционной, но теперь она используется по умолчанию.

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

Библиотека, несомненно, использовалась для создания потрясающих инструментов. Netflix - это приложение на React. Такие компании, как Uber, AirBnB, Wix и другие, React, React, React. Несомненно, это любимец стартапов. Бесконечно гибкий, полный контроль.

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

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

Разработчик React должен вручную, сознательно и явно добавлять функциональность, которую разработчик Ember, Angular или Aurelia считает само собой разумеющимся. Даже роутер. И именно в этот момент преимущества производительности, о которых давно заявлял React, начинают исчезать. Самые последние тесты фреймворка JavaScript по-прежнему показали, что Ember примерно самый медленный. Но новейший Ember работает идентично React с управлением состоянием MobX и очень близок к React со стандартной опцией Redux. Сколько пакетов и дополнений до React на самом деле менее производительно, чем монолиты, но при этом приносят меньше и несут больше багажа при настройке решения?

Стоит отметить, что это конкретно Ember. Angular 2 и Aurelia уже намного быстрее, но при этом обеспечивают обширную функциональность.

Было бы невозможно говорить о React, не говоря о JSX. Это очень субъективно. Ненавижу JSX. Я считаю это ужасным. Может быть, я стар и те времена давно прошли, но мне двадцать лет говорили, что вы не выводите разметку из функции. И я провел десять лет, смеясь над Wordpress и насмешливо указывая на то, что он это делает. Подойти и сказать, что все правила другие и разделение интересов больше не имеет значения ...

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

И я также знаю, что это не совсем HTML и это синтаксический сахар по сравнению с функциями рендеринга, но проблема заключается в абстракции, а не в базовом коде, так что ответ такой же, как если бы PHP API в порядке, потому что все это магнитно закодированные единицы и нули.

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

Vue

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

У меня проблемы с Vue, так это с обменом сообщениями. Vue позиционирует себя как прогрессивный фреймворк. Это означает, что Vue должен быть таким же простым в использовании, как и jQuery, извлеченный из CDN. А затем можно масштабировать до решения любого размера.

Но в этот процесс масштабирования приходится много размахивать руками. Например, почти все другие фреймворки используют подход по умолчанию для той или иной формы процесса сборки. Ember и Meteor включают его в свой рабочий процесс по умолчанию. React обманывает этот процесс, превращая свой официальный код «начала работы» в предварительно настроенный код. Но все другие фреймворки, похоже, признают, что отдельные модули, скомпилированные и построенные каким-либо процессом, являются единственным допустимым способом создания современного JavaScript. Только Vue делает вид, что есть какой-то другой вариант, и поддерживает этот вымышленный рабочий процесс CDN.

Это означает, что только Vue имеет шаг «заставить его работать должным образом» между исходным кодом демонстрационного приложения и фактическим производственным кодом. Слишком много документации и брендов Vue фокусируется на том, насколько «легко» начать работу, что приводит к некоторым презентациям гномов-трусов.

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

В качестве другого примера я видел статью на Reddit о том, как реализовать систему pub / sub в VueJS. Это был продвинутый учебник, насыщенный кодом. Что сразу же вызывает вопрос: если вы этого хотите, почему бы вам не использовать фреймворк, который уже имеет эту функциональность, или аналогичную расширенную систему событий и действий?

Разработчик Vue Эван Ю недавно сделал отличную презентацию, в которой обсудил разницу между тем, что он назвал внутренней сложностью и сложностью инструмента. В частности, разница между тем, насколько сложно решить проблему, и насколько сложно управлять решением.

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

Продолжая метафору Ember о ящиках для инструментов, я чувствую, что использование Vue - это просто появление Кожаного Человека и действия, как будто это все, что вам нужно.

Послушайте, у меня есть отвертка и плоскогубцы. А если мне понадобится молоток, я могу просто купить его в магазине. А потом куплю пилу. Зачем таскать столько вещей? Это просто вздор! У меня есть Кожаный Человек. Это набор инструментов прогрессивного.

Связь с Laravel интересна. Известность Laravel в сообществе PHP - важный фактор, способствующий заметности Vue. Лучшим учебным ресурсом Vue, вероятно, является Laracasts. Привязки Vue теперь по умолчанию доступны в Laravel. Если Vue нужно использовать в качестве дополнения к существующему приложению на основе Laravel, это вполне разумный подход. Но для сложной проблемы - одностраничных приложений - шаблон - катастрофа. SPA гораздо лучше сделать в виде двух отдельных приложений, двух отдельных репозиториев, с двумя отдельными наборами тестов, двумя отдельными стратегиями развертывания и т. Д.

Слабость Vue - его рабочий процесс. Например, у него есть худший инструмент командной строки. Защитники хвалят его за то, что он гибкий, но поскольку он не обеспечивает разумных значений по умолчанию, он заставляет разработчика заранее определять, какие требования у него будут и какой шаблон подходит. Вы хотите просматривать или веб-пакет? Какие последствия? Простой или полный? Что вы получаете или теряете с любым из них? Узнать это нетривиально. React может предлагать очень ограниченную функциональность в приложении response-create-app, но он справедливо предполагает сборку веб-пакета, перенос babel, сервер разработки и т. Д.

Vue молод. Вероятно, со временем он созреет. Разработчики Vue начнут сосредотачиваться на том, как решать вопросы о поддерживаемой и стабильной доставке программного обеспечения, а не на том, как легко сделать кнопку. Они начнут больше беспокоиться о плохом опыте тестирования или о том, как последовательно моделировать сущности предметной области, чем о количестве миллисекунд для вставки 10 000 строк в DOM. Это неизбежная часть цикла хайпа Gartner, текущая высокая видимость приведет к более зрелой платформе, ориентированной на лучшие практики и производство, а не на «начало работы» и тривиальные примеры.

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

Заключение

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

Тем не менее, интересно, что мои мнения достаточно хорошо согласуются с Thoughtworks, гигантами отрасли. Их технический радар отстаивает только два фреймворка для безоговорочно рекомендованного статуса Adopt: Ember и React. У Vue и Aurelia самый низкий нейтральный статус Assess. (Категория между: Пробная версия.)

MeteorJS имеет самый низкий статус Hold для технологий, которые не рекомендуются для использования:

Мы думаем, что идея отличная, даже если фреймворк еще не готов к использованию.

Еще нет. Описание не обновлялось годами, что говорит о том, что вид не изменился. AngularJS находится в том же состоянии Hold, и, что любопытно, не делается различий между Angular 1 и 2, хотя я считаю, что это упущение, которое будет исправлено в апрельском выпуске радара.

Thoughtworks - это бизнес-ориентированная консалтинговая компания, которая избегает передовых технологий, предпочитаемых энтузиастами и защитниками, что, на мой взгляд, делает ее хорошим ориентиром для определения долгосрочной стоимости.

Один из факторов, который люди редко принимают во внимание при выборе фреймворка JavaScript, - это то, к какому бэкэнду он должен подключаться. Теоретически это не актуально. RESTful API будет работать одинаково независимо от реализации, и фреймворк даже не узнает об этом.

Тем не менее, существует некоторая согласованность серверных и внешних интерфейсов с защитой, предположениями и поддержкой сообщества. Ember очень популярен в связанных мирах Ruby и Elixir. Аурелия пользуется сильной поддержкой в сообществе .Net. Node и Angular уже давно связаны стеком MEAN, хотя Angular достаточно велик, чтобы не ограничиваться этим. Vue - это установка по умолчанию с фреймворком Laravel для PHP. Все это может повлиять на видимость или жизнеспособность фреймворка.

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

Фреймворки Javascript: тщетная попытка объективности