Java Происхождение Angular JS: Angular против JSF против GWT

Супергеройская структура Javascript нуждается в хорошей истории происхождения. Давайте попробуем соединить его вместе, рассматривая использование Angular JS в мире корпоративной Java и Angular в MVC.

Этот пост будет посвящен следующим темам и закончится примером:

• Java Происхождение Angular JS
• Угловой против JSF
• Угловой против GWT
• Угловой против JQuery
• Угловой взгляд на MVC (или MVW)
• М в MVC — Области применения
• V в MVC — Директивы
• C в MVC — Контроллеры

Происхождение Angular JS

Angular становится предпочтительным фреймворком для разработки веб-приложений в корпоративных настройках, где традиционно бэкэнд построен на Java, а внешний интерфейс — на основе Java / XML, такой как JSF или GWT.

Поскольку Java-разработчики часто живут в мире Spring / Hibernate, мы можем задаться вопросом, каким образом фреймворк MVC, основанный на внедрении зависимостей и грязной проверке, когда-либо смог прыгнуть с сервера в наши браузеры, и посчитал это интересным совпадением.

История позади угловой

Оказывается, что сходства, скорее всего, не случайны, потому что в своих корнях Angular был создан Java-разработчиками из Google, которые считали, что они неэффективны, создавая приложения с использованием Java, в частности GWT.

Вот несколько важных цитат разработчиков Angular о происхождении Angular, недавно появившихся на Javascript Jabber Podcast (стенограмма здесь ):

мы что-то строили в GWT и очень расстраивались, насколько непродуктивным я был.

мы могли бы создать приложение (Google Feedback) намного быстрее, чем мы могли бы создать его в GWT.

Таким образом, это означает, что Angular был эффективно создан разработчиками Java GWT, работающими полный рабочий день, в ответ на то, что они чувствовали, что платформы Java ограничивают производительность их разработки.

JSF или GWT — все еще путь?

Несмотря на два совершенно разных подхода, одна из основных целей JSF и GWT состоит в том, чтобы абстрагироваться, по крайней мере, от части Интернета, позволяя выполнять веб-разработку в мире Java / XML.

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

Хотя их можно заставить работать нормально, вопрос в том, какой ценой?

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

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

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

Исторический контекст JSF и GWT

Важно понять, как JSF / GWT оказался на первом месте: они были созданы для использования в сценариях, где корпоративный бэкэнд уже существовал, встроенный в Java / XML, и существовала необходимость повторно использовать эту же команду корпоративных разработчиков для создания также интерфейс.

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

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

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

Угловой против JSF

JSF появился более или менее одновременно с Ajax, взорвавшимся на сцене веб-разработки десять лет назад. Первоначальная версия JSF не была разработана с учетом Ajax, а была задана как модель запроса / ответа на всю страницу.

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

Затем серверный вид преобразуется назад и вперед в HTML, CSS и Javascript, рассматривая браузер главным образом как платформу рендеринга без какого-либо состояния и ограниченного контроля над происходящим.

Страницы генерируются путем преобразования представления сервера View в HTML, CSS и Javascript с помощью набора специальных классов, называемых Renderers, перед отправкой страницы пользователю.

Как работает JSF?

Затем пользователь будет взаимодействовать со страницей и отправлять обратно действие, как правило, через HTTP POST, а затем с помощью контроллера JSF запускается жизненный цикл на стороне сервера, который восстанавливает дерево представления, применяет новые значения к представлению и проверяет их, обновляет Модель предметной области вызывает бизнес-логику и возвращает новое представление.

Затем в JSF 2 была разработана среда для нативной поддержки Ajax и веб-разработки без сохранения состояния, но основной подход к генерации HTML в браузере на основе серверной модели остался.

Как Angular сравнивается с JSF?

Основное конструктивное отличие заключается в том, что в Angular модель, представление и контроллер перенесены с сервера в сам браузер.

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

Angular не требует этого, но на сервере обычно практически нет состояния, и он обслуживает в основном JSON через службы REST.

Насколько важен Javascript в JSF?

JSF склоняется к Javascript, кажется, что язык — это то, что разработчики библиотеки JSF должны знать, но обычно не разработчики приложений.

Самая распространенная библиотека JSF Primefaces содержит внутри себя тысячи строк кода Javascript для своих виджетов внешнего интерфейса на основе jQuery, но в проектах на основе Primefaces Javascript часто очень мало или вообще нет в самой базе кода приложения.

Тем не менее, для разработки пользовательских компонентов в Primefaces важно знать Javascript и jQuery, но обычно только небольшая часть команды разработчиков должна знать это.

Угловой против GWT

Второе поколение веб-разработки на Java для браузера появилось с появлением GWT. В дубле GWT модель, представление и контроллер также перемещаются в браузер, как в Angular.

Основное отличие заключается в способе обработки Javascript: GWT предоставляет компилятор Java в Javascript, который рассматривает Javascript как механизм выполнения байт-кода на стороне клиента.

В этой модели разработка полностью выполняется на Java, а в процессе сборки код компилируется в Javascript и выполняется в браузере.

GWT берет HTML и CSS

В GWT HTML и CSS не предназначены для того, чтобы быть полностью скрытыми от разработчика, хотя пространства имен XML предоставляются пользователю для размещения по крайней мере некоторых основных блоков страницы.

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

Почему Javascript трансплантация приближается?

GWT не очень отличается от Angular определенным образом: это MVC в браузере, а Javascript является целью для распространения, а не языком разработки приложений.

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

Помогает ли объектно-ориентированный подход GWT?

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

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

Нужен ли дополнительный уровень абстракции?

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

С объектно-ориентированной абстракцией страницы разработчик часто вынужден отлаживать свой путь через множество классов для простых вещей, таких как поиск, где добавить или удалить простой класс CSS, или обернуть элемент в div.

Режим Super Dev помогает, но кажется, что вся иерархия объектов GWT, компилятор Java to Javascript и несколько режимов отладки, а также экосистема плагинов для браузера и IDE — все вместе гораздо сложнее, чем то, что они пытаются спрятать в первую очередь. : паутина.

Угловой против JQuery

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

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

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

Наиболее успешной из этих библиотек является jQuery, которая в основном представляет собой библиотеку манипулирования страницами, но она не предназначена для MVC-среды.

JQuery в мире Java

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

Много кода наподобие этого написано при использовании jQuery (пример из виджета автозаполнения Javascript Primefaces ):

Как мы видим, сами разработчики Primefaces должны знать о HTML, CSS и Javascript, хотя многие разработчики приложений используют предоставляемые теги XML, которые обертывают виджеты внешнего интерфейса и воспринимают их как черный ящик.

Этот тип кода напоминает код, изначально написанный в Java-разработке, когда появился Servlet API, но еще не было JSP:

Что позволяет Angular — это отделить модель от вида и свободно склеить их вместе с контроллером.

Angular JS принимает MVC (или MVW)

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

В Angular модель — это просто POJO — обычный старый объект Javascript.

Angular также признает существование View, который декларативно связан с моделью. Представление — это просто HTML с некоторым специальным языком выражений для привязки взаимодействия между моделью и пользователем и механизмом многократного использования компонентов, известным как директивы.

Он также признает необходимость чего-то склеивать Модель и Вид, но он называет этот элемент, следовательно, «Wathever». В MVC этот элемент является контроллером, в MVP — ведущим и т. Д.

Минимальный угловой пример

Давайте рассмотрим три элемента MVC и посмотрим, что они соответствуют в Angular, используя пример минимального интерактивного умножения, здесь он работает в jsFiddle .

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

Как это будет выглядеть в JSF и GWT?

В JSF, например, в Primefaces, это означало бы, что нужно написать небольшой плагин или подпрограмму jQuery, чтобы добавить функцию интерактивного умножения, создать шаблон лицевой стороны, объявить тег лицевой стороны и добавить его в библиотеку тегов и т. Д.

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

Улучшенная производительность разработчика

Мы можем видеть, что разработчики Angular JS имели в виду под улучшенной производительностью, поскольку полная версия Angular следующая, написанная за несколько минут:

Итак, давайте рассмотрим настройку MVC этого примера кода, начиная с M.

М в MVC — Угловые Области

Модель в Angular — это простой объект Javascript. Это объект модели, внедряемый в область видимости:

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

V в MVC — улучшенный HTML

Представление в Angular — это просто HTML, аннотированный специальным языком выражений, например определением поля multiply() . HTML действительно действует в этом случае как шаблон на стороне клиента, который можно разделить на многократно используемые компоненты HTML, называемые Директивами.

C в MVC — угловые контроллеры

CalculatorCtrl является контроллером примера приложения. Он инициализирует модель до визуализации представления и действует как связующее звено между представлением и моделью, определяя функцию умножения.

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

Выводы

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

Простота и скорость разработки, которую он приносит, привлекательна для разработчиков Java, которым в той или иной степени уже приходится иметь дело с HTML, CSS и часто с Javascript.

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

Альтернативный способ использования Angular

Другая возможность заключается в том, что Angular используется внутри таких структур, как JSF, в качестве внутреннего механизма реализации.

Посмотрите, например, этот пост от руководителя проекта Primefaces:

У меня есть планы добавить встроенную поддержку фреймворка js mvc, возможно, он будет угловатым.

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

Одна вещь кажется очевидной: Angular как платформа MVC приложения или как внутренняя деталь инфраструктуры на основе Java / XML, кажется, медленно, но верно пробивается в корпоративный мир Java.

Ссылки по теме:

Отличный онлайн-ресурс для Angular: egghead.io Уроки Angular , серия минимальных 5- минутных видео-лекций Джона Линдквиста ( @johnlindquist ).