JavaScript *

Хочу поделиться набором ссылок на нексолько полезных, интересных и, возможно, не самых известных материалов по JavaScript. Из них вы узнаете немного больше об истории появления языка, о его настоящем, тонкостях реализации в различных браузерах, и о будущем развития стандарта ECMAScript. О различных способах наследования в том числе об эмуляции «классического» ООП, множественном наследовании и миксинах. О функциональном стиле программирования в JavaScript: чистые функции, map, reduce, частичное применение и композиции функций. И, наконец, что если бы Хемингуэй писал на JavaScript?

Привет всем!



Сразу ссылка для нетерпеливых: http://bit.ly/habrauser

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

Под катом же немного подробностей для интересующихся.

От переводчика: Представляю вашему вниманию перевод многообещающего стандарта Веб-компонентов от Google, который может стать трендом в ближайшие несколько лет. В данный момент, знание этого стандарта не несёт практического применения, поэтому, если вы не фанат всего нового и интересного, вам возможно будет скучно читать данный перевод.
Перевод выложен на github, поэтому, если вы хотите помочь с переводом или исправить ошибку сделайте pull request, ну или пишите в личку.

Статус: Эксперементальный драфт

Авторы:

• Dominic Cooney, Google, dominicc@google.com
  
• Dimitri Glazkov, Google, dglazkov@chromium.org
  

Введение

Компонентная модель для Web'а (или Web Components) состоит из четырёх модулей, которые, будучи использованными вместе, позволят разработчикам web-приложений создавать виджеты с богатыми визуальными возможностями, легкие в разработке и повторном использовании, что в данный момент невозможно с использованием только CSS и JS-библиотек.

Статья посвящена Java девелоперам, которых жизнь заставила или пока только заставляет двигаться вперед, к светлому agile будущему. Препологается, что читатель знаком с Java, Javascript и слышал про JSR 223.

Постепенно концепция стандарта HTML5 становиться реальностью. Браузеры начинают поддерживать новые возможности, которых так не хватало. Но с новыми возможностями появляются и новые проблемы.
В данной статье рассматривается Application Cache API — совокупность функций, обеспечивающих продвинутое кэширование ресурсов web-приложения, и с помощью которых можно просматривать загруженные ранее сайты без подключения к сети Интернет. Особое внимание я уделил практическому использованию и проблемам Application Cache.

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

Основная идея

В процессе изучения способов многопоточной обработки изображений в браузере многие сталкиваются с проблемой отображения результата Web Workers в canvas. В основном это происходит из-за того, что в web worker нельзя передать элементы DOM. Решением может быть использование getImageData(). Данная статья описывает конкретный пример использования данной технологии на примере обработки фильтра blur в отдельном потоке.

Для этого нам понадобится 2 файла: index.html и filter_worker.js

Callback-функции чрезвычайно важны в языке Javascript. Они есть практически повсюду. Но, несмотря на имеющийся опыт программирования на C/Java, с ними у меня возникли трудности (как и с самой идеей асинхронного программирования), и я решил в этом разобраться. Странно, но я не смог найти в интернете хороших вводных статей о callback-функциях — в основном попадались отрывки документации по функциям call() и apply() или короткие кусочки кода, демонстрирующие их использование, и вот, набив шишек в поисках истины, я решил написать введение в callback-функции самостоятельно.

Начну издалека. С браузеров. Новинками браузеростроения интересуюсь не так уж и часто, но вот однажды, со скуки, решил посмотреть, что javascript грядущий нам готовит и что с этого нам могут предложить современные браузеры. Речь идет, само собой, не о ECMAScript 5, а уже о ECMAScript 6 ECMAScript Harmony. Через пару минут серфинга я наткнулся на такую вот сводную табличку. Не самая актуальная — Chrome, например, довольно давно поддерживает Proxy. Само собой, разброд оказался еще тот. В браузере это использовать пока не реально.
В браузере. А на сервере? На сервере нет необходимости поддерживать зоопарк различных браузеров. Node.js использует V8 — тот же javascript движок, что и Chrome, соответственно, он должен поддерживать те же новые возможности языка.

Начну с того, что метод 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 строк кода.