Алик Кириллович

Закат Веба?

07 июля 2008 г.

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

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

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

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

 

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

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

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

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

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

Гибель ментальная, или HTML — новый ассемблер

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

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

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

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

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

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

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

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

 

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

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

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

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

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

ASP.net Так появилась клиентская концепция ASP.NET [3]. В ASP.NET работа идёт с высокоуровневым серверными контролами (меню, вкладками, деревьями), которые затем «компилируется» [4] в HTML, CSS и JavaScript, так же как программа на C++ компилируется в машинный код или ассемблер.

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

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

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

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

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

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

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

Гибель физическая, или HTML — новый Turbo Pascal

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

ASP.net контролы в Visual Studio Все «прелести» низкоуровневого xHTML программирования налицо. Поэтому, гораздо проще выбросить из головы низкоуровневый xHTML код и работать с высокоуровневым ASP.NET контролом, который затем автоматически «скомпилируется» в xHTML, также как программа на C++ скомпилируется в ассемблер. Пусть получившийся xHTML негибок и уродлив [8], пусть нетривиальные вещи на 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.

 

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

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

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

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

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

Prototype.js Хуже всего, часть разработчиков даже не желают понять 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 Однако, под руководством W3C, они развивались как средства представления информации, а не как технологии создания web-приложений.

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

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

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

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

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

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

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

Заключение

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

Примечания

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

  2. В системном программировании ассемблер, разумеется, используется. Однако, оно не является определяющим в IT-индустрии.

  3. Микрософт косвенно признала, что модель серверных контролов далека от совершенства и собирается выпустить ASP.NET MVC Framework.

    ASP.NET MVC — это огромный шаг вперёд: она даёт почти полный контроль над HTML и в ней нет этих ужасных серверных контролов, __VIEWSTATE и Page Livecicle.

    Но, знаете, я очень не уверен, что все ASP.NET разработчики перейдут на MVC. Ведь модель ASP.NET контролов является настолько родной, привычной и понятной для тех, кто привык к Visual Basic / Delphi парадигме: кинул контрол на форму → щёлкнул два раза мышкой → написал обработчик и все дела…

  4. Речь идёт не о компиляции в узком смысле (генерации машинного кода на основе исходника), а о «компиляции» в широком смысле (генерация низкоуровневого HTML-кода на основе высокоуровневого ASP.NET-контрола)

  5. Конечно, ASP.NET не ограничивается одними серверными контролами. ASP.NET — очень могучая, производительная, надёжная технология, использующая всю мощь .NET Framework. Однако, многие разработчики используют ASP.NET именно из-за серверных контролов.

  6. Насчёт «Delphi for PHP», я, похоже, ошибся. Прошёл уже почти год, а о «Delphi for PHP» мало что слышно.

  7. А вот насчёт Silverlight, я оказался прав. Он получает всё большее и большее распространение.

  8. Надо признать, Микрософт очень старается. От версии к версии, генерируемый ASP.NET’ом xHTML код становится всё менее уродливым, более валидным и семантичным.

  9. Предложенная W3C технология xForms не обладает обратной совместимостью и практически не поддерживается браузерами. Даже Mozilla Firefox, в котором реализованы почти все современные стандарты, поддерживает xForms только с помощью специального плагина.

  10. Помимо технологии создания 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

Статьи

About

Подписка

  • RSS
Valid XHTML 1.0 Strict © Алик Кириллович, 2008—2015