JavaScript *

Некоторое время назад у меня дошли руки до темы, которая давно уже меня нервирует интересует. Эта тема — наследование в JavaScript.

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

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

Вчера сходил на мастер-класс Ильи Кантора (javascript.ru). Если кратко — мне понравилось. Под катом немного подробнее.

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

Всех у кого хоть раз болела голова при написании/чтении javascript кода прошу под кат.

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

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

В HTML5 есть замечательный атрибут placeholder.

<input placeholder="inbox@disney.com">

Сейчас он работает только в webkit-браузерах (Safari, Google Chrome).

С помощью JS, не изобретая велосипедов, placeholder.js делает этот атрибут кроссбраузерным.

<input placeholder="inbox@disney.com" id="some_input">
<script type="text/javascript">
  inputPlaceholder( document.getElementById('some_input') )
</script>

placeholder.js (1.3 килобайта)

Всем привет!

31 октября, 7 ноября и 10 ноября в Москве пройдут интереснейшие мастер-классы по javascript ;)

Материал к ним готовился более полугода.

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

По опыту предыдущих мастер-классов — получилось интересно и очень полезно.

Сегодня PsychodelEKS точно подметил по поводу API джаваскриптового сжатия файлов, недавно встроенного Yahoo в BrowserPlus:

Уж было подумал, что они портировали алгоритм сжатия на js, но оказалось, что это просто браузерный интерфейс к архиватору =)

А вот возможность сжимать большие объёмы текстовых (json) данных на стороне клиента перед отправкой на сервер, была бы удобна в современных веб-приложениях.

Конец цитаты.

На эту тему я очень рад сообщить всем вам приятную новость: в недрах W3C редактор Арун Ранганатан (Arun Ranganathan) подготавливает черновик стандарта File API, в значительной мере поддерживаемого свежими еженощными сборками Файерфокса. Этот стандарт определяет особые API, посредством которых джаваскрипт может читать файлы на машине у пользователя, затем по-разному преобразовывать их, изготавливая при необходимости URLы «data:...» или base64-кодированные строки, а затем совершать с ними что угодно желаемое (например, отсылать на сервер, или использовать в джаваскрипте, или в CSS...).

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

(Это то самое и есть, что делает новый API BrowserPlus, так что тогда он не будет для этой цели нужен, а довольно будет и одного Файерфокса.)

Пока же этого ещё не произошло, я предлагаю вам лицезреть одно зрелищное приложение, недавно упомянутое на hacks.mozilla.org — оно называется Font Dragr, навешивается на некоторый сайт и позволяет читателю сайта закинуть (drag-n-drop) на страницу этого сайта какой-нибудь файл шрифта с собственного диска, чтобы эта страница отображалась на сайте именно этим шрифтом. Отображаться начинает сразу же, так как файл не передаётся на сервер, а преобразуется и скармливается во браузер же, через CSS.

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

Артель BrowserPlus (из Yahoo) выпустила API для сжатия файлов на стороне клиента. Как объясняется в нижеследующем скринкасте, джаваскриптовый API позволяет вам упаковывать и сжимать файлы в клиенте посредством LZMA или tar.


    «Client Side Compression» выложил Lloyd Hilaiel на Vimeo

Вы можете читать далее о реализации или испытать демонстрацию живьём (потребуется BrowserPlus).


    Прилад Browser Plus для упаковки на стороне клиента

Использовать этот API нетрудно: вызываем надобный метод и посылаем ему файлы:

BrowserPlus.Tar.tar({'files':files});
BrowserPlus.LZMA.compress({'files':files});

На GitHub доступны оба эти расширения — LZMA и tar.

Нюансы перевода:  слово «прилад», давно живущее в великорусском языке (как минимум, со времён Даля), здесь служит переводом технического термина «add-on» (а не «device», как в украинском), слово же «артель» означает команду разработчиков (в оригинале — «team»).

Думаю, пост будет интересен начинающим изучать JavaScript и DOM.

Недавно я провозился больше получаса пытаясь понять, почему приведенный ниже код возвращает «undefined» во всех браузерах кроме Internet Explorer'а.

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

Когда деревья были большими, а проблемы просто громадными, существовал такой компьютер — Радио-86РК. Многие программисты на территории бывшего СССР начали свой путь с этой машины.

Но время шло, и РК плавно ушел в небытие. Но для особых фанатов существуют эмуляторы. А в современном мире Web 2.0 вообще модно, чтобы все работало прямо в браузере. А так как правильные браузеры типа Google Chrome предоставляют все возрастающую скорость JavaScript, то подобная мода весьма оправдана. А как результат, даже эмуляторы процессоров теперь можно запускать прямо в браузере (недавно на Хабре была тема про эмулятор Спектрума).

Я так вдохновился тем Спектрумовским эмулятором, что за пару дней перенес свой старый эмулятор РК на платформу JavaScript.

Идея паттерна Observer заключается в создании зависимости типа один ко многим. При изменении состояния одного объекта(субъекта), зависящие от него объекты(наблюдатели) об этом оповещаются и обновляются. Это нужно для согласования состояния взаимосвязанных объектов без их жесткой связанности.

Всем привет.

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

Пожалуй, все встречали подобные инструменты основанные на технологии flash. Однако я считаю, что её использование здесь не к чему. Поэтому потратив несколько часов я реализовал подобный функционал на javascript в виде плагина к jQuery.

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

• Сортировка на стороне сервера посредством SQL или backend'а;
• Сортировка на стороне клиента.

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

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

Поздравляем Эндрю Дюпона (Andrew Dupont) и Тоби Ланжеля (Tobie Langel) (нового официального соведущего ядра Prototype) с выходом нового 1.6.1:

• Полная совместимость с новыми браузерами. Эта версия Prototype полностью поддерживает 1.0 и более крупные версии Google Chrome, и Internet Explorer 8 как в режиме совместимости, так и в суперстандартном.
• Сохранение метаданных в элементах. С лёгкостью объединяйте джаваскриптовые пары ключей и значений с элементами DOM. Поглядите блогозапись, с которой это началось.
• Новые события мыши. Собственнические события Internet Explorer — «mouseenter» и «mouseleave» — теперь доступны для всех браузеров.
• Улучшенное быстродействие и домовитость. Часто использовавшиеся методы Function#bind, String#escapeHTML и Element#down стали быстрее, и Prototype лучше прибирает за собою.
• Собрано со Sprockets. Теперь вы можете включать репозиторий исходного кода Prototype в своё приложение и использовать Sprockets для управления зависимостями и для распространения.
• Внутреннее документирование посредством PDoc. Наша документация по API теперь хранится внутри исходного кода посредством PDoc, так что проще посылать патчи или лицезреть документацию по конкретной версии.

Подробности глядите во блогозаписи о RC2, во блогозаписи о RC3, и в CHANGELOG.

Вот несколько симпатичных изменений. Хотя с неподдельным волнением ожидаю увидеть работу нового Prototype 2.0 и как команда перезагрузит Prototype.

Недавно заметил, что наткнувшись на такое

  var array = [1, 2, 3, ];


Internet Explorer создает объект массива, в котором на самом деле 3 элемента, но length == 4 (!).
Нормальные браузеры ведут себя иначе — там 3 элемента и length == 3. В какой-то степени оба поведения мне кажутся логичными, а вы как думаете?

Проверить можно тут.

Как всем известно, в нашем «дорогом» ИЕ версий ниже 8, нету поддержки Element.prototype (а также HTMLElement, Node).

При написании console-like форума был задан вопрос: «какую разметку лучше использовать?». Среди вариантов были стандартный бб-код ([b]bold[/b]), вики-разметка(*bold*), или TeX-like разметка (\b{bold}). После недолгого совещания выбор был остановлен именно на TeX-like. Была написана небольшая библиотека, которая, по моему мнению, достаточно интересна, расширяема и гибка. Желающие посмотреть пример могут перейти по ссылке freecr.ru/TeX

Иногда у веб-разработчиков возникает задача, которая требует плавного движения объекта по экрану. Это может быть строка загрузки, какой-то спрайт (например, машинки на клавогонках) или что-то ещё. Проблема возникает, когда сдвиг даже на одну точку кажется слишком резким и портит общее ощущение от происходящего. Как этого избежать? Использовать приёмы антиалиасинга.

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

Как это сделано?

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