JavaScript *

Сегодня мы будем тестировать 2 блока кода, выполняющие следующую операцию:
Дается массив, необходимо выбрать все элементы, степень 2 которых больше 5.

В синем углу Вариант А: Низкоуровневый код — старый и страшный (поддающийся частичной оптимизации)

1.    for (i = 0, res = []; i < c; i++) {
2.        t = a[i];
3.        if (t >= 2.236067) {
4.            continue;
5.        } else {
6.            res.push(t * t);
7.        }
8.    }

В красном углу Вариант Б: Высокоуровневый код — молодой и красивый (не поддающийся частичной оптимизации)

1. a.map(function (t) { return t * t}).filter(function (t) { return t > 5});

Битвы будут происходить на 3 аренах.
1. AO args — Параметры объекта активации функции.
2. AO — Локальные переменные объекта активации функции.
3. Global — Глобальные переменные.

Сегодня состоялся релиз Impact JS, дважаскриптовый движок, который в взаимодействии с html5 canvas позволит вам создавать игры. Пример такой игры — Biolab Disaster

Немного огорчает стоимость лицензии — 99$. Но уверен в скором будущем появятся бесплатные альтернативы.

Видео по созданию игры на Impact.

Небольшой обзор ImpactJS

Всем привет! Вторая часть про миниатюрный javascript фреймворк Atom (бывший Nano).
Теперь из Core убрано всё лишнее, вес — 1 кб.
Как и прежде — полный отказ от устаревших браузеров.
Dom, Class, Ajax и т.п. — подключаются как плагины.
Поменялся адрес репозитария: github.com/theshock/atomjs
Под катом — расскажу, что нового и опишу, как создавать плагины

На прошлой неделе вышел очередной релиз QooxDoo. Основная задача фреймворка — предоставить возможность проектировать многофункциональные кросс-браузерные веб-приложения. При этом, как сказано на qooxdoo.org, знания HTML, CSS, DOM не требуются.
Каких-то принципиальных новшеств в новом релизе лично я для себя не отметил. Хотя, безусловно, есть некоторые полезные плюшки, такие как Tri-state CheckBox.
В целом библиотека очень функциональна, хорошо продумана, реализована и задокументирована. Для тех кто впервые слышит о ней — отмечу несколько моментов.

Привет, читатель. Есть много прекрасных и мощных JavaScript-фреймворков. JQuery, MooTools, ExtJS, и множество других. Они кроссбраузерны и громадны. И пользоваться ими — одно удовольствие.

Но иногда, бывает, хочется написать какой-нибудь небольшой скриптик на 5 килобайт и как-то совесть мучает подключать JQuery, который весит в сжатом виде 75 килобайт. И каждый раз начинаешь писать свой мини-фреймворк:

var dom = {
	id  : function (id)  { return document.getElementById(id); },
	tag : function (tag) { return document.getElementsByTagName(tag); },
};

Вроде бы, больше для начала и не надо. А потом вспоминаешь про createElement, легкий способ присвоить CSS, наследование, расширение прототип. И в общем каждый раз пишешь свой велосипед.
В этот раз я решил написать миниатюрный фреймворк, который можно было бы без зазрений совести подключать даже к самым маленьким проектам. В сжатом виде он весит всего 4 килобайта (в 20 раз меньше JQuery).
И в нём есть еще одно преимущество по сравнению со всеми современными фреймворками — полный отказ от устаревших браузеров, за счёт чего в эти 4 килобайта вместилася половина JQuery.

Итак, приветствуйте, JavaScript-фреймворк Nano

Читайте актуальную вторую часть!

Сегодня мы представляем вам Crankshaft (коленчатый вал — прим. пер.), новую инфраструктуру компиляции для V8, JavaScript движка Google Chrome. Используя агрессивную оптимизацию, Crankshaft значительно повышает производительность ресурсоёмких JavaScript приложений — часто более чем в два раза! Это делает интернет-страницы и приложения, использующие сложный код, более отзывчивыми и быстрыми для пользователей. Сравним производительность Chrome с Crankshaft и без него на стандартном наборе тестов V8:

Наткнулся на интересный документ в Твиттере.

JavaScript Performance Best Practices

В заголовке указана категория WRT (Nokia Web Runtime or Widget for S60), то есть конкретная Нокиевская платформа, но, думаю, многим интересно будет почитать, возможно найдёте для себя что-то новое. Есть действительно полезные советы, но есть и вредные, особенно в свете современной разработки _под все браузеры_.
Сначала думал оформить как топик-ссылку, но под катом я обращу внимание на некоторые проблемы этой статьи. Статью прочитать стоит но ни в коем случае не относитесь к ней, как к истине в последней инстанции.

Создатели библиотеки хорошо знакомы с готовыми популярными решениями (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, ибо дело это не совсем простое, на первый взгляд.