JavaScript *

В этой заметке расскажу, как я использую пользовательские события jQuery (custom events) в своей работе.

Имитиация событий

Дана простая задача, реализацию которой наблюдают все хабровчане: когда пользователь достаточно прокрутил страницу вниз, анимированно отображается блок-врезка «Лучшее за 24 часа», и скрывается, когда пользователь прокручивает страницу вверх. Эта задача решается подвешиванием обработчика на события scroll и resize окна (window), который занят двумя вещами: вычисляет, нужно или нет отображать/скрывать блок-врезку, и в зависимости от результата производит анимацию отображения или осуществляет скрытие.

Если эта задача стояла перед нами, как бы мы приступили к ее реализации? Ну, например, написали такой кусочек кода:

Еще одна? Зачем? Есть же CommonJS и AMD? Страждующие могут пройти под кат.

Одной из самых интересных частей нового стандарта ECMAScript 6 являются стрелочные функции. Стрелочные функции, как и понятно из названия определяются новым синтаксисом, который использует стрелку =>. Однако, помимо отличного синтаксиса, стрелочные функции отличаются от традиционных функций и в других моментах:

• Лексическое связывание. Значения специальных переменных this, super и arguments определяются не тем, как стрелочные функции были вызваны, а тем, как они были созданы.
• Неизменяемые this, super и arguments. Значения этих переменных внутри стрелочных функций остаются неизменными на протяжении всего жизненного цикла функции.
• Стрелочные функции не могут быть использованы как конструктор и кидают ошибку при использовании с оператором new.
• Недоступность «собственного» значения переменной arguments.

Было несколько причин для введения этих отличий. Первоочередная — это то, что связывание (binding) используется довольно часто в JavaScript. Очень легко потерять нужное значение this при использовании традиционных функций, что может привести к непредсказуемым последствиям. Другая причина, это то, что JS-движки смогут легко оптимизировать выполнение стрелочных функций за счет этих ограничений (в противоположность традиционным функциям, которые могут быть использованы в качестве конструктора и которые свободны для модификации специальных переменных).

DerbyJs — реактивный фулстек javascript-фреймворк. О нем неоднократно писали на хабре — материалы по Derby. Буквально пару дней назад в репозитории Derby произошла смена основной ветки. Теперь версия 0.5 отошла на задний план, 0.6 — основная.

Не в традициях команды разработчиков заниматься пиаром — изменения произошли тихо и незаметно. А что же поменялось?

Читаю я вчерашний пост простоквашино на Хабре или письмо Дяди Федора. Мысль интересная, но.

Комментарии пугают.

Поясню почему.

Комментарии там условно можно разделить на два вида

• «как много помещается ангелов на конце иглы» «о сортировке дат»,
• «как забивать гвозди электронным микроскопом» «мы напишем что-то такое большое в энтерпрайзненьком стиле».

Душа поэта не выдержала, нашел полчаса, и нарисовал userscript.

Скрипт прост до ужаса — перебирает все комментарии в поисках специального маркера. Если маркер найден — показывает все комментарии с маркером во всплывающем окошке.

Всем желающим поучаствовать в улучшении — добро пожаловать, так сказать откатаем технологию. Если ваш комментарий надо добавить в пост — пишите внутри комментария вот так [also]. А я как инициатор этого безобразия — по мере сил буду ваши пожелания в пост переносить. И соответственно — улучшать скрипт тоже.

Всем привет! Встретил статью о том, как на сайте meteor.com обеспечена работа для высоких нагрузок. Звучит это довольно интересно. (пер.)

Во-первых, зайдите на meteor.com и посмотрите, как это работает.

Мы все знаем, что meteor.com сделан на Meteor. Вы можете заметить, что загружается он очень быстро. Также, у него нет процесса загрузки — после того, как HTML построен, страница сразу отображается на экране.

Но как это возможно? Обычно, это занимает какое-то время — подключение к серверу, получение данных и отображение информации на экране. Может, Meteor использует какую-то магию с Galaxy?

Постараюсь быть неимоверно кратким.

Написано для тех, кто только начинает!

Статей про наследование в JS не счесть:

• Здесь, на Хабре
• google
• yandex

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

У меня в google по запросу "what is the difference between inheritance and legacy" первая ссылка ведёт сюда: ссылка.

Само собой, что статей там не одна.

Там есть такая строчка, дописка: Also, as pointed out in some comments, «inheritance» is generally from the viewpoint of the receiver, while «legacy» is from the viewpoint of the giver: My inheritance was my father's legacy.

Краткая суть, которая не отражает всей глубины, которую я себе уяснил, в том, что:

• legacy — это взгляд со стороны родителя, широкий
• inheritance — это взгляд со стороны потомка, узкий

Поэтому я считаю, что в обычных ООП языках программирования типа Java, C#, С++ и т.п. используется термин inheritance — наследование.

А у нас в JavaScript используется почти то же самое, но немного шире: legacy — наследство.

А т.к. в Русском Языке разницы между этими понятиями почти нет, то отсюда и масса FuckUp'ов с пониманием зачем это нужно.

И, в том числе потому, что от Legacy code мы никуда не денемся.

UPD 2: Выжимка из статьи про legacy code >> Modern interpretations.

… source code inherited from someone else and source code inherited from an older version of the software…

UPD 3: Под катом идёт речь о том, что Inheritance неминуемо влечёт за собой Legacy. Точней наоборот, согласно терминологии носителей языка Legacy — это больше чем Inheritance.

UPD 1: В комментариях подсказывают, что может быть частично речь идёт о Гипотезе Сепира-Уорфа. Спасибо k12th. Так же спасибо lair за конструктивную критику.

I. В чём проблема.

Почтовые ящики, «Входящие» личных сообщений, RSS — всё это объединяет одно удобство: чёткое разделение прочитанных и непрочитанных сообщений. Однако в блогах и социальных сетях, по крайней мере самых распространённых, такая возможность чаще всего не предусмотрена. И по досадному совпадению именно эти ресурсы не предоставляют пользователям потоки RSS.

Вроде бы не так сложно помнить, что ты прочитал, а что ещё нет. Но если следишь за очень динамичной лентой или за активным обсуждением одной темы, порой не так уж просто сразу разобраться. Да и постоянно прочитывать одно-два первых предложений вхолостую, чтобы только понять, что ты это уже читал, — не такое уж приятное и безвредное занятие.

История

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

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

И наконец, в один прекрасный день вы решили: “Сделаем это!”. И вот вы уже пытаетесь разобраться как реализовать бизнес-логику своего приложения, ту киллер-фичу, которая будет двигать продукт вперед. У вас есть идея как это сделать, и вы знаете, что способны на это. И вот вы говорите: “Готово! Работает!” У вас есть успешный прототип! Осталось только упаковать его в веб приложение.

“Окей, сделаем сайт,” говорите вы.

А только потом вы понимаете, что для этого нужно выбрать язык программирования; нужно выбрать (современную) платформу; нужно выбрать какие-то (современные) фреймворки; нужно настроить (и купить) хранилище, базы данных и хостинг; нужно обеспечить интерфейс для администрирования; нужно обеспечить контроль доступа и систему управления контентом.

Перед вами десятки и десятки архитектурных решений, которые необходимо принять. И вы не хотите ошибиться: требуются технологии, которые позволят вести быструю разработку, поддерживают постоянные итерации, максимальную эффективность, скорость, устойчивость и многое другое. Вы хотите быть бережливым (lean) и гибким (agile). Вы хотите использовать технологии, которые помогут вам быть успешным как в краткосрочной, так и в долгосрочной перспективе. А выбрать их далеко не всегда так просто.

“Я перегружен”, говорите вы и чувствуете себя перегруженным. Энергия уже не та, что была в начале. Вы пытаетесь собраться с мыслями, но работы слишком много. Прототип медленно блекнет и умирает.

Всем привет! Этот небольшой пост посвящен системе тестирования MeteorJS-приложений Laika от Arunoda Susiripala. Ее особенности довольно интересны:

• Laika запускает свои тесты так же, как запускается реальное приложение (используется PhantomJS)
• Каждый тест изолирован, т.е. заново запускается ваше MeteorJS-приложение с чистой базой данных
• Вы можете использовать для разработки и meteor, и meteorite, laika прекрасно работает с ними обоими
• Вы можете запускать проверку на сервере и клиенте в одном тесте. Это поможет протестировать такие моменты, как права доступа (permission), подписки (subscriptions) и вызовы методов (method calls)
• Так как MeteorJS работает в реальном времени, то вам потребуется тестировать приложение при работе нескольких клиентов одновременно. Laika это может.
• Возможность использования событий для более точного тестирования, т.е., фактически, эмуляция работы пользователя
• Передача значений в код во время выполнения теста через аргументы
• Ожидание окончания генерации шаблонов (templates)

Сегодня мы запустили новую версию веб-интерфейса сервиса Яндекс.Метро. Теперь в новом «островном» дизайне доступны схемы метрополитена пяти городов. Но мы обновили не только визуальную часть, но и перенесли всю логику с серверной стороны на клиентскую.



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

Сервис Яндекс.Метро был запущен в далеком 2007 году. С тех пор веб-интерфейс практически не развивался, дизайн выглядел откровенно устаревшим. Почтенный возраст сервиса сказывался и на технической стороне. Все схемы представляли собой наборы изображений в формате GIF, на которых при помощи координат размещались объекты. Из-за этого возникали трудности с обновлением графа, нельзя было самостоятельно вносить изменения в схему (приходилось привлекать аутсорсеров, заказывать у них картинки). Так как названия станций также были вшиты в картинки, локализация схем потребовала бы генерации полных наборов GIF-изображений.

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

Самый яркий для меня пример, это обработка псевдокласса :hover. Для начала iOS7, например, не будет реагировать на hover если только на элемент, или его родителя, не навешена обработка события click. Это хорошо видно вот на этом примере: jsfiddle.net/H8EmG — сколько не тыкай пальцем в текст — никаких подчеркиваний не увидишь. А в этом примере jsfiddle.net/H8EmG/1 «тычок» пальцем в текст будет приводить к его подчеркиванию. Интересный факт — пока не ткнем в другой элемент, текст так и будет сидеть под ховером…

Другой интересный пример, это обработка появления элементов «по-наведению»: jsfiddle.net/ASRm9/1 Попробуйте нажать на текст. Сперва вы увидите текст «HOVER!», появившийся внутри строки, а вот второе нажатие уже вызовет alert('click'). Это происходит потому, что iOS понимает что за :hover что-то скрыто, и старается не сломать поведение, заложенное автором сайта.

Но однажды мы столкнулись с такой багой, объяснить которую мы не смогли до сих пор, а на ее локализацию потребовался не один день отладки на iPad… Желающие подробностей, а также хитрого, как мне кажется, способа решения, наверное, всех проблем с :hover разом — прошу под кат…

Иногда создаваемый компонент связан с большим количеством статических данных. Единственный «нормальный» способ хранить эти данные в javascript — это строки. Но хранить в строках многострочные данные неудобно, т.к. каждая строка требует дополнительного форматирования. Кроме того приходится следить за экранированием символов.

Всем привет! Хочу показать свой кусочек CoffeeScript для декларативной подписки и обработки событий.

Предистория

У меня 5 лет инженерного опыта, включающего в себя .NET (+forms, +WPF, +.NET MVC), Java (+Swing, +Tapestry5, +Groovy), JavaScript (+CoffeeScript, +Node).

Последний год я активно пишу собственное одностраничное веб-приложение работающее без перезагрузки, (о котором речь будет в следующих выпусках). Вся динамическая часть пользовательского интерфейса создается на клиенте, с сервера приходят только данные. Как часто бывает в UI, я имею дело с деревом компонентов. Разумеется, для организации взаимодействия дерева мне нужен механизм отправки и обработки событий. Я решил написать свой, и не использовать Backbone, или что-то из Google Closure. В любом случае у меня был опыт реализации этюда Слушатель (Listener pattern).

Класс ИспускательСобытий первой версии если ты хотел слушать его — просто записывал тебя в массив слушателей. Когда возникало событие «Ч» он обходил массив, и искал слушателей с методом «наЧ», и вызывал его. Типа как в Swing / .NET.

Все отлично работало для небольшого числа Испускателей. С ростом системы пришла проблема перекрытия имен событий между разными Испускателями. Подписчик выполнял один и тот же метод «наЧ», даже если «Ч» исходило от разных Испускателей. Затем был более привычный для JS, EventEmitter, как в jQuery / NodeJS. Не буду особо затягивать…

В посте в повествовательной и не очень манере рассказывается о различных реализациях «точных» таймеров на JS. Материал рассчитан на новичков… Добро пожаловать под кат.

Пока JavaScript не обзавёлся настоящими модулями мы продолжаем импровизировать.
Так появилась на свет ещё одна реализация модулей — definer.

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

Для хорошего понимания идеи, под катом примеры от простого к сложному.

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

Node App

Вы когда нибудь задумывались о возможности писать приложения для iOS и OSX на Node.js? А проект, позволяющий решить эту задачу уже есть. Более того часть (хоть и маленькая) функционала доступна уже сейчас. Пишу о проекте с мыслями о том, что хабраобщество значимая единица социального коддинга…

Scala.js

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

Hackathon Starter

Замечательный boilerplate для Node.js проектов. Базовая регистрация через email, авторизация по OAuth (Twitter, Facebook, GitHub, Google), красивые уведомления на animate.css, автокомпиляция LESS, Bootstrap 3 + Flat UI + iOS7 Theme, контактная форма и стандартный функционал управления аккаунтом.

Уже довольно давно у веб-приложений появилась возможность хранить часть данных или файлов локально. Можно даже кешировать MP3-файлы. Браузеры научились хранить немалые объёмы данных. Тем не менее, пока что технологии локального хранения сильно фрагментированы.

localStorage предоставляет лишь самые базовые функции, это хранилище довольно медленно и не умеет хранить блобы. IndexedDB и WebSQL асинхронны, быстры и поддерживают большие объемы данных, но их API довольно запутан. Кроме того, ни IndexedDB, ни WebSQL не поддерживаются всеми основными браузерами, и, похоже, в ближайшем будущем эта ситуация не изменится.

Если вам нужно писать веб-приложение с оффлайн-режимом, и вы не знаете, с чего начать, то эта статься для вас. Если вы уже пытались работать с локальными хранилищами, и у вас от этого голова пошла кругом — статья и для вас тоже. Мы в Mozilla написали библиотеку localForage, которая значительно облегчает задачу хранения локальных данных в любом браузере.

Почувствовать на своей шкуре все сложности работы с локальным хранилищем мне помогла разработка around — HTML5-клиента для Foursquare. Хотя в этой статье я рассказываю, как использовать localForage, возможно кто-то предпочтёт изучить реальные примеры работы с ней.

localForage — очень простая библиотека JavaScript, которая использует API, похожий на API localStorage, с теми же самыми базовыми методами get, set, remove, clear и length, но имеет ещё несколько важных улучшений:

• асинхронный API с колбэками;
• драйвера IndexedDB, WebSQL и localStorage (самый подходящий драйвер выбирается автоматически в зависимости от возможностей браузера);
• поддержка блобов и произвольных форматов данных, так что можно хранить изображения, файлы и так далее;
• поддержка обещаний ECMAScript 6.

Использование IndexedDB и WebSQL позволяет хранить намного больше данных, чем localStorage. Неблокирующий асинхронный API делает приложение более быстрым и отзывчивым, так как основной поток приложения не подвисает во время выполнения вызовов get/set. Поддержка обещаний позволяет писать чистый код без спагетти из колбэков. Конечно, если вы любите колбэки, можно использовать и их.

Ember.js сложный в обучении. Хотя даже не так. Концепты Ember.js сложны в освоении и понимании. Мне кажется, что любой курс обучения Ember.js должен начинаться с этих слов.

Я разработчик, работающий с Ruby on Rails (до этого я программировал в .NET и Python). Для меня было довольно проблематично понять магию, заставляющую Ember.js работать. Иногда я общаюсь с другими начинающими разработчиками, вставшими (или пытающимися встать) на путь Ember.js — все их проблемы начинаются из-за того, что они не понимают, как устроен данный фреймворк.

Да, с одной стороны есть официальная документация в которой детально описаны все аспекты данного фреймворка. Но ей не хватает концепции; для начинающего разработчика это просто осколки информации разбросанные случайным способом. Из документации, например, можно узнать что у нас есть в арсенале контроллеры, модели и виды (controller, model, view). Но для того что-бы узнать за что они отвечают и как работают начинающему разработчику предлагают сначала наступить на грабли пару десятков раз. Плюс в нагрузку к контроллерам, моделям и видам Ember.js нам дает целый взвод разношерстых объектов типа компонентов, шаблонов, маршрутизатора и путей (component, template, router, route).

I. В чём проблема

Если социальная сеть, платформа для блогов или форум предоставляют возможность размечать текст при помощи HTML или BBCode, перечёркивать или подчёркивать текст не составляет труда: можно пользоваться тегами s и u обеих разметок или назначать стили в HTML. Но что делать, если у нас есть только голый текст? Или, например, нам нужно зачеркнуть/подчеркнуть слово в заголовке страницы, отображаемом в заголовке вкладки или всего браузера, или оформить слово в заголовке форумного поста — короче говоря, всюду, где не работает разметка?

Можно рискнуть и воспользоваться средствами Юникода.