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

Google Chrome, несомненно, штурмом захватил мир браузеров.

Однако наиболее волнующий вопрос для разработчиков на Javascript — как это затронет привычный процесс разработки. Я провел небольшое исследование, общался с некоторыми разработчиками, изучал ошибки, и хочу представить вам небольшой список вещей, о которых вам не мешало бы знать.

Здесь представлены некоторые ошибки, скрытые возможности и др.

Задержка таймера

Без сомнений, самое захватывающее изменение: задержка таймера — это то значение, которое вы задали. Например если вы делаете:

setTimeout(someFunction, 2);

то someFunction будет выполнена ровно через 2 миллисекунды.

Одно исключение для данного случая лишь в том, что если вы задаете задержку < 1 мс, она будет округлена до 1 мс. Я общался с Майком Бэлшем, человеком, реализовавшим таймеры в Хроме, и он надеется полностью избавится от этой задержки. По его словам — в разработке браузеров каждая миллисекунда на счету.

Я проводил некоторые исследования в прошлом и обнаружил, что все браузеры имеют нижнюю границу задержки таймера. Как правило это 10-15 мс. Если вы задаете значение меньшее чем эта граница — оно будет округлено до минимума браузера.

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

Напрашивается логичный вопрос — почему браузеры не делают этого? На это есть несколько причин:

1. Это позволит пользователю загрузить процессор так, что это заблокирует пользовательский интерфейс. Однако это не проблема для Хрома, поскольку каждая вкладка работает в отдельном процессе (процессор все ещё будет перегружен, однако это затронет только одну вкладку).
2. 2. Это может вызвать непредвиденные побочные проблеммы. Это сложный вопрос, ответа на который толком никто не знает. Это может привести к странным проблемам, однако никто точно не может сказать к каким именно. В настоящее время Chrome занимается исследованием этого вопроса и отслеживанием таких проблем.

Остается ещё один вопрос относительно тестов производительности. Если тест производительности расчитан на задержку таймера в 10 мс не даст ли это Хрому дополнительных неоправданных преимуществ? Команда Chrome провела исследования и не нашли ниодного подобного теста производительности.

Отсутствие диалога выполнения скрипта

В большинстве браузеров если вы попытаетесь запустить скрипт, который будет выполняться слишком долго (в большинстве браузеров, порядка 5 секунд) — появится диалог уведомляющий о чрезмерной нагрузке и предлагающий пользователю прервать выполнение скрипта на странице.

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

Что касается лично меня, мне понравилось держать открытой вкладку с while(true) {} все время что Chrome был открыт.

UPD: Многие читатели сообщили что им все же удалось вызвать диалог при выполнении слишком долгих скриптов. Однако у меня этого сделать так и не получилось. Вот скриншот от Энрдю Хоукена:

Порядок обхода

В настоящее время все известные браузеры обрабатывают свойства объектов в том порядке в котором они были определены. Chrome делает точно так же за исключением некоторых случаев. (Баг V8, Баг Chrome).

Проблему можно увидеть в следующем примере:
var obj = {first: [1, 2, 3], second: "blah"},
    str = "<b>A property contains an array:</b><br/>",
    count = 1;
for ( var i in obj ) {
    str += (count++) + ": " + i + "<br/>";
}

str += "<hr/><b>Properties all contain strings:</b><br/>";
obj = {first: "blah", second: "blah"};
count = 1;

for ( var i in obj ) {
    str += (count++) + ": " + i + "<br/>";
}

window.onload = function(){
    document.body.innerHTML = str;
};

Если объект содержит значения, которые не являются примитивами (как в первом примере), тогда его свойства будут перечислены не в том порядке, в котором они были определены.

Это интересная ошибка из-за одного факта: это поведение не определено явно в спецификации ECMAscript.
В ECMA-262, в секции 12.6.4 написано:

Механизм перечисления свойств — зависит от реализации.

Несмотря на это, спецификация несколько отличается от реализации. Все современные реализации ECMAscript обходят свойства именно в том порядке, в котором они были определены, и поскольку разработчики Chrome все же считают это ошибкой — это будет устранено.

Сериализация

Это странная ошибка WebKit, которая затрагивает символы "<" и ">" которые нельзя сериализовать в &lt; и &gt; когда они заданы как текстовый элемент. Эта ошибка уже исправлена в транке WebKit и будет исправлена в Chrome при синхронизации веток.

Gears / Клиентские хранилища

Это сложная тема. Гугл решил использовать Gears и при этом удалил поддержку Client-Side Storage API для HTML5.

У Gears есть своя собственная SQL база данных (доступная в своем пространстве имен и имеющая API отличное от API HTML5). Из-за этого нужно поддерживать 2 реализации клиентского хранилища, что само по себе является странным.

На этом, вообщем-то, и заканчиваются все отличия Chrome от WebKit/Safari 3.1. Команда Chrome не делала каких-то новых возможностей (если не считать Gears) и не реализовывала какие-либо новые спецификации.