JavaScript *

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

Итак, условия задачи:

1. Интерфейс должен быть максимально приближен к интерфейсу от Google (т.к. до этого использовали его)
2. Нормальная реализация RFC 2445, его части касательно RRULE (паттернов повторения)
3. Быстрая скорость просчета дат событий (в данном случае рейсов) и их рендер в браузере
4. Максимальное использование существующих библиотек для уменьшения потраченного времени .

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

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

Данная статья была написана 21 января 2014 участником проекта HTML5Rocks, Алексом Данило. Хочу отметить, что это мой первый перевод на Хабре, поэтому к минусам я готов, к критике еще больше. По всем проблемам и недочетам старайтесь писать мне лично, я буду оперативно исправлять. Оригинал на английском.

Высокая производительность веб-приложений является ключевым моментом для конечного пользователя. Так как веб-приложения становятся всё более и более сложными, понимание управления производительностью является убедительным навыком программиста. За последние пару лет появилось множество новых API в браузере, позволяющих следить за производительностью сети, временем загрузки и т.д. но ни одно из них не позволяет достаточно гибко и детально определить, что же именно “тормозит” ваше приложение. Для этого и есть User Timing API, которое предоставляет механизм для вашего приложения, позволяющий определить, на что и когда расходуется время.

Друзья, просто небольшой опрос, чтобы понять — имеет ли смысл рассказывать об этой теме, и на каком уровне рассказывать.
Если у вас есть опыт использования Веб Компонентов или только Пользовательских Элементов — пожалуйста, расскажите об этом в комментариях.
Буду очень благодарен ответам.

В паттерне, объект создается в конструкторе, а его методы объявляются в прототипе.

Данный паттерн используется во фреймворках, таких как Google Closure Library. Нативные объекты JavaScript также используют данный паттернт.

Объявление Pseudo-class

Термит Pseudo-class выбран потому, что в JavaScript нет как таковых классов, как в других языка как C, Java, PHP и др., но данный паттерн близок к определению класса.

Это перевод статьи Alex Danilo о User Timing API, опубликованной 21 января 2014.

Высокая производительность веб-приложений является решающей для достижения хорошего user experience. В то время, как веб-приложения становятся все более сложными, понимание влияния производительности жизненно небходимо для создания конкурентноспособного user experience. За последние несколько лет в браузерах появились различные API, позволяющие анализировать производительность сети, время загрузки и т.д., но они не предоставляют необходимую информацию с достаточной гибкостью для поиска проблем, которые замедляют приложение. Использование User Timing API предоставляет механизм, позволяющий определить какая часть вашего приложения является наиболее медленной. В этой статье будет показана работа с User Timing API и примеры его использования.

С октября 2009 года я занимаюсь разработкой приложения для поиска и прослушивания музыки. Я стремлюсь организовать возможность быстрого взаимодействия пользователя с интерфейсом, и в качестве одного из средств ускорения взаимодействия использую различные способы для быстрой отрисовки страниц.

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

• Использование CSS и переключение классов вместо перестроения DOM дерева
• Повсемнестное кеширование выборок элементов ($('div.active_part span.highlighter')), атомарные операции по изменению (вместо всеобщей перерисовки, вместо переделывания больших участков DOM дерева)
• Минимизации чтений DOM во время записи изменений состояний
• Кеширование размеров и расположения элементов (это спасает от излишнего вычисления при считывании этих значений при наличии других изменений: чтение во время изменения множества частей дерева крайне негативно сказывается на производительности)
• Аккуратное, не затягивающееся накопление изменений, необходимых произвести в DOM
• Прикрепление частей изменяющихся коллекций единовременно (когда, например, в середину списка вставляется 3 новых элемента; createDocumentFragment) в конкретное место (after, before) вместо открепления всей коллекции от DOM и повторного прикрепления (и вместо того, чтобы перерисовывать весь список)
• Прогрессивный асинхронный рендеринг: картина прорисовывается сразу с небольшим количеством деталей, затем деталей появляется всё больше
• Клонирование нодов (как часть шаблонизации)
• Кеширование и использование кеша результатов парсинга DOM шаблонов

изображения из части с заголовком «Прикрепление частей изменяющихся коллекций единовременно...»

Я постоянно слышу людей, ноющих об асинхронных коллбэках в JavaScript. Держать в голове порядок исполнения в этом языке немного трудно (это тот случай, который называют «Callback Hell» или «The Pyramid of Doom»), если до этого ты имел дело с синхронным программированием. Моим обычным ответом было «тебе придется как-то с этим обходиться». В конце концов, ожидаем ли мы, что все языки программирования будут выглядеть и ощущаться одинаково? Конечно нет.

Все поменял недавний обзор черновика ECMAScript 6, в котором описываются генераторы — возможность языка, которая целиком изменит наш способ написания и серверного, и клиентского JavaScript. С помощью генераторов мы можем превратить вложенные коллбэки в похожий на синхронный код без блокирования нашей единственной event loop.
Например, этот код:

    setTimeout(function(){
        _get("/something.ajax?greeting", function(err, greeting) {
            if (err) { console.log(err); throw err; }
            _get("/else.ajax?who&greeting="+greeting, function(err, who) {
                if (err) { console.log(err); throw err; }
                console.log(greeting+" "+who);
            });
        });
    }, 1000);

может быть написан так:

    sync(function* (resume) {
        try (e) {
            yield setTimeout(resume, 1000);
            var greeting = yield _get('/something.ajax?greeting', resume)
            var who = yield _get('/else.ajax?who&greeting=' + greeting, resume)
            console.log(greeting + ' ' + who)
        }
        catch (e) {
            console.log(e);
            throw e;  
        } 
    });

Интересно, не правда ли? Централизованная обработка исключений и понятный порядок исполнения.

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

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

Sweet.js оперирует своим собственным форматом синтаксического дерева, почти на уровне токенов, с минимальной структурой. С одной стороны это делает возможным определять довольно экзотические синтаксисы для своих макросов, с другой — делает написание макросов несколько сложнее, как если бы они были определены над стандартным AST JavaScript.

Web Audio API для меня является одной из тех новинок, которыми сейчас напичканы браузеры и с которой хотелось подружиться поближе и хоть как-то проникнуться тем, что же можно с помощью этого натворить. Что бы проникнуться, я решил написать простенький визуализатор аудио.

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

Существуют различные сценарии для использования дросселирования (throttling) ввода так, что пересчет значений фильтра будет происходить не каждый раз при изменении значения, а реже. Более подходящий термин — это «устранение дребезга» (debounce), так как в сущности вы ожидаете стабилизации значения на каком-либо постоянном уровне перед вызовом функции, чтобы не вызвать «дребезг» постоянных запросов к серверу. Канонический случай такого рода — это пользователь, вводящий текст в поле ввода для фильтрации списка элементов. Если логика вашего фильтра включает некоторый оверхед (например, фильтрация происходит через REST-ресурс, который выполняет запрос на базе данных бекенда), то вы точно не захотите все время перезапускать и перезагружать результаты запроса в то время, как пользователь пишет текст в поле. Более правильным будет вместо этого подождать, пока он закончит, и уже после этого выполнить запрос один раз.

Простое решение этой проблемы находится тут: jsfiddle.net/nZdgm

Представим, что у вас есть список ($scope.list), который вы публикуете как фильтрованный список ($scope.filteredList) на основе чего-либо содержащего текст из поля $scope.searchText. Ваша форма выглядела бы примерно следующим образом (не обращайте внимание на чекбокс throttle пока что):

CSS селекторы в фронтенде можно сравнить с SQL операторами в бэкенде. Не смотря на их изначальную роль в CSS, мы активно используем селекторы в нашем Javascript коде, и, учитывая декларативный стиль селекторов, они являются приоритетными кандидатами на оптимизацию.

Вчера вышла [весьма достойная статья про Web Components, и я понял, что не могу не поделиться тем опытом, что я накопил за последние восемь месяцев. Я не буду рассказывать о том, как работать с Веб Компонентами, я расскажу, почему. Поэтому тем, кто не знает об этом стеке технологий, стоит прочитать статью по ссылке выше.
Дело в том, что в июне вышла первая стабильная версия моей библиотеки CornerJS. Начавшись как автономная реализация директив из AngularJS, она постепенно превратилась в более простой — как в использовании, так и в реализации — аналог (неточный, да, я знаю) Пользовательских Элементов из спецификации Веба Компонентов.

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

Это замечательная, на мой взгляд, в реализации библиотека — я действительно считал ее основным инструментом в разработке, и в последнем проекте (видеопортале) она оказалась важнее jQuery: от него я мог бы отказаться, а от нее нет.

Но я, как человек, внедривший ее в нашу команду, и отказываюсь от нее — мы переходим на Mozilla X-tags для IE9+ сайтов и Polymer для IE10+ сайтов. К счастью, на моей памяти у нас был всего один или два проекта IE8+.

И в этом посте я расскажу, почему веб-компоненты — это не просто будущее веба. А единственное будущее веба.

Статья написана в рамках конкурса среди студентов Технопарка Mail.ru.

Думаю, JavaSript-библиотека jQuery в представлении не нуждается, но на всякий случай напомню, что jQuery призвана ускорить разработку, предоставить синтаксический “сахар” для нативного js и избавить разработчиков от проблем, связанных с кроссплатформенностью.
Прежде чем говорить о том, как устроена обработка событий в jQuery, нельзя не упомянуть об истории обработки событий в браузере.

Раньше основной библиотекой для парсинга был JSDOM, который страдал излишней тяжеловесностью и на самом деле тормозил скорее процесс парсинга. Но время изменились и пришел cheerio. Он делает почти все то же самое, и отбрасывает лишние из процесса, при этом сам реализует какую-то часть jQuery(а именно ту, которая нам нужна для парсинга). И за счет этого позволяет наконец написать не тормозящий парсер, при этом не используя regexp'ы ради увеличения производительности. Он справляется и с xml, только нужно вызвать его с {xmlMode: true}. О том как можно легко парсить на nodeJS под катом.

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

За эталон, к которому я стремился при разработке, был взят проигрыватель http://www.yabla.com (не буду скрывать, изначально планировалось склонировать ресурс целиком, но проект не завёлся). Этот проигрыватель обладает следующими особенностями:

1. навигация по таймлайну осуществляется не с точностью до секунды, а с точностью до предложения. Человеку, изучающему язык по видеороликам, часто приходится проматывать видео назад, чтобы несколько раз переслушать неразборчивую фразу и гораздо удобнее одним кликом переместиться к началу фразы, а не искать её начало несколькими кликами.
2. Каждая фраза может быть зациклена, чтобы прослушать её многократно.
3. Разбивка таймлайна на фразы не требует от редактора какой-то особой подготовки: данные о таймингах выбираются из стандартного srt-файла с титрами.
4. Титры на всех доступных языках выводятся под видеороликом (при желании могут быть скрыты). Эта особенность позволяет, например, показывать пользователю титры на языке оригинала видео и на родном языке пользователя. Клик по слову в титрах ставит видео на паузу и показывает пользователю перевод слова, по которому сделан щелчок.
5. Таймер показывает не только время от начала видеоролика, но также номер фразы и общее число фраз в ролике.
6. Скорость проигрывания ролика может быть замедлена или ускорена.
7. Переход между фразами возможен не только кликом по таймлайну, но и при помощи хоткеев Ctrl + стрелки влево/вправо. Другие горячие клавиши: пробел — зациклить фразу/снять зацикливание, Ctrl + стрелки вверх/вниз — изменение скорости ролика.

Спустя какое время стало ясно, что основная идея Prototype вошла в противоречие с миром. Создатели браузеров ответили на возрождение Javascript добавлением новых API, многие из которых конфликтовали с реализацией Prototype.

— Sam Stephenson, создатель Prototype.js, You Are Not Your Code

Создатели браузеров поступают гармонично. Решение о новых API принимают с учётом текущих трендов в opensource сообществах. Так prototype.js способствовал появлению Array.prototype.forEach(), map() и т.д., jquery вдохновил разработчиков на HTMLElement.prototype.querySelector() и querySelectorAll().

Код на стороне клиента становится сложнее и объёмнее. Появляются многочисленные фреймворки, которые помогают держать этот хаос под контролем. Backbone, ember, angular и другие создали, чтобы помочь писать чистый, модульный код. Фреймворки уровня приложения — это тренд. Его дух присутствует в JS среде уже какое-то время. Не удивительно, что создатели браузеров решили обратить на него внимание.

Есть хороший плагин для всех популярных браузеров, X-Notifier. Он позволяет получать уведомления о новых письмах, сообщениях, да о чем угодно с различных сервисов в одном месте. Для X-Notifier написано множество скриптов (Gmail, Яндекс.Почта, Google+, Facebook, Twitter и прочих). Но скрипта для Хабра, до сих пор никто не написал, пора исправить это недоразумение!

Многие JavaScript-фреймворки предлагают свое представление о том, как должен выглядеть код. Более того, речь идет не просто о стиле, речь идет о способе написания сценариев. Это обусловлено практически абсолютной демократичностью JavaScript, да-да, именно таким является мультипарадигменный язык с С-подобным синтаксисом, прототипным наследованием, динамической типизацией и реализацией разнящейся от браузера к браузеру. Поэтому, когда речь идет о test-driven JavaScript я понимаю, что речь идет не просто об особом стиле программирования, но об особых технических принципах для особого фреймворка позволяющего тестировать JS приложения.

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

Внимание: длиннопост.

Два месяца назад компания Google выпустила первую стабильную версию языка программирования Dart 1.0, который позиционируется как альтернатива JavaScript. При всей своей простоте для написания маленьких скриптов, с помощью Dart можно создавать и сложные модульные веб-приложения, использовать библиотеки, дебаггеры, редакторы кода и другой инструментарий. Веб-разработка становится проще и удобнее.

16 января была официально представлена новая версия Dart 1.1 с повышенной скоростью выполнения скомпилированного JavaScript-кода. Например, в тесте Richards производительность выросла на 25%, по сравнению с первой версией.