Интернет-технологии позволили организациям расширяться, сокращая время выхода на рынок новых продуктов и услуг. Интернет был отличным, но основным преимуществом здесь является HTTP. Некоторые могут не согласиться, но большая часть связи между веб-приложениями и мобильными приложениями осуществляется по протоколу HTTP. HTTP — не единственный протокол для Интернета, но он является основным средством реализации. Один из способов использования протокола HTTP — через веб-браузер. Как разработчик и архитектор, ваши возможности ограничены, когда дело доходит до создания приложения для браузера. Мы рассмотрим некоторые из ограниченных вариантов позже. Мы рассмотрим доступные фреймворки с точки зрения языка Java. В этой статье не обсуждается, какой фреймворк лучше, чем…. Этот выбор остается за вашей командой. Есть много моментов, которые следует учитывать при выборе веб-фреймворка для вашего проекта, но мы ограничимся следующими немногими:
Где ваши пользователи?
Надо сказать, что наиболее важным аспектом программного проекта является учет его пользователей. Как они будут взаимодействовать с приложением? Эта статья блога посвящена Интернету и не будет обсуждать автономные настольные приложения.
То, как программное обеспечение доставляется конечным пользователям, будет иметь большое влияние на решение о том, как реализовать программное обеспечение, по крайней мере, на пользовательском интерфейсе.
Итак, каков наш выбор для интерфейса?
Чтобы приложение доставлялось через браузер, совместимый с HTML5, мы остановились на одном варианте. Помните, чуть ранее мы упоминали, что существуют ограничения в разработке для веб-браузера. Ну, веб-браузеры изначально понимают только следующие языки: HTML, JavaScript и каскадные таблицы стилей. Ключевое слово — «изначально». Вы можете писать плагины, поскольку вы можете видеть, что они быстро становятся вымирающим видом. Просто повторим еще раз, чтобы не запутаться; веб-браузеры изначально понимают только HTML, JavaScript и CSS. Теперь давайте двигаться дальше от этого.
Что делать Java-разработчику?
Что ж, ответ прост: изучайте HTML, JavaScript и CSS! Нет, это не совсем так. Согласен, что изучение языка Интернета дает безграничные возможности J. Разработчики заняты тем, что стараются уложиться в сроки, и поэтому они не могут позволить себе роскошь бросаться в новые горизонты. Предполагая, что все разработчики могут писать код HTML5 и развертывать Bootstrap для CSS, нам остается только JavaScript.
Вот несколько вариантов:
- В зависимости от вашего уровня знаний JavaScript
AngularJS — этот фреймворк был написан разработчиками Java, работающими в Google над проектом GWT. Из-за влияния на их производительность они решили разработать чистый JavaScript, который реализовал контроллер представления модели (или презентацию, или что-то еще, что вы хотите). Этот фреймворк очень популярен и породил BackboneJS и ReactJS .
- Если вы являетесь командой разработчиков Spring, вам придется переосмыслить свою архитектуру, поскольку фреймворк AngularJS перемещает контроллер на сторону клиента. Вы все еще можете подключить его, но вы должны быть готовы к тому, что у вас будет больше стандартного кода. Ваша команда переносит ваш код Spring на архитектуру на основе REST, тогда AngularJS будет хорошей структурой, если вы умеете писать JavaScript.
JQuery — это JavaScript-фреймворк, который является скорее вспомогательным инструментом, чем попыткой изменить привычку программистов. Мощь JQuery означает, что вы можете встроить его в проект, который требует некоторого выполнения на стороне клиента. Вы можете прекрасно использовать в своем проекте Spring. Платформа очень зрелая и стабильная, и это механизм JavaScript в технологии Oracle Java Server Faces (JSF) для выполнения на стороне клиента.
Vaadin (Google Web Toolkit — GWT) — этот фреймворк представляет собой порт GWT, ранее разработанный Google. Когда команда team G решила уйти из GWT, на помощь пришли хорошие ребята из Vaadin Ltd. Для Java-разработчика этот фреймворк имеет наименьшую кривую обучения. Разработчики пишут свой код на Java, который затем компилируется в JavaScript для браузера. Vaadin не вписывается в архитектуру вашего веб-приложения Spring, разработчикам, использующим Vaadin, не нужно беспокоиться о написании одного кода JavaScript, и они по-прежнему обладают мощью Java (подмножество) и JavaScript в браузере.
Apache Wicket — основан на компонентах и не продвигает шаблон MVC. Тем не менее, Apache Wicket можно интегрировать с Spring MVC, чтобы превратить его в полнофункциональную среду MVC. Это должно понравиться команде Spring. Подход к разработке Wicket очень похож на JSF. Есть несколько постов, сравнивающих их и в некоторой степени. Кривая обучения использованию Wicket довольно низкая, поскольку все содержится в коде Java. За исключением пространств имен Wicket в HTML, веб-дизайнер может работать над пользовательским интерфейсом практически изолированно от внутреннего разработчика. Wicket использует JQuery в качестве движка JavaScript.
Итак, как мы на самом деле выбираем, с какой структурой работать?
Здесь необходимо учитывать три основных фактора: время, стоимость и ресурсы. Таким образом, ведущий программы должен был бы задать себе следующие вопросы:
- Когда проект должен быть запущен?
- Есть ли у нас ресурсы, необходимые для реализации проекта с выбранной структурой?
- Сколько будет стоить приобретение этих ресурсов, если они потребуются?
Ответы на приведенные выше вопросы прояснят, что делать. Кроме того, при выборе фреймворка проверьте его зрелость; как часто он обновляется и насколько велико сообщество, поддерживающее его. Не позволяйте шумихе затмить ваше суждение.
Заключение
В статье обсуждались некоторые из самых популярных веб-фреймворков для Java-разработчиков . Выбор фреймворка не должен быть сложной задачей. Если вы зашли в тупик с выбором, проведите проверку концепции, чтобы определить, какой из них работает для вас. Но убедитесь, что вы смогли ответить на все вопросы о времени, стоимости и ресурсах. Все фреймворки претендуют на звание лучших, но это просто бессмысленная шумиха. Помните, когда Ruby был так раскручен, но Twitter и LinkedIn позже отказались от него в пользу Java? Должно быть, это сказалось на стоимости. Не все компании могут позволить себе отложить проект и начать с нуля. Если у вашей команды нет опыта работы с JavaScript, нет смысла заставлять их выбирать что-то вроде AngularJS, так как вероятность появления ошибок будет выше.