JavaScript *

Создатели библиотеки хорошо знакомы с готовыми популярными решениями (jQuery, MooTools), но взялись написать свой собственный фреймворк, который не будет перегружен кодом поддержки десктопных браузеров и сосредоточились на главных нуждах разработки под мобильные приложения.

Уже сейчас XUI поддерживает такие мобильные браузеры, как WebKit, Fennec и Opera. В ближайшем будущем поддержка IE Mobile и BlackBerry.

Сайт библиотеки →

Есть javascript код:

1. var A = function () {};
2. A.prototype.b = 100;
3. var a = new A();
4. A.prototype.c = 101;
5. a.c = -100;
6. A.prototype = {};
7. A.prototype.b = 536;
8. /* 1 */ console.log(a.__proto__.constructor.prototype.b === 536);
9. var b = new A();
10. /* 2 */ console.log(a.__proto__.__proto__.constructor === a.__proto__.constructor.prototype.constructor);
11. /* 3 */ console.log(b instanceof A);
12. /* 4 */ console.log(!(a instanceof Object));

Вопрос. Что возвратят выражения 1-4 и почему?

Затрудняетесь ответить?
Тогда вам стоит пройти под кат ;-) (Далее 600 Кб больших изображений)

В последнее время стали очень популярны тесты производительности JavaScript движков, но в основном они касаются Client Side JavaScript. Меня заинтересовал вопрос: как обстоят дела с Server Side? Но тестировать только Google V8 и SpiderMonkey было бы неинтересно. Ясно, что результаты будут схожи с Client Side — движки-то те же. Поэтому нужно было добавить к тестам что-то, что недоступно в браузере, однако достаточно распространено, а также постараться использовать специфичные для серверных задач тесты. Этим недостающим объектом для тестов виделся компилятор JScript из .Net Framework. Однако предварительные результаты тестов стали сюрпризом для меня, и я решил добавить четвертого игрока из той же команды.

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

Задача

Допустим вы хотите выполнить два или более AJAX запроса на сервер и вызвать функцию после того, как все они будут закончены.

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

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

Собственно, этим и занимается мой небольшой класс WaitSync =)

WaitSync.js

Пользоваться элементарно просто:

1. Создаем объект типа WaitSync, передав в конструктор callback функцию, которая будет вызвана после того, как отработают нужные задачи.

	var vulture = new WaitSync(function () {
		console.debug('Start eating: ', arguments);
	});

2. Вместо простого

	$.getJSON(
		'savannah/get_prey', 
		function (data) {
			console.log('... prey found: ' + data);
		}
	);
	
	$.getJSON(
		'savannah/get_other_predators', 
		function () {
			console.log('... predators are done eating');
		}
	);

«заворачиваем» задачи в метод .wrap

	$.getJSON(
		'savannah/get_prey', 
		vulture.wrap( 
			function (data) {
				console.log('... prey found: ' + data);
			}
		)
	);
	
	$.getJSON(
		'savannah/get_other_predators', 
		vulture.wrap(
			function () {
				console.log('... predators are done eating');
			}
		)
	);

3. Все =) Как только будут выполнены оба AJAX запроса, стервятник начнет есть.

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

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

var process = processFsAndDb.after('fs', 'db');

asyncFsAccess( file, process.fs);
asyncDbAccess(query, process.db);

Javascript — очень изящный язык с кучей интересных возможностей. Большинство из этих возможностей скрыты одним неприятным фактором — Internet Explorer'ом и другим дерьмом, с которым нам приходится работать. Тем не менее, с приходом мобильных телефонов с актуальными браузерами и серверного JavaScript с нормальными движками эти возможности уже можно и нужно использовать прям сейчас. Но по привычке, даже при программировании для node.js мы стараемся писать так, чтобы оно работало в IE6+.

В этой статье я расскажу про интересный и не секретный способ указывать изящные геттеры и сеттеры и немножко покопаемся в исходниках Mootools. Частично это информация взята из статьи John Resig, частично лично мой опыт и эксперименты.

function Foo(bar){
    this._bar = bar;
}

Foo.prototype = {
    get bar () {
        return this._bar;
    },
    set bar (bar) {
        this._bar = bar;
    }
};

Умла́ут или реже умля́ут (нем. Umlaut) — диакритический знак, указывающий на фонетическое явление умлаута гласных звуков в немецком и некоторых других языках. Обычно изображается в виде двух точек над буквой, в готическом же шрифте традиционно (за исключением последних десятилетий) выглядел как маленькая надстрочная буква e. В немецком присутствует в таких буквах, как Ää, Öö и Üü (называемых «A-умляут», «O-умляут» и «U-умляут» соответственно).
Wikipedia

Как вы замеряете производительность javascript кода?
У меня это происходило так:

1. создаю файл index.html;
2. копирую откуда-нибудь шаблон HTML;
3. добаляю тэг script, в котором будет жить тестируемый код;
4. если нужно замерить работу с массивами, то обязательно создаю или беру готовый генератор случайных массивов.

Эта статья предназначена для тех, кого бесят мильён левых служб и драйверов, которые ставят любые виртуалки. Тем, кто будут ставить доп. пакеты Node.js
Все остальные могут скачать скомпилированный Node.js node-js.prcn.co.cc
Или же установить Node.js из-под виртуалки nodejs.ru/25

Прошу под кат

QooxDoo — достаточно хорошо проработанная JS-библиотека для разработки RIA (Rich Internet Applications). Углубляться в подробности библиотеки и описывать, откуда растут ноги проблемы не буду. Кто столкнулся с проблемой — тот поймет что к чему.
И так. Проблема заключается в том, что source-версия приложения, в том виде в котором ее собирает компилятор, не запускается с вебсервера (эмулирует denwer) а только как локальный файл.

CoffeeScript — это новый язык/надстройка/сахарная пудра над обычным JavaScript. Если кто ещё не слышал о нём, то можете прочитать эту отличную вводную статью.

По своей магической природе, сам компилятор для coffee-скриптов написан на coffee-скрипте. Но на наше счастье, пакет исходников CoffeeScript уже содержит готовые к употреблению js-скрипты. И сейчас я расскажу вам как их использовать в windows с помощью Node.js, Cygwin и Nant, ибо дело это не совсем простое, на первый взгляд.

Brendan Eich (создатель языка JavaScript) между делом пишет о том, как язык создавался, и почему он такой, какой есть.

JS был обязан «выглядеть как Java», только поменьше, быть эдаким младшим братом-тупицей для Java. Кроме того, он должен был быть написан за 10 дней, а иначе мы бы имели что-то похуже JS.
…
что-то вроде PHP, только еще хуже. Его босс Netcsape быстро «зарубил» (в июле 1995, если мне не изменяет память; я сдлелал JS в начале/середине мая), т.к. это был уже третий язык после Java и JS. Было и так трудно обосновать то, что у нас 2 новых языка программирования для web.
…

В то время мы должны были двигаться очень быстро, т.к. знали, что Microsoft идет за нами.
…

Считайте, что JavaScript (пожалуйста, только не «JScript») спас вас от VBScript.
…

10 дней на то, чтобы сделать лексер, парсер, компилятор в байткод (bytecode emitter), интерпретатор, встроенные классы и декомпилятор. Помощь была только с файлом jsdate.c — от Ken Smith из Netscape (который, по нашему излишне оптимистичному соглашению, склонировал java.util.Date — Y2K баги и т.д. Гослинг...).

Простите, времени было мало для того, чтобы сделать правильную оптимизацию хвостовой рекурсии. 10 дней почти без сна, чтобы сделать JS с чистого листа, заставить его «выглядеть как Java» (я сделал, чтобы он выглядел как C), и тайком протащить туда его спасительные фишки: first class functions (замыкания сделал позже, но они были частью плана сразу) и прототипы (примерно как в языке Self).

I'll do better in the next life.

Просматривая обзоры инди-игрушек наткнулся на весьма интересный проект — Biolab Disaster (да поможет ему НЛО выдержать хабраэффект) — браузерный платформер на чистых HTML5 & JavaScript, навеивающий воспоминания о тех временах, когда каждую игру делали с душой.
Коротенькая и незатейливая игрушка крутится необычайно быстро и красиво, оставляя за собой приятное впечатление, активированные чекпоинты и маленькие кусочки врагов :)
Выполнена она на движке автора этой же игры, Impact HTML5 Game Engine, в качестве демонстрации его возможностей. Движок на данный момент все еще находится в состоянии разработки, но предлагает уведомить нас электронным письмом по официальному выходу в свет.
За новостями можно так же следить в блоге автора.

На закуску — видео с геймплеем, некоторыми моментами создания игры и редактором уровней — с комментариями автора.

(Благодаря видео можно узнать ссылку на официально еще не опубликованный, но вполне рабочий level editor)

Флеш становится все менее значимым, что не может не радовать.
Приятного пятничного ковыряния в коде ^_^

Хочу Вам рассказать о штуке, которую я изобрел сегодня, чтобы ускорить процесс загрузки сайтов. Все вы знаете, что <script src="..."></script> задерживает отрисовку страницы, пока не загрузится этот скрипт. Если их десятки — это может сереьезно замедлить работу сайта — в результате пользователь 20 секунд пялится на пустую (или недорисованную) страницу из-за какого-нибудь тупящего социального виджета (умножить на десяток этих виджетов).

Не правда ли было бы круто, если бы можно было сказать <script extsrc="..."></script> ("extsrc" = "грузи потом"), чтобы скрипты загружались после того как страница отрисована?

Все бы хорошо, но есть document.write… Сегодня я наконец решил его проблему — представляю extsrc.js — скрипт, который запустит все скрипты после отрисовки страницы (даже если они содержат document.write — и правильно отрисуется все).

Результат? Супер-быстрая загрузка страниц, даже если там море всяких внешних скриптов.

Использование:

Заменяем <script src="..."> на <script extsrc="...">.

Итого получается:

<script src="http://whiteposts.com/extsrc_js/extsrc.js"></script>
<script extsrc="..."></script>

В этой заметке расскажу о своем опыте юнит-тестирования JS-кода, опыте использования среды выполнения тестов js-test-driver, ее возможности code coverage и скручивании ежа с ужом, а именно данных о code coverage от js-test-driver и генератора отчетов о покрытии PHP_CodeCоverage. Расскажу и покажу как получить вот такие отчеты о покрытии кода...

Навигация по странице

Всё чаще и чаще в web появляются сайты, использующие навигацию, написанную на JavaScript. Типичный случай использования javascript для навигации: страница с меню и блоком контента, куда через AJAX подгружается содержимое:



Пользователь кликает по пункту, JavaScript грузит из сети содержимое, вставляет в блок контента, пользователь доволен: страница без перезагрузки показывает требуемое и траффика потребовалось меньше за счёт того, что не потребовалось грузить все эти HEAD, BODY, STYLE и прочие элементы.

Но вот проблема: URL страницы. Если на old scool сайтах на каждый пункт меню показывается новая HTML страница, и у пользователя есть вменяемый URI, который он может скопировать из адресной строки бразуера, послать другу или положить в закладки, то в случае AJAX интерфейсов в URI странице зачастую нет никаких ссылок на текущий контент документа.

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

Не с секрет, что для решения этой проблемы многие программисты кодируют ссылку на текущее просматриваемое содержимое в якорь (anchor) URI документа. К примеру, на сайте jqapi.com (скриншот которого приведён вначале топика) при выборе того или иного пункта меню якорь страницы меняется на #p={contentId}.

Сегодня существует множество браузеров и все они как-то борются друг с другом ради рынка. Основные игроки: Internet Explorer, Mozilla Firefox, Google Chrome, Safari. И на сегодня они друг у друга копируют внешний вид (все пытаются походить на Google Chrome) и все поголовно хвалятся кто из них лучше соответствует HTML 5, правда главное, что они в нем нахваливают — это тэг canvas.

Вот и получается, что все они практически одинаковы, но как-то ведь им надо выделяться, чтобы быть лучшими? А здесь есть еще кое-что, что они всегда нахваливают — скорость работы. Лет 10 назад под скоростью работы браузера подразумевалась скорость загрузки страницы (например, часть армии поклонников Opera как раз из за этой возможности). А вообще на сегодня важна работа Javascript, реализацией которого кичится каждый браузер. Они даже движкам Javascript дают свои имена и это становится их очередной торговой маркой. Вот именно та самая скорость работы Javascript и является сегодня основным достоинством того или другого браузера.

Подведены итоги конкурса скриптов размером 1024 байт или меньше. Ниже список победителей.

1. Legend Of The Bouncing Beholder (автор: @marijnjh)
2. Миниатюрные шахматы (Oscar Toledo G.)
3. Тетрис со звуком (@sjoerd_visscher)
4. WOLF1K и буквы в цветах радуги (@p01)
5. Бинарные часы (tweetable) (@alexeym)
6. Mother fucking lasers (@evilhackerdude)
7. Схема графического движка (Lars Ronnback)
8. Многопользовательский настольный теннис (@feiss)
9. Генератор кода по азбуке Морзе (@chrissmoak)
10. Пульсирующие 3D-провода (@unconed)

Сайт с демками пока лежит, но некоторые из них можно найти на сайтах авторов.