Браузерные войны – 2 или нас ждёт JSON-Hibernate?

Прошло примерно полтора года после (первой) публикации мной статьи «Браузерные войны» с анализом рынка развития приложений. Тогда я описал ситуацию такой, какой увидел её на момент начала 2010 года. Теперь, в середине 2011-го, она во многом качественно изменилась. Что же произошло?

Internet Explorer 9 и стандарты W3C

Явно не по доброй воле, хотя маркетологи компании в этом и не признаются, Microsoft всё-таки сделала шаг в сторону реализации стандартов от W3C и ECMA, приведя свой Internet Explorer (IE) в 9-й версии в некоторое соответствие со стандартами. Конечно, о полной победе говорить пока рано. Например, тест ACID3 IE9 проходит лишь на 95%, но, безусловно, это просто несравнимо с 20% от IE8. А учитывая, что даже Mozilla Firefox проходит его лишь на 97%, думаю, можно открывать шампанское!

Правда есть один неприятный момент - IE9 доступен только пользователям Windows Vista и Windows 7. А вот огромной армии пользователей Windows XP, не признающих альтернативных браузеров (а таких "консерваторов" немало), так и придётся сидеть в лучшем случае под IE8.

Просто монополия Microsoft`а имеет одну особенность - эта компания конкурирует сама с собой. Точнее, "Microsoft сегодняшняя" жестоко конкурирует с "Microsoft вчерашней", поскольку главный конкурент новой версии Windows - это старая версия Windows, которая уже куплена громадным количеством пользователей. При этом многие из них резонно сомневаются в том, нужно ли им платить за переход на новую, если их и так всё устраивает? И Windows XP оказался для них очень мощной преградой хотя бы потому, что обладает преимуществами в быстродействии. Это в свою очередь делает его более предпочтительным для многих пользователей с относительно-слабыми машинами. При этом все приложения на данной системе прекрасно выполняются. Никаких проблем нет, если не считать проблемой трудности Microsoft по продвижению Windows 7 на рынок. Microsoft до сих пор не может закрыть поддержку этой системы. А под давлением общественного мнения (думаю, что под ним понимаются не столько простые пользователи, сколько крупные частные корпорации, государственные компании и, главное, военные организации самих США) вынуждена была несколько раз несмотря на свои попытки остановить её, объявить о продлении поддержки (последний раз была обещана поддержка до 2014 года). До сих пор в магазинах компьютерной техники можно купить нетбуки с предустановленной Windows XP.

Так что выпуск IE9, который будет работать только под Vista и Windows 7 - это, по-видимому, шаг в направлении, призванном заставить пользователей перейти на одну из последних версий Windows, приплатив Microsoft`у ещё немного денег - другого объяснения я не вижу. Конечно, Microsoft в этом не признаётся, утверждая, что Windows XP морально устарел и не поддерживает тех высоких технологий, которые были использованы в супер-совершенном браузере IE9. Однако Google Chrome, Mozilla FireFox, Apple Safari и Opera прекрасно поддерживают стандарты W3C и ECMA, которые поддерживает IE9, при этом отлично работают под Windows XP...
Могу лишь предположить, что маркетологи Microsoft почему-то думают, что Web-разработчики на радостях от того, что Microsoft поддержала стандарты, сейчас навояют кучи сайтов под них (которые будут смотреться только в IE9). Потом же огромная масса пользователей, уныло наблюдая, как эти сайты у них глючат, от безысходности поковыляет в сторону магазинов покупать Windows 7, чтобы не потерять для себя "ускользающую красоту" интернета. На мой же взгляд, даже если это произойдёт, таким пользователям будет значительно проще и, главное, дешевле поставить себе какой-либо из бесплатных браузеров, поддерживающих стандарты (Chrome, FireFox, Opera или Safari), чем обновлять ОС.
Но этого, очевидно, не будет. Я уже писал и повторюсь снова: рынок разработки сайтов в высшей степени конкурентен, и заказчики тут определяют значительно больше, чем разработчики. А если коммерческий успех им всё-таки нужен, то при заказе сайтов у дизайн-студий или одиночек-freelancer`ов они будут ориентироваться на статистику использования браузеров пользователями и в соответствии с ней будут определять приоритеты.

Кстати, о статистике. Сбор адекватной статистики в последнее время становится всё более и более сложной задачей. Если раньше основной массой пользователей интернета были представители среднего класса, то сейчас в него активно вливаются и люди достаточно бедные. Интернет действительно постепенно расслаивается на сегменты, соответствующие различным слоям общества. Точнее, не интернет расслаивается, а разные слои общества проникают в интернет. Если даже 2-3 года назад приходилось слышать высказывания медийщиков (например, гл. редактор Russia.Ru), что Internet – это media для среднего класса, и тогда это походило на правду, то теперь мне всё ближе утверждение А.Лебедева о том, что социальные сети – это «Internet для бедных» (такое мнение было недавно высказано им в программе «Бизнес-секреты с Олегом Тиньковым» 21.02.2011).
По-этому если раньше можно было приблизительно ориентироваться на общую статистику использования браузеров в зоне runet`а, то сейчас всё чаще приходится слышать о том, что бы проводить исследования чуть ли не под каждый проект, что бы понять, какими браузерами в основном пользуется target group, на которую этот проект нацелен. И если в первом случае можно найти десяток сайтов, которые дадут более или менее реальную картину, то во втором – это платное исследование, которое часто получится не рентабельным. По хорошему, нужно было бы более или менее рассортировать интернет-пользователей на группы, примерно соответствующие уровню доходов, и определить, какие их доли используют какие браузеры. Тогда для каждой группы можно было бы описать статистику используемых ими браузеров, что бы каждый, кто делает сайт именно для этой группы, мог ориентироваться на неё. Но сайтов с такой стстистикой я, к сожалению, не знаю...

Кстати, несколько лет назад в нашей стране был осуществлён мощный проект - все почтовые отделения России были подключены к интернету. Это не только города, но и сёла и даже многие деревни. Компьютеры для этого использовались, понятно, слабенькие и оснащались IE6 - расходы и так, думаю, были фантастическими. Так что теперь на почте каждый житель России может получить доступ к Internet. Но это будет Internet через IE6, и обновлять они это всё, похоже, в ближайшее время не собираются...

В общем, радость, конечно, не полная, но это всё-таки радость. По большому счёту, поддержка стандартов будет, ибо рано или поздно, на IE9 перейдут все пользователи IE. А требование обратной совместимости не позволит Microsoft`у отказаться от поддержки стандартов на том уровне, на котором это реализовано в IE9. Это, кстати, и подтверждает IE10 Tech Preview (уровень поддержки стабилен - ACID3 проходится на 95%, хотя отдельные нововведения, в основном из категории HTML5, постепенно вводятся - их просто ещё не успели внести в тест ACID).

Так же среди изменений за эти полтора года следует отметить резкий рост популярности коммуникаторов и планшетных компьютеров, прежде всего, на базе IPhone OS и Google Android. Ваш покорный слуга уже использует вместо телефона Samsung Galaxy Tab и находит это весьма удобным. Эти устройства так же здорово влияют на рынок и, что весьма приятно, их браузеры изначально ориентированы на поддержку стандартов, т.е. проблем при совместимой разработке под них сайтов особых нет.

Перспективы

И вот, когда я в последнее время думаю о перспективах развития RIA (Rich Internet Applications), SaaS и Облаков, меня всё чаще посещает мысль о том, что в ближайшем будущем клиентская часть Web-приложения могла бы полностью взять на себя выполнение бизнес-логики.
Конечно, у такого перехода будет масса проблем, прежде всего - безопасность и производительность. Ведь у JavaScript даже в последней реализации ECMAScript v.5 существует масса проблем с этим, главным образом потому, что этот язык по-прежнему остаётся интерпретируемым, а значит его алгоритмы легко вскрыть и внедриться в их работу. Однако в последнее время наблюдается настойчивая попытка разработчиков разнообразного инструментария решить все эти проблемы и, надо думать, им это со временем как-нибудь удастся. Ведь за этим стоят не только open-source`ники, в отношении которых скепсис ещё был бы хоть как-то уместен (даже несмотря на вполне достойные продукты типа Lunux`а, PostgreSQL`я, Eclipse`а и JBoss`а), но и такие гиганты индустрии, как Google и Yahoo!.

Почему мне так кажется? Для такой ситуации я вижу несколько предпосылок:

1. С одной стороны, мы имеем устойчивую тенденцию перехода к модели сервисов, которая, напомню, состоит в том, что персональный компьютер представляет собой лишь терминал, связывающий пользователя с сервером, и все сервисы пользователь через него получает от сервера.
2. При этом мощности компьютеров падать явно не собираются. Даже специально разработанные для Google Chrome OS ноутбуки (chromebook`и) достаточно мощны (4ГБ ОЗУ, 1,5ГГц`овые AMD-процессоры), не говоря уже о других нетбуках и ноутбуках.

Думаю, последнее обстоятельство связано с тем, что ситуация на рынке производства компьютеров (во многом "благодаря" застою в области web, организованного Microsoft`ом в течение последних 10 лет), уже прошла ту самую "точку невозврата". То есть технологии переразвиты по сравнению с потребностями, а экономия на масштабе для производителя стала перевешивать даже отсутствие реального спроса на вычислительные мощности. Таким образом, мы имеем ситуацию, когда человеку нужен маломощненький компьютер, но он не может его найти на рынке, поскольку произвести такой оказывается чуть-ли не дороже, чем значительно более мощный, запущенный в массовое производство. Так что даже если мощный компьютер будет немного дороже, оказывается проще купить его, чем искать дешевле тот, который нужен, т.е. которого будет достаточно для задач пользователя. А пользователь просто купит, чтобы было "с запасом". Такие явления на рынке называют "экономикой изобилия", в которой спрос уже является не столько источником, сколько следствием предложения, являясь скорее предметом роскоши, нежели необходимости.

Хотя возможно, я ошибаюсь, отводя Microsoft главную роль в этом процессе. Ведь всем известно, что исторически гонка мощностей персоналок по крайней мере у домашних пользователей обеспечивалась, прежде всего, развитием компьютерных игр, всегда столь жадных до вычислительных ресурсов в погоне за реалистичностью, красотой и скоростью отображения виртуальной реальности. Возможно, главную роль в этом процессе сыграли именно они, а, может быть, и что-то третье - тут уже, что называется, можно спорить, но следствие налицо: какими бы ни были причины, мы видим, что не смотря на развитие SaaS и "Облаков", рынок производства более мощных персональных компьютеров набрал слишком большую инерцию, что бы останавливаться и поворачивать вспять. А корпорации-производители железа будут землю рыть, чтобы искать возможности продолжать развитие этого рынка и дальше, ведь ресурсов у них для этого много.

Не исключаю даже, что они давили на Google с его проектом Google Chrome OS, и эта корпорация была вынуждена идти на уступки, что фактически теперь ставит под вопрос судьбу проекта – по крайней мере, по первым отзывам пользователей можно судить, что энтузиазм у людей поугас. Дело-то нешуточное, миллиарды долларов на кону! Было бы наивным полагать, что такой проект, который фактически угрожает привести к значительному сокращению производства компьютеров, так просто дадут осуществить даже такой компании, как они...

И по развитию рынка мобильных телефонов, смартфонов и планшетников мы видим в целом отсутствие минималистических тенденций - те самые игрушки здесь тоже играют если не ведущую, то заметно-важную роль. Несмотря на то, что лидирующие платформы Android и IPhone OS резко теряют преимущества при отсутствии возможности постоянного доступа в Internet (т.е. по сути в них сделано всё, чтобы просто-таки маниакально зависеть от сервисов интернета), мы наблюдаем лишь рост, а отнюдь не падение мощностей всё новых и новых устройств, выбрасываемых на рынок и, главное, пользующихся спросом!

Т.е. идея того, что рынок аппаратных мощностей клиентов сожмётся, в то время как мощности перекочуют на рынок серверов посредством облаков и SaaS - на поверку оказывается не верна. Подъём идёт по обоим этим направлениям. Почему? Я вижу лишь одно объяснение - привычка пользователей работать с шикарными интерфейсами. Эта идея в архитектуре enterprise-систем известна, как подход REST. За неё-то, скорее всего, и постараются ухватиться производители железа!

Вот мне и кажется, что наиболее логичным выходом из ситуации будут являться максимизация подхода RIA, т.е. развитие всё более сложных Web-клиентских приложений, которые так же, как и игрушки, начнут съедать большие вычислительные мощности персональных компьютеров, вбирая в себя как можно больше бизнес-логики приложений. Это, может быть, и не будет особенно разумным выходом, но будет отвечать интересам мощных игроков IT-индустрии, у которых в руках сосредоточено достаточно ресурсов, чтобы эту тему продавливать.

В случае успеха мы с Вами будем наблюдать, как уровень логики на стороне сервера сожмётся до минимума, подвергнется стандартизации и зафиксируется в некоторой спецификации API тех сервисов, которые будет предоставлять для логики клиентской и речь пойдёт о переходе к новой двухзвенной архитектуре. Почему двухуровневой? smile;) Потому, что уровень данных, т.е. БД, никуда, конечно же, не денется. Т.е. у нас снова будет клиент, содержащий всю логику и сервер, содержащий данные.

Даже с учётом наличия в последних браузерах гораздо более мощных средств для хранения данных на стороне клиента - таких, как userData в IE и SharedObject подключаемого Flash-модуля (про несчастные cookies умолчу) - у нас всё равно остаётся вопрос обмена данными с сервером для синхронизации различных web-клиентов между собой. Ведь мы говорим о распределённых приложениях. Конечно, теоретически, механизм синхронизации данных различных web-клиентов может происходить практически без участия сервера, с использованием механизма пиринговых сетей, но разработка механизмов такой синхронизации представляется на сегодняшний день крайне фантастичной и серьёзно об этом говорить, конечно же, слишком рано в силу огромного количества проблем с ними. Думаю, это вопрос даже не ближайшего десятилетия, так что оставим его фантастам. :)

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

JavaScript-приложения сейчас получают данные в форматах JSON, JSONP и JSONPP, так что, надо думать, интерфейс такой БД должен будет предоставлять данные в одном из этих форматов, либо будет разработан другой, более удобный формат на их основе. Он будет отражать структуру данных, т.е. прототипную реализацию ООП, коя реализована в JavaScript. Т.е. по сути сервер для приложения должен быть ORM Tools`ой на манер Hibernate, только выдавать объекты должен в JSON-подобном формате.

Впрочем, это станет реальным, если победит подход HTML5/SVG/JavaScript, который пока доминирует для RIA. Пока ему не хватает только грамотной поддержки 3D - VRML бесславно сошёл с арены, теперь идёт борьба между X3D от ISO, O3D от Google`а и Universal 3D от ECMA при поддержке ряда корпораций, в числе которых Adobe и HP. Если же победят технологии плагинов типа Silverlite`а или Adobe Flash, то технологически картина будет несколько иной, хотя суть от этого, мне кажется, не сильно изменится - в любом случае производители железа будут гнать нас в русло RIA, иначе им самим несдобровать...

Браузерные войны

Примерно полтора года назад мной была написана статья, первоначально озаглавленная "Мечты web-разработчика" ( http://se-la-vy.livejournal.com/53173.html ). Немного позже я опубликовал её на сайте AV-School.ru - учебного проекта "Лаборатории Касперского", в которой тогда работал (там материал был скромно озаглавлен "Попытка анализа Браузерных войн" - http://av-school.ru/article/a-152.html ). В этой статье рассматривалась история "Браузерных Войн" и последовавших за ними событий с позиции разработки Web-клиентов (или Web-интерфейсов, что, на мой взгляд, является уже несколько устаревшим названием) в попытке объяснить логику происходивших процессов прежде всего влиянием в целях отстаивания своих интересов на рынке компании Microsoft.
Сейчас я наблюдаю, что ситуация на рынке (главным образом в связи с выходом IE9, а так же с взрывным ростом продаж планшетных компьютеров и коммуникаторов от Apple и на базе Android) частично переломилась и проблема, на которой я заострял внимание, во многом разрешена, хотя выход из этой ситуации создал принципиально-новую конфигурацию рынка c интересными тенденциями, которую я не мог до конца предвидеть полтора года назад.
В связи с этим настало время написать продолжение этой статьи, сделав в ней анализ того, что произошло за эти полтора года и представить картину такой, какой я вижу её в данный момент. Эта статья будет написана и опубликована в ближайшие дни и, учитывая мой переход на работу в Luxoft Training, я решил опубликовать её в этом блоге. Для тех же, кто не читал первой статьи и интересуется развитием рынка RIA (Rich Internet Applications), будет полезно для начала ознакомиться с первоначальной статьёй, каковую я и представляю на Ваш суд...

Существует 2 вида программистов:
те, которые ненавидят Windows и программируют под Unix,
и те, которые ненавидят Windows и программируют под Windows
В.Пелевин

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

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

Тенденции

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

Например, практически все приложения, входящие в пакет Microsoft Office, могли бы быть заменены сервисами Internet`а. И так со многим другим - более 70% программ, которыми активно пользуются люди локально, почти ничего не потеряют, за то немало приобретут, будучи перемещёнными в интернет и реализованными как интернет-сервисы.

А лет 10 назад это стало очевидно практически всем серьёзным участникам рынка.

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

Конечно, речь в обозримом будущем не идёт о переносе вообще всех программ в браузер. Например, практически невозможно представить реализацию графических пакетов (таких как Adobe Photoshop), программ работы с 3D-графикой (3D MAX, не говоря уже о Maya), Архитектурных (ArchiCAD) в Web`е. Да что там такие высоты! Есть даже большие сомнения в возможности эффективного переноса разработческого инструментария (Visual Studio, IntelliJ IDEA, Eclipse, Enterprise Architect) в Web.

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

Браузерные войны

Так бы ситуация и развивалась, постепенно эволюционно придя к этому, но почему-то Microsoft вдруг начала демонстрировать очень странное поведение, сильно повлиявшее на эту тенденцию.

Примерно в середине-конце 90-х она, обладая монополией на рынке операционных систем (ОС) под клиентские машины (в отличие от рынка ОС для серверов, где рынок ОС намного разнообразнее), вдруг начинает предпринимать действия, которые быстро получили в работах аналитиков рынка название "браузерной войны". Заключались они в том, что они внезапно включились в активную конкурентную борьбу с господствовавшим в середине 90-х интернет-браузером Netscape Navigator (NN). Свой Internet Explorer (IE) у них, конечно, уже был - 3 версия, но никто из участников рынка не рассматривал его всерьёз. Это была фактически маловажная заплатка - должны же они были в состав операционной системы включить хоть какой-никакой браузер! Не было смысла его делать хорошим - просто хоть что-то сделать, что бы как-то худо-бедно отображало текст - и довольно. По сравнению с Netscape Navigator на тот момент он был как Paintbrush по сравнению с Adobe Photoshop, как велосипед по сравнению с автомобилем. Не удивительно, что в то время практически все, кто активно пользовался интернетом, использовали именно NN - в то время это было общей нормой, фактически - стандартом де-факто.

Но уже в IE 4-й версии Microsoft реализовала массу нововведений, традиционно присутствовавших в NN, реализовала стандарты, использующиеся на тот момент в этой отрасли и в придачу к ним реализовала массу дополнительных возможностей, отсутствовавших в стандартах и спорящих с расширениями NN. IE из примитивной игрушки для любителей вдруг превратился в передовой браузер! Полноценный конкурент NN, он его, конечно, не превосходил, но и существенно ему не уступал. Практически все web-разработчики признают, что 4-й и 3-й IE - это просто небо и земля!

Дизайн-студии тут же разделились на два лагеря сторонников NN против сторонников IE и наполнили интернет сайтами, которые на первой странице писали, что "этот сайт рекомендуется просматривать в Netscape Navigator" или, наоборот - "Эта страница лучше смотрится в Internet Explorer" - и рядышком помещалась ссылочка для скачки и последующей бесплатной установки.

И всё бы было хорошо, если бы конкуренция между браузерами была честной и, соответственно, по законам рынка это приводило бы к ускорению развития этой отрасли, но Microsoft использовала в этой конкурентной борьбе один грязный приём, живо поставивший их конкурента на колени. Воспользовавшись своим господством на рынке операционных систем, она прибегла к тому, что в маркетинге называется "пакетной продажей". Она просто включала Internet Explorer в состав операционной системы при её выходе, сделав вид, что он бесплатен. Многие забывают, что бесплатен он только при покупке отнюдь не бесплатной лицензионной Windows, в цену которой на самом деле и входит реальная цена всех имеющихся в её составе программ и уж какая часть цены на Windows является ценой на Internet Explorer - можно только предполагать, однако это не имеет особого смысла, поскольку мы всё равно не можем купить Windows без Internet Explorer`а...

Никто не предлагает вам купить лицензионный Windows без IE и потом, при первой попытке выйти в интернет, скачать какой-нибудь браузер - NN, IE, Opera, Safari или какой-либо другой. Нет, наоборот, если пользователю кто-то со стороны специально не расскажет про то, что есть другие браузеры, он даже не будет знать, что есть что-то другое для хождения в интернете, кроме Internet Explorer`а. По-этому как только к этому прибавляется то качество, что этот самый IE не лучше, но и, в общем-то, не хуже других браузеров - выбор подавляющего большинства очевиден - зачем мне другой браузер, если этот у меня уже есть?

Netscape`у, конечно, ничего больше не оставалось, кроме как объявить в ответ на это свой браузер бесплатным и искать иные способы получения прибыли. Руководству Netscape быстро стало ясно, что при прочих равных Microsoft их вытеснит. Они признали, что это не честная борьба и противопоставить MS`у они могли только на порядок более высокое качество своего продукта.

Антимонопольный комитет

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

Да и что может на самом деле антимонопольный комитет, если даже правительства независимых стран ничего не могут сделать против MS? В качестве примера можно привести поведение MS на рынке ЕС. В начале 2000-х годов правительство ЕС озаботилось аналогичной пакетной продажей на своей территории - MS Windows продавался в комплекте с MediaPlayer`ом и тем самым выдавливал с рынка компании, разрабатывавшие свои проигрыватели музыки. Решением суда Microsoft обязали продавать версию Windows без MediaPlayer`а на территории стран ЕС.

И MS даже выполнила это решение. Она действительно стала продавать Microsoft Windows без Media Player`а на территории стран ЕС! Казалось бы, производители проигрывателей музыки должны были плясать от счастья, но они быстро окончательно разорились и плясать стало некому, кроме хитрой Microsoft, ведь на прилавках европейских магазинов с программным обеспечением рядом продавались две коробки. На одной было написано, что это - Windows без MediaPlayer`а, а на второй - что это Windows с Media Player`ом (ведь речь шла о предоставлении возможности покупателям не покупать MediaPlayer`а вместе с Windows!). И обе эти коробки продавались по одинаковой цене! :)

Вот сами представьте себя европейцем, которому нужна Windows - вы приходите в магазин ПО, и видите Windows с MediaPlayer`ом и без него по одинаковой цене - что вы купите? :)

Вопрос о том, почему антимонопольный комитет так неэффективно сработал в этом случае - вопрос на самом деле интересный. Лично мне сложно это объяснить, не прибегая к пресловутой "теории заговора". Единственное объяснение, которое приходит на ум - в работу антимонопольного комитета по этому делу вмешались люди из правительства США. Ведь Microsoft - одни из крупнейших налогоплательщиков и так как его бизнес носит во многом и международный характер, то и налоги эта компания платит из доходов, получаемых в том числе на рынках Европы, Азии и Южной Америки. Следовательно, монополия на этом рынке обеспечивает правительству весьма немалый доход в виде налогов. Стремление же создать справедливый и честный рынок браузеров запросто могло привести к потере этой монополии и появлению сильных игроков на рынке, например, Европы, с которых налоги будет получать уже Европейский Союз и они будут идти мимо кошелька США. А если они ещё и захватят рынок США, так и вообще - деньги США начнут утекать из этой страны и оседать в карманах европейских корпораций и правительств.

К тому же так удобно всегда иметь под рукой справедливый повод придраться к такой крупной корпорации, что бы время от времени заставлять её идти на некоторые уступки, если вдруг её действия не понравятся политикам из Вашингтона... :)

Окончание браузерных войн

Поняв всё это, руководство Netscape в целях резкого повышения качества своего браузера принимает решение, ставшее для них роковым - решение переписать свой браузер полностью, с нуля. Теперь во многих статьях и книгах по управлению IT проектами это решение приводится как иллюстрация того, как не надо делать - переписывание заняло 2 года, в течении которых был выпущен Internet Explorer 5 (и даже, если не изменяет память, 5.5), последняя же версия Netscape 4.01 в течении этого времени безнадёжно устарела, после чего все пользователи перешли на Internet Explorer, а за ними и разработчики (многие - нехотя) окончательно переориентировались на него.

Microsoft тогда даже учудила такой проект, как Internet Explorer для Macintosh`а, где традиционным браузером был Safari (более того - сама компания Apple в течении 5 лет ставила IE для Macintosh`а как браузер по умолчанию). Аргументация была примерно такая: раз многие дизайн-студии разрабатывают и тестируют свои сайты в IE, то, что бы не напрягать пользователей Apple Macintosh, им тоже нужно дать возможность смотреть сайты такими, какими они разрабатывались и тестировались (правда, и здесь не обошлось без "у-у-упс!" со стороны MS - далеко не все технологии, поддерживаемые в IE для Windows были реализованы в тех же версиях для Mac).

Выход Netscape Navigator`а 6-го состоялся (5-ю версию они пропустили), но фурора не вызвал - качественно он не превосходил Internet Explorer, да и его интерфейсных идей никто толком не понял. Для подавляющего большинства пользователей интернета этот выход прошёл незамеченным, даже бывшие пользователи NN уже окончательно забыли про этот браузер, не говоря уже о новых пользователях компьютеров и, всеми забытая и брошенная, компания была вынуждена бесславно уйти с рынка, передав все новёхонькие исходные коды своего некогда лидировавшего браузера разработчикам программ с открытым исходным кодом.

Эра Open Source

Разработчики программ с открытым исходным кодом обрадовались такому повороту дел и принялись дорабатывать и раскручивать этот браузер. Тогда проект получил название Mozilla и быстро стал стандартом де-факто среди пользорвателей Linux, но у него была версия и для Windows-платформы. Через некоторое время, отчасти из маркетинговых соображений, а отчасти и по технологическим причинам проект создания браузера был выделен из остальных появившихся приложений Mozilla (таких, как, например, почтовый клиент Thinderbird, система контроля версий BugFox и некоторых других) и получил название Mozilla FireFox (FF) и полностью сменил имидж - иконка динозавра была заменена на иконку лисы и т.д.

С точки зрения поддержки технологий создания страниц и сайтов, разработчики Open Source были в первую очередь ориентированы на стандарты. Происходило это по банальным причинам - у них был дефицит аналитиков. Ведь программный продукт - это не просто программа, он требует не только программистов, но и как минимум тестировщиков, аналитиков и менеджеров. И если более или менее сносное тестирование могут обеспечить сами разработчики-энтузиасты, то найти адекватное количество энтузиастов-аналитиков по ряду причин не получается. А кто же будет тогда писать Техническое Задание на разработку этим людям?

По-этому, как говорится, "не было бы счастья, да несчастье помогло" - по факту в качестве детальных инструкций на разработку в open source`ных проектах выступают спецификации стандартов, что очень удобно. :) Это коммерческие компании могут не сильно торопиться за стандартами - у них есть своё видение, свои маркетинговые и прочие соображения, которые могут накладывать отпечаток на скорость реализации того или иного стандарта. А у open source`а такого нет - но есть необходимость разработчикам-энтузиастам со всего мира иметь чёткие инструкции, понимание в деталях что и как нужно делать, что бы эффективно кооперироваться. Вот и получается, что FireFox быстро стал лидером в аспекте поддержки стандартов и заслужил по-этому безмерную любовь разработчиков сайтов и Front-end`ов (интерфейсов) корпоративных приложений, ведь в нём ничего правильно (т.е. в соответствии со стандартами) написанное, не глючило и исправно работало. :)

Последствия поражения

Но для массового Internet-пользователя ситуация уже была безнадёжно запущена. Напрасно разработчики FireFox с помпой праздновали переход через 10% барьер (т.е. момент времени, когда по оценкам ряда популярных интернет-порталов, следивших, за какими браузерами сидят их пользователи, пользователей FF стало более 10%), напрасно считали, сколько миллионов раз был скачен дистрибутив FF 3-ей версии за первый день с момента выпуска - всем реальным игрокам рынка разработки сайтов было и до сих пор остаётся очевидно, что максимум, чего теперь можно добиться - это процентов 15, не больше. 15%, на которых бизнес не сделаешь.

Пляска Microsoft на могиле Netscape

Впрочем, на рынке IT было много и оптимистов-идеалистов. Были люди, которые утверждали, что победа IE в "браузерной войне" рынку в целом - на руку, мол, кто сумеет сделать лучший браузер, чем имеющая для этого все условия Microsoft? У кого ещё достаточно ресурсов для того, что бы разрабатывать новые технологические новинки и подходы в области web?

Подзуживал их к этому и сам Билл Гейтс, ведь он был плодовит - книжечки писал, интервью многочисленные давал. И так любил порассуждать в них о светлом будущем интернета! (Прям так и вспоминаю Михаила Саакашвилли, который как раз накануне войны с Южной Осетией по государственному телеканалу рассказывал, как он уважает осетин, как любит их культуру... Простите.)

Вот только действия MS по факту говорили скорее об обратном. Развитие IE, шедшее до поры - до времени семимильными шагами, вдруг по непонятной причине забуксовало. Постепенно застопорилась поддержка новых выходящих стандартов. Перспективные технологии HTA и HTC и вовсе были кинуты на полпути, явно не доведены до логического конца. Фактически, с версии 5.5 не создано ничего нового.

Организация World Wide Web Consorcium (W3C) продолжала выпускать новые и новые стандарты - CSS 3 (в IE и то частично реализована версия 2), XHTML 2.0 (поддерживается, да и то с "косяками", XHTML 1.0), XSLT 2.0 (в IE реализована лишь поддержка 1.0), XPath 2.0 (для xml-документов реализована поддержка 1.0, для html - вообще не реализована), DOM Level 3 (В IE даже DOM Level 1 реализован не полностью, плюс реализованы отдельные, точечные технологии, аналоги которых присутствуют в DOM Level 2), на фоне этого ряд мелких несоответствий со стандартом ECMA Script (такие, как разрешение использования ряда зарезервированных слов в качестве идентифткаторов и утечки памяти при использовании замыканий в работе с DOM-объектами) является сугубой мелочью. Ну и я уж не говорю про поддержку стандарта E4X или тега Canvas, давно реализованных во всех маломальски-популярных браузерах, кроме IE.

Кроме того, у Internet Explorer`а не реализовано достаточно удобной и незаметной системы обновления версий, в связи с чем в куче государственных компаний, а так же интернет-кафе, в почтовых отделениях и т.д., а вместе с этим - и у многих неопытных домашних пользователей и даже в конторах с консервативными системными администраторами до сих пор стоят старые версии Internet Explorer, не давая разработчикам сайтов пользоваться даже теми технологиями, которые предоставляет последняя версия IE, потому что при этом они вынуждены всегда оглядываться на "отстающих" - пользователей IE 7 и 6 (слава богу, хоть 5.5 уже ушёл в лету).

Загадка

Почему так? Они ценой больших затрат "разбили в пух и прах проклятых конкурентов" и теперь... Практически ничего не делают!

Всё это сначала погрузило оптимистов в недоумение, кто-то из них пытался найти какие-то мутные оправдательные доводы - мол, это всё сложно (при том, что open source`ники без копейки денег прекрасно справляются!), что на Microsoft огромная ответственность (а open source`ники, под решениями которых работает весь Linux-мир, значит, безответственные?). В общем, наводят туману.

Скептики говорят о банальном рыночном законе спроса и предложения - мол, нет конкуренции - нет и развития. Но зачем же тогда вообще Microsoft`у было ввязываться в это противостояние с Netscape? Почему бы было не оставить этот рынок в покое, как они оставили, скажем, рынок интернет-общалок - ведь ICQ точно так же можно было выдворить с рынка общалок своим Messenger`ом, как Netscape - c рынка браузеров для интернета. Да и PaintBrush довести до профессионального уровня и потеснить Adobe Photoshop на рынке программ для обработки графики. Вообще, используя "пакетную продажу", можно выдавливать с рынка коробочных софтверных продуктов кого угодно.

Так почему - именно браузеры?
Ведь денег на браузерном рынке не так уж много - Netscape, скажем, была не очень-то богатой конторой, бравшей денег лишь с корпоративных клиентов-пользователей своего браузера. Да и было в общем-то очевидно, что подними они плату слишком высоко - компаниям проще было бы проплатить создание open-source`ного браузера и использовать его.

Та же Opera пыталась брать денег с пользователей, но в итоге пришла к бесплатной схеме (правда, только на компьютерах - Opera mobile до сих пор остаётся платной) и получает деньги за продажу по сути приватной информации о том, куда через него ходят пользователи с тем, что бы маркетологи Internet-пространства могли анализировать эту информацию и с опорой на неё выстраивать свою маркетинговую стратегию о продвижении того или иного интернет-сервиса.

Разгадка

Для того, что бы понять действия MS, давайте порассуждаем о её бизнесе и о его потенциальной судьбе. Дело в том, что большую часть доходов Microsoft получает с продажи лицензионных копий своей операционной системы Windows.

При разработке этой операционной системы главный ориентир был - простота интерфейса и обратная совместимость. Рынок операционных систем для персональных компьютеров был наиболее чувствителен именно к этому. Они писали эту систему для домохозяек и их главной целью было создание системы, для работы с которой было бы достаточно как можно меньшего уровня технической компетенции пользователя. И они добились этой цели - на наиболее распространённой в мире платформе процессоров Intel (и совместимых с ними) у них фактически нет конкурентов. Чего стоит хотя бы заявление из стана их формальных врагов - от одного из замов президента компании Red Hut (одной из лидирующих компаний, специализирующихся на выпуске коммерческих Linux-дистрибутивов) в начале 2000-х годов о том, что в качестве операционной системы для персональных компьютеров они рекомендуют ставить Windows (это, конечно, было до появления Ubuntu - версии Linux`а, ориентированного на персональные компьютеры).

Их монополия настолько безальтернативна, что я даже встречал версию, высказываемую отнюдь не последними людьми нашего IT-бизнеса о том, что они (Microsoft) не просто не опасаются, а даже тайно поддерживают такие проекты, как Ubuntu Linux, т.е. проекты, которые пытаются дать альтернативу персональным пользователям - лишь для того, что бы сделать вид перед антимонопольным комитетом и клиентами, что конкуренция на этом рынке - есть! :)

С другой стороны, с точки зрения критериев качества серверных операционных систем Windows, мягко говоря, не блещет. Дело в том, что системные администраторы и разработчики сайтов, а так же программисты распределённых интернет-приложений - это совсем не домохозяйки. Они имеют высокий уровень технической компетенции и далеко не так чувствительны к простоте интерфейса (когда он излишне упрощён - это их часто даже раздражает), за то имеют повышенные требования к надёжности, качеству внутреннего API и быстродействию, с которыми у Windows, стремившейся к простоте интерфейса в ущерб всему остальному, дела, соответственно, обстоят далеко не так хорошо, как у тех, кто изначально ориентировался на серверный рынок. И тут явное лидерство принадлежит системам на базе Unix и его многочисленных модификаций (бесплатный - Linux, а так же Sun Solaris и ряд других). На этом рынке, насколько я помню, пару лет назад, их доля Windows Server оценивалась довольно скромно - примерно в 20% рынка. Думаю, что с тех пор она подросла и сегодня может быть 30-35%, не больше.

Что, конечно, далеко от практически 100%`оного доминирования на персоналках. По-этому переезд сервисов на серверную платформу с персоналок и упрощение операционной системы до уровня браузера означает для Microsoft, что их 99% рынка размениваются на 30-35% рынка серверов, на которых впредь всё и будет развиваться в то время, как рынок персональных операционных систем сжимается раза как минимум в 3. В итоге MS становится весьма заурядной конторкой - конечно, первой величины, но уже не качественно превосходящей конкурентов. И стоит ли удивляться, что Microsoft не желает себе такого падения доходов?

Понимая неминуемость такого финала, признавая, что прогресс неумолим, Microsoft лезет из кожи вон, что бы не потерять контроля за подавляющим большинством пользователей. Они предпринимают колоссальные усилия, пытаясь влезть на рынок распределённых интернет-приложений и корпоративных информационных систем, выпустив инструментальную платформу ".NET" с явным желанием вытеснить с рынка господствовавшую на рынке сайтов технологию PHP и господствовавшую на рынке создания крупных распределённых корпоративных приложений платформу Java EE.

Но для того, что бы максимизировать свою долю на рынке корпоративных и интернет-серверов, кроме денег, нужно ещё и время, а его нет. По популярности у Java и .NET`а пока примерный паритет (последняя оценка, которую я слышал, 40% Java EE, 50% - .NET и 10% все остальные платформы, при чём следует особо учитывать, что крупный бизнес охотнее работает с Java EE - решениями и только средний предпочитает .NET), а о вытеснении технологией ASP.NET технологии PHP на рынке разработки сайтов вообще говорить рано, даже не все провайдеры в принципе предоставляют услугу ASP-хостинга, при том, что без хостинга PHP никто даже не рискует выйти на этот рынок.

При этом рынок уже явно перегрет, широкие массы уже готовы пересаживаться на интернет-сервисы, будь они качественными, а доля MS от этого рынка даже не достигла половины. Понятно, что с нынешними финансовыми ресурсами Microsoft для них эта задача в принципе выполнимая, но нужно время. Как его выиграть?

Вот где собака-то и зарыта! Вот для чего им и нужен был контроль за браузерами. Вот для чего они в своё время последовательно выдавили с рынка Netscape - теперь они получили возможность притормаживать развитие интернет-сервисов при помощи своей монополии на браузерном рынке, как бы между прочим ставя много мелких палок в колёса развитию Web.

Что имеем сейчас

Конечно, когда я говорю о том, что развитие IE полностью остановилось, я слегка преувеличиваю - кое-что они всё-таки меняют. Например, в IE 7 появились долгожданные закладки, которые давным-давно были у Opera и FireFox`а, худо-бедно исправляются старые ошибки, но это происходит исключительно медленно. Когда набирается критическая масса нововведений и та или иная фишка, описанная в стандарте или реализованная в одном из браузеров, начинает создавать отток большого количества пользователей, Microsoft "прозревает" и всё-таки реализует её в следующей версии своего браузера, при чём, как правило, максимально по-своему, что бы создать как можно больше неудобств разработчикам сайтов и web-интерфейсов корпоративных приложений, которые пытаются сделать свои продукты такими, что бы они хорошо смотрелись во всех браузерах.

Показателен пример с перспективными технологиями HTA и HTC, о которых я уже упоминал. Их разработку они, было, затеяли, но они быстро зафиксировались на достигнутом явно недостаточном для нормальной работы уровне (хорошо ещё, что они вообще их не выкинули - видимо, боялись потерять обратную совместимость решений, уже на них написанных) и дальнейшего их развития не происходит. В то время, как аналогичный по направленности XUL от разработчиков FireFox уже на порядки мощнее. Казалось бы - неужели Microsoft слабее, чем какие-то несчастные OpenSource`ники? У них меньше денег? Глупые программисты? Нет, им просто не нужна конкуренция на этом рынке, потому что им не нужно развитие этого рынка, этого направления.

В итоге создание развитых интернет-сервисов, требующих хитрых web-интерфейсов, весьма осложнено. Фактически, совместимой со всеми браузерами разработкой таких сложных браузерных приложений, как GMail, сервисы Google Docs, Google Map, могут заниматься только такие богатые конторы, как Google или как минимум Yandex. Не может и речи идти о том, что бы средний провейдер нанял команду из 5-7 грамотных разработчиков и реализовал у себя сервис с интерфейсом такого уровня сложности - тем не менее, я возьмусь утверждать, что это было бы возможно для браузеров, хорошо реализующих стандарты.

Просто пока их общая доля среди интернет-пользователей составляет не более 15%, ни один инвестор, хоть как-то думающий о возврате своих денег, не профинансирует такие проекты - нет, он будет настаивать на том, что бы какой бы хитрый интерфейс ни был у вашего приложения, он бы корректно работал в первую очередь как раз Internet Explorer`е.

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

В итоге издержки разработки именно под IE съедают очень существенные ресурсы. И небольшие дизайн-студии вынуждены карабкаться на этот рынок буквально "через терни к звёздам" - весьма колючие терни Internet Explorer`а. И естественно, они в большинстве случаев могут выходить лишь с предельно-простыми c точки зрения поведения web-интерфейсами. Они так и делают - в итоге сервисы интернета развиваются в основном благодаря программированию на стороне сервера. Дисгармония просто ужасает - на сервере часто выполняются даже такие простейшие операции, как сортировка таблиц на странице или добавление новых полей формы, когда в нормальном браузере это сделать - раз плюнуть, совершенно не трогая сервера. Но это - только в нормальном браузере, а с Internet Explorer`ом придётся пободаться. Сделать можно, но придётся делать через известно что...

Разработчики коллекционируют решения большинства проблем совместимости стандартных браузеров и IE, при написании библиотек для языка сценариев JavaScript, которых развелось огромное количество - JQuery, Prototype, MooTools, Ext и многие другие, но это не решение проблем - сами эти библиотеки становятся всё более и более тяжеловесными и всё чаще из-за этого подвергаются критике со стороны разработчиков, стремящихся оптимизировать страницы, делать их легковесными.

Больше всего жаль несчастных разработчиков Opera - они с самого начала приняли, казалось бы, выигрышную стратегию - в случае конфликтов реализации IE и спецификаций W3C, реализовывать всё так, как в IE, а не так, как в стандарте. Они, очевидно, решили, что Microsoft с W3C просто разошлись во мнениях о том, в какую сторону развивать web-интерфейсы. Вот только ребята не поняли, что Microsoft не потому всё это делает, что просто видит собственный путь развития Web-технологий, отличный от того, как это видит W3C, а потому, что пытается по мере сил просто затормозить это развитие - и всё. В итоге Oper`цы оказались между двух огней - для Microsoft они - конкуренты, а для приверженцев стандартов они - жалкие трусливые отступники, как шакал Табаки в "Маугли" примкнувшие к грозному Шерхану-Microsoft`у...

Намечающаяся тенденция

К счастью, Google, прочно взявший курс на перевод сервисов в Web, на глазах всё-таки пересиливает MS даже со всеми её возможностями торможения web-разработок.

У этой компании, в отличие от многочисленных небольших дизайн-студий, достаточно денег для того, что бы преодолевать все капканы, которые ставит разработчикам Web-интерфейсов Microsoft - руководство этой компании когда надо и денег заплатит, наняв нужное количество разработчиков, а когда надо - и не побрезгует использовать решения open source и даже поможет этим разработчикам инфраструктурой, создав удобную среду.

Да и правительство США здесь вряд ли вступится за Microsoft используя не рыночные механизмы регулирования, ведь Google - такой же налогоплательщик и точно так же зарабатывает деньги во всём мире, а налоги платит - практически исключительно в США. Но при этом Google развивает отрасль, а Microsoft - стопорит, портя имидж экономической политике правительства США - а тут подворачивается такой прекрасный шанс стать "белыми и пушистыми" в глазах представителей IT-рынка во всём мире! :) Так что для правительства США переход с отстаивания антирыночными методами интересов Microsoft на мировой арене на отстаивание интересов Google - идеальный расклад! :)

У них есть уже и браузер, страмительно набирающий пользователей, агрессивно продвигаемый на всех порталах, владельцем которых является Google (все уже заметили, например, на YouTUBE внизу ссылочку, рекомендующую поставить Chrome, поскольку в нём эта страница смотрится лучше? smile:) ) и содержащий прекрасную реализацию всех стандартов, имеющихся на сегодняшний день. Есть инструментарий Google Web Toolkit (GWT), пока достаточно тяжеловесный, но позволяющий надёжно использовать java-технологии для создания web-интерфейсов, который сам берёт на себя заботу о межбраузерной совместимости получающихся интернет-приложений.

Но это всё - полумеры. А вот настоящий финал, развязка этой борьбы уже на пороге - в середине 2010 года появятся в продаже netbook`и с операционной системой Google Chrome OS, которая реализует как раз ту идею, которая уже давно просится - операционная система, которая будет представлять собой практически голый браузер. Надеюсь, что это будет началом конца если не Microsoft вообще, то по крайней мере их политики по торможению развития web-интерфейсов! :)

Вот простой и понятный ролик о том, что такое Google Chrome OS:

Продолжение - "Браузерные войны – 2 или нас ждёт JSON-Hibernate?".

P.S. Есть ещё одна проблема со стандартизацией Web-интерфейсов, препятствующая их развитию, на которую в своё время указал Джоел Спольски - отсутствие эталонной реализации для стандартов визуального отображения документов. Дело в том, что документы W3C не достаточно хорошо описывают внешние эффекты поведения тех или иных элементов в браузере и часто разобраться, как в данном конкретном случае должен отображать документ браузер в соответствии со стандартом - весьма не простое дело. В силу чего необходима эталонная реализация браузера, про которую было бы чётко сказано стандартизирующей организацией, что все элементы этот браузер отображает правильно. Роль такой эталонной реализации выполняет, например, Tomcat для Java EE Web и Glassfish для Java EE EJB.

Боюсь загадывать, но лично мне кажется наиболее приемлемым решение признать эталонной реализацию браузера FireFox - тогда Google сможет дополнять свой браузер по мере своих возможностей, а пересмотревшая свою политику Microsoft будет пытаться догнать и перегнать его и в случае спорных моментов, протестировав свою страницу в FireFox`е, каждому разработчику станет ясно - чей это косяк. :)

P.P.S. Под конец можете послушать песенку разработчика о наболевшем:

ППКС! :)))

Уровни экспертизы

Когда-то давно услышал чьё-то мнение о том, что японцы - самая художественная нация. Возник законный вопрос - почему? Ведь на вскидку почти любой образованный гражданин России, США и Европы не сможет припомнить ни одного знаменитого японского художника, хотя легко назовёт несколько великих российских и европейских художников. Выяснил, что критерий тут другой - лингвистический. Дело в том, что в японском языке присутствует самое большое количество самостоятельных слов, выражающих различные оттенки цветов. Можно долго строить предположения, с чем это связано, но пока можно заключить лишь, что на каком-то этапе развития японской культуры для них было очень важно различать большое количество оттенков цветов и для их отражения в их языке появились эти слова.

Я - тренер, так что предмет моей работы - это знание. И я думаю, что уже назрела необходимость расщеплять это понятие и разобраться с тем, что мы называем "знаю", а что - нет. Т.е. разобраться с тем, что знание по сути собой представляет и каким оно в силу этого бывает, так как отсутствие возможности объясниться по существу не даёт развиваться, более глубоко разбираться в теме. Не могу сказать, что долго копался в работах по гносеологизму, которые должны были бы, видимо, в этом вопросе активно копаться, так что сильно рискую изобрести велосипед, но всё-таки напишу как я вижу вопрос, не претендуя на особую оригинальность. Надеюсь, это окажется полезным и кому-то другому.

Часто приходится слышать размышления о "практическом" и "теоретическом" характере того или иного знания. На мой взгляд, это разделение имеет более фундаментальный характер, чем то, о чём собираюсь написать я. Не следует забывать, что все программисты - это инженеры, а не учёные. Критерии знания учёных-теоретиков отличны от наших, поскольку от инженера, в конечном итоге, всегда требуется тот или иной результат его работы. Так что это разделение мне видится условным, поскольку теоретическое знание - это скорее прерогатива учёных. Конечно, теоретическое знание необходимо и инженеру, но чаще всего оказывается, что не во всей своей полноте, а в сильно-упрощённом и сокращённом виде - часто приходится слышать о том, что та или иная теория, выдвинутая учёными, нуждается в упрощении (обычно - по закону Парето, более известному, как "Принцип 20/80") для того, что бы превратиться в удобный для работы инструмент инженера.

Перво-наперво определим предмет обсуждения. Я бы хотел разобраться в том, что можно называть "глубиной знания" какой-то темы. Глубина бывает разной. Что бы мерить глубину, нужны какие-то объективные критерии в виде того, что позволяет знание той или иной глубины, имеющееся у человека в отношении какой-либо темы. Т.е. в качестве критериев удобнее всего взять возможности, которые открывает знание определённой глубины. Такие критерии и становятся уровнями, вносящими разметку в глубину знания.

Итак, что значит - знать какой либо инструмент? По своему опыту я склонен делить знание на 3 уровня:
1. Знакомство или игровое знание. Знание, полученное в ходе игры с технологией. Знания на этом уровне достаточно для того, что бы делать интересные и в общем-то, как правило, никому, кроме автора, ненужные штуки на ней. Программисты так обычно и говорят - "поиграться" с какой-то технологией (например - "Я поигрался со Spring`ом"). Это означает, что на ней просто сделано что-то, что в принципе получилось и даже работает, но ничего полезного никому не приносит - не для этого делалось, а просто так. Кстати, знание именно на этом уровне обычно формируется в результате прохождения того или иного тренинга. В программировании людей, до конца прошедших этот уровень, обычно называют Junior Developer`ами или просто Junior`ами.

2. Навык или рабочее знание. Знание, полученное в ходе активного применения технологии в работе над каким-либо боевым проектом. Знания на этом уровне достаточно уже для того, что бы не просто делать ЧТО-ТО с помощью этой технологии, но и для того, что бы выполнять РЕАЛЬНЫЕ ЗАДАЧИ БИЗНЕСА, более или менее укладываясь в заявленные сроки. Т.е. необходим опыт применения этой технологии, достаточный для оценки рисков по срокам работ при получении задачи работником от своего менеджера проекта. Если такого опыта нет - просто ставить задачу бесполезно - человек не может оценить всех рисков и его согласие - это лишь согласие заняться этой задачей, а не принятие на себя ответственности за её решение в заявленные сроки. По-этому обычная обязанность Team-Lead`а (руководителя группы разработчиков) - брать на себя управление рисками при постановке задач Junior`ам. Обычно разработчиков, имеющих знание на этом уровне, называют либо просто разработчиками, либо Старшими разработчиками (Developer или Senior Developer).

У меня ушло очень много времени для того, что бы понять, в чём конкретно заключается разница между Senior`ом и простым Developer`ом. По сути во многих IT-организациях эти различия очень условны и на практике обычно отражают простую "выслугу лет" - например, 5 лет работал Developer`ом - после этого тебя нарекают Senior Developer`ом. Это, конечно, плохая практика с точки зрения удовлетворения карьерных амбиций - когда молодой сотрудник стремится построить свою карьеру, все его усилия сосредотачиваются на эффективном, быстром достижении каких-то целей, но когда он понимает, что цель "стать Senior`ом", фактически, является пассивно-достижимой (сама придёт к нему через 5 лет, и никак этот процесс ускорить нельзя) - это способно погрузить его в уныние.

Иногда говорят, что старшие разработчики должны дополнительно тянуть лямку обучения младших, однако на практике это требует уже следующего уровня (об этом - чуть ниже) и по-этому по факту выражается в пассивном обучении: такой старший разработчик говорит младшему примерно следующее - "Смотри на меня и делай, как я!" - и пишет при нём код, слегка проясняя какие-то моменты. Наиболее чёткий критерий я услышал от одного из крупных менеджеров Ланит`а. Он выразил мысль, что Senior - это тот, кому можно поставить задачу и не контролировать её выполнение, будучи полностью уверенным, что он уложится в срок или сам вовремя подаст сигнал о том, что не успевает или у него возникли какие-то иные трудности. А простому Developer`у нужен некоторый контроль, хотя, конечно, и не такой сильный, как за Junior`ом.

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

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

Основное различие этого уровня знания от предыдущего - навыка - состоит в таком понимании темы, которое характеризуется его слабой связанностью с психологическими особенностями самого тренера, в то время, как навык - это знание, сильно связанное с особенностями их носителя. Спросить у человека, обладающего лишь навыком, "Как ты это делаешь?" - примерно то же самое, что спросить любого человека - "Как ты дышишь?". Он, чаще всего, не сможет сказать ничего вразумительного или в лучшем случае скажет что-то, что сможет понять лишь человек, который очень хорошо его знает или очень на него похож психологически и похожим с ним образом мыслит.

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

Действительно, многим из нас часто кажется, что если, как утверждают философы, "практика - критерий истины", то способность использовать знание - есть критерий его наличия. И, соответственно, если ты знаешь - то "чего такой жадный?", ведь, "От тебя не убудет?" - обучи другого, "Жалко, что ли?".

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

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

Действительно, проведите над собой эксперимент. Найдите сейчас в своём поле зрения, например, дерево и задайте себе вопрос - какое оно? Скажите, что первым придёт в голову. Потом ещё раз - какое оно кроме того, что Вы уже сказали? И так раз 5-7, запоминая порядок, в котором Вы назвали эти признаки. Что получилось? У меня вот - Круглое в обхвате, большое, высокое, раскидистое, старое, унылое, шершавое, коричневое, красивое. Каких из этих признаков вы не назвали и что назвали такого, чего нет у меня? Попытайтесь проанализировать тот порядок, в котором вы назвали эти признаки. Это - не случайная последовательность признаков - нет! Это - картина ваших приоритетов, т.е. тех качеств, которые Вы видите в деревьях в первую очередь, поскольку именно в такой последовательности они для Вас важны. То, что вы назвали в числе последних - для вас практически не важно, а вот то, что называли первым - бросилось в глаза, значит, действительно важно. Если вы через несколько дней будете вспоминать, какое это было дерево, то вспомните, вероятно, только те его качества, которые назвали первыми. Этот порядок - это и есть проявление Вашей особенности восприятия мира вокруг на примере такого объекта, как дерево.

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

Но если дать ему группу желающих научиться работать с этой технологией и попросить её обучить - получится, что то, как привык действовать он, не подходит другим людям, т.к. они мыслят по-другому. У них другие приоритеты и они, применяя принцип Парето, из общего объёма знаний отсеяли бы ДРУГИЕ 20%, нежели те, которые отсеял он, восприняв то, что знает он, как "воду", "информационный шум".

Поэтому существует 2 подхода к решению данного вопроса.

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

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

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

Обогащение (enrichment) или псевдо-конструктор (pseudo-constructor) как JavaScript-pattern

Вторым открытым при разработке библеотеки Drag and Drop приёмом, который я бы назвал шаблоном, является обогащение (enrichment). Ещё я иногда про себя называю его псевдо-конструктор (pseudo-constructor), что считаю менее удачным, но так же подходящим для него названием.

Он служит для ситуаций, когда нужно придать некоторую дополнительную функциональность группе объектов одинакового вида.

Я столкнулся с этой проблемой при работе с тем же самым объектом Event для IE. Дело в том, что продемонстрированный в позапрошлой статье приём "Заплатка" (Patch) был несколько неполным. Напомню приведённый код:

(function setAddEventListener(){
    if ('attachEvent' in this && !('addEventListener' in this))
        addEventListener = function(eventName, handler, isCapturing) {
            if (isCapturing)
                throw new Error("We are in IE, so we haven`t way to set event listener on capturing phase of any event to any of HTML-elements");
            attachEvent("on" + eventName, handler);
    }
})(); //IE patch for window.addEventListener

В этом коде, к сожалению, не было учтено, что для придания стандартного поведения функции addEventListener нужно, что бы она вызывала слушателя, передавая ему объект Event, при чём это должен быть объект Event стандартного вида.

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

Имитация функциональности стандартного объекта Event на почве IE`шной реализации сама по себе является сложной задачей и у меня нет уверенности, что она действительно представляет для читателей практический интерес, так что я просто проиллюстрирую принцип, показав скелет решения, а уже "наполнение мясом", каждый может делать для себя сам - по крайней мере для меня эта задача пока не актуальна. Так что упростим задачу - возьмём лишь один аспект нестандартного поведения и его сэмулируем. Например, отмена поведения браузера по-умолчанию для данного события. В стандартном W3C`шном объекте Event это действие производится вызовом метода preventDefault, а в IE - установкой значения false в свойство returnValue этого кода.

Итак, имеем нестандартный Event, который нужно сделать стандартным Event`ом. Для выбранного нами аспекта это означает, что ему нужно приделать такую функцию:

/** Отменяет поведение браузера для данного события по-умолчанию. */
event.preventDefault = function(){
    this.returnValue = false;
};

Это нельзя сделать раз и навсегда, поскольку сам объект постоянно (при наступления каждого нового события) меняется. Тут мы, кстати, видимо, что в основу этой модели уже заложена однопоточность выполнения JavaScript-сценариев, которую сейчас так активно критикует JavaScript-сообщество. Так же однопоточность заложена в основу на этот раз стандартного конструктора RegExp. Первое, что приходит на ум, это просто приписать этому объекту несколько новых свойств "не отходя от кассы" - т.е. там, где это нам понадобится. Однако это будет иная логика, которая тем самым замусорит код - будет удобнее собрать все эти операции в одном, отдельном месте.

Следующая мысль, уже более зрелая - создать отдельный конструктор, который наследовался бы от нестандартного Event`а и расширял бы его функционал стандартными свойствами и методами:

/** Конструктор, служащий для придания не совместимым с W3C DOM level 3 объектам
 * Event стандартного поведения.
 * @constructor
 * @extends Event */
function EventW3C() {
    /** Отменяет поведение браузера для данного события по-умолчанию. */
    this.preventDefault = function() {
        this.returnValue = false;
    };
};

Вызов же этого конструктора в нужном месте предполагается примерно такой:

EventW3C.prototype = event; //Сначала присваиваем правильный прототип конструктору
var w3cEvent = new EventW3C(); //Затем создаём экземпляр, который будет ссылаться ссылкой __proto__ куда надо.

После этого получим объект, поведение которого соответствует стандартному и который уже можно спокойно передавать функции, не подозревающей, что она выполняется в нестандартном (IE6-8) браузере.

Однако нетрудно увидеть, что этот приём излишне-расточителен. Фактически, для каждого события он создаёт не один, а два объекта в памяти, так что сборщику мусора будет в два раза больше работы. Кроме того, само по себе создание объектов - не такая уж быстрая операция и хотелось бы по возможности её избегать, если это не сильно оправданно ситуацией. Не говоря уже о том, что механизм вызова из двух выражений выглядит излишне-громоздким.

Гораздо более экономным является такой вариант - можно вызвать эту функцию не при помощи оператора new, а при помощи метода call:

EventW3C.call(event);

и объект сам, без создания наследника, получит нужное свойство. Именно из-за того, что по форме это очень напоминает использование конструктора, я про себя иногда и называю этот шаблон псевдо-конструктором (pseudo-constructor).

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

function EventW3C() {
    /** Отменяет поведение браузера для данного события по-умолчанию. */
    this.preventDefault = function() {
        this.returnValue = false;
    };
    return this;
};

Для использования этой функции в качестве реального конструктора это ровным счётом ничего не изменит, а вот для использования её в качестве псевдо-конструктора это может сделать вызов более удобным - тогда само выражение вызова будет возвращать результат, прямо как у реального конструктора:

var w3cEvent = EventW3C.call(event);

На последок приведу полный вариант реализации pattern`а "Заплатка" ("Patch") для эмуляции addEventListener`а, который использует приведённый pattern Обогащение (Enrichment) или псевдо-конструктор (Pseudo-Constructor):

//IE patch for window.addEventListener
function setAddEventListener()
{
    if ('attachEvent' in this && !('addEventListener' in this))
        addEventListener = function(eventName, handler) {
            if (isCapturing)
                throw new Error("We are in IE, so we haven`t way to set event listener on capturing phase of any event to any of HTML-elements");
            attachEvent("on" + eventName, function() {
                handler(EventW3C.call(event) //Здесь используется pattern "Enrichment"
            });
        }
}
setAddEventListener.call(document);// Применяем заплатку для объекта document

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

P.S. Думается, что данный шаблон имеет так же большой потенциал применения для добавления свойств объектам DOM, если нужно придать им нужную функциональность. По крайней мере сейчас я прорабатываю эту идею как раз в контексте своей библиотеки - она поможет пользователям навешивать несколько обработчиков событий в ходе Drag&Drop-перемещения.

P.P.S. Пришло в голову, когда уже собирался опубликовать сообщение - а может, лучше будет назвать этот приём - Псевдо-наследование ("Pseudo-Inheritance")? Пишите в комментах Ваши версии :)

Самонастраивающаяся функция

В ходе написания второй версии библиотеки для Drag&Drop`а (уже скоро выложу и опубликую, ждите - осталось недолго :) ) была найдена парочка интересных JavaScript`овых решений, которые тоже вполне могут претендовать на звание Pattern`ов. Рискуя тем, что, возможно, изобретаю велосипед, всё-таки распишу, как я их использую.

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

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

Именно с такой задачей я имел дело при написании второй версии своей библиотечки. Мне нужна была функция, которой передавался бы объект pos, имеющий два свойства - 'x' и 'y' и от неё требовалось, что бы она проставила в них значения x и y-координат курсора мыши. Я назвал её refreshMousePos.

Саму эту функцию должен вызывать обработчик того или иного события, который в W3C-совместимых браузерах получает ссылку на объект Event, соответствующий данному событию. Для вычисления координат курсора мыши этот объект нужен, так что в этом случае ссылку на него нужно передать в refreshMousePos вторым аргументом. В случае же W3C-несовместимого браузера (в основном, IE6-8), обработчику не передаётся этот объект, по-этому он и не может быть передан в функцию refreshMousePos.

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

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

Сам IE меняет в соответствии с обрабатываемым событием объект event, который всегда находится у него в глобальном контексте. И интерфейс этого объекта несколько иной, что проявляется в логике вычисления координат курсора мыши.

Так что я сделал разделение логики следующим образом:

/** Обновить координаты мыши.
 * @param {Position} pos координаты курсора мыши
 * @param {Event} [evt] объект события */
function refreshMousePos(pos, evt) {
    return (refreshMousePos = typeof evt !== 'undefined' ?
        function(pos, evt) { //W3C realization
            var body = document.body;
            pos.x = evt.clientX + body.scrollLeft - body.clientLeft;
            pos.y = evt.clientY + body.scrollTop - body.clientTop;
            return pos;
        } :
        function(pos) { //IE realization
            pos.x = event.pageX;
            pos.y = event.pageY;
            return pos;
        }
    )(pos, evt); //вызываем тот вариант функции, которую присвоили и возвращаем результат выполнения
};

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

P.S. Спросите, зачем я возвращаю объект pos, ведь его поля итак уже изменены и значит, необходимый внешний эффект достигнут? Отвечу - для того, что бы можно было после вызова функции сразу же в той же конструкции обратиться к объекту pos:

alert(
    refreshMousePos(pos, evt).x
);

"Заплатка" ("Patch") как JavaScript шаблон проектирования

Недавно пришла в голову мысль, что "Заплатка" вполне заслуживает звания JavaScript-шаблона проектирования. По-англицки можно было бы назвать "Patch". Суть его не собственно в хаке, а скорее в том, что бы отделять код, написанный в соответствии со стандартом, от кода, который приспосабливает браузер, не поддерживающий стандарты, корректно работать со стандартным кодом при помощи того или иного хака.

Сам я использую заплатки уже достаточно давно. Разумеется, основные заплатки ставятся на IE6-8, с которыми, по-видимому, ещё предстоит много возни, пока они, наконец, отомрут. Однако так же не помешает установить их и для старых версий иных браузеров.

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

function onLoadListener() {
    //some code...
}
if ('addEventListener' in window)
    addEventListener("load", onLoadListener, false);
else if ('attachEvent' in window)
    attachEvent("onload", onLoadListener)

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

Тем не менее, сократить эту конструкцию до стандартного кода

addEventListener("load", function() {
    //some code...
}, false);

мы не можем, поскольку стандарты поддерживают не все браузеры, в которых нам хотелось бы, что бы наш сценарий успешно выполнялся. Для остальных же браузеров у нас есть многочисленные хаки. Так как же быть?

Как только я в своих проектах сталкиваюсь с несовместимостью работы того или иного браузера со стандартными методами, первая мысль у меня возникает о том, что бы вынести обеспечение совместимости в отдельный от основного код, что бы он его не захламлял. У меня уже накопилось достаточно много таких заплаток, латающих различные дыры в поддержке стандартов различным браузерами - главным образом IE. Обычно я помещаю их в отдельный файл проекта, называя его "commons.js" (есть и исключения - например в случае, если это нужно только для тестирования, я считаю не зазорным вставлять такой код просто в начало тестового файла).

В данном случае полезной была бы следующая заплатка:

(function setAddEventListener()
{
    if ('attachEvent' in this && !('addEventListener' in this))
        addEventListener = function(eventName, handlerб isCapturing) {
            if (isCapturing)
                throw new Error("We are in IE, so we haven`t way to set event listener on capturing phase of any event to any of HTML-elements");
            attachEvent("on" + eventName, handler);
        }
})(); //IE patch for window.addEventListener

Здесь элегантно используется то обстоятельство, что ссылка this при вызове в глобальном контексте в функции указывает на объект window. По-этому сразу же после объявления функция просто вызывается.

Здесь не могу не отметить, что заплатка получилась лишь частичная - третий параметр метода addEventListener невозможно эмулировать при помощи метода attachEvent, доступного в IE. Так что в этом случае приходится вызывать исключение, что бы при отладке или тестировании это обязательно всплыло в виде корректного сообщения.

Если необходима реализация парного метода removeEventListener, её легко написать по аналогии, реализовав через метод detachEvent.

Теперь другие элементы, которым так же нужно "привить" правильное поведение, могли бы обрабатываться следующим образом:

setAddEventListener.call(document.getElementById('id1'));

В статье "JavaScript: Реализация pattern`а Singleton" я уже приводил ещё одну заплатку - для безпроблемного объявления объекта XMLHttpRequest (который я нашёл в англоязычной Wikipedia):

// Provide the XMLHttpRequest class for IE 5.x-6.x:
if (typeof XMLHttpRequest == "undefined")
    /** @constructor */
    XMLHttpRequest = function() {
        try { return new ActiveXObject("Msxml2.XMLHTTP.6.0") } catch(e) {}
        try { return new ActiveXObject("Msxml2.XMLHTTP.3.0") } catch(e) {}
        try { return new ActiveXObject("Msxml2.XMLHTTP") } catch(e) {}
        try { return new ActiveXObject("Microsoft.XMLHTTP") } catch(e) {}
        throw new TypeError( "This browser does not support XMLHttpRequest." )
    };

Напоследок приведу ещё одну заплатку. Она служит для безпроблемной реализации стандартного метода window.getComputedStyle, отсутствующего в IE вплоть до 8 версии включительно. Кто не знает, это очень удобный метод, позволяющий получать ссылки на объект, содержащий информацию о "вычислимых стилях" для HTML-элемента. Вычислимым называется стиль, специально не установленный разработчиком, однако получившийся в результате вывода браузером этого элемента на странице. IE вместо него имеет свойство computedStyle, доступное у каждого элемента. К сожалению, оно не может представить вычислимый стиль для псевдоклассов, по-этому заплатку можно вставить так же, как и для addActionListener`а - лишь частичную.

Таким образом, вот как можно решить данную проблему несовместимости IE со стандартом:

//IE patch for window.getComputedStyle
if (!('getComputedStyle' in window))
    getComputedStyle = function(element, pseudoclass) {
        if (pseudoclass === null || typeof pseudoclass === 'undefined')
            return element.currentStyle;
        else
            throw new Error("We are in IE, so we haven`t way to get pseudoclass styles of element");
    };

Я скачал ЕЁ!!!

Самая лучшая книга по JavaScript всех времён и народов! Лучше неё ничего нет!
O`Reilly - Девид Фленаган, «JavaScript. Definitive Guide, 6th edition»(2011) - туда вошли все новшества от HTML5 и ECMAScript 5! :))))

Вот тут она есть - http://uploading.com/files/3735d769/Oreilly.j

Фленаган пишет очень подробно, для профессионалов.

Искал в электронном виде уже месяца два, кучу времени убил – нигде не было, хотя куча вирья всякого пыталась под её видом пролезть на манер файлов «JavaScript_Definitive_Guide,6th_edition.pdf.exe» с иконкой pdf`а... И вот, наконец, она – вот она!!!)