Закат Веба?

7 марта прошлого года W3C, после 10-летнего перерыва, возобновила работу над HTML.

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

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

Я решил выложить их в виде статьи, переработав и снабдив иллюстрациями и примечаниями.

Содержание:

1. Вступление
2. Сценарии гибели
   • Гибель ментальная, или HTML — новый ассемблер
   • Гибель физическая, или HTML — новый Turbo Pascal
3. Все ли так серьезно?
   • Ментальной гибели не будет, если web-технологии будут правильно поняты
   • Физической гибели не будет, если web-технологии будут развиваться
4. Заключение
5. Примечания

В настоящий момент мир вступает в эпоху расцвета богатых web-приложений.

Программы, работающие через Веб, все больше вытесняют традиционные десктопные приложения. Gmail, Google Map, online-офис, даже web-операционные системы… Список можете продолжить сами.

Однако, по мере продвижения web-приложений, все больше возрастают требования к основным клиентским web-технологиям: xHTML, CSS, JavaScript.

И, если эти технологии не будут поспевать за все более возрастающими требованиями, это приведет к их медленному закату…
 

Сценарии гибели:

Гибель ментальная,

или HTML – новый ассемблер

На заре IT все программы писались на ассемблере.

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

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

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

Поэтому, на смену ассемблеру пришли языки высокого уровня. Ассемблер при этом физически никуда не делся — все программы на высокоуровневых языках компилируются во все тот же ассемблерный код ^[1]. В уродский неэффективный ассемблерный код.

Тем не менее, ассемблер исчез ^[2]. Исчез из сознания программистов. Они стали писать на высокоуровневых языках, уже на этих языках вылизывать код программы и доводить его до совершенства. А то, что красивая программа на C++ компилируется в уродский ассемблерный код, уже никого не волнует.

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

Таким образом, никуда не деваясь физически, ассемблер исчез из IT индустрии.

 

Подобная судьба может ждать и xHTML/CSS/JS.

За все время существования Веба, основной web-технологией был xHTML.

Web-разработчики довели эту технологию до совершенства: научились отделять представление от содержания посредством CSS, применять бестабличную и семантическую верстку, использовать микроформаты…

Но, в xHTML нет столь нужных для современных web-приложений тегов, таких как вкладки, меню, деревья, календари и т.д.

Чем удачно воспользовалась корпорация Микрософт. У Микрософта давний зуб на web-технологии, ведь будучи открытыми стандартами, они (в отличие от Windows API) не подчиняются микрософтовской власти. С этим надо было что-то делать, и раз Микрософт не могла уничтожить xHTML физически, надо было, чтобы он исчез хотя бы в сознании разработчиков.

Так появилась web-интерфейсная модель ASP.NET. В ASP.NET работа идет с высокоуровневым серверными контролами (меню, вкладками, деревьями), которые затем «компилируется» в HTML, CSS и JavaScript, так же как программа на C++ компилируется в ассемблер.

xHTML/CSS/JS исчезает из сознания web-разработчиков; более того, они в какой-то мере перестают быть web-разработчиками, возвращаясь в привычную Windows forms / Delphi / Visual Basic парадигму, к старым добрым Windows API.

В ASP.NET обесценивается то, что мы так долго учили: умение писать понятный xHTML код, бестабличная и семантическая верстка и т.д. Обесценивается даже одна из основ Веба — CSS, ведь оформление сайта можно задавать при помощи ASP.NET тем (themes), идеология которых сильно отличается от каскадной модели CSS.

Для того, чтобы разработчики забыли и про JavaScript, Микрософт собирается выпустить Script# — компилятор, позволяющий писать клиентские скрипты на C#, а затем компилировать их в JavaScript.

Многие разработчики не любят ASP.NET ^[3]. Он заточен под быстрое и удобное решения типовых задач. Но сделать что-то нетривиальное гораздо красивее на чистом HTML, CSS и JavaScript.

Однако нетривиальные задачи встречаются, может быть только в 1% случаев, а оставшиеся 99% типовых задач быстрее решить на ASP.NET. Быть может, это не так красиво, но бизнес требует скорости разработки…

Другим web-технологиям уже сложно конкурировать с ASP.NET. Недавно появился продукт Delphi for PHP, с помощью которого PHP разработчики начинают думать в рамках Windows парадигмы Delphi ^[4].

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

Гибель физическая,

или HTML — новый Turbo Pascal

Вы наверно помните среду разработки Turbo Pascal. Это была консольная программа с текстовым псевдографическим интерфейсом. Все, что было у разработчиков оболочки Turbo Pascal — это матрица из 80 * 25 символов ASCII, их цвет и фон. Все!

И из этих текстовых символов они сделали невозможное: реализовали многооконный интерфейс, с главным и контекстным меню, псевдо-трехмерными нажимающимися кнопками, технологией перетаскивания окон… В общем, почти все, что сейчас есть в современной графической Windows'овской программе.

Однако, перепрыгнуть ограничения таблицы из 80*24 символов было невозможно. Как ни старайся, нельзя нарисовать объект тоньше одного символа или провести диагональную, а тем более изогнутую линию. Интерфейсы наподобие Turbo Pascal ушли в историю, уступив место графическим интерфейсам Windows…

 

И опять, история может повториться. Призрак Turbo Pascal'я витает над xHTML…

Основа Веба — язык HTML не предназначался даже для создания сайтов (в современном их понимании), а тем более web-приложений. Тим Бернерс-Ли создал его для простой разметки научных документов, наподобие Word.

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

Однако у web-технололгий есть ограничения, которые, как ни старайся, перепрыгнуть не удастся. Средствами чистого xHTML/CSS/JS нельзя создать 3D графику, векторную анимацию, управлять звуком, хранить большие объемы данных на стороне клиента…

Смена не заставит себя долго ждать. В качестве основы «богатых интернет приложений» компания Macromedia (сейчас Adobe) уже много лет продвигает Flash/Flex. Микрософт относительно недавно, но с удвоенным рвением продвигает WPF/Silverlight ^[5].

И если xHTML не изменится, он может повторить судьбу псевдографического интерфейса Turbo Pascal, навсегда исчезнув из IT-индустрии.
 

Все ли так серьезно?

Итак, клиентские web-технологии могут ждать две трагические судьбы:

• Ментальная гибель: останутся физически, но исчезнут из сознания разработчиков, накрывшись высокоуровневыми абстракциями, вроде ASP.NET, став низкоуровневыми языками — новым ассемблером;
• Физическая гибель: исчезнут полностью, уступив место Silverlight или Flex.

Ментальной гибели не будет,

если web-технологии будут правильно поняты

В отличие от ассемблера, который объективно был низкоуровневым языком, xHTML/CSS/JS лишь воспринимаются как низкоуровневые из-за неправильного их понимания разработчиками. Попробую показать, почему.

Еще раз повторю:

Причина, по которой столь популярны серверные ASP.NET контролы (вкладки, деревья, меню, календари и т.д.), состоит в том, что в самом xHTML нет тегов для этих высокоуровневых интерфейсных элементов.

И поэтому, разработчикам приходится вручную описывать эти вкладки, меню и деревья с помощью мешанины низкоуровневых xHTML тегов: таблиц со сложными объединенными ячейками, внутри которых вложенные таблицы с большим количеством тегов <font> и декоративных картинок для обрисовки веток. Примерно также, как много лет тому назад ассемблерные программисты описывали операцию деления с помощью мешанины низкоуровневых команд сложения и сдвига регистра.

Все «прелести» низкоуровневого xHTML программирования налицо. Поэтому, гораздо проще выбросить из головы низкоуровневый xHTML код и работать с высокоуровневым ASP.NET контролом, который затем автоматически «скомпилируется» в xHTML, также как программа на C++ скомпилируется в ассемблер. Пусть получившийся xHTML негибок и уродлив ^[6], пусть нетривиальные вещи на ASP.NET сделать невозможно, но зато в оставшиеся 99% тривиальных задач решаются быстро и привычно.

Так вот:

Такой подход возникает, если относиться к xHTML как к языку визуальной разметки. Секрет же в том, что xHTML является языком не визуальной, а логической разметки, т.е. описывает не то, как должен выглядеть документ, а то, какие данные он содержит. И поэтому, он и не должен содержать теги, описывающие конкретные визуальные интерфейсные элементы. Вместо внешнего вида, xHTML описывает данные, которые содержит тот или иной интерфейсный элемент. А уже с помощью CSS соответствующий элемент «разукрашивается», так, чтобы выглядел как меню, вкладка или дерево; а JS придает ему требуемую функциональность.

Пример 1:

При высокоуровневом подходе:

Дерево — это не мешанина таблиц, вложенных таблиц, тегов <font> и картинок.

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

А уже с помощью CSS список «разукрашивается», так, чтобы он выглядел как дерево: с веточками, иконками открытых и закрытых папочек и т.д.;

JavaScript придает списку функциональность дерева — открытие/закрытие узлов, выделение, перетаскивание и т.д.

Пример 2:

Меню, также, также как и дерево — это иерархическая структура. И оно, также, создается с помощью многоуровневого списка.

Просто потом, к этому списку применяется уже другой CSS и JS, придающий списку внешний вид и функциональность именно меню.

Пример 3:

Вкладки, по сути своей — это несколько разделов документа со своим заголовком. Поэтому, в xHTML, вкладки прекрасно описываются как несколько блоков <div>, каждый со своим заголовком <h2>.

А уже потом, JavaScript придает этим блокам функциональность вкладок, скрывая или показывая блоки в зависимости от действий пользователя.

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

При таком высокоуровневом подходе можно прекрасно обойтись без разных псевдо‑высокоуровневых надстроек, вроде серверных контролов ASP.NET.

Более того, xHTML является даже более гибким и высокоуровневым языком построения интерфейса, чем многие другие. Ведь именно потому, что xHTML хранит лишь данные, а не внешний вид и функциональность интерфейсного элемента, делает интерфейсы гораздо более универсальным. Т.е., в одной ситуации, один и тот же элемент ведет себя как дерево, в другой — как меню, в третьей — как обычный список. При этом, xHTML код интерфейса остается неизменным. Мы даже можем превратить дерево в контекстное меню, а контекстное меню в список прямо на лету, без перезагрузки страницы! В каком еще языке разметки интерфейса так можно?!

Но такой «высокоуровневый» подход сильно отличается от традиционного оконного Windows-подхода, и поэтому, непривычен и непонятен многим разработчикам. ASP.NET не является в полной мере более высокоуровневой, чем xHTML. Она скорее, больше пытается применить к Веб Windows-парадигму, чем перейти на более высокий уровень абстракции. А web-парадигма не всегда хорошо соотносится с парадигмой Windows, например, модель тем (themes) оформления в ASP.NET плохо соотносится с каскадной моделью CSS.

 

Еще одна непривычная и малопонятная для многих разработчиков web-технология — это JavaScript (который даже прозвали СНЯП — Самый Недооцененный Язык Программирования в мире).

JavaScript — удивительно мощный, гибкий и красивый язык, превосходящий в ряде случаев по гибкости и функциональным возможностям таких монстров, как Java или C#.

Однако, многие особенности JavaScript, придающие ему такую мощь и гибкость: ООП на основе прототипов, объекты-как-хеши, функциональное программирование, замыкания и т.д. оказались недопоняты разработчиками, привыкшими к классическим языкам, вроде C++, Java, Delphi или VB. Из-за этого, JavaScript стал восприниматься как детский, «игрушечный» недоязык для скрипткидди.

Не язык это, а скрипт. Даже классов нормальных в нем нету…

— не помню, откуда

Хуже всего, часть разработчиков даже не желают понять JavaScript, а пользуются уродскими библиотеками, вроде Prototype.js, или недавно вышедшей Microsoft Ajax Library (бывшая Atlas), в которых эмулируется классическое классовое ООП, что является страшным надругательством над JavaScript, лишающим его такой красоты и гибкости.

Prototype.js был написан теми, кто не знает JavaScript, для тех, кто не знает JavaScript

— Richard Cornford

 

Итак, первая причина потенциальной «гибели» xHTML/CSS/JS — превращения их в новый ассемблер, состоит в недопонятости этих технологий. Но, я надеюсь, в скором времени, большинство разработчиков лучше поймут философию web-технологий и научатся обходиться без псевдо-высокоуровневых костылей.
 

Физической гибели не будет,

если web-технологии будут развиваться

С «физической гибелью» все серьезнее.

В web-технологиях сейчас действительно отсутствует ряд возможностей, необходимых для создания полноценных web-приложений: работа с 2D и 3D графикой, векторной анимацией, управление звуком, хранение большие объемы данных на стороне клиента…

И поэтому, угроза со стороны Flash/Silverlight сильна как никогда.

Для того, чтобы не исчезнуть из IT-индустрии и не повторить судьбу Turbo Pascal, эти технологии должны развиваться и преодолевать собственные ограничения.

Надо заметить, что xHTML, CSS и JavaScript никогда не переставали развиваться.

Однако, под руководством W3C, они развивались как средства представления информации, а не как технологии создания web-приложений.

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

Была проделана огромная работа по созданию технологий Semantic Web: RDF, OWL и SPARQL. Semantic Web позволит сделать информацию в Вебе понятной не только человеку, но и компьютеру. Это, например, даст возможность строить SPARQL-запросы «ко всему интернету», вроде такого: «Сколько щенков у собаки 2-го президента России?»

Но, скажем, web-формы так и остались на уровне 1995 года ^[7].

И, похоже, на W3C надежды было мало.

К счастью, нашлись те, кто осознал проблему. Ими стали фирмы-разработчики трех основных «нормальных» браузеров: Mozilla Foundation, Opera Software и Apple, которые организовали рабочую группу WHATWG, предназначенную для развития web-технологий, как технологий создания web-приложений.

И вот, 7 марта произошло, историческое событие: WHATWG официально вошла в состав W3C. В настоящий момент ведется работа над спецификацией HTML5 (или Web Applications 1.0) ^[8], которая:

• во-первых, является развитием HTML4/xHTML1.1 и включает многие теги, столь необходимые для web-приложений: <canvas> — тег для рисования графики, <video> — для видеоконтента, высокоуровневые элементы формы и т.д.
• во-вторых, является развитием DOM и включает API для: хранения данных на стороне клиента и работы offline, управления кнопками вперед/назад, управления Drag&Drop и многое-многое другое!

Так что HTML5 — это не еще одна ненужная версия HTML, а жизненно необходимое направление развития web-технологий.
 

Заключение

Таким образом, xHTML/CSS/JS выживут, если:

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

Примечания

1. ↑  Обычно программы компилируются не в ассемблерный код, а сразу в машинный. Но, для удобства, в пределах этой статьи будем считать, что это одно и то же.
2. ↑  В системном программировании ассемблер, разумеется, используется. Однако, оно не является определяющим в IT-индустрии.
3. ↑  Конечно, ASP.NET не ограничивается одними серверными контролами. ASP.NET — очень могучая, производительная, надежная технология, использующая всю мощь .NET Framework. Однако, многие разработчики используют ASP.NET именно из-за серверных контролов.
4. ↑  Насчет «Delphi for PHP», я, похоже, ошибся. Прошел уже почти год, а о «Delphi for PHP» мало что слышно.
5. ↑  А вот насчет Silverlight, я оказался прав. Он получает все большее и большее распространение.
6. ↑  Надо признать, Микрософт очень старается. От версии к версии, генерируемый ASP.NET'ом xHTML код становится все менее уродливым, более валидным и семантичным.
7. ↑  Предложенная W3C технология xForms не обладает обратной совместимостью и практически не поддерживается браузерами. Даже Mozilla Firefox, в котором реализованы почти все современные стандарты, поддерживает xForms только с помощью специального плагина.
8. ↑  Помимо технологии создания web-приложений, стандарт (x)HTML5 призван:
   • обеспечить обратную совместимость с HTML4/xHTML1;
   • определить единый для всех браузеров механизм обработки ошибок;
   • и не забыть о первоначальном предназначении языка HTML — средства представления информации. В HTML5 вводятся новые элементы для более семантической разметки документа: <section>, <article>, <header>, <footer> и др.

При подготовке статьи были использованы изображения с сайта www.wikimedia.org, а также: www.codegear.com, www.microsoft.com, www.w3c.org, www.json.org, www.whatwg.org, www.gmail.com, www.dotnetheaven.com, idesisnery.blogspot.com