Pull to refresh

О некоторых современных технологиях разработки веб-интерфейсов

Reading time 6 min
Views 2.4K

Наступление


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

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



ExtJs desktop example application
Имитация рабочего стола, сделано на ExtJs

История вопроса


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

Каменноугольный период


Итак, когда трава была зеленее, девушки добрее, а мониторы толще, в нашем распоряжении были только HTML, CSS и какой-нибудь слабенький скриптовый язык на выбор, jscript или vbscript (ни на что путное не годный).

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

Отдельные смельчаки пытались использовать ActiveX и Ява-апплеты (помните – «приложеньице запущено»?), но без особого успеха. Тяжёлое было время, чего там говорить.

Средневековье


Время шло, скриптовые языки потихоньку окрепли и в профессиональный лексикон прочно вошёл термин DHTML – dynamic HTML. Вскоре ни один большой коммерческий сайт не обходился без выпадающего меню. Чем изощрённее была dhtml страница, тем больше было ошибок при её отображении именно в вашем броузере. Многими сайтами из-за обилия неграмотного кода было просто невозможно пользоваться. Среднестатистический разработчик по-прежнему был обречён работать с набором платформ, и каждая из них добавляла ему неповторимый набор проблем.

Новое время


К вящей радости всех людей доброй воли, jscript победил vbscript и в нашем распоряжении стали появляться удачные и унифицированные библиотеки утилит, сильно упрощающие процесс разработки и позволяющие создавать более-менее совместимый код. К тому же, утвердившийся к тому времени в умах разработчиков (и, что немаловажно, клиентов) Ajax навсегда изменил подход к разработке интерфейсов.

Параллельно, Macromedia и её Flash, который ещё недавно никто из программистов не воспринимал всерьёз, стала предоставлять уже не очень смешные инструменты для разработки веб-приложений.

Наши дни


Нельзя сказать, что наступил золотой век, но, повторюсь, маленькая революция в области разработки продвинутых интернет-приложений (rich internet applications) уже произошла. Современные фреймворки позволяют программисту веб-интерфейсов уже не чувствовать себя строителем космической ракеты из скрепок и жевательной резинки.



Backbase — крепкий середняк

Проблемы платформы


Почему броузер – это наша патентованная таблетка для головной боли:
  • HTML плохо подходит для точного позиционирования элементов
    Jscript тормозит, как и любой другой интерпретируемый
    DOM тормозит
    Модификация DOM в реальном времени очень тормозит
    Совместимость Jscript между разными броузерами и ОС по-прежнему хромает
    Небольшая ошибка в коде может повалить всё приложение.

    Решение


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

    При наличии такого слоя нам неважно, с чем мы на самом деле работаем, с document.all или document.layers, с XMLHttpRequest или Microsoft.XMLHTTP, все необходимые трансформации производятся за кадром, без нашего участия.

    Именно таким путём пошли создатели Flex, ExtJs, GWT, BackBase и ещё нескольких современных фреймворков для создания продвинутых веб-приложений.

    Классификация


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

     Компилируемые   Интерпретируемые 
     Декларативные   Flex
    SilverLight

     Объектно-ориентированный код   GWT   ExtJs 


    Сompiled vs interpreted


    Компилируемые технологии компилируют (сюрприз!) код, превращая его или в бинарный исполняемый файл (Flex, SilverLight) или в обычный HTML+Jscript (GWT).

    Интерпретируемые, по старинке, используют броузер для запуска Jscript, но добавляют в объектную модель ещё один уровень абстракции, взамен стандартного DOM’а (Ext.Element в ExtJs, Element в Prototype).

    От себя добавлю, что компилятор, конечно, штука хорошая, но и цена у него немалая: цикл разработки удлиняется, потому что в него добавляется этап компиляции – compile, deploy, run, compile, deploy, run… А в случае с Flex, в ваш любимый IDE придётся добавить поддержку ActionScript (SilverLight, насколько я понимаю, интегрируется с .NET, а GWT – с Java).

    OOP vs declarative


    Одни фреймворки используют декларативный XHTML-подобный код для построения интерфейса (BackBase: <b:listGrid width="auto" height="100%" />), другие – объектно-ориентированный (ExtJs: new Application.GridPanel(…).add(new Application.Button(…)).

    Лично мне больше нравится OOP подход, потому что при декларативном подходе, вам всё равно придётся писать дополнительный, недекларативный код для расширения функциональности стандартных виджетов. Так например, выглядит фрагмент кода в BackBase:
    <e:handler event="click" type="text/javascript">
    var oMask = document.getElementById("maskContainer");
    oMask.style.zIndex = "3";
    [...]
    </e:handler>


    У такого стиля есть преимущества – он близок и понятен HTML-кодеру (тэги! тэги!!), но обычного программиста может и напугать.

    Ajax vs plug-in based


    Ребята из MS и Macromedia (то есть, виноват, Adobe) не стесняются устанавливать в ваш броузер плагин, который выполняет роль виртуальной машины, исполняющей компилированный код (Flex, SilverLight). Понятно, что плагин даёт массу преимуществ, прежде всего – скорость исполнения. Интерпретируемому коду не угнаться за исполняемым.

    Вдобавок, этот плагин можно переносить на самые разные платформы, практически не меняя исходного кода. Вот Adobe уже сделала AIR – технологию, позволяющую разработчикам Flex писать на нём «почти настоящие» десктоп-приложения.

    Недостатки, однако, тоже очевидны – не каждый пользователь готов устанавливать плагин, да ещё и периодически его обновлять. К тому же, вы, разработчик, будете накрепко привязаны к фирме-производителю плагина. Если он перестанет обновляться и поддерживаться, ваше приложение придётся переписывать заново. Если же обанкротится фирма-производитель более традиционного, Jscript-фреймворка, то вы вполне можете поддерживать своё приложение в рабочем состоянии самостоятельно – код-то весь у вас.


    Flex — очень быстро, но очень хлопотно

    Новая старая модель


    Все упомянутые объектно-ориентированные технологии используют более-менее один и тот же подход к описанию собственно интерфейса. HTML/CSS код уступает место набору объектов. Вместо

    <table …>

    My application




    Вы пишете нечто вроде New Panel({ header: “My application” })

    Вместо <input type=”button” value=”My Button” … />
    будет New Button( {label: “My button”, handler: Buttons.myButton.click} )

    И так далее. Понятно, что за кадром весь такой код трансформируется во всё тот же HTML/CSS, но явное построение интерфейса происходит в форме, хорошо знакомой разработчикам обычных десктоп-приложений.

    Как выбрать?


    Да, как же выбрать подходящую технологию для разработки? Правильного ответа не существует. Решение принимать вам. При подобных размышлениях советую принимать во внимание, как минимум, следующие критерии:
    • какие новые возможности открывает технология
      время обучения (порог вхождения) для нового разработчика
      относительная скорость разработки
      быстродействие приложений
      изменения, которые придётся сделать в вашей среде разработки
      наличие инструментов для быстрого построения приложения (RAD)
      возможность интеграции с вашим серверным кодом
      лицензирование
      репутация и время существования фирмы-производителя (или коллектива энтузиастов, если это open source)
      техподдержка / форумы энтузиастов
      качество графических тем, доступных по умолчанию (к сожалению, некоторые вполне серьёзные фреймворки снабжены беспомощным набором тем, которыми невозможно пользоваться «из коробки» без дополнительной обработки напильником)
      качество документации
      локализация и интернационализация
      расширяемость – возможность писать свои компоненты
      …и ещё миллион соображений. Решайте сами, какие факторы для вас важны, а чем можно поступиться.

      Заключение


      Жизнь разработчика веб-интерфейсов в последнее время сильно упростилась. ExtJs, GWT, Flex, SilverLight, BackBase и многие другие современные разработки практически нейтрализуют недостатки броузера, как платформы для приложений. Пользуйтесь готовыми хорошими технологиями, не изобретайте велосипедов и всё у нас с вами будет хорошо.

      P.S. Эту и некоторые другие статьи можно почитать на сайте emdin-here.ru.
Tags:
Hubs:
+14
Comments 21
Comments Comments 21

Articles