Что такое фреймворк в java
Java библиотеки и фреймворки
Для ускорения процесса разработки java-приложения широко используют библиотеки (java library) и фреймворки (java framework). С точки зрения Java библиотека представляет собой файл jar, используемый для определения бизнес-логики программы и построения интерфейсной части. Библиотеку необходимо определенным образом прописать в CLASSPATH и подключить к приложению.
Фреймворк (framework) в переводе с английского означает каркас (структура). Java framework — это программная платформа, определяющая архитектуру построения приложения и облегчающее разработку и объединение разных компонентов большого программного проекта.
Использование java фреймворка в разработке web-приложения является каркасным подходом к архитектуре программы, где любая конфигурация программы состоит из двух частей: постоянная часть (каркас приложения), не меняющийся от конфигурации к конфигурации, и переменная часть — сменные модули, определяющие бизнес-логику и интерфейс приложения.
Различие между библиотекой и фреймворком
Основное отличие фреймворка от библиотеки заключается в том, что java библиотека может быть использована в приложении как набор подпрограмм близкой функциональности, не влияя на архитектуру программного продукта и не накладывая на неё никаких ограничений. В то время как java framework определяет правила построения архитектуры приложения, задавая на начальном этапе разработки поведение по умолчанию. Также фреймворк может взаимодействовать с большим числом разных по тематике библиотек.
Другое ключевое отличие фреймворка от библиотеки заключается в инверсии управления. Так при обращении к библиотеке управление получает один из методов класса после вызова. Во фреймворке пользовательский код может реализовывать конкретное поведение, встраиваемое в более общий, абстрактный код фреймворка. При этом фреймворк вызывает функции класса пользовательского кода.
Фреймворк Java Server Faces (JSF), описание
Web framework JSF (Java Server Faces) написан на Java и предназначени для web-приложений. Он существенно облегчает разработку пользовательских интерфейсов для Java EE приложений. Данный web framework основывается на использовании компонентов в отличие от прочих MVC-фреймворков, которые управляются запросами. При использовании классов JavaBean состоянием визуальных компонентов можно управлять : сохранить значение при переходе пользователя на другую страницу, и затем восстанавить, при возвращении назад.
Широкое распространение для формирования интерфейса в JSF получили технологии JSP и Facelets.
Платформа Java Server Faces включает:
В последнем на данный момент релизе JSF 2.2 от 21.05.2013 выполнена поддержка различных атрибутов HTML 5 и объединение с Java EE 7. В JSF 2.0 в качестве обработчика представления используется технология Facelets которая пришла на замену JSP.
Подробное описание web framework’а JSF представлено в разделе WEB технологии.
Фреймворк Stuts2, описание
Web framework Struts2 поставляется с открытым исходным кодом и предназначен для создания WEB-приложений в технологии Java2EE. Основой Struts является Java Servlet API, который он расширяет. В архитектурном плане данный фреймворк реализует, или, точнее, дает возможность реализовать шаблоный подход MVC. Struts2 имеется чёткое разделение моделей бизнес-логики, представления HTML-страницы и контроллера, отвечающего за передачу данных от модели к представлению и обратно.
Framework Struts2 включает стандартный контроллер — сервлет ActionServlet и различные средства для управления страницами представления (действия, интерцепторы). Разработчик приложения отвечает за написание кода модели и формирование конфигурационного файла struts-config.xml, который связывает воедино модель, представление и контроллер.
Запросы из браузера поступают на сервер (контроллер) в виде «action» (действия), определённых в конфигурационном файле. Когда контроллер получает запрос, он передаёт его соответствующему action-классу. Последний взаимодействует с кодом модели и, согласно правилам навигации, определяет страницу для отправления клиенту. Информация передаётся между моделью и представлением в виде особых JavaBeans. Богатая библиотека тегов позволяет получать данные из бинов и записывать их без Java-кода.
Web framework Struts2 поддерживает интернационализацию i18n, облегчает валидацию данных полученных из веб-формы и предоставляет механизм использования шаблонов «tiles».
Struts2 не является доработкой предыдущей версии Struts, это абсолютно новый фреймворк построенный на основе Webwork с использованием Model-View-Controller (MVC).
Подробное описание web framework’а Struts2 представлено в разделе WEB технологии.
Фреймворк Google Web Toolkit, описание
Используя framework GWT, можно быстро разрабатывать и отлаживать AJAX приложения на языке Java с использованием инструментария отладки Java.
GWT включает XML парсер, поддерживает интернационализацию и интеграцию с JUnit, включает интерфейс для удаленного вызова процедур, содержит небольшой пакет виджетов для разработки элементов графического интерфейса пользователя (GUI). Большой набор визуальных компонентов типа GXT (Ext-GWT), SmartGWT позволяют существенно упростить и ускорить разработку интерфейсной части WEB-приложения.
IDE разработки WEB-приложений, как правило, имеют соответствующие плагины для работы с GWT. Отладка GWT-приложения разделена на две части. Отладка серверной части приложения осуществляется как отладка обычного Java WEB приложения. Для отладки же клиентской части понадобится gwt dev-plugin для браузера.
Подробное описание фреймворка GWT с инcталляцией плагина GWT SDK в IDE Eclipse представлено на странице Фреймворк GWT.
Фреймворк Spring, описание
Несмотря на то, что Spring не обеспечивает какую-либо конкретную модель программирования, он получил широкое распространёние в Java-сообществе главным образом как альтернатива и замена модели Enterprise JavaBeans.
Spring был выпущен под лицензией Apache 2.0 license в июне 2003 года. Релиз Spring 3.1 вышел в декабре 2011. Текущая версия — 4.2.
Spring обеспечивает бо́льшую свободу в проектировании; кроме того, он предоставляет хорошо документированные и лёгкие в использовании средства решения проблем, возникающие при создании приложений корпоративного масштаба.
Особенности ядра Spring позволяют использовать его в любом Java-приложении. Существует множество расширений и усовершенствований для построения WEB приложений на платформе Java Enterprise Edition. По этим причинам Spring приобрёл большую популярность и признаётся разработчиками как стратегически важный фреймворк.
Наиболее известен Spring как источник расширений функциональности (свойств), нужных для эффективной разработки сложных бизнес-приложений вне тяжеловесных программных моделей. Этот фреймворк предлагает последовательную модель и делает её применимой к большинству типов приложений, которые уже созданы на основе платформы Java. Считается, что Spring реализует модель разработки, основанную на лучших стандартах индустрии, и делает её доступной во многих областях Java.
Более подробно с описанием Spring можно познакомиться на странице Википедии.
Библиотека Hibernate, описание
Библиотека Hibernate предназначена для решения задач объектно-реляционного отображения (object-relational mapping — ORM) при программировании на Java. Она относится к свободно программному обеспечению с открытым исходным кодом (open source), распространяемое на условиях GNU Lesser General Public License.
Hibernate предоставляет легкий в использовании каркас для работы с объектно-ориентированной моделью данных в традиционных реляционных СУБД. Библиотеку можно использовать как в процессе проектирования системы классов и таблиц «с нуля», так и для работы с уже существующей базой данных.
Hibernate не только обеспечивает связь между классами Java и таблицами базы данных, а также соответствие типов данных Java с типами данных SQL, но также предоставляет средства для автоматической генерации и обновления набора таблиц, построения запросов и обработки полученных данных. Таким образом, библиотека позволяет значительно уменьшить время разработки, которое обычно тратится на ручное написание SQL-запросов с использованием JDBC-кода.
Одним из основных достоинств Hibernate является автоматическая генерация SQL-запросов и обработка результирующего набора данных по преобразованию объектов (сериализация объектов), максимально облегчая перенос (портирование) приложения на любые базы данных SQL. То есть, Hibernate обеспечивает прозрачную поддержку сохранности данных (persistence) для «POJO» (Plain Old Java Object). POJO класс Java содержит только поля, без дополнительной логики их обработки, и доступ ко всем полям осуществляется только через методы get/set. Пример простого класса POJO приведен на странице описания компонента JavaBean.
Более подробное описание библиотеки Hibernate с инcталляцией плагина Hibernate Tools в IDE Eclipse представлено на странице Библиотека Hibernate.
Библиотека Swing, описание
Библиотека Swing предназначениа для создания графического интерфейса desktop’ых приложений, разрабатываемых на языке Java. Swing был создан компанией Sun Microsystems и содержит ряд графических компонентов (widget), таких как кнопки, поля ввода, таблицы и т.д.
Swing относится к библиотеке классов JFC (Java Foundation Classes), которая представляет собой набор библиотек для разработки графических оболочек. В состав JFC входят, в частности, библиотека Java 2D и первая библиотека Java для создания пользовательских интерфейсов AWT (Abstract Window Toolkit).
Начиная с версии Java 1.2 (1998 год) Swing включён в Java Runtime Environment.
Look and Feel
Архитектура Swing разработана таким образом, что можно изменять «look and feel» (L&F) приложения. «Look» определяет внешний вид компонентов, а «Feel» — их поведение. JRE предоставляет следующие L&F:
Таким образом, компоненты Swing поддерживают специфические динамически подключаемые виды и поведения (plugable look-and-feel), благодаря которым возможна адаптация интерфейса приложения к графическому интерфейсу платформы. То есть к компоненту можно динамически подключить другой, специфический для операционной системы. Таким образом, приложения, использующие Swing, могут выглядеть как «родные» приложения для данной операционной системы.
Сравнение с AWT
Swing предоставляет более гибкие интерфейсные компоненты, по сравнению с более ранней библиотекой AWT. В отличие от AWT, компоненты Swing разработаны для кросс-платформенной работы, в то время как компоненты AWT повторяют интерфейс исполняемой платформы без изменений.
AWT использует только стандартные элементы операционной системы (ОС) для отображения, то есть для каждого элемента создается отдельный объект ОС (окно), в связи с чем, AWT не позволяет создавать элементы произвольной формы (возможно использовать только прямоугольные компоненты). Элементы управления на основе AWT всегда отображаются поверх Swing-элементов, т.к. все Swing компоненты отображаются на поверхности контейнера.
Принцип Lightweight
Принцип «Lightweight» означает, что Swing компоненты прорисовываются самими компонентами в родительском окне (например, на JFrame), без использования компонентов операционной системы. В отличие от «тяжелых» компонентов AWT, Swing приложение может иметься только одно окно.
В приложении могут сочетаться компоненты Swing и AWT. Но это может порождать некоторые проблемы — в частности, компоненты AWT всегда перекрывают Swing элементы, а также закрывают собой всплывающие меню JPopupMenu и JComboBox. Для предотвращения этого, у данного типа компонентов имеются методы setLightWeightPopupEnabled (boolean), позволяющие запретить использование «легковесных» всплывающих элементов. При установке данного свойства в true AWT элементы не будут перекрывать меню.
Основным минусом таких «легковесных» (lightweight) компонентов является относительно медленная работа. Положительная сторона — универсальность интерфейса созданных приложений на всех платформах.
Описание библиотеки Swing более подробно с примерами рассматривается на странице Библиотека Swing
Библиотека SWT, Standard Widget Toolkit
Информация о SWT и ее использования в java-приложениях рассматривается на странице Библиотека SWT
Топ-10 фреймворков для разработки на Java
Фреймворки позволяют строить приложения быстро, просто и эффективно, а также использовать готовые фрагменты кода, избавляя от необходимости писать его с нуля. Их выбор из всего многообразия зависит от потребностей конкретного проекта. Ресурс Technotification подготовил подборку из 10 фреймворков для Java-программистов и разработчиков.
Фреймворки позволяют строить приложения быстро, просто и эффективно, а также использовать готовые фрагменты кода, избавляя от необходимости писать его с нуля. Их выбор из всего многообразия зависит от потребностей конкретного проекта. Ресурс Technotification подготовил подборку из 10 фреймворков для Java-программистов и разработчиков.
Содержание
1. Spring Framework
Spring — один из самых популярных Java-фреймворков. Его предпочитает большинство разработчиков на этом языке, в том числе благодаря возможности внедрения зависимостей.
Spring идеально подходит для создания корпоративных приложений и моделей конфигурации на базе Java. Он позволяет разработчикам сосредоточиться на бизнес-логике приложения. Близко связан с фреймворком Spring Boot.
2. PrimeFaces
PrimeFaces относится к лучшим лёгким Java-фреймворком. Его можно скачать в одном.jar-файле. PriemFaces существует уже много лет и служит UI-фреймворком для спецификаций JavaServer Faces и Java EE. Также он насчитывает более 100 компонентов, среди ключевых — валидация на стороне клиента и инструментарий для сенсорных смартфонов.
3. Blade
Blade — это легковесный MVC-фреймворк на базе Java 8. Он прост и включает интерфейс маршрутизатора в стиле RESTful. Также он относится к тем немногим Java-фреймворкам, в которых отсутствуют навязчивые перехватчики. Под «легковесностью» имеется в виду небольшой по объёму исходный код, который не превышает 500 Кб.
Для использования Blade понадобится создать типичный Maven-проект. Фреймворк поддерживает модульность в Java 9, а также большое число веб-компонентов Java.
Онлайн-курсы, чтобы стать крутым Java-разработчиком
4. Dropwizard
Dropwizard — мощный Java-фреймворк, высоко оптимизированный под разработку RESTful-сервисов. Он также идеален для написания микросервисов на этом языке и даёт лёгкий доступ ко всем мощным Java-библиотекам, например Google Guava, Jetty server, Hibernate Validator, Logback, Joda Time, а также Jackson для обработки JSON-файлов. JSON избавляет от необходимости писать код для метрик и конфигураций, позволяя направить силы на функционал приложения.
Dropwizard помогает достичь максимальной продуктивности при разработке. Приятный бонус — понятная для новичков документация.
5. Google Web Toolkit (GWT)
Фреймворк Google Web Toolkit выпущен Google с целью помочь разработчикам в написании веб-приложений на Java. Он даёт возможность писать Java-код и компилировать в JavaScript для запуска в браузерах.
GWT поддерживает команда опытных программистов Google. С помощью этого фреймворка можно создавать комплексные веб-приложения, не имея практического опыта с языками фронтенд-разработки, такими как JavaScript.
Фреймворк включает ряд уникальных функций, например абстракция UI, кросс‐браузерная совместимость и интернационализация.
6. JavaServer Faces (JSF)
MVC-фреймворк JavaServer Faces появился 14 лет назад. Он упрощает разработку пользовательских интерфейсов для веб-приложений. Самая замечательная особенность этого фреймворка в том, что построенные в нём UI-компоненты можно повторно использовать для других веб-страниц. В качестве шаблонов в JSF использует Facelets.
7. JHipster
JHipster — относительно молодой фреймворк, вышедший в 2013 году. Он сочетает Spring Boot, Angular и React в одном большом фреймворке. С помощью него можно запросто построить современное веб-приложение на Java.
Интеграция Spring Boot позволяет создавать приложения на базе фреймворка Spring. Помимо Angular и React, JHipster также использует Bootstrap. Кроме того, JHipster предоставляет два вида архитектур: монолитную или микросервисную. В первом случае фронтенд и бэкенд реализованы в едином приложении, во втором — раздельно.
8. Spark Framework
Spark — оптимальный выбор для программистов, разрабатывающих веб-приложения на Java. В нём можно быстро и без усилий строить бэкенд сайтов. Spark поддерживает практически все функции Java 8 и имеет выразительный API.
9. MyBatis
MyBatis фреймворк для осуществления маппинга между Java-приложениями и базами данных SQL. Обычно для подключения приложения к реляционной БД необходим API Java Database Connectivity. Он позволяет разработчикам выполнять крупные SQL-операции за несколько строчек кода.
MyBatis сравнивают с фреймворком Hibernate, так как оба являются посредниками между приложением и базой данных. Единственное отличие в том, что MyBatis не делает маппинг объектов Java в реляционную БД.
10. Play Framework
Play — ещё один лёгкий Java-фреймворк, завоевавший расположение большинства разработчиков. Он предоставляет интерфейс, через который можно реализовывать изменения в коде без необходимости заново развёртывать или компилировать его.
Фреймворк имеет асинхронные API, которые позволяют разработчикам масштабировать приложения, обходясь без дополнительных ресурсов. Play прекрасно поддерживает различные микросервисные паттерны.
Что нужно знать о популярных JS-фреймворках
Привет! Меня зовут Дима Чудинов, я наставник на веб-факультете Яндекс.Практикума, Head of Group, Front-end, ABBYY.
Студенты недавно задали мне вопрос: «Что лучше: Angular или React?». Я начал отвечать и понял, что мне понадобится для этого статья. Позже я понял, что и одной статьи не хватит.
О том, какой фреймворк выбрать, я расскажу в другой раз. А в этой статье опишу историю создания фреймворков и их особенности. Выбрать рабочий инструмент статья не поможет. Зато поможет вести споры с другими разработчиками на кухне (если не будет карантина) и в сети. Статья будет полезна новичкам, которые только начинают своё знакомство с фреймворками и библиотеками, и поможет взглянуть на «зоопарк» веб-технологий сверху.
Библиотеки и фреймворки
Для начала важно понимать, что библиотека и фреймворк — не одно и то же.
Библиотеки
Библиотека — код, который встраивается в приложение и решает ограниченный набор задач в зависимости от того, какие обязанности на нее возложили разработчики.
Как правило, библиотека — контейнер для набора классов и/или функций, которые разработчики могут использовать в своем приложении. Например:
Фреймворки
Фреймворк — каркас приложения, который состоит из набора библиотек.
Вместе они дают возможность пользователю выстроить свою функциональность на некотором фундаменте. Фреймворк задаёт структуру и подход к архитектуре вашего приложения, он диктует, как вы должны писать код. Например:
Что и когда используют
Приложение может быть построено как только на одних библиотеках, так и на одном фреймворке. Но чаще всего разработчики используют фреймворк и сторонние библиотеки одновременно.
Выбор того, какой каркас взять или из каких блоков построить новый проект, зависит от вашей экспертизы и кругозора инструментов.
Как правило, новички начинают либо с нативного JS без использования библиотек/фреймворков, либо с одного из популярных фреймворков. Изучают его, находят слабые места и пытаются со временем закрыть их библиотеками.
Более опытные разработчики уже знают подводные камни многих инструментов и выбирают технологический стек исходя из задач. К примеру, один из частых наборов инструментов — React и Redux — библиотеки, которые не дают готового решения и каркаса, а открывают путь для творчества.
Что было раньше
React, Vue, lodash, D3… новичку порой сложно разобраться в этих названиях. Так в сети появилась шутка от разработчика, который всегда просит рекрутеров назвать, кто из стека в его профиле — покемон. Сможете отгадать?
Интерпретация мема: «I typically ask recruiters to point out which of these are pokemon»
Google в 2000-е и сейчас. UX сильно отличается: изначально он был сделан на стандартных html-контролах, теперь это более сложные и стилизованные компоненты.
Не было статей и вопросов в интернете на тему, какой фреймворк выбрать: «React, Angular или Vue?». Разработчики фокусировались на реализации функциональности и наполнении веба. Но были и пытливые умы, которые старались ускорить разработку и создавали библиотеки — с ними можно было писать меньше кода. Такие библиотеки давали возможность инженерам создавать более «богатые» приложения с динамикой, анимацией и прочими радостями, которые есть сейчас.
Первые шаги к приложениям будущего
В марте 2005 года появился Dojo Toolkit, который содержал виджеты, методы для работы с локальными хранилищами и REST-клиент. В июне 2006 года была выпущена альфа-версия библиотеки jQuery, которая включала в себя методы для манипуляций с DOM, работу с событиями, методы для анимаций и модуль AJAX. Все эти инструменты помогали унифицировать разработку, не писать одни и те же утилиты, шаблоны, а брать готовые протестированные модули.
JavaScript: ES3 и ES5
Javascript тогда заметно отличался от современной версии как по синтаксису, так и по возможностям. В 1999 году был опубликован стандарт ECMAScript 3. Он содержал хорошую базу той функциональности, что мы имеем сейчас. А вот стандарт ECMAScript 5 2009 года уже имел особенности:
Переход к новому стандарту позволил сделать огромный шаг в развитии фронтенда, а именно Javascript. Как изменилось написание и объём кода можно увидеть на примере маленькой задачи:
Куда делся ES4
ECMAScript 4 был амбициозным проектом, но по слухам имел плохую совместимость с ES3. В итоге после долгих прений, техническим комитетом TC-39, в который входили участники из Google, Intel, Microsoft, Facebook, было принято решение продолжить работу над ECMAScript 3.1. Позже, в 2009, этот проект был переименован в ECMAScript 5.
Эра фреймворков
Новый стандарт дал огромный толчок развитию как Javascript, так и созданию новых фреймворков.
Backbone.js
В 2010 году появился Backbone.js — библиотека, которая реализует MPV (Model-Presenter-View) паттерн. С помощью Backbone.js можно было создавать SPA с клиентским рутингом. До этого клиентский рутинг был диким неукрощённым зверем, поэтому повсеместно использовали вариант с отдачей шаблонов — серверным рутингом.
На Backbone.js написано много приложений, некоторые до сих пор поддерживаются. Особенность приложений на Backbone.js — частое использование CoffeeScript от того же автора. Он предоставлял более широкие возможности по сравнению с Javascript: код выглядел короче и был более читаемым, были стрелочные функции и наследование. Но, к сожалению, эти технологии забыты на новых проектах, хотя и оказали колоссальное влияние на разработку.
AngularJS
В это же время произошёл релиз AngularJS от Google — полноценного фреймворка, который включал не только каркас приложений, но и средства для тестирования. Изначально этот фреймворк завоевал сердца разработчиков — на нём написано множество популярных сайтов. Например, сайт МакДональдса:
Сайт МакДональдса, написанный на AngularJS
Но несмотря на свою популярность, AngularJS сильно разочаровал разработчиков. Как так вышло — расскажу дальше.
Ember.js
2011 год принес Ember.js — ещё один SPA фреймворк со встроенным шаблонизатором Handlebars. Сам же фреймворк построен на классической архитектуре MVC (Model-View-Controller). У Ember очень дружное комьюнити, которое развивает инструмент и не останавливается, — даже в 2020 году у фреймворка есть роадмап и цели по развитию. Всё ещё можно встретить статьи: «Как мигрировать с React на Ember», поэтому этого старичка не стоит списывать со счетов.
Библиотек и фреймворков становилось всё больше и больше. Поэтому в 2010-х годах разработку разделили на бэкенд и фронтенд — стало сложнее найти специалиста, который знал бы серверные технологии, все тонкости JS и необходимого фреймворка, ведь каждый из них имел свои особенности. Работодатели начали оценивать не общий кругозор в веб-разработке, а умение пользоваться конкретной технологией, на которой можно выстроить новый продукт.
Хороший маркетинг — AngularJS
В 2010 году разработчики Google выпустили фреймворк AngularJS. Поддержка крупной компании и хороший маркетинг сильно выделяли его среди равных — Backbone и Ember.
Кроме этого, AngularJS предлагал на тот момент интересный подход — two-way data binding (с англ. двустороннее связывание данных), который ещё не был широко распространён в разработке.
Особенности AngularJS
AngularJS — полноценный фреймворк, целью которого было упростить разработку Single Page Applications.
Основная особенность фреймворка в том, что отображение может менять модель, как и модель — менять отображение. Это нужно, чтобы связать действия пользователя. Например, пользователь вводит данные в поле → обновляется модель → посылается запрос на сервер → приходит ответ с сервера → обновляется модель → обновляется представление. Это и есть принцип two-way data binding.
Схема взаимного обновления модели и представления
Еще AngularJS привнёс несвойственный клиентским приложениям паттерн проектирования — Dependency Injection (с англ. внедрение зависимости).
Упрощённая схема работы паттерна Dependency Injection
Этот механизм позволяет легко подключать нужные зависимости модулям. Внедрение зависимости можно представить так: у вас есть команда, которая состоит из разработчика (контроллер), дизайнера (сервис) и контент-менеджера (константа). Все они сидят в одном кабинете (DI контейнер). Когда разработчику нужен макет, он обращается к дизайнеру, а тот берёт наполнение для макета у контент-менеджера. Это легко и быстро, ведь все они сидят в одном кабинете. На выходе разработчик получается всё необходимое для реализации проекта.
Но AngualrJS не был бы фреймворком, если бы держался на паре паттернов. В него входит множество сопутствующих инструментов:
AngularJS изменил многое в мире разработки. Появилось всё больше специалистов, которые помогали компаниям ускорить разработку приложений, переписать или написать новые с помощью этого инструмента. Но AngularJS не был идеальным фреймворком и разбил много сердец.
Недостатки
AngularJS тянул с собой облегчённую версию JQuery — JQLite. Это было некоторым оверхедом для приложений, где JQuery был не нужен или у разработчиков была на него аллергия, для современных же приложений — совсем плохая практика.
Но основная проблема была в “digest loop” и его производительности. Digest loop — то, на чём держится тот самый магический two-way data binding. Этот цикл работает так: при изменении модели запускаются все слушатели и происходит сравнивание текущих значений модели с предыдущими. Если функция слушателя изменяет модель, этот цикл будет повторяться до окончания сверки, то есть пока модель не перестанет меняться. Даже если функция слушателя ничего не поменяла, цикл запустит проверку минимум один раз, чтобы убедиться в консистентности модели.
Принцип работы digest loop в AngularJS
Тут и начинается проблема производительности из-за множественного запуска цикла и частых обновлений представления и модели. Это особенно ощутили разработчики, которые работали с “realtime data” или чьи приложения содержали большие и часто изменяемые модели.
Проблему производительности так и не удалось исправить в AngularJS, ведь тогда пришлось бы переписать ядро и отказаться от обратной совместимости. Поэтому чуть позже появился Angular 2+ или просто Angular.
Работа над ошибками — Angular 2
В 2014 году в тёмных лабораториях Google неподалёку от зоны 51 (Area 51) начал создаваться новый фреймворк — Angular.
В сентябре 2016 была опубликована первая версия финального релиза. После этого — анонс Angular 4, а 3 версия была пропущена. Это смутило разработчиков — все боялись повторения опыта AngularJS, связанного с поднятием мажорных версий и отсутствием обратной совместимости. Но, напротив, 4 версия была полностью совместима со 2.
Angular начал регулярный выпуск новых версий с поддержкой обратной совместимости и добавления новой функциональности и оптимизаций. На момент написания статьи последняя версия Angular — 11.
Особенности Angular
Разработчики учли слабые места AngularJS. Изюминкой Angular 2 стал компонентный подход, которого не было в первом, добавилась изоморфность и, конечно же, — Typescript.
Компонентный подход обусловлен использованием и переиспользованием отдельных модулей, которые содержат в себе логику работы с представлением, разметку, стили, события, возможно даже модель. При этом каждый компонент решает конкретную задачу и берёт на себя только то, что должен делать. Например, на простом сайте навигация — компонент, который можно перенести в другое приложение, поменяв конфигурацию.
Разработчик определяет размер компонентов — это могут быть как атомарные части кода, так и большая подсистема, которая состоит из множества подкомпонентов.
Так выглядит небольшой компонент в Angular:
В Angular компоненты могут иметь собственное состояние, но если нужен глобальный state, то можно использовать сервисы и подключать их через Dependency Injection. Если поток данных более сложный и включает в себя много трансформаций, то, как правило, используют библиотеку NgRx.
Ещё несколько новых возможностей Angular по сравнению с AngularJS:
Недостатки
Typescript — не только особенность, но и недостаток Angular. Это отталкивает новичков, ведь писать без него Angular-приложения нельзя. Проблемы Typescript для обывателя: строгая типизация, ошибки, которые порой поправить очень сложно; разные концепты, такие как сложные типы, модификаторы доступа, дженерики, которые нужно понимать.
Кроме этого, Angular — фреймворк с богатыми возможностями, на изучение которых требуется время, нет, скорее, много времени. Поэтому иногда новички сдаются и переходят на более «лёгкие» фреймворки. Но те, кто упорно продолжает осваивать Angular, — редко в нём разочаровываются.
Серебряная пуля от Facebook — React
В 2011 году команда Facebook проводила эксперименты по созданию фреймворков, которые решали бы проблему производительности, а именно — каскадных обновлений. Существовавшие на тот момент решения — AngularJS, Backbone, Ember, Knockout — не давали нужного результата.
У Facebook появилось прототипное решение — FaxJS. Этот проект имел свои особенности:
Изначально на FaxJS построили Facebook Ads Org, а затем Instagram испытал его на своей ленте. Проект FaxJS был экспериментальным и дал начало знаменитому сегодня React. В 2013 React был уже представлен как open-source библиотека на JSConf US.
React — библиотека для отображения данных, которая включает в себя Virtual DOM, JSX, изоморфность и компонентный подход. Грубо говоря, React — это умный шаблонизатор.
Особенности React
Virtual DOM, или виртуальный DOM, — легковесная копия реального HTML DOM в виде JS-объекта в памяти, с которой работает приложение. Он агрегирует в себе все динамические изменения, а уже после применяет их к реальному DOM.
Основная проблема нативного HTML DOM — его скорость при работе с динамическими данными: из него дорого как читать, так и много и часто писать. Виртуальный DOM не является простым объектом, который хранит данные, он имеет эффективные и производительные алгоритмы для сравнения и группировки изменений и выборочных изменений отдельных частей HTML DOM.
Упрощённый пример виртуального DOM:
Другой новый концепт, который привнёс React, — JSX (Javascript and XML). Это синтаксический сахар или, по-другому, расширение JavaScript. JSX напоминает язык шаблонов, наделённый силой JavaScript.
Результат превращения в JS:
Мы уже говорили про архитектурные паттерны MVC и MVVM, так вот React и его компоненты — это буква “V” в MVC/MVVM, то есть view или представление. Такой подход позволяет писать переиспользуемые компоненты и собирать большие функциональные блоки с помощью композиции более мелких компонентов. Так можно описать форму, которая состоит из разных атомарных компонентов на JSX:
С помощью такого компонентного подхода и композиции можно формировать представления любой сложности.
Недостатки
React — слой представления, который не имеет никаких моделей. Иначе говоря, в нём негде хранить данные. Более того, их практически нельзя переиспользовать между компонентами, ведь передача свойств из компонента в компонент на несколько уровней ведёт к антипаттерну — prop drilling.
Проблема такого поведения в том, что при изменении этих данных — добавлении или удалении свойства — требуется пройтись по всем компонентам, где происходит передача, и сделать исправления. Кроме этого, сами свойства могут изменяться (новое имя или информация). В любом случае подход prop-drilling тратит много ресурсов разработчиков и ведёт к появлению багов.
Схема передачи свойств через множество уровней компонентов, что приводит к prop-drilling
Разработчики Facebook понимали эту проблему и добавили в экосистему React новый инструмент — Flux.
Попытка уложить всё по полочкам — Flux
Flux — не только библиотека для хранения глобального состояния приложения, но и архитектурный паттерн. Этот инструмент в первую очередь был представлен в дополнение к React, хотя сама архитектура может применяться где угодно, иначе говоря, framework-agnostic.
Особенности
Схема передачи данных между компонентами в React, как и у любого приложения, которое использует подход MVVM, выглядит так:
Обычная схема взаимодействия многих MVVM-фреймворков
Это катастрофа, которую и призван был решить Flux. Главная цель Flux — сделать движение данных в приложении предсказуемым: они всегда должны двигаться по одному пути.
Flux состоит из 4-х главных частей:
Так выглядит однонаправленный поток:
Схема движения данных во Flux-архитектуре
Недостатки
Всё это выглядит прекрасно, но только на картинке. На практике Flux имел высокий порог входа и проблемы переиспользования функциональности между хранилищами, сложность рендеринга на сервере, недостаточно инструментов для отладки и другие сюрпризы.
Поэтому в 2015 году Даниил Абрамов и Эндрю Кларк представили комьюнити новый инструмент — Redux. Он реализует Flux-архитектуру, но при этом имеет некоторые преимущества.
На этот раз получилось лучше — Redux
Redux — библиотека с простым API, хранилищем состояния приложения, или state container с однонаправленным потоком данных. Во Flux содержится множество хранилищ, в Redux — одно глобальное.
Особенности
Поток данных в React с Redux и без него имеет огромные отличия. Представьте, что вы продаёте значки: самостоятельно ищете точки сбыта через знакомых, что может быть сложно и неэффективно. Так работает React без Redux. Но стоит добавить Redux, как появляется большая площадка для сбыта — Redux store. Это можно сравнить с Wildberries или Lamoda, куда продавец выставляет товар и не тратит время на продажу самостоятельно. Так это выглядит на схеме:
Сравнение передачи данных в React с использованием Redux и без него
Схема потока данных в Redux:
Схема движения данных в Redux
Вам уже знакомы почти все элементы, кроме Reducer.
Reducer — чистая функция, которая принимает действие (Action) и изменяет состояние приложения, иначе говоря, модель. При этом она не мутирует его, а возвращает всегда новое состояние. Поэтому компоненты могут быть оповещены об изменении разных частей хранилища.
Несмотря на то, что Redux был создан с фокусом на React, он вполне нашёл себе применение с другими библиотеками и фреймворками, даже с AngularJS.
Недостатки Redux
Redux немного удручает большим количеством бойлерплейта (кода, который нужно писать, хотя он не несёт в себе логики): на каждую команду нужно написать Action (иногда асинхронный), Reducer, Selector. Чем больше кода пишешь, тем больше бандл.
Комьюнити позиционирует Redux простым инструментом, но с ним всё равно нужно «набить руку»: изучить тонкости и способы применения, научиться проектировать хранилище, а это, как правило, не всегда получается с первого раза.
На связке React и Redux пишут много проектов, поэтому Redux популярен и в 2020 году. Это не самая простая библиотека, а правильное её применение требует знаний и опыта.
От Multipage к SPA и обратно — Next.js
До этого я рассказывал про SPA-фреймворки, которые динамически могут строить страницы без перезагрузки. SPA-приложения обычно включают в себя много кода, который нужно получить при первом старте приложения. Это бьёт по быстродействию открытия страницы и конечно же влияет на UX (с англ. User Experience). Кроме этого, поисковые боты не особо расположены индексировать страницы, построенные на JS, — в 2020 году Google-Bot один из немногих, кто индексирует SPA.
Влияние скорости загрузки страницы на настроение пользователя
До новомодных SPA в тренде был подход multipage, который не имел таких проблем. При этом, чтобы отобразить новое состояние страницы, её нужно было перезагрузить.
Объединить две стратегии работы с приложением взялась компания ZEIT. Так в 2016 году был выпущен SSR (Server Side Rendering) фреймворк — Next.js. Он работает поверх React и позволяет быстро писать и разворачивать multipage приложения, а после получения страницы — работать как с полноценным SPA.
Особенности
Главная особенность Next.js — SSR. Этот фреймворк построен поверх React, поэтому вовсю использует его изоморфность, что позволяет отдавать шаблоны с преднаполненными данными. После этого на страницу добавляется скрипт, который не блокирует построение DOM, и впоследствии загружает весь необходимый JS для динамической работы со страницей. После отображения данных, пользователь взаимодействует со страницей как с полноценным SPA-приложением.
Сode-splitting (с англ. разбивка кода) — ещё одна важная особенность, которая позволяет ускорить открытие отдельных страниц. При получении отдельной странички мы передаём в качестве JS-кода не всё приложение, а лишь малую его часть. Поэтому передача данных по сети происходит быстрее — браузер выполняет код и не тянет лишние зависимости, которые не будут использоваться на нужной странице.
С Next.js можно колоссально сэкономить время на развёртывание приложения — достаточно одной команды. Кроме этого, он берёт на себя всю чёрную работу, которая не всегда приносит удовольствие.
У него есть ещё пара особенностей:
Недостатки
Идеальных решений не бывает и под все задачи просто не существует универсального инструмента. Так и Next.js заставляет разработчиков принимать свою прибитую гвоздями структуру, которая нужна для корректной сборки и работоспособности приложения.
Если вы привыкли собирать проекты с помощью Webpack, добавлять кучу лоудеров, плагинов и оптимизировать сборки, тут этот номер не пройдёт — конфигурация, по которой происходит сборка, скрыта от редактирования и не поддержит любую прихоть.
Кроме этого, Next.js — большой проект, в который придётся вникать, хотя документация и комьюнити весьма хороши.
В 2015–2016 годах было много холиваров на тему SPA vs SSR. Всё новое — хорошо забытое старое, поэтому разработчики с удовольствием встретили multipage-подход, предложенный Next.js. Тем не менее SPA приложения ничуть не потеряли популярность, а, наоборот, стали дополнять SSR. В 2020 году прекрасно применяется как SPA-, так и SSR-подход — каждый из них решает свои задачи и подходит для определённых типов приложений, а количество холиваров на эту тему заметно уменьшилось.
Из Китая с любовью — Vue.js
В 2014 году React только набирал обороты, AngularJS, наоборот, утрачивал свою популярность, а Angular находился ещё в стадии активной разработки. У фронтенд-разработчика уже был большой выбор инструментов, но не все проблемы фреймворков и библиотек были разрешены. Например, сохранялись такие проблемы, как высокий порог входа, низкая скорость разработки и необходимость писать большое количество кода, чтобы приложение «взлетело». Для решения этих проблем появился новый фреймворк — Vue.js. Его создатель, бывший сотрудник Google, активно использовал AngularJS в своей работе, поэтому Vue.js синтаксически на него похож.
У Vue.js был долгий путь становления — фичи добавлялись от релиза к релизу. В начале многие предсказывали ему провал, но с выходом новых версий он только набирал популярность: последняя версия 3.0 вышла в 2020 году. В развитии ему помогло сплочённое азиатское комьюнити разработчиков, а в популяризации — евангелисты.
Довольно быстро фреймворк вошёл в топ-3 китов и стал тягаться с Angular и React:
Сравнение статистики топ-3 фреймворков на Github
Особенности
Vue позаимствовал лучшие практики из разных инструментов.
Cинтетический пример использования шаблонов:
Пользователям понравилось в этом фреймворке многое: от низкого порога входа до скорости разработки приложений.
Из особенностей Vue.js выделяют:
Vue не привнёс что-то новое, он взял уже наработанный багаж знаний из React/AngularJS/Angular и других инструментов, убрал раздутое и сложное API и привёл всё к минималистическому виду.
Vue.js — простой фреймворк, поэтому не нужно долго изучать его экосистему, искать дополнительные библиотеки и писать под него сборку. У него подробная документация, которую многие ставят в пример. На Vue можно быстро писать производительные приложения.
Недостатки
На протяжении становления и развития этого фреймворка разработчики жаловались на небольшое комьюнити и отсутствие гайдов по написанию масштабных приложений. При достижении определённого LOC (lines of code — количество строк кода) и сложной бизнес-логики они не знали, куда и как двигаться дальше. При этом приложение начинало дублировать код и терять унификацию.
Хорошая новость: комьюнити выросло и появился неплохой опыт разработки на Vue.js, поэтому эти проблемы практически себя изжили.
Другой недостаток — компонентный подход не дотягивает до конкурентов вроде React по гибкости. Но в этом нет вины Vue.js, ведь это фреймворк, который предоставляет инструменты для полного цикла разработки приложения. Тогда как React — библиотека для рендеринга, которая в основном фокусируется на компонентном подходе.
В целом Vue.js закрепил за собой статус рабочего решения, которое быстро поднимет проект на ноги за скромные ресурсы. Ему легко обучиться, поэтому всегда можно найти специалистов, готовых поддерживать и развивать проект. А новички могут быстро втянуться во фронтенд-разработку и не утонуть в зоопарке веб-технологий.
Черная магия — Svelte
Казалось бы, топ-3 лидеров продакшена очевиден и устоялся, но комьюнити этих инструментов было недостаточно. Им нужен был быстрый и простой фреймворк, который виртуозно решает повседневные задачи, имеет всё из коробки, и его результирующий код не занимает много места. Последним не могут похвастаться ни React, ни Angular, ни Vue.
Svelte впервые презентовали сообществу в 2016 году, но первая версия особо не продвигалась. Популяризация фреймворка началась со второй версии в 2018 году, а с выходом третьей версии о нём наконец заговорили в комьюнити.
Особенности
Принцип работы Svelte: мы пишем высокоуровневый код с использованием декларативного подхода — описываем, что нужно сделать, а фреймворк уже решает, как это сделать. Иначе говоря, мы описываем результат, а не путь его достижения. На выходе Svelte отдаёт уже низкоуровневый и оптимизированный код, который эффективно работает, например, в браузере.
Как работают Svelte и React под капотом
По сути, Svelte — это компилятор, который не несёт собственный код в результирующую сборку, что выделяет его среди других инструментов. Для сравнения посмотрим на таблицу с размерами минифицированных бандлов библиотек и фреймворков без учёта кода приложения:
Фреймворк/библиотека | Размер, кб |
---|---|
React (v.16) | 97.5 |
Vue (v.2) | 58.8 |
Angular (v.2) | 566 |
Svelte | 0 |
Со временем цифры уменьшаются, но у Svelte по-прежнему остаётся 0.
Кроме этого, Svelte может похвастаться:
Неудивительно, что Svelte активно набирает популярность с таким набором особенностей. А ещё он дружелюбен для новичков и имеет хороший интерактивный туториал.
Недостатки
Бедный CLI или, точнее, отсутствие официального поддерживаемого CLI для Svelte — ощутимый недостаток. Ведь генерация каркаса и сборка возможна только с помощью сторонних шаблонов для развёртывания проекта.
Кроме этого, у Svelte небольшая экосистема по сравнению с React, Vue и Angular. Не всегда просто найти какой-то готовый компонент или библиотеку для Svelte, как в React. Чтобы отыскать альтернативы, потребуется время. Возможно, нужно будет доработать их напильником, а в итоге может оказаться, что они не подходят из-за отсутствующей функциональности или багов.
Ещё один недостаток — небольшое комьюнити. Этот вывод можно сделать по количеству вопросов на https://stackoverflow.com/, где их заметно меньше, чем у Angular или Vue.
Фреймворк Svelte не поддерживается корпорациями, а продвигается за счёт комьюнити. Несмотря на отсутствие больших вложений в маркетинг, Svelte обзавёлся 40k stars на github. Его часто обсуждают на профессиональных конференциях и в блогах, что говорит о его потенциале.
Заключение
В 2020 году лидерами среди фреймворков и библиотек по-прежнему остаются React, Angular и Vue.
Но на горизонте за предыдущие несколько лет уже появились интересные проекты с открытым кодом и большим потенциалом, например Svelte.
Если вам захочется освежить в памяти все рассмотренные фреймворки и библиотеки из этой статьи, просмотрите таблицу:
Название | Год появления | Особенности | Недостатки |
---|---|---|---|
AngularJS | 2010 | В основе лежит паттерн Dependency injection. Использует Two-way data binding подход. Встроенный Router. Встроенная библиотека анимаций. Наличие тест-раннера. Встроенный HTTP-клиент. | Обязывает использовать JQuery. Имеет проблемы производительности. |
Angular | 2016 | Позволяет писать SSR приложения. В наличии богатый CLI. Кроссплатформенный. В основе лежит паттерн Dependency injection. Использует Two-way data binding подход. Имеет встроенный Router; Своя библиотека для анимаций. Наличие тест-раннера. Встроенный HTTP-клиент. Интернационализация. Code-splitting. Написан на Typescript. | Высокий порог входа. Большой размер бандла. Обязательное использование Typescript. |
React.js | 2013 | Высокая производительность рендеринга. Позволяет писать изоморфные приложения. Использует компонентный подход. Реактивность. Концепция Virtual DOM. Компоненты пишутся с использованием JSX. Поддержка Typescript. | Работает только с отображением, не предназначен для работы с данными. |
Flux | 2014 | Предсказуемый поток данных. Легковесная библиотека. Поддержка Typescript. | Высокий порог входа. Отсутствие гибкости в переиспользовании кода. |
Redux | 2015 | Ещё более предсказуемый поток данных, чем во Flux. Легковесная библиотека. Поддержка Typescript. | Не самый низкий порог входа. Необходимость писать много бойлерплейта. |
Next.js | 2016 | SSR-фреймворк. Code-splitting из коробки. Поддержка Typescript. Хороший CLI, который не требует настройки для запуска приложения. Встроенный Router. Hot reload из коробки. | Жёсткая структура проекта. Негибкая конфигурация сборки. |
Vue.js | 2014 | Низкий порог входа. Two-way data binding. Изоморфный фреймворк. Неплохой CLI. Компонентный подход. Возможность использовать JSX. Поддержка Typescript. | Не такое большое комьюнити, как, например, у React. Слишком большая гибкость, которая может привести к архитектурным проблемам. |
Svelte | 2016 | Не занимает место в результирующем бандле. Высокая производительность. Встроенная библиотека анимаций. Поддержка SSR. Кросплатформенный. Поддержка Typescript. | Небольшое комьюнити. Слабый CLI. Небогатая экосистема. |
Полезная литература
Если эта статья вдохновит вас на изучение новых фреймворков и библиотек, я собрал полезные источники, которые могут в этом помочь.