JavaScript *

Начну с того, что метод jQuery.each я всегда использую только для работы с jQuery object. В остальном — циклы for / while или свой аналог «each». Вроде это и логично, но в документации говорится о том, что вышеупомянутый метод можно использовать для любых коллекций.
Разрушим этот миф.

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

Синтаксис

Во время работы с JUST, который использует EJS-совместимый синтаксис, пришло понимание, что это не очень удобно. Хотелось упрощения, хотя бы, для условных операторов и циклов. Я начал развивать код в этом направлении, но вовремя остановился. Я сам очень плохо отношусь к подобным велосипедам в плане синтаксиса. Когда добавляешь подобный синтаксический сахар в свою разработку, это кажется очень крутым и удобным нововведением. Но разработчик, который видит его впервые, скорее выберет знакомое ему и понятное решение, чем будет разбираться в новом синтаксисе.

Логичным решением в данной ситуации стало использование CoffeeScript в качестве встраиваемого языка.

Вступление

Люди всегда стремились систематизировать музыку, разбивая её на жанры и поджанры. Основным методом такой систематизации был и остаётся «исторический» метод, который можно описать так:
Есть исполнитель K, который играет музыку похожую на жанр L, но явно в этот жанр не вписывающуюся. Сам исполнитель или муз. критик, лейбл придумывают для такой музыки новый под жанр, жанра L – LL. И через R лет жанр LL становится каноническим. Или не становится, в зависимости от результатов «проверки временем». Таким образом, все музыкальные жанры можно соединить в граф, в котором жанр L ближе к корню, а LL – к листьям.

Этот метод является историческим, так как поджанры всегда появлялись позже основных жанров. Т.е. этот способ иллюстрирует развитие музыки, её эволюцию. Но такой граф не совсем корректно иллюстрирует связи жанров друг с другом, с плоской музыкальной точки зрения. Т.е. из двух совершенно разных музыкальных направлений, разных эпох могут появиться поджанры которые будут настолько близки, что значительное число музыкантов будут в качестве своей “лейбы” указывать оба жанра. Но в “историческом” графе они вряд ли будут рядом.
К тому же из-за высокой степени субъективности и сложности исторического метода, не существует “единого дерева жанров”. Насколько я осведомлён, существуют лишь отдельные успешные попытки построить такой граф на уровне отдельных групп близких жанров.

Сегодня в корпоративном блоге Mozilla появилась запись одного из ключевых разработчиков Firefox Девида Андерсона (David Anderson) о том, что фонд заканчивает разработку нового движка для JavaScript под кодовым наименованием IonMonkey. Широкий круг пользователей сможет отметить повышение быстродействия браузера на страницах сложных веб-приложений уже с выходом Firefox 18, бета-версия которого будет выпущена 20 ноября.

Работа IonMonkey будет состоять из трёх фаз и выглядеть следующим образом: сначала будет выполняться трансляция в промежуточное представление (intermediate representation (IR)), к полученному результату будут применяться различные алгоритмы по оптимизации и уже после этого этот IR будет транслироваться непосредственно в машинный код.

Здравствуйте, я разработчик игр на Flash. Последнее время все больше стало появляться постов про флешокапец, и MustHave JavaScript (дальше JS). Вроде как за JS будущие, и за открытым вебом.
Я долго не рассматривал JS всерьез как платформу для разработки игр. Ведь это интерпретированный язык, и скорость JS оставляет желать лучшего. Но совсем недавно был портирован на JS мой любимый фреймворк для анимации TweenLite. Вместе с этим автор создал тестовый пример показывающий производительность актуальных JS фреймворков: здесь.

Мне стало очень интересно, так как TweenLite JS выдавал неплохие FPS. И тут я решил написать такой же пример для сравнения Flash и JS фреймворков.
Дальше мне стало интересно сравнить FPS этих примеров в разных браузерах, и на разных ОС.
Сам тест — это анимация передвижения, и изменения размеров картинок, при чем можно изменять их количество. Тестовый пример для Flash лежит здесь, исходники примера здесь.

Однажды, при разработке сложного приложения на JavaScript-е возникла непреодолимая проблема — большой массив в Internet Explorer (далее IE). Так как я изначально проверял работу в Chrome, то не замечал каких-либо проблем при использовании массивов. Скажу больше — вложенные массивы не вызывали чувства страха. Chrome легко справлялся с трудными задачами. Однако IE, в очень жёсткой форме, указал на все мои огрехи и недостатки кода, особенно на обработку Больших массивов.

Картинка стоит тысячи слов — мы же предлагаем взлянуть на скринкаст:



Засветились:

• LiveEdit — обновляет фрагменты страницы без перезагрузки, включая javascript
• ZenCoding — мгновенная генерация сложных конструкций из соответствующих CSS-селекторов
• AceJump — навигация по видимому участку кода

Разумеется мы умеем гораздо больше
Загрузить последнюю версию для вашей платформы

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

1. Контактная форма, в которой есть поле «телефон». Пользователь может добавить еще несколько дополнительных полей для телефонов, если возникнет желание.

2. Счет на оплату. Есть фиксированный набор полей, таких как «имя плательщика» и «номер счета». Кроме того, есть таблица с позициями. Каждая позиция состоит следующих полей: «наименование», «количество», «цена». Пользователь может добавлять произвольное количество дополнительных позиций.

Давайте рассмотрим работу с jqDynaForm на примере такого счета. Вот пример такой формы:

В прошлый раз мы попытались разобраться со следующими вещами:

• 1. Не смотря на расхожее мнение «всё в JS является объектами» — это не так, мы выяснили, что из 6 доступных программисту типов данных аж 5 является примитивами и лишь один представляет тип объектов.
• 2. Про объекты мы узнали, что это такая структура данных, которая содержит в себе пары «ключ-значение». Значением может быть любой из типов данных (и это будет свойство объекта) или функция (и это будет метод объекта).
• 3. А вот примитивы – это не объекты. Хотя с ними и можно работать как с объектом (и это вызывает заблуждение что примитив – это объект), но…
• 4. Переменные можно объявить как по простому (литерально) (var a = ‘str’), так и через функцию-конструктор (обёртка)(var a = new String(‘str’)). Во втором случае мы получим уже не примитив, а объект созданный конструктором String(). (что за магический оператор new и что такое функция-конструктор мы узнаем дальше).
• 5. Узнали, что именно за счёт создания обёртки над примитивом (new String(‘str’)) c ним можно работать как с объектом. Именно эту обёртку создаёт интерпретатор вокруг примитива, когда мы пытаемся работать с ним как с объектом, но после выполнения операции она разрушается (поэтому примитив никогда не сможет запомнить свойство, которое мы ему присвоим a.test = ‘test’- свойство test исчезнет с обёрткой).
• 6. Узнали, что у объектов есть метод toString() который возвращает строковое представление объекта (для типа number valueOf() – вернёт числовое значение).
• 7. Поняли, что при выполнении операций конкатенации или математических операциях примитивы могут переопределить свой тип в нужный. Для этого они используют функции-обёртки своих типов, но без оператора new (str = String(str)).(в чём разница и как это работает, поговорим дальше)
• 8. И наконец, узнали, что typeof берёт значения из жёстко зафиксированной таблицы (вот откуда ещё одно заблуждение, основанное на typeof null //object).

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

В проектах с небольшим фронтэндом бывает не всегда разумно использовать тяжелые фреймворки вроде backbone, ember или knockout. Тем не менее потребность использовать модели, наследование и качественное взаимодействие между ними остается. Предлагаю вашему вниманию фреймворк Neutrino, который делает все вышеперечисленное, при этом его размер не превышает 100 строк кода.

16-я версия браузера Firefox, релиз которой намечен на 9 октября, содержит серьёзное обновление движка JavaScript. Сборщик мусора перейдёт от стратегии «stop-the-world», когда на время уборки полностью замораживается работа скриптов, к инкрементальной стратегии, когда сборка мусора происходит в несколько этапов. Хотя в целом работа сборщика мусора будет отнимать немного больше времени, отзывчивость браузера существенно улучшится, так как элементы интерфейса, анимация и игры не будут больше подвисать на несколько сотен миллисекунд на время уборки.

Мы рады представить новую библиотеку, разработанную силами Google – Wicked Good XPath, реализацию спецификации XPath для DOM Level 3. Мы уверены, что на сегодня эта библиотека является самой быстрой из всех существующих.

Чтобы начать ее использовать, достаточно скачать файл wgxpath.install.js и включить его на вашей странице

CSS3-транзишены — чертовски полезная штука. По сравнению с javascript-анимацией они:

1. Обеспечивают более плавные переходы;
2. Потребляют меньше ресурсов;
3. Открывают новые возможности. Например, автоматическую обработку матричных преобразований (CSS-transforms);

Конечно, наш с вами любимый IE их не поддерживает даже в 9 версии.

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

delete testedObject[ i ].obj;

Но, повторюсь только в определенных условиях. Еще одно но, пока точно неизвестно это браузерный баг или особенность JS.
Гугл, ничего не сказал мне по этому поводу, Копания в спецификации ECMAScript, тоже ничего не дало, ибо ее трудно понимать в трезвом состоянии. Собственно это и стало поводом написания данной статьи.

Я решил написать цикл статей, под названием «Сложно о простом». Этот цикл будет посвящён языку JavaScript. Почему «сложно о простом»? Потому что всё, что я буду рассказывать я буду рассказывать учитывая особенности работы интерпретатора, начиная с типов данных. Всё это будет делаться для того, что бы потом можно было рассказать просто о сложном, например, о способах наследования в JavaScript и прочих патернах.

Крошечная (2 килобайта в минифицированном виде) JavaScript-библиотека Piecon генерирует круговую диаграмму на месте фавикона. API предельно прост и состоит из трёх методов объекта Piecon.

Во всех браузерах есть опция, позволяющая запретить приём cookies со сторонних сайтов (например, из iframe с отличным от текущего доменом). В некоторых браузерах (привет, Apple) эта функция включена по умолчанию, но часто пользователи самостоятельно её включают и благополучно об этом забывают, вследствие чего разработчик не может записать необходимые данные в cookies или localstorage. Например, при разработке приложений для ВКонтакте вы можете столкнуться с такой проблемой.

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

Будучи начинающим javascript разработчиком, я заинтересовался темой межплатформенной разработки мобильных приложений. В этой области, в настоящее время, балом правят Cordova (phonegap) www.phonegap.com, Appcelerator Titanium www.appcelerator.com, Mosync www.mosync.com.

Рано или поздно, после выпуска первых мини-приложений, основанных на этих системах, разработчику захочется создать что-нибудь Большое и Светлое, и хотелось бы, чтоб в этом новом приложении/сервисе были пользователи (c аватарами и проч.), push-notifications, user-generated-content и т.д… Но при этом, не хотелось бы тратить время и деньги на написание своей серверной инфраструктуры, а хотелось бы воспользоваться чем-нибудь недорогим, вплоть до бесплатного, и простым в освоении (и ещё чтоб «в облаке»!).

Как раз подобного рода тяжести и взяли на себя многочисленные Backend-as-a-Service (не путать с другими aaS). Я хочу кратко пробежаться по некоторым игрокам на этом рынке. Подчеркну, что меня в первую очередь интересовали те платформы, которые можно было бы легко и безопасно использовать с мобильным javascript (Phonegap/Titanium). Если платформа просто предоставляет REST API, этого мало, т.к. вопрос безопасности требует наличия некоторого специального ограничительного функционала: AccessControlList/permissions/masterKeys/etc. И вообще, желательно отдельный javascript SDK.

(Так как это «поверхностный обзор», я не буду подробно писать кому и зачем нужен BaaS и почему вместо всего этого не использовать старый-добрый PHP/MySQL на VPS или новый-добрый node.js в облаке)

Я начал поиск с www.programmableweb.com/apis/directory/1?apicat=Backend там перечислено почти 40 платформ, просмотрев их, я оставил для обзора те, что легко можно использовать с javascript:

Для отслеживания изменений, в объекте ViewModel, может помочь dirtyFlag, входящий в состав библиотеки KoLite, которая в свою очередь расширяет возможности knockout, добавляя новые возможности:

• dirtyFlag — предназначен для отслеживания изменений как в отдельных, так и в совокупности свойств ViewModel
• asyncCommand — предназначается для выполнения асинхронных команд
• activity — предназначена для индикации активности. Используется совместно с asyncCommand