JavaScript *

Объекты, классы, конструкторы

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

В JavaScript нет привычных классов, но есть функции-конструкторы, порождающие объекты по определенным алгоритмам (см. Оператор new).

Прототипное делегирующее наследование

Классическое наследование очень похоже на то, как люди наследуют гены своих предков. Есть какие-то базовые особенности: люди могут ходить, говорить… И есть характерные черты для для каждого человека. Люди не в состоянии изменить себя — свой класс (но могут поменять собственные свойства) и бабушки, дедушки, мамы и папы не могут динамически повлиять на гены детей и внуков. Все очень по земному.

Теперь представим другую планету, на которой не такое как на Земле генное наследование. Там обитают мутанты с «телепатическим наследованием», которые способны изменять гены своих потомков.
Разберем пример. Отец наследует гены от Дедушки, а Сын наследует гены от Отца, который наследует от Дедушки. Каждый мутант может свободно мутировать, и может менять гены своих потомков. Например у Дедушки был зеленый цвет кожи, Отец цвет унаследовал, Сын тоже унаследовал цвет. И вдруг Дед решил: «надоело мне ходить зеленым — хочу стать сними», смутировал (изменил прототип своего класса) и «телепатически» распространил эту мутацию Отцу и Сыну, вобщем посинели все. Тут Отец подумал: «Дед на старости лет совсем двинулся» и поменял свой цвет в генах обратно на зеленый(изменил прототип своего класса), и распространил «телепатически» свой цвет сыну. Отец и Сын зеленые, Дед синий. Теперь как бы дед ни старался Отец и сын цвет не поменяют, т.к сейчас Отец в своем прототипе прописал цвет, а Сын в первую очередь унаследует от Прототипа Отца. Теперь Сын решает: «Поменяю ка я свой цвет на черный, а моё потомство пусть наследует цвет от Отца» и прописал собственное свойство, которое не влияет на потомство. И так далее.

Несколько дней назад мы с TheShock создали топик в котором собирали ваши вопросы, касательно JavaScript (архитектура, фрэймворки, проблемы). Настало время ответить на них. Мы получили очень много вопросов, как в комментариях так и по email. Эта первая часть ответов — те вопросы, которые достались мне.

Джед Шмидт, Томас Фухс и Дастин Диаз — достаточно известные в JavaScript-коммьюнити ребята в последнее время нашли себе новую развлекуху — писать полезные штуки размером не больше одного твита, то есть 140 байт. Даже домен зарегали — 140byt.es, куда приглашаются все желающие попробовать свои силы в написании супер-компактных функций.

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

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

Предлагаю продолжить тему часто задаваемых вопросов на хабре. Неделя Canvas отгремела, теперь, пришел черед JavaScript. Такой формат топика показался TheShock и мне очень удачным, поэтому мы решили поделиться с вами нашими знаниями JavaScript.

Мы ответим на ваши вопросы, касаемо сомнительных моментов языка(this, arguments, bind, функции, замыкания, модули), ECMAScript 3, 5, 6+, реализации языка в конкретных браузерах, фрэймворков(jQuery, Prototype, Mootools...), архитектуре приложений(паттерны, MVC...), тестировании, и вообще всего с чем связан JavaScript и разработка на JavaScript(как клиентской так и серверной).

Если у вас нет возможности задать вопрос в комментарии, то вы можете связаться с нами по другим источникам, которые вы можете найти в профиле: azproduction, TheShock или по email: azazel.private@gmail.com, shocksilien@gmail.com

В конце недели, начале следующей мы опубликуем ответы на все ваши вопросы.
Этот пост краток, а ответы будут развернутыми!

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

В настоящее в время существует огромное количество сетей распределенных вычислений. Я насчитал порядка 30. Наиболее крупные — Folding@home, BOINC, SETI@home, Einstein@Home, Rosetta@home (по результатам их вычислений было написано несколько десятков диссертаций). Вычисляют они все, что только можно вычислять распределено — от подбора md5 паролей до симуляции свертывания белка.
Каждая из эти сетей имеет необычно высокую производительность и включает в себя миллионы нодов. Производительность каждой сравнима с производительностью суперкомпьютера.

• Rosetta@home — более 110 Тфлопс
• Einstein@Home — более 355 Тфлопс
• SETI@home — более 560 Тфлопс
• BOINC — более 5.6 Пфлопс
• Folding@home — более 5.9 Пфлопс
• Bitcoin — более 9.4 Пфлопс

Сравните с суперкомпьютерами:

• Blue Gene/L (2006) — 478.2 Тфлопс
• Jaguar (суперкомпьютер) (2008) — 1.059 Пфлопс
• IBM Roadrunner (2008) — 1.042 Пфлопс
• Jaguar Cray XT5-HE (2009) — 1.759 Пфлопс
• Тяньхэ-1А (2010) — 2.507 Пфлопс
• IBM Sequoia (2012) — 20 Пфлопс

А теперь, давайте, подсчитаем существующий неиспользуемый потенциал пользователей интернет:
По расчетам на конец 2010 года пользователей Инернет было около 2000000000 (2 млрд).
Каждый пользователь имеет хотя бы 1 ядро процессора производительностью не менее 8 Гфлопс (AMD Athlon 64 2,211 ГГц).

По нехитрым математическим расчетам производительность такой сети составит:
8 * 109 * 2 * 109 = 16 эксафлопс (10¹⁸).
Такая сеть в 800 раз производительней, чем ещё не построенная IBM Sequoia (2012), в 1700 раз производительней, чем сеть Bitcoin и производительней всех суперкомьютеров и вычислительных сетей вместе взятых! Сейчас число пользователей ПК и Интерент растет, растет и число ядер. Безусловно, это число (16 эксафлопс) идеальное, никто не будет вычислять 24/7, но если каждый пользователь будет вычислять хотя бы 2 минуты в день (что, впринципе, более чем реально), то такая сеть сравнится с IBM Sequoia.

Сейчас распределенные браузерные вычислительные сети на JavaScript более чем реальны.

Всем привет. Данная статья посвящается методологии Разработки через тестирование (TDD) в применении c JavaScript.
Напишу лишь вкратце о методологии TDD, более подробную информацию можно почерпнуть из ссылки выше.

Разработка через тестирование подразумевает, что перед написанием кода необходимо:

• создать тест, который будет тестировать несуществующий код, тест соответственно не пройдет
• написать код и убедиться, что тест прошел
• почистить код
• повторить

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

13 мая компания CloudMade (со-основатель компании — основатель OpenStreetMap Стив Кост) объявила о новой open source JavaScript-библиотеке для любых карт под названием Leaflet.

Как написал Mourner (он же на Хабре — Mourner), автор этой библиотеки, живущий в Киеве (кстати, он будет рад услышать отзывы и ответить на ваши вопросы на форуме OpenStreetMap и здесь на Хабрахабре):

«Leaflet задумана как библиотека, одинаково хорошо работающая и на десктопных браузерах, и на мобильных устройствах (iPhone/iPad, Android) — очень быстрая, легковесная, с простым API, красивым и понятным ООП-кодом. В отличии от OpenLayers (самого популярного выбора на сегодняшний день) мы не пытаемся впихнуть в нее все фичи, о которых только можно помыслить, раздувая код до немыслимых размеров — только самое основное, минимальный набор, который удовлетворяет нужды 99% применений карт в онлайне (тайлы, маркеры, векторы, попапы), но реализовывая их максимально лучшим образом.»

Взаимодействие частей приложения друг с другом — важная часть архитектуры любой программы.
И существует немало паттернов для их реализации. Я бы хотел на примере веб-приложения показать применение одного из них, а именно — Event-driven модели.
Она хорошо известна любому frontend-разработчику — всякий раз, работая с событиями DOM, вы используете эту модель. Давайте попробуем построить на ней не маленькое веб-приложение — файловый менеджер.

Backbone.js это каркас для создания RIA JavaScript приложений, его автором является Jeremy Ashkenas, создатель CoffeeScript, Backbone является частью компании Document Cloud ей же «принадлежит» Underscrore.js. Backbone — очень легкая библиотека, помогающая вам создавать интерфейсы. Она может работать с любыми библиотеками, к которым вы привыкли.

Backbone это набор классов, размером менее 4Кб, которые формируют структуру вашего кода и помогают создавать качественные MVC веб-приложения.

Backbone формирует структуру тяжелых JavaScript приложений, внесением моделей с key-value подобным хранилищем и своими событиями, коллекций с богатыми API, видов (ориг. views) с декларативной обработкой событий и соединяет все это в в одно приложение, поддерживающее RESTful JSON интерфейс.

Backbone не может работать без Underscore.js. Для поддержки REST API и работы с DOM элементами в Backbone.View настоятельно рекомендуется подключить json2.js и jQuery-подобную библиотеку: jQuery или Zepto

В статье будет рассмотрена структура Backbone.js, будет поэтапно создано простое Todo приложение.

От переводчика: В статье есть несколько JavaScript нюансов, которые могут быть интересны и тем, кто далек от CoffeeScript

Как и все программисты, я осторожен в отношение CoffeeScript. Как может, немного синтаксического сахара, оправдать дополнительный шаг компиляции?

Но, после того как я поиграл с CoffeeScript, всего несколько дней, я понял, я никогда не вернусь назад. Синтаксический сахар — это только начало. Я стал писать код быстрее, и с меньшим количеством ошибок, потому что он, стал намного чище. CoffeeScript помогает придерживаться хорошего стиля в написание кода. Ниже я приведу несколько примеров на Javascript и опишу их более изящное решение с помощью CoffeeScript.

В пятой редакции ECMAScript был представлен строгий режим (далее в статье Strict Mode). Strict Mode накладывает слой ограничений на JavaScript, он отгораживает вас от опасных частей языка (те части, которые есть исторически, но лучше чтобы их не было) и позволяет снизить вероятность ошибки.

Пока читал эту статью я написал 38 тестов, покрывающих все правила Strict Mode, объявленные в спецификации ES5. Вы можете посмотреть насколько ваш браузер поддерживает эти справила вот тут.



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

Firefox 4 уже полностью поддерживает Strict Mode, а Chrome 11 практически полностью. Strict Mode уже не за горами — давайте изучим его подробнее!

CANVAS шаг за шагом:

1. Основы
2. Изображения
3. Понг
4. Пятнашки

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

Прокси — это новые объекты JavaScript для которых программист должен определить своё поведение. Стандартное поведение всех объектов определено в движке JavaScript, который чаще всего написан на C++. Прокси позволяют программисту определить практически любое поведение объекта JavaScript, они полезны для написания базовых объектов или оберток функций или для создания абстракций виртуальных объектов и предоставляют API для мета-программирования. Сейчас Прокси не входит в стандарт, но его стандартизация запланирована в ECMAScript Harmony. Чтобы избежать путаницы уточню, что эти Прокси не имеют ничего общего с прокси серверами.

Где их можно использовать

1. Общие промежуточные абстракции
2. Создание виртуальных объектов: обертки существующих объектов, удаленные(от слова далекий) объекты, ленивое создание объектов (Пример ORM — Ruby ActiveRecord, Groovy GORM)
3. Прозрачное ведение логов, трассировки, профилирования
4. Внедрение предметно-ориентированных языков
5. Динамический перехват несуществующих методов, создание отсутствующих методов (__noSuchMethod__)
6. База для специфичных итераторов

Есть простейший с виду код:

setInterval(function(){
     var xhr = new XMLHttpRequest();
     xhr.open('GET', 'json.txt', true);
     xhr.onreadystatechange = function() {
        if(this.readyState == 4 && this.status == 200) {
           console.log(this.responseText);
        }
     };
     xhr.send('');
}, 500);

Если оставить этот код работающим в, например, Google Chorme, скажем, на 1 час, он съедает память. Съедает методично. Если посмотреть в Developer Tools на профиль использования памяти видно что память таки чистится GC но не до конца. Со временем минимальная точка на графике после GC растет.



Аналогично рост потребления памяти видно и по about:memory. «Отжир» памяти стабильно видно и в FF…

Важное...

• Файл json.txt лежит на localhost, его загрузка не занимает более 500мс гарантированно (я проверял).
• Вывод в консоль я тоже отключал — память по прежнему отжирается.
• EDIT без включенных developer tools — тоже течет, видно на about:memory.

Кроме этого кода более на данной странице никакого кода нет вообще.

Возможно я не понимаю как работает GC в JS, но по моему понятию тут нечему течь и нечему жить вечно. Может кто-то объяснить почему?

P.S. «Настоящей» утечки таки нет, если обновить страницу — память очищается.
P.P.S. Есть локальная жизненна потребность («требования бизнеса») оставлять подобный по структуре код на гораздо большие промежутки чем 1 час.

UPD: Оказывается есть даже тикет в хромиуме: code.google.com/p/chromium/issues/detail?id=52411
UPD: Якобы fixed in 9, но я проверяю на 10.

arguments — очень специфическая штука, о которой новички и даже любители знают только то, что это «вроде массив, но какой-то неправильный». На самом деле, у него есть ряд интересных особенностей. Предлагаю в топике пофантазировать на тему TypeHinting, аргументов по-умолчанию и всякого другого.

(function (foo, bar) {
	console.log(typeof arguments); // ?
	
	arguments[0] = 42;
	console.log(foo); // ?
})(10, 20);

А также покажу интересную идею-библиотеку

function test (foo, bar) {
    Args(arguments).defaults(100, 100);

    return [foo, bar];
};

test(      ); // 100, 100
test(15    ); //  15, 100
test(21, 42); //  21,  42

От переводчика: Я думаю многие читали статью Rey Bango — What to Read to Get Up to Speed in JavaScript, но до хабра обсуждение так и не докатилось. Предлагаю закрыть этот пробел и поговорить о хороших книгах, блогах, тренингах и конференциях, посвященных в первую очередь клиентскому JavaScript и клиентской веб-разработке. Чтобы не копипастить оформляю статью в виде перевода.

Сейчас в рассылке JSMentors JavaScript идет обсуждение книг, который стоит прочитать, чтобы улучшить свои знания. Там было много позитивных отзывов и предложений. Я хочу показать вам те книги и интернет-ресурсы, который я считаю важными и которые помогут вам в обучении. На этой странице я перечислил большое количество источников, разделенных по уровням.

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

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

В своём фреймворке AtomJS я активно использую аксессоры — геттеры и сеттеры:

Foo = atom.Class({
    get bar () {
        return this._bar;
    },
    set bar (bar) {
        this._bar = bar;
    }
});

Я уже описывал теорию, но в топике я расскажу о том, как заставить их работать во всех современных браузерах, а именно — как разрулить ситацию с тем, что Internet Explorer 9 ничего не знает о __defineSetter__ и подобных методах.

За нахождение хорошей фотографии спасибо ant99 а также фотографу.
Некоторое время назад я писал о том, как блокировать видимость в JavaScript с помощью конструкции let. Как оказалось из комментариев, let (как и JavaScript 1.7-1.8.5) поддерживается только браузерами на основе обезьянок и Rhino. Меня постигло разочарование, но минут 15 назад я придумал (хотя это громко сказано, наверное, и до меня было уже придумал кто-то) костыль для не такого красивого, но тем не менее рабочего кода. Он использует конструкцию with (да, я знаю, что она причислена к Bad Parts из-за ненужности и неэффективности, но вот прямо сейчас я опровергну первое утверждение).