| « Поставить закладку » « Сделать стартовой » | |||
|
|||
| Статьи:: Интернет технологии :: Вебмастеру :: Будущее веб-стандартов
Будущее веб-стандартовПримечание: ниже находится перевод статьи The future of web standards, в которой автор рассматривает текущее состояние организаций, связанных с разработкой веб-стандартов, и возможное будущее как организаций, так и самих веб-стандартов вообще. Мои комментарии далее даны курсивом. Индустрию веб-дизайна и веб-разработок, основанных на применении стандартов, в последнее время достаточно сильно будоражит. Статья Andy Clarke "CSS Unworking Group", по видимому, открыла дорогу обсуждению текущего неудовлетворительного состояния подхода (или отсутствия оного) по стандартизации новых возможностей для веб-разработчиков и дизайнеров. Статья Alex'а Russell "The W3C Cannot Save Us" и моего друга и бывшего коллеги Jeff'a Croft "Do we need a return to the browser wars?" продолжила эту дискуссию, как и Stuart Langridge c "Reigniting the browser wars", которая появилась уже после того, как я закончил первый черновой вариант этой своей заметки. В конечном счете, я думаю, все поднятые вопросы можно отнести к одной из двух больших проблем: Первая, не слишком лицеприятная, заключается в том, что текущий прогресс разработки новых стандартов, в лучшем случае, заморожен. HTML был создан из первоначальной задумки до версии 4.01 менее чем за десятилетие. Но текущая версия 4.01 не изменялась еще с конца прошлого тысячелетия (XHTML не сильно лучше: версия 1.0 была, практически, идентична HTML 4.01, за исключением XML-синтаксиса, а XHTML 1.1 не сильно изменил ситуацию, так как все новшества фокусировались на реорганизации и разделении стандартов на модули). Совершенно аналогично, CSS застыл на спецификации версии 2 с 1998, а CSS 2.1 по-прежнему всего лишь "Candidate Recommendation". Второй проблемой является то, что все основные нововведения в интернете
появляются из проприетарных технологий: Flash выскакивает везде, где только
можно, Microsoft и Adobe раздельно работают над следующим поколением RIA (rich
internet application), а наиболее модное слово — "AJAX" — изначально
произошло из исключительно Microsoft'овской технологии ( Если взглянуть на обе эти проблемы повнимательнее, то возникает закономерный вопрос: что же произойдет с веб-стандартами, если интернет как среда для обмена информацией в один прекрасный момент исчезнет? Что произойдет, если все тексты и приложения более не будут общедоступными и окажутся разделенными стеной ограничений на частную собственность, а все новые возможности будут предоставляться исключительно в частном порядке? Рассмотренные вопросы — медленная скорость стандартизации и инновации, узаконивающие пока-еще-нестандартные вещи, — очевидно, сильно связаны. Естественный вопрос: как же решить их в совокупности, как обеспечить такой процесс стандартизации, который смог бы быстро реагировать на новые идеи и поощрить внедрение уже имеющихся стандартов? Хотя я и не могу предложить никакого выхода из сложившейся ситуации, но у меня есть пара мыслей по поводу возможного пути ее решения, и ниже я хотел бы обсудить, где можно найти успешную модель поведения для такой ситуации. Ложная дилемма моделей стандартизацииОдним из наиболее существенных моментов при решении этих проблем является то, что бОльшая часть дискуссии проходит при изначальном предположении ложной дилеммы (false dilemma), которая подразумевает, что существуют только два пути для осуществления процесса стандартизации:
Естественно, существует не только две такие возможности, но лишь немногие (например, Daniel Glazman), по видимому, отдают себе отчет, что это действительно так. Поэтому, во-первых, нам нужно отказаться от этой дилеммы вообще и понять, что на самом деле существует бесконечное множество возможных организаций сообщества, которые лежат между этими двумя полюсами. Другими словами, мы должны найти баланс между вкладом людей, которые используют и разрабатывают интернет-приложения, и теми, которые разрабатывают сами браузеры и сопутствующие технологии. В поисках балансаЭто приводит нас к следующему вопросу: как нам добиться согласия между конкурирующими интересами веб-производителей и веб-пользователей/разработчиков? Лично мне кажется, что за ответом стоит обратиться к нашей истории: в мире веб-стандартов не нужно искать новых путей для обретения такого согласия, уже известно достаточно успешных примеров такого развития, и те, кто захотят реформировать саму организацию процессов веб-стандартизации, должны будут на них опереться. В первую очередь, я думаю в сторону разработок программного обеспечения с открытым кодом (open-source), которые сталкивались с похожими проблемами уже много раз: существует огромное количество абсолютно разного программного обеспечения с открытым кодом, которое используется как «среднестатистическим американцем», так и международными корпорациями, и только немногие из таких проектов успешно развиваются. Одним из таких примеров успеха может послужить ядро Linux; сообщество, участвующее в его разработке, не является ни закрытым, ни полностью открытым, но чем-то между этими двумя крайностями. Разработка Linux не является ни диктаторским режимом, ни демократией: Linus Torvalds и его доверенные «лейтенанты» полностью удерживают контроль над всем проектом, но при этом любой вклад от активного сообщества принимается к рассмотрению. И хотя не все мнения признаются одинаковыми, процесс принятия решения, каким мыслям придать больше веса, а каким — меньше, по-видимому, является весьма практичным и справедливым. В результате, участие больших корпораций не превращает Linux в закрытое сообщество разработчиков, и более мелких участники могут свободно обсуждать и развивать проект без превращения оного в «кричащую толпу» (howling mob). Это, определенно, успех, и такую модель поведения ни в коем случае не стоит упускать из рассмотрения при реформировании процесса веб-стандартизации. Естественно, существует еще множество замечательных примеров успешных сообществ: Perl, Python и Ruby, например, все разрабатываются с открытым исходным кодом, но полностью контролируются единственным "BDFL" (бессрочным великодушным диктатором, Benevolent Dictator For Life) и(ли) его несколькими «лейтенантами». Успех такой организации во множестве различных отраслей показывает, что процесс в целом протекает исключительно благоприятно: общий шаблон поведения, при котором все вносимые изменения обсуждаются в присутствии нескольких высокопрофессиональным специалистов, обладающих большим кредитом доверия. Они и правят балом, и обладают достаточным весом для принятия финальных решений: какие изменения должны быть внесены, а какие стоит отклонить или подвергнуть дальнейшему обсуждению. Эти же специалисты должны предотвращать все возможные минусы от применения любой из двух полярных моделей, описанных выше. Сперва W3C, затем WHATВозникает естественный вопрос, может ли WHATWG, которая в течение нескольких лет работает над оптимизацией, улучшением и расширением многочисленных стандартов, взять на себя труд довести до ума процесс веб-стандартизации, чтобы он осуществлялся таким же образом, как сейчас живет проект по разработке Linux и многие другие успешные проекты с открытым кодом. В данном случае я, честно, не представляю, каким образом это может быть осуществлено, и не знаю никого, кто бы представлял, хотя недостатка во мнениях как за, так и против не ощущается. Гораздо более компетентные и грамотные специалисты, чем я, высказываются совершенно по-разному, одни говорят, что WHATWG находится на верном пути развития, другие утверждают, что это дурацкая затея. Однако, есть пара обнадеживающих вещей:
Скорее всего, кто-то обязательно вспомнит недавнее волнение по поводу медиа-кодеков в качестве примера, когда WHATWG слишком сильно защищала корпоративные интересы, но я не разделяю эту точку зрения (хотя, если быть честным, я также не уверен, что задача HTML-спецификация состоит в том, чтобы указывать, какими медиа-форматами стоит пользоваться, а какими — нет). В отличие от многих людей, которые с пеной у рта начинают доказывать свою позицию по этому поводу, я просто слежу за дискуссией, и пока ничего в ней не вызвало во мне противоречий. Спецификация больше не так настоятельно рекомендует Ogg Theora, но по-прежнему оставляет возможность для реализации поддержки открытых и свободно распространяемых медиа-форматов. В конечном счете может оказаться, что «неизвестное неизвестного» (unknown unknown) (воспользуюсь цитатой из Tao от Donald Rumsfeld) будет хуже для больших компаний, чем известное неизвестного в реализации Theora. И текущий язык черновой рекомендации более похож на голос дантиста, который утверждает, что больной зуб когда-нибудь да выпадет. В любом случае, сейчас слишком рано говорить о какой бы то ни было определенности. И неизвестно, сможет ли WHATWG взять в свои руки работу над веб-спецификациями, в особенности, над CSS. В основном, сейчас работа WHATWG сфокусирована на HTML и DOM, как указано в текущей черновой спецификации WHATWG. Монстр Microsoft'аНаиболее существенным препятствием для любых реформ в области веб-стандартизации является присутствие Microsoft и все, с нею связанное. При том что Microsoft является действительным членом W3C и участником многочисленных рабочих групп, все реализации итоговых стандартов крайне незначительны, если не сказать, смешны. И это при всем при том, что Internet Explorer занимает доминирующее положение на рынке браузеров, что, естественно, ведет к тому, что все достижения в мире веб-стандартов будут обречены на провал, если не получат существенную поддержку со стороны Microsoft. Но с этой точки зрения, честно говоря, я не уверен, что позиция Microsoft может быть существенной. В конце концов, по-видимому, никто ее не рассматривает как существенную. Если вы еще не ознакомились со статьей Joel Spolsky "Fire and Motion", сделайте это сейчас, потому что все мои слова не будут столь информативными в противном случае. Давайте, прочитайте ее прямо сейчас (прим.: в статье автор забавно рассуждает о том, как Microsoft применяет принцип «Стреляй и Беги», "Fire and Motion", в действии), она очень интересная, но самое главное, что хотелось бы выделить на фоне остальных фактов, это доминирующее положение Microsoft ' а по причине, которую сам Joel очень красноречиво высказал при помощи сравнения ее с боевой тактикой пехоты:
Однако, давайте теперь остановимся и посмотрим на Internet Explorer 7 (о-да, я имею в виду "Windows Explorer 7"). IE7 является прекрасным примером того, как Microsoft, несмотря на всю мощь своей рекламной кампании, вынуждена уступить требованиям индустрии. Mozilla, Apple и Opera атакуют ее со всех сторон: табы в браузере, повышенная безопасность, и все те улучшения, без которых люди просто не могут жить — и Microsoft вынуждена изменить своей собственной стратегии. Как следствие, многие производители программного обеспечения, стараясь успеть за Microsoft, выпускают некачественные продукты, при этом Microsoft, как это ни странно, приходится идти на поводу у интернет-сообщества и выпускать некачественный браузер. То же самое сейчас происходит с Microsoft одновременно по нескольким направлениям:
Microsoft проигрывает; она безуспешно пытается следовать тому, что уже сделано, тогда как отрасль предлагает все новые возможности и технологические решения. Естественно, панихиду по Microsoft играть пока рано, совсем рано: IE по-прежнему является лидером среди браузеров, и Windows по-прежнему лидирует среди операционных систем. Но в индустрии уже заметны волны изменений: Microsoft, непробиваемый джаггернаут, все же несет потери, и ей приходится следовать всем нововведениям, чтобы не упустить доминирующего положения. В данном случае можно процитировать Lewis Carroll, что она бежит так быстро, насколько может, но все равно остается на месте. И, конечно же, Microsoft действительно не отвечает за фактическое будущее веб-стандартов. Любая разработка, которая возникнет в этой индустрии, будет только доливать масла в огонь, на котором жарится корпорация. У Microsoft просто не останется выбора, как продолжить свое «преследование», независимо от качества своего участия в общей процессе. Куда катится мир?Я действительно не знаю. Прямо сейчас я занимаюсь некоторыми наблюдениями в этой области и делаю небольшой анализ ситуации. Я всерьез полагаю, что затронутые аспекты окажут сильное влияние на любое принятое по данному вопросу решение:
Но и после всего сказанного, я не знаю правильного пути решения проблемы. В данный момент я пристально слежу за WHATWG (как и последние несколько лет, ибо это единственная организация, которая действительно что-то делает), но, может быть, будет иметь место и более благоприятный вариант. Я считаю, что наиболее важным шагом для всех, кто недоволен ситуацией со статусом кво, должно стать принятие решения о дальнейших действиях. Andy Clarke уже предложил пару идей, но при этом забавно высмеял мысль о принятии общего решения путем консенсуса, пока все предложения выдвигаются самим сообществом (и, по-видимому, сильно увлекся ложной дилеммой, описанной выше). Это все замечательно, особенно осознание того факта, что, возможно, присутствует другая возможность по развитию событий, но в каком именно направлении они будут развиваться, предсказать практически невозможно. Итак, я позволю себе закончить цитатой по этому поводу от одного из моих любимейших философов, G.K. Chesterton (из первой части его удивительной книги Еретики): Автор: http://sunnybear.habrahabr.ru/ Рубрика: Вебмастеру
О том как разработчики пьют кофе.
Сегодня ночью вернулся из Москвы, где я посетил сразу три конференции — SQA, PM Days и PHPconf. На конференции прозвучала масса интересных докладов, о которых наверняка еще не раз напишут, я же хочу поделиться некоторыми забавными наблюдениями. В перерывах между докладами все присутствующие могли выйти в холл, где их ожидали вкусные плюшки, молоко, чай и кофе. Для последнего на столах установили пять термосов. Разумеется для более чем двухсот участников конференции их было явно недостаточно и на каждой конференции эту проблему решали по своему, как умели.
Подробнее... |
Рубрика: Юмор
| Добавлено: 24.06.2008
Работаем с LINQ to XML.
Что же, попробуем раскрыть принципы работы этой новой технологии от Microsoft.
Подробнее... |
Рубрика: LINQ
| Добавлено: 24.06.2008
XmlSerializer - Assembly Leak без спроса.
В некоторых частях .NET Framework, таких как XmlSerializer, используется внутреннее динамическое создание кода.XmlSerializer создает временные файлы C#, компилирует результирующие файлы во временную сборку и затем загружает эту сборку в процесс. Такое создание кода тоже стоит сравнительно дорого, поэтому XmlSerializer размещает временные сборки в кэш, по одной на каждый тип. Это значит, что в следующий раз при создании кода XmlSerializer для класса Х не будет создаваться новая сборка, а будет использована сборка из кэша. Однако, не все так просто.
Подробнее... |
Рубрика: Сборки и развертывание
| Добавлено: 24.06.2008
Остальные статьи:
Реализация MVC в WPF. Александр Шер
ADO.NET Sync Services. Марат Бакиров
Рефакторинг JavaScript с применением Microsoft ASP.NET AJAX. Александр Шер
Архитектура приложений: интерфейс пользователя. Дмитрий Мартынов
Введение в Windows Workflow Foundation. Марат Бакиров
Создание расширяемых и удобных библиотек на платформе .NET. Особенности реализац...
Почему Ruby и Python не могут занять место стареющей Java
Использование пространств имен для организации JavaScript-кода
Создание сложных приложений в ExtJS
Google добавил интерфейс для AJAX-библиотек
Стивен Синофски о Windows 7
Несколько вещей об Ajax, которые должен знать веб-мастер
Model-View-Controller для JavaScript
Remix 2008: интернет меняет Microsoft
Планировщик задач на JavaScript
Построение систем автоматического протоколирования Си/Си++ кода |
Цитата дня (все,добавить): |
Realcoding.NET
© 2003-2008 |
Контакты |
Реклама на сайте
|