JavaScript *

Я обожаю twitter bootstrap. Прост, местами логичен, достаточно красив, подходит для быстрого прототипирования веб-интерфейсов. Но этого оказалось недостаточно. Взяв twitter bootstrap в большой проект, мне пришлось целиком его разобрать и переосмыслить css-фреймворки как боевые единицы в веб-проектах. В результате переосмысления родились требования к любому css-фреймворку, удобному как верстальщику, так и frontent-разработчику.

Знаменитая социальная сеть постоянно обновляется, что далеко не всегда несет искреннюю радость пользователям. Сколько людей столько и мнений, каждому не угодишь, так и меня однажды не обрадовал новый стиль отображения альбомов видеозаписей в сети ВКонтакте.
Но мы программисты люди проворные, сразу смекаем – вот она радостная возможность чего-нибудь такого слепить… Вот и я слепил небольшое приспособление, которым хочу поделиться, и заодно напомнить, что такое и как делаются букмарклеты.

TL;DR
Эта обзорная статья. Такое себе "краткое содержание предыдущих серий". Она будет полезна для новичков, или тех, кто не следил за отраслью в последнее время. Для новичков это будет первый шаг во "Вселенную JavaScript", бывалые смогут освежить свои знания.

У JavaScript очень удивительная судьба. Он преодолел путь от самого не понимаемого до самого удивительного языка. У него было тяжелое детство:
Изначально Автор хотел написать функциональный язык. Но менеджеры хотели получить, «обычный» объектно-ориентированный. И чтобы было легко искать разработчиков для новоиспеченного языка синтаксис решили сделать похожим на Java и даже название сделали похожим.
Но на этом история не заканчивается. Java, JavaScript это торговые марки Sun (а теперь Oracle). Microsoft не мог воспользоваться именем JavaScript (Netcape и Sun дружили против Microsoft). В результате Microsoft решил сделать реверс инжиниринг JavaScript и назвал его JScript. Сделали реверс инжиниринг, и сделали его настолько хорошо, что даже содрали все баги в реализации. Позже решили сделать стандарт и назвали его ECMAScript.

Статья делится на три части:

• Вступление
• Как сделать простейший редактор самому, причем не будет никакой теории, только практика. Предупреждаю, для многих эта часть покажется простой и очевидной, так как текст ориентирован, можно сказать, на себя, в прошлом (нет, я не путешествую во времени :));
• Описание работы очень легкого редактора «Suit Up» (оригинальный объем кода: 5.97KB (1.87KB gzipped), минимизированный: 3.35KB (1.37KB gzipped) на момент написания статьи, не считая спрайта и стилей).

UPD Критика

Вступление

Не так давно, а, точнее, года два назад, в кругу разработчиков, с которыми я имел честь общаться (почти все — новички), каждый, кому поступила задача поставить WYSIWYG, ставили монстрообразный TinyMCE. Этот редактор считался почему-то стандартом у многих веб разработчиков, хотя, мало кому нужны были то большое количество функций, которые предлагались программистам. Тут тебе и то и это. Наверно, таким образом, новички пытались сказать клиенту «смотри, мы тебе на сайт запилили Ворд».

Однажды (не помню при каких условиях), мне захотелось или понадобилось разобраться в том, как работают браузерные «рич эдиторы». Моему удивлению не было предела, когда я сам, не имея каких-либо глубоких познаний в веб разработке, сделал две кнопочки: Bold и Italic, что оказалось очень простой задачей. Мне захотелось больше узнать о том, что же делать дальше. Так я познакомился с серией статей «WYSIWYG HTML редактор в браузере» (по ссылке первая статья, советую прочесть). Но информация на тот момент мне показалась несколько сложноватой. Поэтому я решил методом тыка, наступая на уже растоптанные кем-то грабли, написать свой простой редактор.

Сделал я его в виде jQuery плагина, и, думаю, не стоит отвечать «почему». Получилось кое-как заставить работать его в разных браузерах. Тут мне пришла в голову идея написать статью на хабр, после некоторых доработок. Время шло, допиливание я откладывал, откладывал… Два года, черт, целых два года. Но я постараюсь исправиться.

Простейший редактор

Для того, чтоб дать возможность пользователю менять содержимое блока (в данном случае, обычного дива) просто задаём ему (блоку) атрибут contenteditable:

<div contenteditable></div>

Редактор готов!

Этим постом мы продолжаем серию статей на тему разработки веб-интерфейсов для touch-устройств.

Смартфоны с сенсорными экранами достаточно сильно распространены и стали незаменимыми помощниками многим из нас. Потому нельзя не учитывать их особенности при разработке мобильных веб-интерфейсов.
Сенсорное управление существенно отличается от привычного управления мышкой.
Пользователь взаимодействует пальцами с самим экраном. И в зависимости от того, какие движения и сколькими пальцами производит пользователь, интерфейс реагирует по-разному: если быстро коснулся экрана и отпустил палец, то срабатывает клик; если коснулся и провел пальцем по экрану – скролл; если провел двумя пальцами – zoom; и великое множество других вариантов реакции.

Сегодня речь пойдет о swipe, в простонародье – листалке. Swipe позволяет перелистывать «страницы» привычным движением пальца. О том, как грамотно реализовать swipe, я расскажу на примере блока новостей на главной странице портала Mail.Ru.

За последнее время я несколько раз успел поучаствовать в дискуссиях о том, чем Angular лучше или хуже Knockout и других JS-фреймворков. И очень часто я сталкивался с тем, что есть некоторое непонимание сути различий в подходах, заложенных в эти продукты. Иногда дело доходило даже до того, что в качестве преимущества Knockout приводились валидные по умолчанию префиксы «data-», что ну просто совсем смешно (не говоря уж о том, что их можно использовать и в Angular).

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

1. Модульная организация кода, тестируемость и жестокая война с любыми глобальными данными.
2. Пропаганда декларативного подхода через создание собственных HTML-директив.
3. Механизм проверки изменения данных в дата-биндинге без использования коллбэков.

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

Всем давно известно, что jQuery легко расширяем. Сегодня мы добавим новый селектор — :regex.

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

Тема для сегодняшнего поста достаточно большая и я постараюсь рассказать о ней поинтереснее и не слишком поверхностно. Рассмотрим мы сегодня методы attr, prop и data.

Рассмотрим задачу парсинга HTML на клиенте (Javascript) с последующим оформлением полученных данных стилями и вёрсткой и выводом их в нужные места страницы просмотра. Применение такой подгрузчик страниц и блоков нашёл в юзерскриптах — когда разработчики подгрузчика никак не связаны с разработчиками сайта. Но есть основания использовать подход и для обычных сайтов для полного отделения View от Model.

Статья получилась теоретической, потому что из-за её объёма я не стал перегружать её практическими результатами. Да и трудно пока представить некие шаги, по которым каждый мог бы подхватить идеи и начать строить подобное. Вначале надо посеять идеи, но пока попытки посева (здесь, на Хабре) не давали всходов, хотя я и не особо старался в этом направлении. Подход развивался последние полгода и был даже анонсирован на Хабре примерно в апреле-мае. В статье рассказано, «как это сделать», и перечислены преимущества подхода. Он требует глубокого и специфического программирования на JS. По результатам работы, скорее всего, имеет смысл выделить библиотеку для аналогичных задач.

Во всем мире объем используемого JS кода в приложениях растет очень сильно, что уже неоднократно подчеркивалось, посмотреть картинки на эту тему можно например тут или тут. Соответственно с ростом количества кода возникает необходимость структурирования данных, управления зависимостями и проч., которые на данный момент решает целый букет фрэймворков, например RequireJS в композиции с Backbone. С другой стороны в мире Java для управления зависимостями и контроля процесса сборки проекта используется Maven, который отлично справляется с задачей разделения больших проектов на модули, запуска тестов в нужное время и т.д. У некоторых разработчиков, уже давно использующих Maven для сборки проекта, может возникнуть желание вынести свой отлично структурированый JS код в отдельный модуль, тестировать его во время сборки и совершать с ним все операции, которые позволяют делать плагины, о чем и пойдет речь.

Написать расширение для google chrome несложно. Но при написании первого раширения могут возникнуть (и возникают) вопросы. Большинство мануалов по написанию первого расширения расчитаны на использования манифеста первой версии, поддержка которого в скором будущем прекратится.

В этой статье будет рассмотрено:

• Как составлять манифест v.2
• Как работать с удаленными ресурсами
• Как работать с cookies
• Как работать с local storage
• Как работать с уведомлениями

Начал изучать NodeJS. Нигде не нашел актуальный стек мейнстримных библиотек (технологий) применяемых в node. Поэтому решил сам составить список.

О библиотеке knockout.js на хабре написано не так много, но кое что есть (и конечно же есть официальный туториал и другие материалы на оф. сайте и хороший ресурс на англ. языке knockmeout.net, статьи которого смогу перевести, если будет спрос). Данная статья возможно перерастёт в цикл статей по javascript и нокауту, если нло не похитит меня.

Изначально готовил материал для людей, уже знакомых с нокаутом и mvvm, но в комментариях к другим статьям меня попросили рассказать как готовить нокаут для чайников. Предполагаю, что вы уже прочитали предыдущие статьи о нокауте на хабре. Поехали!

Перед Новым годом на хабре были опубликованы два топика (первый, второй) о создании «Солнечной системы» на HTML5 Canvas. Бегло прочитав их и изучив результаты профилирования я удивился тому что такая простенькая программа так неэффективно работает. Вооружившись Notepad++ решил проверить всё ли так плохо, написав свою реализацию.

ТЗ остаётся всё тем же. 12 планет, период обращения первой — 40 секунд, каждой последующей на 20 секунд дольше. Изначально планеты имеют случайное расположение на своих орбитах. У каждой планеты есть описание, которое отображается при наведении курсора на неё. При клике на планету она останавливается. Если курсор находиться над орбитой — подсветить её. Всё это должно работать в Opera 12+, IE9+, Chrome и FF.

— Я не хочу ничего читать, давай результат!
— Держи: жмяк

Существует не слишком широко известная браузерная игра. Игровой процесс в ней очень простой и монотонный, что способствует появлению ботов. Для борьбы с ними в игру введена капча, время от времени вылезающая во время боя. На угадывание даётся 50 секунд, если угадать за 20, то дадут дополнительный бонус. Капч два вида: «Угадай пони» и «Пройди лабиринтик». С угадыванием пони проблем у меня обычно не возникало, а вот пройти лабиринт за 20 секунд — задача не всегда тривиальная. И я задумался, а нельзя ли написать Userscript, который бы самостоятельно проходил лабиринт и сообщал мне правильный ответ…

Мой предыдущий пост "Как сделать 3D шутер на JavaScript за пару дней" показал, что тема разработки браузерных игр весьма интересна и по этому я решил очередные выходные посвятить еще одной моей задумке.

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

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

Долго думал, что же разобрать дальше — атрибуты, свойства и данные или манипуляцию с DOM, даже начал писать обе статьи. И вроде бы сначала хорошо было бы дать первую тему, но в комментариях к предыдущему топику уже обратили внимание на одну особенность работы со скриптами, которая как раз относится ко второй теме, так что не будем тянуть и начнем именно с нее. Заодно прошу прощения у тех, кто увидел начало статьи, которое я по ошибке опубликовал в процессе написания.

Итак, сегодня мы продолжим серию копаний в исходниках jQuery под номером 1.8.3 (стабильная версия на момент написания статьи). Общее представление о jQuery мы уже получили, парсить html — тоже. Пора то, что мы распарсили куда-нибудь вставить.

Нужно было написать игру на JavaScript. Решил остановиться на примитивных гоночках. Когда я овладел принципами вращения и перемещения по HTML5 Canvas появилась следующая проблема: управление автомобилем. Делая эту игру я вспоминал игру Grand Prix Simulator 2 ZX Spectrum, в кторую я играл на компьютере «Байт».

Продолжаем дело первой статьи и пытаемся разобраться с тем, что же делает за нас jQuery, когда мы с помощью этой библиотеки создаем DOM-элементы.

В прошлом выпуске мы упомянули, что при передаче в jQuery вместо селектора html-строки, на основе нее функция parseHTML создаст соответствующие элементы и вернет их в привычном jQuery-объекте. Сейчас мы рассмотрим все это более тщательно и затронем кроме core.js еще manipulation.js и attributes.js (мельком).

Директивы — это ключевая особенность AngularJS. С помощью директив можно добавлять новое поведение существующим HTML элементам, можно создавать новые компоненты. Примерами директив, добавляющих новое поведения для существующих HTML элементов, могут служить input, select, textarea в связке с ngModel, required и т.п. Перечисленные директивы в основном связаны с валидацией форм в AngularJS. Но тема валидации заслуживает отдельной статьи.

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

Если вы разрабатываете приложение на AngularJS и не создаете директивы, то это уже само по себе немного настораживает. Либо ваше приложение достаточно простое и уложилось в стандартные возможности AngularJS, либо, скорее всего, что-то не так с архитектурой вашего приложения. А если у вас при этом есть работа с DOM-ом в контроллерах или сервисах, то вам однозначно надо разбираться с темой создания директив, т.к. манипуляций с DOM-ом не должно быть нигде, кроме директив.

В данной статье я постараюсь рассмотреть процесс создания собственных директив на нескольких примерах.