Наши партнеры

UnixForum





Библиотека сайта rus-linux.net

Processing.js

Глава 17 из книги "Архитектура приложений с открытым исходным кодом", том 2.

Оригинал: Processing.js
Автор: Mike Kamermans
Перевод: А.Панин

Для чего использовать язык JavaScript, если он не совместим с Java?

Это не бессмысленный и имеющий множество вариантов ответа вопрос. Наиболее очевидный ответ заключается в том, что интерпретатор языка JavaScript поставляется в составе браузера. Вам не придется "устанавливать" программные компоненты для поддержки языка JavaScript самостоятельно, не требуется плагина для загрузки перед использованием приложений; все необходимое уже здесь. Если вы хотите портировать какое-либо приложение для работы в веб-окружении, вам придется столкнуться с языком JavaScript. При этом, учитывая гибкость языка JavaScript, выражение "столкнуться" на самом деле никак не говорит о том, насколько мощным является язык. Таким образом, одной из причин для выбора языка JavaScript является то, что "этот язык уже здесь". Практически любое интересующее нас устройство на сегодняшний день поставляется с поддерживающим язык JavaScript браузером. Это утверждение не справедливо в случае языка Java, который все реже и реже распространяется в форме предустановленного программного компонента в том случае, если он вообще доступен.

Однако, корректный ответ заключается не в том, что язык JavaScript "не может" выполнять те функции, которые выполняет язык Java; он может выполнять их, но при этом будет работать медленнее. Даже с учетом того, что изначально язык JavaScript не поддерживает некоторые возможности языка Java, следует помнить о том, что он является Тьюринг-полным языком программирования и может эмулировать работу любого другого языка программирования со снижением скорости работы. Технически мы могли бы разработать завершенную реализацию интерпретатора языка Java с наборами объектов String, разделенными моделями переменных и методов, ориентацией на объекты, классы и их экземпляры со строгими иерархиями классов и любыми другими функциями, существующими под солнцем и реализованными работниками компании Sun (или, на сегодняшний день, компании Oracle), но это не то, для чего мы хотим использовать его: библиотека Processing.js предназначена для преобразования кода Processing в характерный для веб-окружения код с применением такого малого объема вспомогательного кода, как это необходимо. Это значит, что хотя мы и приняли решение о поддержке некоторых специфичных для языка Java возможностей, наша библиотека имеет одно весомое преимущество: она работает со встроенным в страницы кодом на языке JavaScript очень и очень хорошо.

Фактически во время встречи между разработчиками проектов Processing.js и Processing в помещении компании Bocoup, расположенной в Бостоне, в 2010 году Ben Fry спросил John Resig о том, почему он использует замену с помощью регулярных выражений и только частичное преобразование кода вместо создания системы разбора кода и компилятора. Ответ от John заключался в том, что для него важно сохранение возможности смешивания пользователями синтаксиса Processing (Java) и JavaScript без необходимости выбора одного из них. Этот изначальный выбор был ключевым для формирования философии проекта Processing.js. Мы выполнили большой объем работы для предоставления возможности использования этого подхода в рамках нашего кода и четко видим результат этой работы при рассмотрении работ всех создателей "классических веб-приложений", которые используют библиотеку Processing.js и никогда не использовали язык программирования Processing, при этом успешно смешивая синтаксические конструкции языков Processing и JavaScript без лишних проблем.

В следующем примере показано, как может функционировать код со смешанными синтаксическими конструкциями из языков JavaScript и Processing.
    // Код на языке JavaScript (должна быть сгенерирована ошибка при использовании в Processing)
    var cs = { x: 50,
               y: 0,
               label: "my label",
               rotate: function(theta) {
                         var nx = this.x*cos(theta) - this.y*sin(theta);
                         var ny = this.x*sin(theta) + this.y*cos(theta);
                         this.x = nx; this.y = ny; }};

    // Код на языке Processing
    float angle = 0;

    void setup() {
      size(200,200);
      strokeWeight(15); }

    void draw() {
      translate(width/2,height/2);
      angle += PI/frameRate;
      while(angle>2*PI) { angle-=2*PI; }
      jQuery('#log').text(angle); // Код на языке JavaScript (ошибка при использовании в Processing)
      cs.rotate(angle);           // Корректный код как на языке JavaScript, так и на языке Processing
      stroke(random(255));
      point(cs.x, cs.y); }

Многие вещи в языке Java являются обещаниями: строгая типизация является обещанием для компилятора, относящимся к данным, область видимости является обещанием того, кто будет вызывать методы и ссылаться на переменные, интерфейсы являются обещаниями о том, что экземпляры классов содержат методы, описанные в рамках интерфейса, и.т.д. Нарушение этих обещаний приведет к жалобам компилятора. Но в том случае, если вы не нарушаете их, что является наиболее важным аспектом архитектуры библиотеки Processing.js, вам не понадобится дополнительного кода для выполнения этих обещаний, чтобы программа работала. Если вы устанавливаете числовое значение переменной и ваш код рассматривает эту переменную как числовую, то в конце концов объявление var varname ничем не хуже объявления int varname. Вам необходима типизация? При использовании языка Java это так; в случае использования JavaScript она не требуется, поэтому зачем принуждать разработчиков использовать ее? Аналогичный подход используется в отношении других обещаний. Если компилятор языка Processing не жалуется на ваш код, мы можем убрать все точные синтаксические конструкции, соответствующие описанным обещаниям, и код все так же будет работоспособен.

Этот подход сделал библиотеку Processing.js чрезвычайно часто используемой при создании визуализаций данных, мультимедийных презентаций и даже развлекательных приложений. Скетчи, созданные с использованием классического синтаксиса языка Processing, работают, при этом скетчи, в которых смешивается синтаксис языков Java и JavaScript, также отлично работают, как впрочем и скетчи, при создании которых используется классический синтаксис языка JavaScript и которые рассматривают библиотеку Processing.js в качестве улучшенного фреймворка для рисования на канве. После приложения участниками проекта усилий к созданию альтернативы классическому языку программирования Processing без жесткого требования исключительного использования синтаксиса языка Java, проект стал использоваться широким кругом пользователей, представленным в масштабе всей сферы веб-технологий. Мы наблюдали примеры использования библиотеки Processing.js в масштабе всей глобальной сети. Все компании, начиная с IBM и заканчивая Google, создавали приложения для визуализации, приложения для создания презентаций и даже простые игры с помощью Processing.js - библиотека Processing.js набирала вес.

Другой замечательной особенностью процесса преобразования кода, использующего синтаксис языка Java в код, использующий синтаксис языка JavaScript, при условии невмешательства в уже существующий код на языке JavaScript является то, что мы реализовали возможность, о которой даже не думали: библиотека Processing.js получила возможность работы с любыми приложениями, которые используют язык JavaScript. Одной из действительно интересных вещей, которую мы наблюдаем на сегодняшний день, например, является то, что люди используют язык CoffeeScript (изящно упрощенный язык программирования похожий на Ruby, в ходе работы которого происходит транскомпиляция кода в код на языке язык JavaScript), комбинируя его с библиотекой Processing.js, и добиваются по истине превосходных результатов. Даже если бы мы намеревались создать "язык программирования Processing для веб-приложений", осуществляющий разбор синтаксических конструкций языка Processing, люди воспользовались бы результатами нашей работы и добавили поддержку совершенно новых синтаксисов. Но они никогда не сделали бы этого в том случае, если бы мы реализовали библиотеку Processing.js в форме простого интерпретатора Java-кода. Используя преобразование кода вместо реализации его интерпретатора, библиотека Processing.js поспособствовала широкому распространению языка Processing в сфере веб-приложений в более значительной степени, чем это могло бы случиться при исключительном использовании синтаксических конструкций языка Java, или даже в том случае, если бы использовался исключительно синтаксис языка Java, но выполнение приложений осуществлялось с привлечением средств языка JavaScript. Использование нашего кода не только конечными пользователями, но и разработчиками, пытающимися интегрировать его со своими технологиями, выглядело удивительно и вдохновляюще. Было ясно то, что мы делаем что-то правильно и сообщество веб-разработчиков довольно результатами нашей работы.

Результат

В преддверии релиза библиотеки Processing.js версии 1.4.0 следует отметить то, что результатом нашей работы уже является библиотека, с помощью которой можно выполнить любой переданный скетч при том условии, что он не импортирует функций из скомпилированных Java-библиотек. Если вы можете разработать приложение на языке Processing, и оно будет корректно функционировать, вы сможете также разместить его на веб-странице и просто запустить его. Из-за различий в методах доступа к аппаратному обеспечению и в низкоуровневых реализациях различных частей конвейера обработки изображений, появятся различия во временных интервалах, но в общем случае скетч, который выводит изображение с частотой 60 кадров в секунду при работе в Processing IDE будет выводить изображение с такой же частотой 60 кадров в секунду при работе на современном компьютере с современным браузером. Мы достигли точки точки развития проекта, в которой число сообщений об ошибках начало сокращаться и большая часть работы заключается не в добавлении новых возможностей, а в исправлении и оптимизации кода.

Благодаря усилиям множества разработчиков, работающих над исправлением более 1800 ошибок, описанных в сообщениях пользователей, скетчи на языке Processing "просто работают" при использовании библиотеки Processing.js. Даже те скетчи, которые импортируют код библиотек могут работать в том случае, если в распоряжении имеется исходный код используемой библиотеки. При благоприятных обстоятельствах библиотека может быть разработана таким образом, что у вас будет возможность преобразовать ее к виду, использующему классический синтаксис языка Processing, путем выполнения нескольких операций поиска и замены строк. В этом случае код может начать работу в виртуальном пространстве незамедлительно. В том же случае, когда библиотека предоставляет такие функции, которые не могут быть реализованы с использованием классического синтаксиса языка Processing, но могут быть реализованы с использованием классического синтаксиса языка JavaScript, потребуется дополнительная работа для эффективной эмуляции библиотеки с помощью кода на языке JavaScript, но портирование все так же возможно. Единственными функциями, при использовании которых код на языке Processing не может быть портирован, являются функции, по своей сути не доступные для браузеров, такие, как функции для непосредственного взаимодействия с аппаратным обеспечением (таким, как веб-камеры или платы Arduino) или функции, выполняющие необрабатываемые операции записи данных на диск, хотя даже эта ситуация меняется. Браузеры постоянно расширяют свои функции для возможности выполнения все более сложных приложений и актуальные на сегодняшний день сдерживающие факторы через год могут исчезнуть, таким образом, можно надеяться на то, что в не очень далеком будущем даже те скетчи, которые на данный момент невозможно запустить в браузере, смогут быть портированы.


Далее: Компоненты кода