1. Ajax 101 | Workshop
Автор: Bill Scott | This presentation on SlideShare
Введение в программирование с помощью Ajax. Включает XMLHttpRequest, XML, JSON, JavaScript, HTML, CSS, Dom Scripting, Event Handling с небольшими примерами на YUI.

2. Modular CSS
Автор: Russ Weakley | This presentation on Slide Share
Вполне доступно (даже я понял) объясняется механизм построения правильного модульного CSS, что позволяет прятать/показывать отдельные CSS правила для отдельных браузеров, без различного рода уловок и обходных путей.

3. jQuery in 15 minutes
Автор: Simon | This presentation on SlideShare
Небольшое введение в JQuery. Функции, коллекции, работа со значениями и цепочками.

4. JavaScript Library Overview 
Автор Jeresig | This presentation on SlideShare
Интересный обзор популярных JavaScript библиотек (jquery, prototype, Scriptaculous...) для веб-дизайнеров.

Интересное видео в тему к предыдущему посту. Если вы еще не в курсе, как работает браузер - жмите на серенький треугольничек рядом с дядькой.

Давно известно, что операции с DOM'ом весьма и весьма трудоемки. Потери в производительности заметны обычно в трех случаях:

• когда скрипт выполняет манипуляции с деревом объектов (создает, удаляет или изменяет часть дерева)
• если скрипт "заставляет" браузер перерисовывать (redraw) или перестраивать разметку (reflow) страницы
• и наконец, в случае когда скрипт "ищет" один из узлов дерева объектов (если дерево большое).

Последний пункт я уже рассматривал в одной из статей своего цикла Скаженi кабани, на примере JQuery. Поэтому сегодня мы поговорим о первых двух. Эм...на самом деле я схитрил, и первый пункт представляет собой ни что иное, как причину появления второго пункта. Тогда сразу перейдем ко второму пункту и попробуем разобраться в терминах перерисовывать и перестраивать разметку:

Перерисовка страницы браузером происходит в случае, когда что-то визуально изменилось, но разметка страницы осталась прежней. Например, изменился цвет элемента или элемент стал видимым/невидимым (с помощью visibility: [hidden, visible], так как это не повлияет на разметку). Эта операция существенно влияет на производительность веб приложения, так как заставляет браузер пройтись по дереву объектов и определить какие элементы видимы и как они должны быть отображены.

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

• при первой загрузке страницы. В случае с Firefox, перестройка может происходить несколько раз, по мере докачивания контента страницы;
• когда вы добавляете или удаляете элементы DOM'a. Надо сказать, тут есть одно исключение - если вы добавили/удалили объект с абсолютным позиционированием, то это может и не привести к перестройке разметки страницы, так как позиция и размеры других элементов не были изменены;
• когда стиль элемента изменен и он влияет на размер и положение этого либо других объектов;
• когда вы пытаетесь обратиться к свойствам, требующим вычислений со стороны браузера (например, offsetWidth, clientHeight). А также в случае попытки получить вычисляемые CSS значения (с помощью getComputedStyle() или currentStyle в IE).

Процесс перестройки разметки страницы выглядит примерно следующим образом:

Mozilla.org

Wikipedia

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

Теперь когда мы в курсе "почему наш сайт тормозит", рассмотрим несколько техник оптимизации работы с DOM'ом. Первое что приходит в голову, это минимизировать количество дорогостоящих операций (описанных выше). А значит, необходимо как можно больше операций совершать вне DOM'а, например используя DocumentFragment.

var products = ... //init array of products
var list = document.getElementById("myProducts"); //find list populate to
for (var i=0; i < products.length; i++){
    var item = document.createElement("li");

    item.appendChild(document.createTextNode("Product" + products[i]);
    list.appendChild(item); // AHTUNG! Operation with DOM
}

Предыдущий код можно оптимизировать следующим образом:

var products = ... //init array of products
var list = document.getElementById("myProducts"); //find list populate to
var fragment = document.createDocumentFragment(); //create document fragment
for (var i=0; i < products.length; i++){
    var item = document.createElement("li");
    item.appendChild(document.createTextNode("Product" + products[i]);
    fragment.appendChild(item); //working with fragment only, not with DOM
}
list.appendChild(fragment); //add fragment to DOM

Эта версия кода затрагивает дерево объектов только раз, в последней строчке. И так как DocumentFragment не имеет визуальной составляющей, то все операции с ним не вызывают ни перерисовки, ни изменения в разметке страницы. Но так как DocumentFragment не может быть добавлен в DOM, то операция appendChild добавит все дочерние элементы фрагмента (вместо того, чтобы добавить сам фрагмент).

Другим, более эффективным подходом, будет работать с элементом, не находящимся в дереве. К примеру, мы можем удалить наш объект из дерева перед выполнением операций над ним (removeChild() или replaceChild())

var products = ... //init array of products
var list = document.getElementById("myProducts"); //find list populate to
var parent = list.parentNode; //find parent
parent.removeChild(list); //remove list element from DOM
var fragment = document.createDocumentFragment(); //create document fragment
for (var i=0; i < products.length; i++){
    var item = document.createElement("li");
    item.appendChild(document.createTextNode("Product " + products[i]);
    list.appendChild(item);
}
parent.appendChild(list);

Мы не избежали перестройки разметки страницы, но мы уменьшили количество таких перестроек.

Другой причиной перерисовки или перестройки страницы служат стили и спобосы их назначения элементам. Рассмотрим следующий кусок кода:

element.style.backgroundColor = "white"; //will cause redraw
element.style.color = "red"; //will cause redraw
element.style.fontSize = "12em"; //will cause reflow
element.style.widht = "100px"; //will cause reflow

Как видите первые две строки инициируют перерисовку. Избежать этого можно, если перед изменением стилей скрыть элемент с помощью visibility:hidden или display:none (будет произведено два лишних reflow). Избежать перестройки разметки тут не получиться, но их количество можно уменьшить, если задать все изменения стилей в CSS классе.

.newClass{
	background-color: blue;
	color: red;
	font-size: 12em;
	with: 100px;
}

а затем

element.className = "newClass";

Скрытый reflow может также произойти, если мы попытаемся получить одно из вычисляемых свойств (например offsetWidth). Браузер должен быть уверен, что значение свойства актуально, поэтому он рассчитает его заново, а это фактически и будет перестройка разметки страницы. Избежать этого опять же нельзя, но мы можем уменьшить количество таких операций за счет кэширования значения этого свойства:

var posElem = document.getElementById('animation');
var calcWidth = posElem.offsetWidth;
posElem.style.fontSize = ( calcWidth / 10 ) + 'px';
posElem.firstChild.style.marginLeft = ( calcWidth / 20 ) + 'px';
posElem.style.left = ( ( -1 * calcWidth ) / 2 ) + 'px';
... other changes ...

Полезные ссылки

Notes on HTML Reflow

Dom document fragments

Efficent Javascript (from Opera)

Increasing appendChild Performance with DOM Tricks

Честно говоря раньше не придавал особого значения такой фазе веб-девелопмента, как верстка. Отчасти потому что никогда этим сам не занимался(на должном уровне), отчасти от того, что недопонимал некоторые аспекты веб-разработки. Недавно наткнулся на интересную статью Сергея Чикуенока (из команды никому не известного Артема Лебедева). Суть этой статьи сводится к следующему: если клиентский код работает медленно - убейте дизайнера, верстальщика или кто этим у вас там занимался. Потому как разметка влияет на скорость работы веб-приложения. Кому интересно почитать детали можно в оригинале статьи, а я лишь процитирую выводы:

1. Для интерактивных элементов лучше использовать position: absolute.
2. Большое количество элементов на странице может снизить производительность, но не стоит увлекаться их сокращением в ущерб надежности макета.
3. Не надо делать очень глубоких вложенных структур элементов.
4. Прежде чем начинать верстку макета, следует узнать, какие интерактивные механизмы там должны быть — это избавит от многих проблем уже на начальном этапе работы над проектом.
5. Не надо загонять себя в угол глупых стереотипов: «валидность» и «семантичность» никому, кроме самих разработчиков, не нужна.
6. Не стоит без надобности растягивать картинки. Если это необходимо сделать, следует воспользоваться canvas.
7. Как правило, img-элемент будет работать гораздо быстрее, чем CSS-свойство background-image.
8. Помните главное правило: оптимизировать нужно то, что требует оптимизации.

Вот так-то господа, веб разработчики...

Почему следующий кусок кода генерирует StackOverflowException?

IEnumerable<int> q = new int[] { 1, 2 };

q = from x in new int[] { 1, 2 }

    from y in q

    select x + y;

q.ToArray();

С предложениями, как это исправить - прошу в комментарии ;)

По роду деятельности получаю различного рода документы(требования) от наших клиентов. Ввиду подписанного мною NDA, я не могу их публиковать. Поэтому я представляю требования к проекту, как требования к постройке дома.

Уважаемый Архитектор,

Пожалуйста спланируте и построте мне дом. Я не совсем уверен, что именно мне нужно, поэтому полностью полагаюсь на вас. Тем не менее, у меня есть несколько идей, которые я бы хотел видеть реализованными в моем доме. К примеру, я бы хотел иметь 2 или 44 спальных комнаты. Спланируйте пожалуйста, так чтобы эти комнаты можно было потом легко убрать или добавить, потому что я приму окончательное решение только тогда, когда увижу чертежи. А также оцените финансовые затраты на каждый вариант, чтобы я мог принять правильное решение.

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

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

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

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

И пожалуйста, не утомляйте меня сейчас деталями. Ваша задача не построить дом, а просто сделать план, нарисовать общую картину так сказать. К примеру, сейчас не время определять цвет паркета. И вот еще, учтите, что моей жене нравиться синий цвет.

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

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

Вы должны быть восхищены такой уникальной возможностью поработать на меня и используя последние новаторские технологии и материалы построить дом. Я вам предоставляю невероятную свободу в принятии решений для моего дома. Свяжитесь со мной как только закончите разработку плана.

Заранее неуверен в успехе,

Заказчик

P.S.

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

P.P.S.

Возможно мне нужен, не дом, а трейлер на колесиках. Пожалуйста ответьте мне, если вы считаете также.

Все вышенаписанное было создано по мотивам схожего романа и моего личного опыта.

John Resig, создатель JQuery, совсем недавно провел небольшую презентацию в Гугле. Темой встречи были улучшения производительности в браузерах(в ближайших релизах), некие новшества в Javascirpt движках, новые способы работы с DOM и изумительные эффекты с помощью CSS стилей. Но обо всем по порядку.

Количество процессов на браузер

Одним из интереснейших нововведений в IE8 и Chrome стало то, что теперь вкладки разделены на несколько процессов. Это дает огромное преимущество в производительности, так как теперь различные веб страницы могут загружаться и исполняться параллельно, не отнимая машинных ресурсов друг у друга. В тоже время такие браузеры как FF, Opera и более старые версии IE загружают/исполняют несколько страниц в одном процессе (различные страницы выполняются отдельными потоками).

Позвольте я поясню, каким же образом происходит разделение вкладок на процессы в Internet Explorer 8. Но для начала давайте вспомним модель процессов IE7:

Как видите, каждое окно браузера (UI Frame) находиться в отдельном процессе. Хотя, надо сказать, тут есть одно исключение - если вы нажмете CTRL+N, то новый UI фрейм создастся в том же процессе. Закладки, расширения браузера (toolbar extensions), вспомагательные объекты и ActiveX контролы находятся в том же процессе, что и UI фрейм. Проблема такой модели в том, что любая фатальная ошибка (например stack overflow) в одной из закладок приведет к закрытию всех закладок в этом процессе.

Рассмотрим модель процессов в IE8:

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

И так как закладки изолированы от UI фрейма, то фатальная ошибка в одной из закладок приведет к закрытию всех закладок в этом процессе, но окно браузера останется открытым. Зачем нам это нужно? А для того, чтобы браузер (UI Frame) имел возможность восстановить закрытые вкладки. Но вернемся к разделению вкладок на процессы. Как вы наверное уже успели заметить закладки разделяются на процессы по принципу принадлежности к одной из моделей безопасности (medium IL или low IL). Это накладывало некоторые ограничения на процесс(окно браузера) и когда вы, например, открыли Интранет страницу в одной вкладке, а затем пытались открыть Интернет страницу в другой, то браузер вам сообщал: "Internet Explorer needs to display this webpage in a new window". Это происходило по той причине, что данный процесс(а следовательно и данное окно браузера) имело определенные security-ограничения в отношении страниц, которые он отображал. Теперь, вы можете открывать страницы с разными уровнями безопасности в одном окне.

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

Chrome создает три типа процессов:

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

Отрисовщик (Renderer). Прости господи меня за такой перевод, но этот тип процессов действительно отвечает за обработку HTML, Javascript, CSS, картинок и много чего еще.  Причем эти процессы не имеют доступа ни к вашему диску, ни к сетевым ресурсам. Все взаимодействия с пользователем, а также отрисовка на дисплее лежит на процессе типа Браузер. Такое разделение на процессы позволяет сразу убивать подозрительные процессы, которые могли быть подвержены различного рода атакам.

Плагины. Процесс браузера также создает по одному процессу для каждого типа плагина: Flash, Quicktime, Adobe Reader и тп.

Все эти процессы можно увидеть в собственном Chrome Task Managar'e:

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

Процессы типа Плагин создаются сразу как только вы открыли страницу, нуждающуюся в этом плагине. И убивает этот процесс, вскоре после того как вы закрыли последнюю страницу, использующую этот плагин.

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

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

Полезные ссылки

IE8 and Loosely-Coupled IE (LCIE)

IE8 and Reliability

Группировка вкладок в IE8

Multi-process Chrome Architecture