В этой статье я хочу рассказать об инструменте Autopolyfiller, который помогает вам использовать последние функции ECMAScript и при этом не думать об подключаемых полифиллах.

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

Есть целый ряд способов исправить эту ситуацию:

lodash и underscore

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

_.chain([1, 2, 3, 4])
.map(function (item) {
    return item * item;
})
.filter(function (item) {
    return item < 9;
})
.value();

На момент написания этой статьи в JavaScript еще не существовало официальной модульной системы и все эмулировали модули как могли.

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

Вот в JavaScript своя атмосфера — в языке нет официальных модулей, более того все файлы лежат удаленно, один поток приложения. Приходится постоянно решать какие-то странные проблемы с загрузкой, хитро паковать модули в один файлы, чтобы ускорить время загрузки. Бывает, что нужно воевать с двойными стандартами, адаптировать модули другого формата.

Дело в том, что раньше не думали, что на JavaScript можно делать огромные проекты, а не просто «пропатчить DOM», поэтому о модулях не думали. Да и вообще не думали о будущем. И тут Внезапно будущее нагрянуло! Все вроде-бы уже есть, а модули в JavaScript, мягко говоря, запаздывают. Поэтому разработчикам приходится крутиться и выдумывать какие-то эмуляторы модульности.

Думаю многие из вас читали прекрасную статью Addy Osmani Writing Modular JavaScript With AMD, CommonJS & ES Harmony, которая стала одной из глав его книги Learning JavaScript Design Patterns в этой статье рассказывается про «современные» JavaScript модули или же читали достаточно старую статью JavaScript Module Pattern: In-Depth 2010 года про «старые» модули.

Я не буду переводить эти статьи и не буду делать из них солянку. В своей статья я хочу рассказать о моем модульном пути. О том как я проделал путь от «старых» модулей к «новым» и что использую сейчас и почему.

С появлением мобильного веба наш интернет стал снова плохим, а устройства медленными. 3G, 4G, Wi-Fi… — они, конечно, где-то есть, но когда очень надо, то как правило скорость падает до околомодемной и получается, что наши мобильный устройства «каменного века» попадают в условия современного объема информации. Даже в центре города (правда на 15-м этаже) значок мобильного интернета может показывать волшебную букву Е, намекающую о том, что уж лучше не тратить нервы и потерпеть. Лучше уж использовать нативную версию какого-то веб-сервиса, чем каждый раз ждать, загружать по мегабайту, чтобы отправить короткое сообщение. Нативную версию веб-сервиса... Понятное дело маркетинг, гонка приложений. Однако, же пользователи выбирают нативные веб-приложения, которые работают быстрее, не качают кучу ресурсов, хотя им приходится периодически его обновлять.

Эта статья о том какими путями можно оптимизировать загрузку и инициализацию JavaScript.

Dart это новый класс-ориентированный язык для создания структурированных веб-приложений. Он разрабатывается, чтобы быть простым, эффективным и масштабируемым. Dart соединяет в себе новые мощные возможности со знакомыми языковыми конструкциями в один понятный и читаемый синтаксис.

Основные возможности

Классы

Классы и интерфейсы представляют из себя простой и понятный механизм для создания всевозможных АПИ. Эти конструкции добавляют инкапсуляцию и повторное использование методов и данных.

Опциональные типы

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

Библиотеки

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

Инструменты

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

Около 2-х месяцев назад я и TheShock собирали вопросы по JavaScript в теме FAQ по JavaScript: задавайте вопросы. Первая часть, те вопросы, которые достались мне, появилась буквально через несколько дней JavaScript F.A.Q: Часть 1, а вот вторая часть все не выходит и не выходит. TheShock сейчас переезжает в другую страну и поэтому ему не до ответов. Он попросил меня ответить на его часть. Итак вторая часть ответов — те вопросы, которые достались тоже мне.

Более месяца назад в статье FAQ по JavaScript: задавайте вопросы был задан вопрос «Подскажите примеры хорошего подхода организации JS кода к сайту на достаточно высоком уровне. Как можно узнать подробнее практики реализации например gmail?».

Пришло время ответить на данный вопрос. Я немного затянул т.к. хотел рассказать доклад на одноименную тему на Я.Субботнике. Доклад был очень коротким многие важные моменты пришлось выкинуть. Статья — более-менее полная версия.

Эта статья о том, как сделать крупное веб-приложение расширяемым и поддерживаемым: архитектура, подходы, правила.

До появления HTML5 единственное, что мы не могли контролировать и управлять (без перезагрузки контента или хаков с location.hash) — это история одного таба. С появлением HTML5 history API все изменилось — теперь мы можем гулять по истории (раньше тоже могли), добавлять элементы в историю, реагировать на переходы по истории и другие полезности. В этой статье мы рассмотрим HTML5 History API и напишем простой пример, иллюстрирующий его возможности.

Основные понятия и синтаксис

History API опирается на один DOM интерфейс — объект History. Каждый таб имеет уникальный объект History, который находится в window.history. History имеет несколько методов, событий и свойств, которыми мы можем управлять из JavaScript. Каждая страница таба(Document object) представляет собой объект коллекции History. Каждый элемент истории состоит из URL и/или объекта состояния (state object), может иметь заголовок (title), Document object, данные форм, позиция скролла и другую информацию, связанную со страницей.

Основные методы объекта History:

1. window.history.length: Количество записей в текущей сессии истории
2. window.history.state: Возвращает текущий объект истории
3. window.history.go(n): Метод, позволяющий гулять по истории. В качестве аргумента передается смещение, относительно текущей позиции. Если передан 0, то будет обновлена текущая страница. Если индекс выходит за пределы истории, то ничего не произойдет.
4. window.history.back(): Метод, идентичный вызову go(-1)
5. window.history.forward(): Метод, идентичный вызову go(1)
6. window.history.pushState(data, title [, url]): Добавляет элемент истории.
7. window.history.replaceState(data, title [, url]): Обновляет текущий элемент истории

Обработка элементов коллекции/массива обычная и частая операция. В JavaScript есть несколько способов обхода коллекции начиная с простого for(;;) и for a in b

var divs = document.querySelectorAll('div');
for (var i = 0, c = divs.length; i < c; i++) {
    console.log(divs[i].innerHTML);
}

var obj = {a: 1, b: 2, c: 3};
for (var i in obj) {
    console.log(i, obj[i]);
}

У объекта Array есть методы обхода всех элементов map(), filter()

var numbers = [1, 2, 3, 4, 5];
var doubled = numbers.map(function (item) {
    return item * 2;
});
console.log(doubled);

В Firefox есть "заполнитель массива" (Array comprehensions)

var numbers = [1, 2, 3, 4];
var doubled = [i * 2 for each (i in numbers)];
console.log(doubled); // [2, 4, 6, 8]

Итераторы и Генераторы появились в JavaScript 1.7 (по версии Mozilla) они есть пока в Firefox 2+ (в статье будет упомянут способ как их можно «эмулировать» почти во всех браузерах с костылем) Итераторы и Генераторы вносят механизм, позволяющий управлять поведением for in и инкапсулировать процесс получения следующего элемента в списке объектов.

Часто для обхода и обработки элементов массива мы пишем большие конструкции, часто копипастим их части. Задача Генераторов и Итераторов усовершенствовать этот процесс, добавив синтаксический сахар.

Одним из незамеченных героев вселенной HTML5 является XMLHttpRequest 2. Строго говоря XHR2 не является частью HTML5 и не является самостоятельным объектом. XHR2 это тот же XMLHttpRequest, но с некоторыми изменениями. XHR2 является неотъемлемой частью сложных веб-приложений, поэтому ему стоит уделить большее внимание.

Наш старый друг XMLHttpRequest сильно изменился, но не многие знают о его изменениях. XMLHttpRequest Level 2 включает в себя новые возможности, которые положат конец нашим безумным хакам и пляскам с бубном вокруг XMLHttpRequest: кросс-доменные запросы, процесс загрузки файлов, загрузка и отправка двоичных данных. Эти возможности позволяют AJAX уверенно работать без каких-либо хаков с новейшими технологиями HTML5: File System API, Web Audio API, и WebGL.

В этой статье будут освещены новые возможности XMLHttpRequest, особенно те, которые можно использовать при работе с файлами.

Буквально недавно стало известно, что Firefox 6 получит SSE (уже есть в Opera 10.6+, Chrome, WebKit 5+, iOS Safari 4+, Opera Mobile 10+) так, что поддержка более половины всех браузеров (охват аудитории пользователей) уже не за горами. Настало время присмотреться к этой технологии. SSE предложил Ian Hickson более 7 лет назад, но только год назад она стала появляться в браузерах. У нас же есть WebSockets зачем нам ещё один какой-то протокол?! Но во всем есть свои плюсы и минусы, давайте посмотрим чем же SSE может быть полезен.

Идея SSE проста — клиент подписывается на события сервера и как только происходит событие — клиент сразу же получает уведомление и некоторые данные, связанные с этим событием. Чтобы понять полезность протокола SSE необходимо сравнить его с привычными методами получения событий, вкратце объясню их суть: