Javascript фреймворки. Что это? Зачем? Почему? Фреймворки JavaScript: как их выбирать

Свежая подборка самых популярных и наиболее востребованных JavaScript фреймворков, библиотек и инструментов на 2017 год.

Кажется, что JS-библиотек и фреймворков больше, чем JS-разработчиков. На май 2017 года быстрый поиск по GitHub выдает более чем 1.1 миллион проектов на JavaScript. На npm.js находится 500 тысяч активно используемых пакетов с почти 10 миллиардами скачиваний каждый месяц.

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

Пожалуйста, примите нижеизложенные соглашения перед прочтением данной статьи:

Мир JavaScript меняется изо дня в день. Эта статья будет устаревшей с момента ее публикации!
Под «лучшими» имеются в виду «наиболее популярные проекты общего назначения». Все они бесплатны и имеют открытый исходный код, но список может не включать ваши любимые.
В список не попали проекты, разработка которых приостановлена, даже если они широко распространены и активно используются.
Упомянуты только клиентские приложения. Некоторые из них могут выполнять функции серверной части, однако список не содержит полностью серверно-ориентированных приложений вроде Express.js или Hapi .
Информация о каждом проекте краткая и предоставляет свободу для дальнейшего изучения.
У каждого проекта есть индикатор популярности, но статистика, как известно, может вводить в заблуждение.
Автор подборки предвзят. Вы предвзяты. Все предвзяты!

Хитрая терминология

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

Библиотеки

Библиотека - это структурированный набор полезного функционала. Стандартная библиотека должна содержать функции для работы со строками, датами, DOM-элементами, событиями, cookie, анимацией, запросами, и многим другим. Каждая функция возвращает значения вызывающему ее приложению, которое может в дальнейшем использовать их в зависимости от логики разработчика. Это можно сравнить с подбором запчастей для автомобиля: вы свободны в выборе любого варианта, с которым машина будет работать, но логика целиком на вашей совести.

Библиотека обычно сокращает время разработки примерно на 20%, позволяя вам не беспокоиться о мелочах. Отрицательные стороны:

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

Фреймворки

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

Фреймворк находится на более высоком уровне абстракции по сравнению с библиотекой и позволит вам без труда выстроить около 80% вашего приложения. Его минусы:

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

Инструменты

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

Инструменты призваны облегчать процесс разработки. Например, многие предпочитают Sass чистому CSS, потому что он предоставляет возможность использовать циклы, функции, локальные переменные и многое другое. Браузеры не понимают Sass/SCSS синтаксис, так что код переводится в CSS.

Не вешайте на меня ярлыки!

Грань между фреймворками, библиотеками и инструментами довольно смутная. Фреймворк может содержать в себе библиотеку. Библиотека может реализовывать фреймворко-подобные методы. Инструменты могут быть неотъемлемой частью обоих.

JavaScript фреймворки и библиотеки

Проекты упорядочены по популярности.

Самая популярная js-библиотека всех времен. Она произвела революцию в программировании клиентской части веб-приложений, введя селекторы CSS для доступа к узлам DOM-дерева, обработчики событий, анимации и ajax-запросы.

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

Плюсы:

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

Минусы :

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

React

Самая горячо обсуждаемая библиотека прошедшего года. React претендует на роль библиотеки для создания пользовательских интерфейсов. Он фокусируется на «View»-части MVC-разработки и позволяет создавать компоненты интерфейса, сохраняющие свое состояние. Это была одна из первых библиотек, реализующих виртуальное DOM-дерево.

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

Плюсы:

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

Минусы:

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

Lodash и Uinderscore

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

Плюсы:

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

Минусы:

некоторые методы доступны в ES2015 И других более поздних версиях JavaScript

Первый фреймворк (или MVC фреймворк) в нашем списке. Наиболее популярной является версия 1.х, расширяющая HTML двусторонней привязкой данных одновременно с разделением манипуляций с DOM и логики приложения.

Angular 1.x до сих пор находится в разработке, несмотря на версию 2 (которая теперь версия 4!). Запутались? Читайте дальше…

Плюсы:

популярный фреймворк, поддерживаемый несколькими крупными компаниями
часть «стандартного» стека MEAN (MongoDB, Express.JS, AngularJS, NodeJS), доступны множество статей и туториалов

Минусы:

сложнее в освоении в сравнении с некоторыми альтернативами
обширная база кода
несовместимость с Angular 2.x
несмотря на то, что является проектом Google, самим Google не используется

Angular 2

Angular 2.0 был представлен миру в сентябре 2016. Он был полностью переписан и представляет модульную модель компонентов, создаваемую на TypeScript. В марте 2017 состоялся релиз версии 4.0 (третья была пропущена во избежание нестыковок в семантическом версионировании).

Плюсы:

универсальное решение для создания современных веб-приложений
все еще часть стека MEAN
TypeScript предоставляет некоторые преимущества для людей, знакомых с объектно-ориентированными языками вроде C# и Java

Минусы:

см. минусы Angular 1.x

Vue.js

Легкий современный фреймворк для создания пользовательских интерфейсов. Предлагает React-подобный виртуальный слой ст поддержкой DOM, который может быть интегрирован с другими библиотеками.

Vue.js использует синтаксис шаблона HTML для связки DOM и данных. Модели являются простыми js-объектами, которые перестраивают интерфейс и/или контент при изменении данных.

Плюсы:

зрительские симпатии и растущая популярность
прост в освоении с нуля
мало зависимостей и хорошая производительность

Минусы:

молодой проект - высокие риски
меньше ресурсов, чем у альтернатив

Backbone.js был одним из первых клиентских фреймворков, реализующих модель MVC. Единственная зависимость - Underscore.js, созданный тем же разработчиком.

Скорее его можно отнести к библиотекам, потому что он может быть интегрирован в другие проекты. Хотя большинство разработчиков все же склонно называть Backbone.js фреймворком.

Плюсы:

компактный, легкий и простой в изучении
не добавляет дополнительной логики в HTML
прекрасная документация
использован в разработке многих приложений включая Trello, WordPress, LinkedIn и Groupon

Минусы:

низкий уровень абстракции по сравнению с альтернативами (например, AngularJS)
требует дополнительных компонентов для реализации фич вроде связывания данных
более современные фреймворки отказались от модели MVC

Алины Архиповой “JavaScript Frameworks: How To Make Your Choice”.

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

Чем больше появляется фреймворков, тем больше вокруг них споров. В сообществе разработчиков много говорится о том, какие фреймворки наиболее эффективны для фронтенд-разработки. Основываясь на нашем исследовании, мы определили пятерку самых обсуждаемых фреймворков JavaScript. Их мы и описали в этой статье. Также в ней мы поделимся опытом Yalantis: расскажем о том, какие фреймворки предпочитают наши фронтенд-разработчики.

Обзор популярных фреймворков JavaScript

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

Angular

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

Сегодня Angular это один из самых популярных фронтенд-фреймворков. Многие разработчики выбирают Angular, поскольку рассматривают его как ключ к упрощению разработки. Благодаря его шаблонам специалисты по фронтенду могут с легкостью использовать Angular для создания динамических одностраничных веб-приложений со множеством изменяемых данных. Кроме того, в Angular есть Model-View-Controller (MVC, «Модель-Представление-Контроллер»), делающий тестирование более простым и доступным.

React.js

React.js это фреймворк, выпущенный командой Facebook в 2013 году. Крупные компании, включая Dropbox, PayPal, BBC, Atlassian и Instagram используют React в качестве основного инструмента фронтенда.

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

Vue.js

Vue.js это довольно новый фреймворк JavaScript, созданный Эваном Ю. Его главная цель – сделать разработку пользовательского интерфейса более организованной.

Многие специалисты по фронтенду утверждают, что это превосходный инструмент для новичков. Он очень прост для понимания, поскольку фокусируется на слоях представления. Vue.js работает без Babel – транспилятора, конвертирующего код JavaScript в старую версию ES5, которая запускается во всех браузерах. Отказ от использования Babel ускоряет разработку. Шаблоны Vue.js это валидный HTML, поэтому интеграция проходит легко. Этот фреймворк является хорошим решением для разработки легковесных приложений.

Ember.js

Фреймворк Ember.js был создан в 2011 году. Он был использован при создании сайтов многих хорошо известных компаний, включая Kickstarter, Heroku и LinkedIn.

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

Next.js

Next.js это необычный JavaScript-фреймворк. Он был разработан командой React в качестве дополнительного инструмента для рендеринга на стороне сервера. При работе с React и Next.js процесс разработки становится проще, как при использовании Vue.js.

Next.js имеет такие достойные упоминания особенности как автоматическое разделение кода и маршрутизация на основе страницы на стороне клиента. Кроме того, Next.js имеет полную поддержку CSS (под названием styled-jsx) для значительного облегчения стилизации интерфейса пользователя.

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

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

Какие фреймворки выбирают фронтенд-разработчики Yalantis

Команда по фронтенд-разработке в Yalantis часто работает с JavaScript-фреймворками. За последние несколько лет мы испытали разнообразные фреймворки, чтобы найти наиболее эффективный и выгодный инструмент.

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

Angular

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

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

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

TypeScript. Обучающие ресурсы и документация по Angular основаны на TypeScript, поэтому его трудно избежать. TypeScript некоторым разработчикам может показаться сложным, но ничего плохого в нем нет. Многие новые фичи становятся гораздо быстрее доступны для TypeScript, чем для других языков. Больше того, TypeScript обеспечивает шаблоны объектно-ориентированного программирования и опциональную статическую проверку типов, что полезно для больших приложений.

Удобные шаблоны. Шаблоны в Angular представлены в HTML, так что разработчики могут создавать функциональные приложения даже если они не слишком хорошо знают JavaScript. Браузер обрабатывает шаблоны и генерирует инструкции рендеринга, также известные как директивы.

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

Поддержка сильного сообщества. Фреймворк Angular это продукт Google, поэтому естественно, что у него много поклонников и людей, которые его поддерживают. Разработчики могут с легкостью найти множество советов в блогах и на форумах.

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

React

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

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

JSX. Декларативный синтаксис JavaScript, который помогает создавать аккуратный и читаемый код. JSX также помогает комбинировать компоненты в один исполняемый файл.

Легкость изучения. Если разработчики знают JavaScript, они могут сразу приступать к использованию React. Разработчики могут пропустить мануалы, поскольку React прост и хорошо организован. Чтобы стать специалистом по React, вам нужно будет познакомиться с JSX.

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

Поддержка Facebook и сообщества. React курируется одним их технологических гигантов – Facebook. Команда Facebook знает, как работать со сложными веб-приложениями, поэтому фреймворк React ориентирован на увеличении производительности. Сообщество React одно из самых больших (если сравнивать с сообществами других популярных фреймворков для фронтенд-разработки). Есть много блогов, плагинов и SDK, имеющих отношение к React. Поэтому, если у разработчика возникнут какие-либо проблемы с этим фреймворком, он может с легкостью найти ответы в интернете.

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

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

Статья посвящена 8 самым популярным фреймворкам, библиотекам и инструментам JavaScript. Каждый из них может значительно облегчить разработку приложения, если вы будете использовать JavaScript.

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

А зачем использовать именно фреймворки JS? Этому есть три причины:

1 React

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

Именно благодаря React была популяризирована идея использования виртуального DOM. Подобная технология позволяет не работать с DOM напрямую, а использовать для работы легкий JS-объект, который имитирует дерево DOM. Алгоритм улучшает производительность на клиентской стороне, поэтому React отлично подходит для создания максимально быстрых приложений с высоким трафиком (например, Instagram).

Это одна из самых быстрорастущих библиотек, и она может быть легко интегрирована в любую архитектуру (если брать модель MVC, Модель-Представление-Контроллер, то React отвечает за часть V, представление).

Несмотря на то, что React обычно не сравнивают с фреймворками, можно отметить, что при сравнении с Angular 1.x он обеспечивает больший рост производительности.

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

Компании, использующие React: Facebook, Instagram, Netflix, Alibaba, Yahoo, E-Bay, Airbnb, Sony.
Страница на GitHub:

2 Vue

Говоря о Vue, большинство имеет в виду, как правило, вторую версию - Vue 2, которая появилась чуть больше года назад (в сентябре 2016 года) и получила много улучшений по сравнению с предыдущей версией.

Vue - это прогрессивный JS-фреймворк, релиз которого состоялся в 2014 году. Его создал Эван Ю, ранее работавший в Google и Meteor Development Group (которые создали MeteorJS). На разработку существенно повлияли Angular, Knockout, React и Rivets, и Vue может стать как раз той золотой серединой, которая собрала все лучшее и предложила разработчикам.

Например, если сравнивать Vue c Angular, то это более гибкий и простой (с точки зрения API) фреймворк, который также имеет более высокую производительность.

На официальном сайте Vue характеризуется как доступный (если знаете HTML, CSS и JS, то сможете изучить его очень быстро), разносторонний (экосистема позволяет масштабироваться из библиотеки в полноценный фреймворк) и производительный (виртуальный DOM и возможность оптимизации).

Как и React, Vue используется для разработки пользовательских интерфейсов. Его легко постепенно внедрить в уже имеющий проект, он хорошо интегрируется с другими библиотеками.

Vue отлично подходит для создания Single-Page Applications - веб-приложения, размещенного на одной странице, где весь необходимый код загружается вместе с самой страницей.

Вебсайты, использующие Vue: laravel.com, gitlab.com, laracast.com.
Страница на GitHub:

3 AngularJS

AngularJS - один из самых известных, популярных и упоминаемых фреймворков JS. Он был создан разработчиками Google и прекрасно подходит для разработки веб-приложений.

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

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

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

Вебсайты, использующие AngularJS: weather.com, freelancer.com, netflix.com.
Страница на GitHub:

4 Backbone

Backbone - еще одна известная и часто используемая при разработке библиотека. Она основана на шаблоне проектирования MVP. Одна из отличительных особенностей - это очень легковесная библиотека, единственные зависимости которой - библиотека Underscore.js (в качестве шаблонизатора), ну и jQuery (используется для работы с DOM-элементами).

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

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

Вебсайты, использующие Backbone: uvdesk.com/en/, reddit.musicplayer.io, helpscout.net
Страница на GitHub:

5 Polymer

Polymer - это библиотека, которая предназначается для создания и использования веб-компонентов. Эти веб-компоненты можно использовать как стандартные HTML-элементы для создания приложений. Иначе говоря, вы можете создавать свои собственные HTML-элементы. Для использования Polymer нужно быть знакомым со стандартом Web Components .

Элементы Polymer поделены на 8 групп:

App Elements - слабо связанный набор элементов, который может быть полезен в целом при разработке приложения (маршрутизация, хранение данных и т.д.);
Iron Elements (ранее Core Elements) - основные, базовые элементы для разработки приложения;
Paper Elements - набор UI-компонентов;
Google Web Components - коллекция компонентов для Google API и сервисов Google;
Gold Elements - набор компонентов для электронной коммерции;
Neon Elements - компоненты анимации (в данный момент отсутствуют);
Platinum Elements - компоненты для того, что превратить веб-сайт в приложение (push-уведомления, использование офлайн, bluetooth и т.д.);
Molecules - молекулы облегчают взаимодействие с другими библиотеками.

Полный список элементов смотрите .

Сервисы, использующие Polymer: YouTube, Google Earth & Google Music
Страница на GitHub:

6 Ember.js

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

Одним из главных принципов Ember.js являются маршруты. Каждому маршруту соответствует модель с данными о состоянии приложения, а также URL-адрес, определяющий текущее состояние приложения. Для добавления модели какую-либо логику отображения используются контроллеры. Что касается шаблонов, то они в Ember.js используются для того, чтобы построить HTML-код приложения и встраивать в него динамически обновляемые выражения.

Ember.js - это возможность легкой кастомизации проекта и универсальность, выраженная в возможности компонентной архитектуры.

Вместо MVC фреймворк использует паттерн DDAU (Data down, actions up). Это позволяет использовать один поток данных, благодаря чему код приложения воспринимается проще, и это позволяет значительно улучшить производительность.

Ember.js - это производительный и эффективный фреймворк, который позволяет создавать амбициозные приложения.

Компании, использующие Ember.js: Linkedin, PlayStation, TED, Yahoo!, Twitch.tv
Страница на GitHub:

7 Aurelia

Над созданием Aurelia работал Роб Эйзенберг, который также принимал участие в работе над Angular, поэтому два этих фреймворка очень похожи, но в то же время различаются в некоторых деталях.
Aurelia достаточно новый фреймворк, который вышел пару лет назад. Его называют “next generation UI Framework” (UI-фреймворком следующего поколения) и самым продвинутым и дружелюбным к разработчикам фронт-энд фреймворком на сегодняшний день.

Один из принципов Aurelia - “Convention over Configuration” (обычно переводят как «соглашения по конфигурации»). Этот принцип призван сократить количество требуемой конфигурации без потери гибкости.

Aurelia поддерживает ES6/ES7. Другие характерные черты - модульность, использование веб-компонентов и тестируемость.

Если возвращаться к сравнению с Angular, то в Aurelia акцентом сделан Ненавязчивый JavaScript (unobtrusive JavaScript), поэтому Aurelia имеет более компактный и сопровождаемый код, чем Angular.
Несмотря на то, что Aurelia вышел не так давно, его популярность растет, и у многих разработчиков этот фреймворк вызывает интерес.

Приложения, использующие Aurelia: brainy, seecode.run
Страница на GitHub:

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

Абстракции опасны

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

Var page = Framework.createPage({ "type": "home", "visible": true });

Предположим, что это реальный фреймворк. Под капотом createPage создает новый класс отображения , который загружает шаблон из home.html . В зависимости от значения параметра visible мы вставляем (или нет) созданный элемент DOM в дерево. А теперь представьте себя на месте разработчика. Мы прочитали в документации, что этот метод создаёт новую страницу с заданным шаблоном. Нам неизвестны конкретные детали, потому что это абстракция.

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

А что если мы перепишем пример выше вот так:

Var page = Framework.createPage(); page .loadTemplate("home.html") .appendToDOM();

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

Function ViewModel(first, last) { this.firstName = ko.observable(first); this.lastName = ko.observable(last); } ko.applyBindings(new ViewModel("Planet", "Earth"))

Мы объявляем модель и сами же её инициализируем. А вот в AngularJS чуть по-другому:

Function TodoCtrl($scope) { $scope.todos = [ { "text": "learn angular", "done": true }, { "text": "build an angular app", "done": false } ]; }

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

Работа с DOM

Что бы мы ни делали, нам нужно взаимодействовать с DOM. То, как мы это делаем, очень важно, обычно каждое изменение узлов дерева на странице влечёт за собой пересчёт размеров или перерисовку, а это могут быть весьма дорогостоящие операции. Давайте в качестве примера разберём такой класс:

Var Framework = { "el": null, "setElement": function(el) { this.el = el; return this; }, "update": function(list) { var str = "

"; for (var i = 0; i < list.length; i++) { var li = document.createElement("li"); li.textContent = list[i]; str += li.outerHTML; } str += ""; this.el.innerHTML = str; return this; } }

Этот крошечный фреймворк генерирует ненумерованный список с нужными данными. Мы передаём элемент DOM, в котором следует поместить список, и вызываем функцию update , которая отображает данные на экране.

Framework .setElement(document.querySelector(".content")) .update(["JavaScript", "is", "awesome"]);

Вот, что у нас из этого вышло:

Чтобы продемонстрировать слабую сторону такого подхода мы добавим на страницу ссылку и назначим на ней обработчик события click . Функция снова вызовет метод update , но с другими элементами списка:

Document.querySelector("a").addEventListener("click", function() { Framework.update(["Web", "is", "awesome"]); });

Мы передаём почти те же самые данные, поменялся только первый элемент массива. Но из-за того, что мы используем innerHTML , перерисовка происходит после каждого клика. Браузер не знает, что нам надо поменять только первую строку. Он перерисовывает весь список. Давайте запустим DevTools браузера Opera и запустим профилирование. Посмотрите на этом анимированном GIF, что происходит:

Заметьте, после каждого клика весь контент перерисовывается. Это проблема, особенно, если такая техника применяется во многих местах на странице.

Гораздо лучше запоминать созданные элементы

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

SetElement: function(el) { this.list = document.createElement("ul"); el.appendChild(this.list); return this; }

Теперь нам больше не обязательно хранить ссылку на элемент-контейнер. Достаточно создать элемент

Логика, улучшающая быстродействие, находится внутри метода update:

"update": function(list) { for (var i = 0; i < list.length; i++) { if (!this.rows[i]) { var row = document.createElement("LI"); row.textContent = list[i]; this.rows[i] = row; this.list.appendChild(row); } else if (this.rows[i].textContent !== list[i]) { this.rows[i].textContent = list[i]; } } if (list.length < this.rows.length) { for (var i = list.length; i < this.rows.length; i++) { if (this.rows[i] !== false) { this.list.removeChild(this.rows[i]); this.rows[i] = false; } } } return this; }

Первый цикл for проходит по всем переданным строкам и создаёт при необходимости элементы

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

Браузер перерисовывает только ту часть, которая изменилась.
Хорошая новость: фреймворки вроде React и так уже работают с DOM правильно. Браузеры становятся умнее и применяют хитрости для того, чтобы перерисовывать как можно меньше. Но всё равно, лучше держать это в уме и проверять, как работает выбранный вами фреймворк.
Я надеюсь, в ближайшем будущем мы сможем больше не задумываться о таких вещах, и фреймворки будут заботиться об этом сами.
Обработка событий DOM
Приложения на JavaScript обычно взаимодействуют с пользователем через события DOM. Элементы на странице посылают события, а наш код их обрабатывает. Вот отрывок кода на Backbone.js, который выполняет действие, если пользователь взаимодействует со страницей:
Var Navigation = Backbone.View.extend({ "events": { "click .header.menu": "toggleMenu" }, "toggleMenu": function() { // … } });
Итак, должен быть элемент, соответствующий селектору.header.menu , и когда пользователь на нём кликнет, мы должны показать или скрыть меню. Проблема такого подхода в том, что мы привязываем объект JavaScript к конкретному элементу DOM. Если мы захотим подредактировать разметку и заменить.menu на.main-menu , нам придётся поправить и JavaScript. Я считаю, что контроллеры должны быть независимыми, и не следует их жёстко сцеплять с DOM.
Определяя функции, мы делегируем задачи класса JavaScript. Если эти задачи - обработчики событий DOM, есть смысл создавать их из HTML.
Мне нравится, как AngularJS обрабатывает события.
click me
go - это функция, зарегистрированная в нашем контроллере. Если следовать такому принципу, нам не нужно задумываться о селекторах DOM. Мы просто применяем поведение непосредственно к узлам HTML. Такой подход хорош тем, что он спасает от скучной возни с DOM.
В целом, я был бы рад, если бы такая логика была внутри HTML. Интересно, что мы потратили кучу времени на то, чтобы убедить разработчиков разделять содержимое (HTML) и поведение (JavaScript), мы отучили их встраивать стили и скрипты прямо в HTML. Но теперь я вижу, что это может сберечь наше время и сделать наши компоненты более гибкими. Разумеется, я не имею в виду что-то такое:
banner text
Я говорю о наглядных атрибутах, которые управляют поведением элемента. Например:
…
Это не должно выглядеть, как программирование на JavaScript в HTML, скорее это должно быть похоже на установку конфигурации.
Управление зависимостями
Управление зависимостями - важная задача в процессе разработки. Обычно мы зависим от внешних функций, модулей или библиотек. Фактически, мы всё время создаём зависимости. Мы не пишем всё в одном методе. Мы разносим задачи приложения в различные функции, а затем их соединяем. В идеале мы хотим инкапсулировать логику в модули, которые ведут себя как чёрные ящики. Они знают только те детали, которые касаются их работы, и больше ничего.
RequireJS - один из популярных инструментов разрешения зависимостей. Идея состоит в том, что код оборачивается в замыкание, в которое передаются необходимые модули:
Require(["ajax", "router"], function(ajax, router) { // … });
В этом примере функции требуется два модуля: ajax и router . Магический метод require читает переданный массив и вызывает нашу функцию с нужными аргументами. Определение router выглядит примерно так:
// router.js define(["jquery"], function($) { return { "apiMethod": function() { // … } } });
Заметьте, тут ещё одна зависимость - jQuery. Ещё важная деталь: мы должны вернуть публичное API нашего модуля. Иначе код, запросивший наш модуль, не сможет получить доступ к самой функциональности.
AngularJS идёт немного дальше и предоставляет нам нечто под названием фабрика . Мы регистрируем там свои зависимости, и они волшебным образом становятся доступными в контроллерах. Например:
MyModule.factory("greeter", function($window) { return { "greet": function(text) { $window.alert(text); } }; }); function MyController($scope, greeter) { $scope.sayHello = function() { greeter.greet("Hello World"); }; }
Вообще говоря, такой подход облегчает работу. Нам не надо использовать функций вроде require для того чтобы добраться до зависимости. Всё, что требуется, - напечатать правильные слова в списке аргументов.
Ладно, оба эти способа внедрения зависимостей работают, но каждый из них требует своего стиля написания кода. В будущем я хотел бы увидеть фреймворки, в которых это ограничение снято. Было бы значительно изящнее применять метаданные при создании переменных. Сейчас язык не даёт возможности это сделать. Но было бы круто, если бы можно было делать так:
Var router:;
Если зависимость будет находиться рядом с определением переменной, то мы можем быть уверены, что внедрение этой зависимости производится, только если она нужна. RequireJS и AngularJS, к примеру, работают на функциональном уровне. То есть, может случиться так, что вы используете модуль только в определённых случаях, но его инициализация и внедрение будут происходить всегда. К тому же, мы можем определять зависимости только в строго определённом месте. Мы к этому привязаны.
Шаблоны
Мы часто пользуемся шаблонами. И мы делаем это из-за необходимости разделять данные и разметку HTML. Как же современные фреймворки работают с шаблонами? Вот самые распространённые подходы:
Шаблон определён в Hello, !
Такой подход часто используется, потому что шаблоны находятся в HTML. Это выглядит естественно и не лишено смысла, раз уж в HTML есть теги. Браузер не отрисовывает содержимое элементов , и покорёжить внешний вид страницы это не может.
Шаблон загружается через AJAX Backbone.View.extend({ "template": "my-view-template", "render": function() { $.get("/templates/" + this.template + ".html", function(template) { var html = $(template).tmpl(); }); } });
Мы положили свой код во внешние файлы HTML и избежали использования дополнительных тегов . Но теперь нам нужно больше запросов HTTP, а это не всегда уместно (по крайней мере, пока поддержка HTTP2 не станет шире).
Шаблон является частью разметки - фреймворк получает его из DOM-дерева. Этот метод опирается на уже сгенерированный HTML. Нам не нужно делать дополнительных HTTP запросов, создавать новые файлы или дополнительные элементы .
Шаблон - часть разметки страницы var HelloMessage = React.createClass({ render: function() { // Обратите внимание: следующая строка кода // не является корректным JavaScript. return Hello {this.props.name}; } });
Такой подход был введён в React, там используется собственный парсер, который превращает невалидную часть JavaScript в валидный код.
Шаблон - не HTML
Некоторые фреймворки вообще не используют HTML напрямую. Вместо этого шаблоны хранятся в виде JSON или YAML.
Напоследок о шаблонах
Хорошо, а что дальше? Я ожидаю, что с фреймворком будущего мы будем рассматривать данные отдельно, а разметку отдельно. Чтобы они не пересекались. Мы не хотим иметь дело с загрузкой строк в HTML или с передачей данных в специальные функции. Мы хотим присваивать значения переменным, а DOM чтобы обновлялся сам. Распространённое двустороннее связывание не должно быть чем-то дополнительным, это должно быть обязательной базовой функциональностью.
Вообще, поведение AngularJS ближе всего к желаемому. Он считывает шаблон из содержимого предоставленной страницы, и в нём реализовано волшебное двустороннее связывание. Впрочем, оно ещё не идеально. Иногда наблюдается мерцание. Это происходит, когда браузер отрисовывает HTML, но загрузочные механизмы AngularJS ещё не запустились. К тому же, в AngularJS применяется грязная проверка того, поменялось ли что-нибудь. Такой подход порой очень затратен. Надеюсь, скоро во всех браузерах будет поддерживаться Object.observe , и связывание будет лучше.
Рано или поздно каждый разработчик сталкивается с вопросом динамических шаблонов. Наверняка, в наших приложениях есть части, которые появляются после загрузки. С фреймворком это должно быть просто. Мы не должны задумываться об AJAX-запросах, а API должно быть таким, чтобы процесс выглядел синхронным.
Модульность
Мне нравится, когда возможности можно включать и выключать. A если мы чем-то не пользуемся, зачем держать это в коде проекта? Было бы хорошо, если у фреймворка был бы сборщик, который генерирует версию с только необходимыми модулями. Как, например YUI , у которого есть конфигуратор. Мы выбираем те модули, которые хотим, и получаем минифицированный и готовый к использованию файл JavaScript.
Даже так, существуют фреймворки, у которых есть нечто, называемое ядром . Вдобавок к нему мы можем использовать пачку плагинов (или модулей). Но мы могли бы это улучшить. Процесс выбора нужных возможностей не должен включать в себя загрузку файлов. Мы не должны их вручную подключать на странице. Это каким-то образом должно быть частью кода фреймворка.
Помимо адекватных возможностей при установке, идеальная среда должна предусматривать расширяемость. У нас должна быть возможность писать собственные плагины и делиться ими с другими разработчиками. Другими словами, среда должна быть благоприятной для написания модулей. Не получится создать сильное сообщество без существования подходящих условий для разработчиков.
Открытое API
Большая часть фреймворков предоставляют API к своей базовой функциональности. Но при помощи этих API можно добраться только к тем частям, которые поставщики посчитали нужными для нас. И вот тут могут понадобиться хаки. Мы хотим что-то получить, но для этого нет подходящих инструментов. И приходится идти на хитрости и двигаться в обход. Рассмотрим такой пример:
Var Framework = function() { var router = new Router(); var factory = new ControllerFactory(); return { "addRoute": function(path) { var rData = router.resolve(path); var controller = factory.get(rData.controllerType); router.register(path, controller.handler); return controller; } } }; var AboutCtrl = Framework.addRoute("/about");
У такого фреймворка есть встроенный маршрутизатор. Мы определяем путь, и контроллер инициализируется автоматически. Когда пользователь посещает определённый URL, маршрутизатор вызывает у конструктора метод handler . Это здорово, но что если нам нужно выполнять небольшую функцию JavaScript при совпадении URL? По какой-то причине, мы не хотим создавать дополнительный контроллер. С текущим API такое не получится.
Мы могли бы сделать по-другому, например, вот так:
Var Framework = function() { var router = new Router(); var factory = new ControllerFactory(); return { "createController": function(path) { var rData = router.resolve(path); return factory.get(rData.controllerType); } "addRoute": function(path, handler) { router.register(path, handler); } } } var AboutCtrl = Framework.createController({ "type": "about" }); Framework.addRoute("/about", AboutCtrl.handler);
Заметьте, маршрутизатор не торчит наружу. Его не видно, но теперь мы можем управлять как созданием контроллера, так и регистрацией пути в маршрутизаторе. Разумеется, предложенный вариант подходит для нашей конкретной задачи. Но он может оказаться излишне сложным, потому что контроллеры тут приходится создавать вручную. При разработке API мы руководствуемся принципом единственной обязанности и рассуждением делай что-то одно, и делай это хорошо . Я вижу, как всё больше и больше фреймворков децентрализуют свою функциональность. В них сложные методы делятся на более мелкие части. И это хороший признак, я надеюсь, в будущем больше фреймворков будет так делать.
Тестируемость
Нет нужды убеждать вас в необходимости писать тесты для кода. Дело даже не только в том, что надо писать тесты, а в том, что надо писать код, который возможно покрыть тестами. Иногда это невероятно сложно и занимает много времени. Я убеждён, что если мы на что-то не напишем тесты, даже на что-то очень маленькое, то именно в этом месте в приложении начнут плодиться баги. Это в особенности касается JavaScript на клиентской стороне. Несколько браузеров, несколько операционных систем, новые спецификации, новые возможности и их полифилы - да куча причин начать практиковать разработку через тестирование.
Есть ещё кое-что, что мы получим от тестов. Мы не только убеждаемся в том, что наш фреймворк (приложение) работает сегодня. Мы убеждаемся, что он будет работать завтра и послезавтра. Если есть какая-то новая возможность, которую мы привносим в код, мы пишем для неё тесты. И очень важно, что мы делаем так, чтобы эти тесты проходились. Но так же важно, чтобы проходились и предыдущие тесты. Именно так мы гарантируем, что ничего не сломалось.
Я с радостью бы увидел больше стандартизованных утилит и методов для тестирования. Мне хотелось бы использовать одну утилиту для тестирования всех фреймворков. Было бы ещё хорошо, если бы тестирование было как-то включено в процесс разработки. Следует обратить больше внимания на сервисы вроде Travis CI . Они работают как индикатор не только для того программиста, который вносит изменения, но также и для других контрибьюторов.
Я всё ещё работаю с PHP. Мне приходилось иметь дело с фреймворками вроде WordPress. И множество людей спрашивало меня, как я тестирую свои приложения: какой фреймворк я использую, как я запускаю тесты, есть ли у меня вообще компоненты. Правда в том, что я ничего не тестирую. И всё потому у меня нет компонентов. То же самое относится и некоторым фреймворкам на JavaScript. Некоторые их части тяжело тестировать, потому что они не дробятся на компоненты. Разработчикам следует подумать и в этом направлении. Да, они предоставляют нам умный, изящный и рабочий код. Но код должен быть ещё и тестируемым.
Документация
Я уверен, что без хорошей документации любой проект рано или поздно загнётся. Каждую неделю выходит куча фреймворков и библиотек. Документация - это первое, что видит разработчик. Никто не хочет тратить часы на то, что узнать, что делает определённая утилита, и какие у неё возможности. Недостаточно простого перечисления основной функциональности. Особенно для большого фреймворка.
Я бы разделил хорошую документацию на три части:
- Что я могу сделать - документация должна учить пользователя и должна делать это правильно. Неважно, насколько крутой или мощный у нас фреймворк, он нуждается в объяснении. Кто-то предпочитает смотреть видео, кто-то читать статьи. В любом случае, разработчику нужно показать всё, начиная с самых основ и заканчивая сложными частями фреймворка.
- Документация API - это обычно есть везде. Полный список всех публичных методов API, того, какие у них параметры и что они возвращают. Может быть, примеры использования.
- Как это работает - обычно этого раздела в документациях нет. Хорошо, если бы кто-нибудь разъяснил структуру фреймворка, даже простая схема базовой функциональности и её взаимосвязи уже бы помогла. Это сделало бы код прозрачным. Это помогло бы тем разработчикам, которые хотят внести свои изменения.
Заключение
Будущее, конечно, тяжело предугадать. Но зато мы можем о нём помечтать! Важно говорить о том, что мы ожидаем и что мы хотим от фреймворков на JavaScript! Если у вас есть замечания, предложения или вы хотите поделится своими мыслями, пишите в Твитер с хештегом

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

Давайте оглянемся назад и постараемся понять, как мы к этому пришли.
Angular и Backbone и Ember, о боже
HTML Imports, HTML шаблоны, настраиваемые элементы и Shadow DOM - все эти технологии расширяют наши возможности. Они должны позволить нам разорвать связь с фреймворками, позволяя создавать пригодные для повторного использования элементы и функционал. Для наглядного представления смотрите эти статьи и библиотеки:

Хорошо, если бы у нас была одна огромная библиотека полифиллов HTML5, но ещё лучше было бы то, что я назвал бы «html-5-polyfill-o-matic», набор инструментов, который позволил бы мне использовать Веб-компоненты минуя трясину HTML+JS, а затем анализировал мой код, или статическим анализом, или через Object.observe при работе, и выдал бы мне из всего полифилла HTML5 только то, что нужно для моего проекта.

Этот вид функциональности ещё более важен, потому что я начал пытаться совместить веб-компоненты и библиотеки из нескольких источников, т.е. от X-Tag и от Polymer, значит ли это, что мне придётся подключать обе эти библиотеки полифиллов? (Оказывается, что ответ нет.) И как именно я должен получать эти специфические элементы? И X-Tag, и Brick имеют собственные пакеты генераторов:

Если я начну создавать собственные элементы, мне нужно будет создавать и свой собственный пакет? Я не думаю, что это масштабируемая идея, я считаю, что нам нужны идиомы и инструменты, которые справлялись бы с этим гораздо лучше. Это на самом деле может означать изменение того, как пишется открытый код. «Виджет» не проект, поэтому наша работа с этими вещами должна изменится. Конечно, продолжайте хранить код в Git, но нужны ли вам накладные расходы в виде GitHub? Что-то более легковесное, ближе к Gist, чем к проекту, подошло бы лучше. А как минимизировать/вулканизировать весь этот код в подходящий для использования в моем проекте вид? Что-то вроде Asset Graph может стать хорошим началом.

И так, что нам теперь нужно?
Идиомы и принципы построения повторно используемых компонентов.
Инструменты, которые работают в рамках этих идиом, для компиляции, сжатия, и т.п. HTML, CSS, и JS.
Масштабируемый полифилл HTML5, полностью или частично построенный на основе тех, которые сейчас реально используются.

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

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

В: Вы не можете сделать ____ на HTML5, для этого вам нужен фреймворк.

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

В: Но ____ не фреймворк, это библиотека!

О: Да, как я уже сказал, есть градиент от gist до фреймворка, и вы можете видеть всё немного иначе, чем я. Это нормально, я не про классификацию какой-либо конкретной части программного обеспечения, речь идет об отдалению от фреймворков.

В: Я делал это годами с помощью ____ и ____ и ____.

О: Опять же, это не вопрос, но всё равно, это хорошо, вы должны быть в хорошей форме, чтобы помочь всем остальным.

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

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

В: Чувак, все эти HTML Imports скажутся на производительности сайтов

О: Если вы используете все это бездумно, то да. Вот, почему я указывал на необходимость инструментов, компилирующих и сжимающих HTML, CSS, и JS.

В: Так что я не должен использовать никакие библиотеки?

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

В: Но мне нравится связывание данных!

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

Оригинальная статья: No more JS frameworks Статью вычитывали: