Почему .Net 3 не использует HTML или SVG  ( или о пользе разработки новых языков программирования).

С точки зрения UI, программирование HTML основано на том, что любая программа, кот. называет себя браузером, может показать пользователю определенный набор заранее известных тэгов (table, img etc.). Способ их показа широко обсуждается много лет и услилиями широкой общественности иногда становится если не стандартом, то рекомендацией.  Одновременно он может служить и предметом нападок, если один из браузеров этих стандартов не придерживается. Поддержка стандатов, наоборот, должна открыть перед разработчиками браузеров и их многочисленными (и особенно корпоративными) пользователями мир приложений, где роль дизайнера становится программированием, а фантазия ограничивается только диапозоном стандартизированных тэгов и их стилей.
 К этому надо добавить скрипты. Их роль в современном Web трудно переоценить : кто же склеит вместе эти тэги? Кто же добавит к ним эффекты? Кто, наконец, научит их обрабатывать ввод пользователя и даже передатвать его на заоблачный сервер (a-la Ajax)? Все это сделает скрипт, и соответствующий браузер будет обязан предоставить скрипту программную иерархию тэгов, начинающиюся с главного документа, Web-страницы. Общая модель, однако, скриптами не изменяется : браузер покажет и скрипту, и конечному пользователю только те тэги, которые он знает, даже если из них скриптом сконструированы значительно более замысловатые конструкции.
 В этой перспективе ничего не меняет и серверное программирование : ASP или JSP разделят страницу на UI и бизнес-логику, но прорисовка (rendering) останется за теми же HTML-тэгами, число которых не менялось десятилетиями. Что касается SVG, то этот нонсенс лишний раз показывает, что Web берут не числом, а умением.
 В эту картину не укладывается одно исключение : среди HTML-тэгов есть такой, который вполне стандартно разрешает всем участникам процесса отклониться от стандарта и таким образом взять на себя прорисовку собственного UI. Это <object> тэг. Зона прорисовки этого тэга целиком отдана браузером на откуп самого элемента. О том, насколько продуктивной оказывается такая уступка, говорит тот факт, что ни одна коммерческая страница не обходится без ActiveX или флэша. Все клипы, подавляющее большинство анимации, почти все текстовые редакторы и даже нек. полноценные приложения (Microsoft OWA, Mercury QC)  разрабатываются внутри этого тэга.
 Все это находится в полной противоположности модели, принятой для разработки не Web-приложений.  Для них не существует тэгов и браузеров, но никому не кажется странным, что сам UI-элемент  может успешно прорисовать себя в окне приложения, да и само окно тоже может полностью само выполнить свою прописовку. Конечно и здесь есть свои стандартные элементы, но они не имею ничего общего с HTML-тэгами, и хотя для прикладного программиста они служат иногда тоже только кубиками, из которых составляется внешний вид приложения, но никого не смутит и создание собственных UI-элементов. Причем последние 10 лет эти элементы совсем не обязательно должны оформляться только в виде ActiveX.
  Насколько мне известно, никому до .Net 3 (MyXaml работает с .Net 2, но создан позже)  не приходило в голову или не хватало смелости объединить обе модели программирования UI. Для этого нужно отказаться от браузера как универсального прорисовщика тэгов и, возможно, для этого нужно также забыть HTML и скриты. Согласимся, не всем по плечу такая рубаха.
 XAML успешно решает эту задачу. Помимо того, что сегодняшний XAML ориентирован (прежде всего, благодаря встроенному в VS 2005/2008 XAML-редактору*) на WPF, им можно (нужно!) пользоваться для манипуляций с любыми .NET объектами. Если искусство объектного программирования все-таки существует, то состоит оно, наверное, в умении построить модель, т.е. иерархию связей, моделируюшую предметную область. XAML даст возможность ею манипулировать. Web или не Web - детали.

* - по-моему, его раньше называли Cidor.