JavaScript *

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

Постановка задачи

Насчет с самого простого: чего мы хотим добиться? Мы хотим, задав произвольную строку CSS-селектора, соответствующую спецификации, получить на выходе массив из всех элементов, соответствующих этой самой строке. Вроде пока все просто.

В качестве иллюстрации спецификации можно привести следующие примеры:

//вернет элемент с идентификатором my_id
querySelectorAll('#my_id')
//вернет все элементы с классом external
querySelectorAll('.external')
//вернет все абзацы на странице
querySelectorAll('p')

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

После заметки Стыкуем асинхронные скрипты и предложенного решения от Steve Souders я подумал о модульной загрузке какого-то сложного JavaScript-приложения. И понял, что предложенный подход в таком случае будет довольно громоздким: нам нужно будет в конец каждого модуля вставлять загрузчик следующих модулей. А если нам на разных страницах требуются различные наборы модулей и разная логика их загрузки? Тупик?

Ан нет. Не зря Steve упоминает в самом начала своей заметки о событии onload / onreadystatechange для скриптов. Используя их, мы можем однозначно привязать некоторый код к окончанию загрузки конкретного модуля. Дело за малым: нам нужно определить этот самый код каким-либо образом.

Решение первое: дерево загрузки

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

Недавно на хабре была статья «Когда программисту нечего делать…», вот и у меня такая ситуация но я не просто хочу дать ссылку на Цветные линии, а рассказать как можно самому сделать её. Всем кого интересует добро пожаловать под кат

Периодически натыкаясь на статьи, посвященные оптимизации кода на JS (вот одна из популярных) я ловил себя на мысли, что информации в них катастрофически мало. Перечислены 2-3 конструкции, 1-2 браузера и все на этом.

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

Ну и раз уж результаты получены, почему бы не выложить их для всеобщего пользования?

Upd: добавил графики результатов, предоставленные хабраюзером deerua (для тех, кто воспринимает визуальную подачу информации лучше чем табличную)

В этой статье я хочу по возможности полно и последовательно рассказать о том, что такое объект в JavaScript, каковы его возможности, какие взаимоотношения могут строиться между объектами и какие способы «родного» наследования из этого вытекают, как это все влияет на производительность и что вообще со всем этим делать :)

В статье НЕ будет ни слова про: эмуляцию традиционной класс-объектной парадигмы, синтаксический сахар, обертки и фреймворки.

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

… он возьмет и сделает бесполезную ерунду вечерком, просто так, для себя. Недоработано, сыро и не поддерживает оперу, извиняюсь, конечно, но мне хотелось спать =)

UPD: Перенес в JavaScript, надеюсь, я все правильно сделал

Привет, хочу представить одну интересную разработку студии, в которой я работаю. И как ведущий разработчик буду её освещать :)

В моем твиттере прошла ссылка на десять JS-фреймворков, которые интересны в плане изучения и расширения возможностей, для того, чтобы разработчики не ограничивались только верхушкой мейнстрима (имеется ввиду jQuery/Prototype/Mootools/YUI). Вполне вероятно, что что-то из этого списка завтра будет не менее популярно, да и просто для повышения своей квалификации или подсматривания интересных решений. Оригинал на английском языке здесь, а я попробую рассмотреть самое интересное со своей колокольни.

Прочитал топик и решил реализовать на js (yass) + css.
Рабочий пример

Вчера, после прочтения поста Джон Резига, решил записать по горячим следам первый в своей жизни (это я к тому, что сильно ругать не стоит, а конструктивная критика приветствуется :) скринкаст.

Fireunit — это инструмент для тестирования javascript кода, созданный в виде дополнения к firebug'y Джоном Резигом в рамках его сотрудничества с командой firebug. На данный момент, он работает только под ff3+, firebug 1.2+.

Зачем же нужен такой инструмент тестирования, если он работает только в firefox?

1. Fireunit позволяет тестировать очень интересные dom-события — события загрузки и готовности контента, завершнения отрисовки, вроде contentReady
2. Вполне вероятно, что fireunit будет включен в состав (или, по крайней мере, его можно будет установить с) firebug light.
3. Сама идея фреймворка тестирования, встроенного в браузер, является очень привлекательной. Вполне возможно, что производители других браузеров включат аналогичный инмструмент в свои продукты (как уже было с web inspector'ом для webkit, dragonfly для opera, developer toolbar для ie8)

Итак, напишу о том, как пофиксить дрожание в IE при эмуляции position:absolute; (без фоновой картинки), устроить склонение слов, решить проблемы с вопросиками в Mysql и про остальные неважные, но иногда полезные хитрости.
Если Вы матёрый веб-технолог, можете не читать: ничего нового не найдёте.

Захотелось вот что-нибудь для людей сделать.


Оно умеет:

• Ползать
• Дрыгаться
• Разваливаться на листы
• и Менять размер
• а ещё оно разных цветов

Много нового и просто хорошего:

• Поддержка части CSS2/3.
• Ускорение в 2 раза: быстрее последних Sizzle и Peppy.
• Размер кода (min.gz): 1066 байтов.
• Google Code SVN: code.google.com/p/yeasss .
• Дизайн для yass.webo.in .

Эта статья о мирном атомеXSS. Заставим зло работать на добро!

А зачем?

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

Методы организации XSS

1. Через тэг iframe
2. Через тэг script
3. Через flash<->javascript
4. Через window.name + iframe + form
5. Через CSS хак
6. Через canvas + img
7. Через прокси

Спасибо всем.

Честно, не ожидал настолько позитивного отклика (некоторые даже кинулись внедрять библиотеку в свои проекты и всячески пропагандировать :). Для большей ясности поясню основные идеи:

1. Это мини-ядро. Чтобы выбирать элементы DOM-дерева. На его основе (или дополнительно к нему) можно разрабатывать остальные модули. Но конкретно этот функционал дальше CSS-селекторов расширяться вряд ли будет. Идея ни разу не новая.
2. Это самое быстрое мини-ядро. Каждая строчка тестируется и будет тестироваться на экстремальную производительность в большинстве случаев. Чтобы это можно было положить в основу большого проекта. Иначе все остальное не имеет смысла.
3. Код открытый (MIT + GPL). Можно использовать где угодно (вроде даже без ссылок на авторство). Комментарии по улучшению приветствуются.

После заметки о Peppy я почти обрадовался — вот оно, счастье. Наконец появился движок CSS-селекторов, который делает тоже самое, что и jQuery, только быстрее. Сильно быстрее.

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

Почему нельзя сделать быстрое мини-ядро для CSS-селекторов, которое обеспечит базовую функциональность для работы с DOM (ну, совсем базовую — просто выборку элементов, например)? И, самое главное, чтобы это работало не медленнее (в идеале, даже быстрее), чем нативные вызовы.

Привет.

Наверное, многие из вас пользовались стандартными javascript-виджетами, написанными как безвестными разработчиками, так и крепкими профессионалами, так и гуру. Есть великолепные коллекции виджетов, поставляемых в качестве плагинов к известным фреймворкам (вроде jQuery, Prototype JS, YUI), так и целые фреймворки, акцентирующие свое внимание на создании виджетов, вроде Ext JS или qooXdoo.

Но что, если вы не хотите использовать достаточно объемный фреймворк для создания простого диалогового окна, или хотите разобраться в том, как создаются такие виджеты, или даже разрабатываете собственный фреймворк?

Об этом и пойдет речь в сегодняшнем посте — как сделать простейшее диалоговое окно и alert средствами чистого javascript, без применения каких-либо фреймворков.

Привет.
Решил я познакомится с технологией canvas и написал ардкадную игрушку.

Использовал для старта руководство.

Иногда приходится искать файлы на всяких файлопомойках типа rapidshare. Так как единого поискового механизма не предлагается, слепил левою рукою такую штуковину–искалку. Её можно вставлять в страницы, при нажатии на линк «искать» выкидывается промпт, куда задаётся искомое понятие, по нажатию «поиск» открывается новое окно/таб с результатами поиска. Набросал две версии, для ие и фф. К тому ж вывешиваю список 1689 файлопомоек, которые можно вставлять в искалку. И ещё учитывайте, что гуглостринг ограничен по длине.

Для ФФ
a href="javascript:Qr=document.getSelection();if(!Qr){void(Qr=prompt('Find files ',''))};if(Qr)location.href='http://www.google.com/search?num=50&hl=en&safe=off&q='+escape(Qr)+'+%28rapidshare.+%7C+megaupload+%7C+любое другое название файлопомойки%29&btnG=Search'" target="_blank" rel="nofollow" >Find files</a

Для ИЕ
a href="javascript:Qr=document.selection.createRange().text;if(!Qr){void(Qr=prompt('Find files ',''))}if(Qr)location.href='http://www.google.com/search?hl=en&q='+escape(Qr)+'+%28rapidshare+%7C+megaupload+%7C+любое другое название файлопомойки%29&btnG=Google+Search'" target="_blank" onclick="Qr=prompt('Dateien bei Free File Hosters finden','');if(Qr)location.href='http://www.google.com/search?hl=en&q='+escape(Qr)+'+%28rapidshare+%7C+megaupload+%7C+любое другое название файлопомойки%29&btnG=Google+Search';return false" rel="nofollow" >Find files</a

Список 1689 файлопомоек

посмотреть, как работает, можно тут.

UPDFree file hosting services часто называются файлопомойками из–за несортированности складируемых файлов и неразборчивости сервисов в вопросах того, что там складируется. И вы и я знаем об этом, поэтому большая просьба не обижаться на это название и не обвинять меня в попытке оскорбления.

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