Кодеры за работой. Размышления о ремесле программиста
Шрифт:
И теперь мы думаем, что должны его как-то исправлять. Это нужно было сделать еще в 2000-м, но тогда этого никто не сделал, поскольку на него тогда никто не обращал внимания. Теперь же это сделать очень сложно.
Есть еще одна особенность JavaScript в контексте Сети. Обычно, разрабатывая серверное, прикладное или встроенное (embedded) приложение, выбираешь не только язык, но и компилятор, и среду выполнения. Однако в случае JavaScript нет такого выбора: нужно, чтобы код работал на чем угодно.
Поскольку код должен выполняться на чем угодно, ошибки не исправляются. Если разработчик броузера выпустит его с ошибкой, то скажет: “Ой, мы лажанулись”, - и на следующий месяц выпустит следующую версию с другой ошибкой, а мы не можем подстраиваться под все обновления, которые устанавливают их пользователи. Большинство
Сейбел: То есть ситуация сейчас именно такова. Но вы хотите сделать Сеть более совершенной платформой для разработки приложений. Если мы не можем исправить свои ошибки, пока разработчики броузеров не исправят собственные, если даже и это не помогает, значит, мы в тупике. Где же выход?
Крокфорд: Как раз этим я и занимаюсь. Я вижу идеальное решение. Я знаю, каким оно должно быть. Знаю, где мы находимся, и вижу все преграды на нашем пути. И пытаюсь придумать, каким образом нам выйти из этого положения. Мы оказались в ловушке, в том смысле что разработали громоздкие системы - экономические, социальные, технические, которые в значительной степени зависят от этих непродуманных решений.
Несомненно, худшей особенностью JavaScript является зависимость от глобального объекта. В JavaScript нет компоновщиков и информация между элементами компиляции никак не скрывается. Все объединяется в общий глобальный объект. Так что каждый компонент видит все остальное; все компоненты имеют равноправный доступ к DOM; все они имеют одинаковый доступ к сети. Если какой-нибудь скрипт проберется на вашу страницу, он сможет зайти на сервер, представив себя в качестве вашего скрипта, и сервер никак не сможет отличить его от вашего.
У него есть доступ к экрану, он может представиться пользователю вашим скриптом, и пользователь также не сможет определить это. Все новые антифишинговые вещи, добавленные в Chrome, не работают, если страница пришла с вашего сервера, так что все скрипты обладают равными правами независимо от того, откуда они пришли.
Ситуация ухудшается еще и тем, что есть и другие пути попадания скрипта на вашу страницу. Архитектура Сети включает несколько языков: HTTP, HTML, язык URL-адресов, CSS и язык сценариев. Все они существуют и могут встраиваться друг в друга, обладая разными правилами цитирования (quoting), экранирования (escaping) и комментирования. Не во всех броузерах все эти правила реализованы одинаково. А некоторые из этих правил могут быть вообще не определены. Из-за этого злоумышленник легко может встроить какой-либо скрипт в URL, вставить его в кусок CSS, который затем вставить в HTML, а тот - в другой скрипт и так далее.
Сейбел: Классические межсайтовые скриптовые атаки, связанные с ошибками в броузере.
Крокфорд: Именно. Это ужасно. Нам нужно что-то с этим делать, потому что оставлять все это так совершенно не хочется.
В конце концов мы открыли мэшапы [37] . Это как раз то, чего мы пытались добиться в области программного обеспечения в течение двадцати лет: компоненты многократного использования, которые можно объединять друг с другом, как детали в конструкторе LEGO, очень быстро создавая новые приложения. Мэшапы действуют аналогичным образом, и получается великолепно: берешь что-то из Yahoo!, что-то из Google, что-то свое, что-то чье-нибудь еще и делаешь из всего этого приложение. Класс! И все это делается в броузере, прямо у тебя перед глазами. Проблема одна: каждый из этих компонентов имеет доступ к тому же, что и другие. Мы сознательно создаем условия для XSS-атак. Модель безопасности броузеров не ожидает от этого ничего хорошего и не предоставляет никаких механизмов взаимодействия при взаимном недоверии. Вся всемирная Сеть построена на сплошных ошибках. Результат - множество неприятностей.
37
Мэшап (mash-up) - веб-приложение, объединяющее данные из нескольких источников в один интегрированный инструмент; например использует картографические данные Google Maps для добавления к ним данных о недвижимости с Craigslist,
– Прим. науч. ред.
Сейбел: Можно ли из всего этого сделать вывод, что все усилия по принятию стандарта ES4 [38] относятся к альтернативным издержкам и все думают именно об этом, а не о том, как избавиться от имеющихся проблем?
Крокфорд: Именно так. Этот стандарт решает не ту проблему. Он решает проблему, связанную с тем, что люди ненавидят JavaScript. И я могу понять позицию Брендана Айка, поскольку он проделал потрясающую работу, но он торопился, допускал ошибки в руководстве, и в итоге вышла полная ерунда. Его ругали и поносили последние двенадцать лет за его глупость и за то, что он создал глупый язык, но все это не так. Там есть блестящие идеи, и сам Брендан - блестящий парень. Он сейчас пытается оправдаться и доказать, что действительно умен, и показать это всем с помощью языка, который будет содержать все классные возможности, которые он когда-либо видел, объединенные и работающие все вместе.
38
Имеется в виду четвертая версия стандарта ECMAScript, работа над которой так и не была завершена.
– Прим. науч. ред.
Не думаю, что именно эту проблему нам нужно сейчас решать. Я думаю, что нужно решить следующее: Всемирная Сеть поломана, и мы должны ее починить. Нам нужно решить, каким путем продвигаться вперед. И мое главное возражение против того, что собирается сделать Брендан, в том, что он всех отвлекает.
Думаю, нужно двигаться шаг за шагом. Если у нас появится модульность или возможность выбирать язык программирования, это уже будет шаг вперед. Это еще не все, что нам нужно, но гораздо больше того, что есть у нас сейчас. Потом есть такие вещи, как Caja и ADsafe, пытающиеся сделать то же самое с помощью сегодняшних технологий. Мы не можем ждать.
ADsafe создает безопасное подмножество языка JavaScript, блокируя доступ ко всему глобальному и опасному. Но даже это подмножество все еще представляет собой полезный язык. У нас все еще остаются лямбда-выражения, а они могут многое. Таким образом, это нестандартный язык. Он не позволяет использовать прототипы так, как мы уже привыкли. Но этот язык остается невероятно мощным, поскольку в нем присутствуют лямбда-выражения.
Сейбел: Возвращаясь к ES4: есть ли в нем хоть что-то, что вам нравится с точки зрения языка?
Крокфорд: В нем исправлены некоторые ошибки языка, чем следует воспользоваться. Но в этом стандарте слишком много неопробованных возможностей. Наш опыт со стандартом ES3 говорит о том, что если ошибка однажды закралась в спецификацию языка, то удалить ее невозможно. Но у нас нет опыта работы с этим языком. Никто пока не написал на нем ни одного крупного приложения.
А он будет стандартизирован и внедрен до того, как мы поймем, что он действительно работает. Думаю, мы слишком торопимся. Я бы чувствовал себя спокойнее, если бы существовали примеры его реализации и полезные приложения, написанные на нем. Вот тогда я бы сказал: “Хорошо, давайте стандартизировать язык, давайте внедрять его по всему миру”. А мы все делаем в обратном порядке.
Сейбел: Google Web Toolkit (GWT) позволяет компилировать Java в JavaScript. Многие уже пробовали компилировать другие языки в JavaScript. Это правильный путь?
Крокфорд: Любопытно наблюдать, как JavaScript становится универсальной средой выполнения. Мы никогда не ожидали увидеть его в такой роли.
Сейбел: Но, как вы уже говорили, он везде. Он стал универсальной средой выполнения.
Крокфорд: Что тем более заставляет нас обратить внимание на производительность. Особенно при переходе на мобильные платформы, к которым закон Мура неприменим. Здесь уже имеет большое значение то, сколько времени мы тратим на интерпретацию. Все это дополнительные такты процессора. Так что, думаю, это должно дополнительно улучшить качество среды выполнения.