Этим летом ко мне обратился старый знакомый, который хотел начать разработку нового веб-проекта. Он хотел пообщаться/посоветоваться на тему современных инструментов (фреймворков) для разработки веб-приложений. Дело в том, что у него скорее планировалась не разработка нового, а переделка старого проекта, сделанного на JSP и сервлетах, базовая архитектура которого ваялась еще в начале 2000-ных. В прошлом я немного участвовал в жизни этого программного продукта (доработки по Hibernate, прикручивал apache fop и т.д.), поэтому был немного в курсе внутренних особенностей системы.
В целом это было добротное веб-приложение на Spring-e и оракловой СУБД. Думаю многие из нас в былые времена делали подобные вещи. С тех пор многое поменялось, одни инструменты сильно развились, появились абсолютно новые, а некоторые безнадежно устарели и канули в Лету. В итоге мы решили встретиться, пообщаться, попить кофе и обсудить, кто с чем столкнулся на профессиональном поприще за последние несколько лет, а также поделиться впечатлениями об использовании тех или иных инструментов.
На мой взгляд к 2013 году человечество создало такое огромное количество библиотек, утилит, платформ и других полезных и бесполезных вещей для создания веб-приложения, что разобраться в них становится все сложнее и сложнее. Суть проблемы заключается в том, что обилие различных модных слов создают кашу в голове программистов.
Чтобы хоть в чем-то упростить себе (и другим программистам) жизнь, я решил после нашей беседы написать этот небольшой обзор различных веб инструментов (в контексте Java и JavaScript). Возможно многие вещи покажутся слишком простыми и очевидными, рассчитанные на совсем юных программистов, тем не менее думаю ошибочно считать, что “каша” возникает только у новичка. Наоборот, умудренные опытом программисты, опираясь на сформировавшиеся у себя в мозгу концепции, проецируют свои старые понятия на новые фреймворки, в итоге сложнее впитывают суть, смысл и назначение новых.
Ведь на самом деле, многие инструменты качественно отличаются друг от друга и сравнивать их порой не представляется возможным. 
В английском языке существует выражение “сравнивать яблоки и апельсины“, в русском языке ближайшим аналогом этого высказывания “путать теплое с мягким“. Сравнивать разные по сути вещи. Например, все равно что сравнивать JSF и jQuery.
Поэтому, чтобы внести ясность, я решил раскидать “яблоки к яблокам, а апельсины к апельсинам”. В итоге получился следующий текст.
Servlet-ы, JSP и JSTL
Начнем со старых очевидных вещей, которые знают все Java программисты. Если упрощенно, то Servlet – класс, который отдает HTML-ку на браузер. JSP cделали, чтобы не писать громоздкие сервлеты в котором куча HTML-кода. Другими словами пишется HTML-подобный код со специальными “хаками”, с помощью которых можно вызывать в нужных местах Java-код. Затем из JSP-ки создается сервлет, который компилируется и запускается как обычный сервлет.
Лично мое мнение, внешне исходный код на JSP чем-то похож на PHP. Только почему-то тот код, который в JSP считают “некрасивым”, в PHP считается нормой и элементами “хакерской культуры”. Еще раз повторюсь, это мое личное мнение.
Чуть позже появились Custom Tags и стандартная библиотека тэгов (JSTL), поскольку долго мучатся со скриплетами было невыносимо. Некоторые до сих пор пользуются этим стэком технологий для небольших задач.
Struts, JSF, Spring MVC
Дальше интересней. Выдавать HTML-ки это полбеды. Стал вопрос как не запутаться в правилах — какой запрос каким сервлетом обрабатывается, какая страничка в итоге должна показаться? Где и как проверять данные от формы? Как связывать содержимое HTML страницы с данными хранящимися в объектах?
Грубо говоря нужно где-то понятно описывать логику: нажали на кнопку, отправили запрос на сервер, сервер обработал запрос, показал нам новую страничку, при этом данные биндятся в верстку наглядным способом.
Сейчас это кажется очевидным. Всем понятно, что нужен механизм для диспетчеризации запросов и необходимо ввести такую сущность как сервлет-диспетчер, который выполняет функцию контроллера и осуществляет обработку и перенаправляет к соответствующей JSP. Всё это считается классикой MVC, а указанные выше фреймворки плотно заняли свою нишу (в умах программистов).
Отдельно хочу остановиться на JSF, технологией которой можно считать “правоприемницей” JSP. Во-первых текущую (вторую) версию JSF ругают на много меньше, чем первую. Специально интересовался мнением разных своих знакомых веб программистов, все как будто спелись и говорят: “А мы последние пару лет на JSF 2 живем, решили попробовать и нам нравится”. С первой версии JSF была совсем другая история.
Во-вторых JSF уже вобрал довольно большое количество сторонних компонентов и фреймворков, поэтому при создании UI уже есть из чего выбрать. Например довольно популярны PrimeFaces. Библиотека написана турецкими программистами, но пользуется спросом у нас и за рубежом.
Google Web Toolkit. Инструмент, который создает JavaScript-код на основне Java кода. Многие, когда пытаются рассказать про GWT, говорят, что он позволяет делать интерфейс похожими на Gmail. На самом деле это только внешнее сходство, Gmail сделан не на GWT, но об этом позже.
Принцип работы GWT довольно занятный. Вы пишите код на Java, как в старые добрые времена с помощью Layout-ов, Button и других классов предоставленных Google. После этого классы анализируются и на основе их “компилируется” JavaScript-код. Лично я, в последнее время стараюсь GWT использовать по минимуму и считаю, что необходимо очень хорошо подумать, прежде чем принимать решение применять его или нет.
Так, плавно, мы перешли к описанию клиентских фреймворков, то есть кода, работающего непосредственно в браузере, при этом я хочу сказать абсолютно банальную вещь, до сих пор смущающую некоторых разработчиков.
AJAX – это не фреймворк и не библиотека. Это способ отправки асинхронных запросов на сервер с помощью JavaScript-а из странички. Можно отправить запрос на сервер, обработать ответ и вставить результат в текущую страничку.
Подобное заблуждение напоминает казус с австралийской девушкой, баллотирующейся в местный парламент, которая назвала ислам — страной. Подобная ошибка, безусловно, поставила крест на ее карьере, также как и нам непонимание принципов работы может стать непреодолимой проблемой в решении задач.
Влияние AJAX на умы веб-разработчиков было огромно. В итоге появилось огромное количество веб-приложений, интерфейс которых в большей части формируются с помощью JavaScript кода. Для пользователя это хорошо, но в итоге программистам пришлось больше писать на JavaScript-e, а это сомнительное удовольствие.
Сейчас все меньше и меньше людей, которые пишут на JavaScript-е без сторонних библиотек — это не удобно, большинство использует готовые фреймворки вроде jQuery.
jQuery — JavaScript библиотека. Просто набор функций (API), с помощью которых удобней писать программы на JavaScript.
Вместо:
var el = document.getElementById("some_id");
el.innerHTML = 'hello';
Получаем:
$('#some_id').text('hello');
jQuery это не готовые UI компонентов, а скорее удобные функции для работы с DOM-ом и AJAX-ом! Если нужен свой UI, то есть библиотека которая дополняет jQuery, она называется jQuery UI. В ней можно найти набор разных графических компонентов начиная от кнопок и заканчивая диалогами и табами.
Sencha Ext JS (в прошлом просто Ext) – JavaScript библиотека, основная мощь которой в наборе классных виджетов для создания UI. С его помощью любят создавать интерфейс в приложениях а-ля админка, в которых много формочек и таблиц.
Существует связка Sencha + GWT (Sench GXT), которая позволяет делать интерфейс как в Sencha, но с помощью GWT. Года три-четыре назад это было популярно, некоторые до сих продолжают использовать. Если открыть их демонстрационный пример, скорее всего вам покажется, что вы уже где-то видели похожее веб приложение.
Backbone.js – библиотека, которая позволяет структурировать JavaScript-код. Создает некий шаблон связывающий Model (хранение данных) и View (представление данных) и обработку событий. Backbone.js — это не набор виджетов. Это “каркас” состоящих из набора объектов и функций на JavaScript-e, который должен определить структуру JS-кода. Помните как все мучились на сервер сайде до появления внятного MVC фреймворка (Struts и последователи)? Вот здесь похожая ситуация, только на стороне браузера. Поскольку количество JavaScript кода становиться с каждым годом всё больше и больше, то необходимость в структурирование становится все острее. Сейчас в обиход входит такое понятие как JavaScript MV* framework, которое объединяет подобного рода библиотеки.
Вернёмся к Google. На самом деле Google использует для создания GMail и других своих действительно массовых продуктов Closure Tools. Этот набор инструментов состоит из “компилятора” (Closure Compiler), библиотеки для написания JavaScript-кода (Closure Library) и других полезных вещей. Библиотека призвана решать такие чувствительные для JavaScript-программиста вопросы как управление зависимостями (появляется “модульность”), работы с событиями, API для работы с виджетами и многое другое. Компилятор – проверяет целостность и корректность JavaScript кода на основе специальных “аннотаций”, которые программист могут указать в комментариях в коде. В итоге можно частично сделать проверку типов и некоторые другие проверки еще на этапе “компиляции”, кроме этого после прохода компилятором может уменьшится итоговый размер JavaScript кода.
Итог.
Я умышленно не стал писать про скальный лифт, рельсы и другие популярные веб-фреймворки, чтобы не вносить еще большую путаницу. Конечно они заслуживают внимания, но здесь я старался ограничиться скорее Java/JavaScript. Конечно я понимал, что описать все подобные фреймворки/инструменты мне не удастся, т.к. эта “вселенная” огромна и постоянно расширяется, тем не менее считаю, что когда расставлены хоть какие-то “указатели” становится немножко легче.
P.S.: Отдельная благодарность Serj за предложенные дополнения к тексту.