← All posts tagged JavaScript

SannySanoff
programming faggots интеллектуальное_гопничество Вот эти люди со светлыми лицами хотят быть хозяевами дискурса, мля.

pbs.twimg.com

GraphQL сделает с REST то, что JSON сделал с XML.

Это просто потрясающе!

Они хотят сказать, что ихний json что-то сделал с нашим XML. Да этот json появился, потому что в языке javascript (во время оно) не били по рукам за eval(), и тогда какой-то главный сумасшедший задумался, а чем это хуже, чем XMLDocumentBuilder.parse(), и человечество свернуло в гнилой закоулок, где с этим json до сих пор мучается, не в силах бросить каку.

Вот они, эти люди со светлыми лицами, смотрите на них.
SannySanoff
идея внезапно WWW продуктивность Я вот щас придумал future web app platform. Без всякого гомняного CSS HTML и жабоскрипта, всяких gulp grunt uglify и 100 прочего унылого однодневного crap, а будет как старый добрый виток desktop apps, ну всякие там Swing, Windows Forms итп.

Короче, DOM используется чисто как девайс для постскрипта. Есть шрифты, есть их метрики, известны размеры. Есть output device (document.body.clientWidth x height), расставляй себе буквы как пожелаешь. Линии там рисуй (через канвас получится). Поля ввода тоже расставляй, они без рамок и паддингов, рамки и паддинги рисуются как линии если чо.

Всякие layout managers и вообще весь код — приходят в бровзер на webassembly и они работают быстрее чем встроенный в бровзер, т.к. специализация и никакой тебе backward compatibility 20 лет. Если сайт хочет, он вообще изобретает себе сам язык разметки, кладет в бровзеру в кеш webassembly килобайт 300 и с тех пор он сам себе HTML. А разработка ведется на каком-нибудь в натуре dart-подобном языке (который удобен тем, что весьма динамический, но аннотирован типами и нормально компилится в llvm и как следствие в вебасм)

Кроме того, Дартиум (или прочий бровзер с поддержкой VM для норм языка разработки, отличного от javascript) становится не нужен (он уже и так помирает в случае дарта, но по своим причинам). Пишешь ты как прежде было в GWT — прямо в IDE на любимом язычке который нативно вертится в своей VM, а всякое отображение с евентами рисуется удаленно по TCP в бровзере, и никакого DOM описания не гоняется там по протоколу, боже упаси, исключительно "нарисуй строку там", "картинку сям (и вот так)", а тут жолтеньким подкрась. Так как HTML layout весь отсутствует, тяжелый DOM с вложенностью двадцать уровней — отсутствует, то анимации "вручную" должны норм летать, если что.

Да, и здесь полностью становится не нужен GC на жабоскрипте, да. Хотя конечно DOM bridge будет что-то кушать, но немного.

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

Станет разработка под бровзер приятной как раньше.

Запомните это псто!
SannySanoff
programming faggots Далее про react native, зашкаливающий режим WTF у меня.

1) Есть там способ из нативного кода отправить евент в жабоскрипт (в жабоскрипте на него можно подписаться, это рекомендуемый способ достучаться из нативного в жс) — работает почти всегда. Перестает работать (то есть не доходит в js) если однажды там случился exception. Или если ты хотя бы раз перезагрузил новую версию жабоскрипта через релоад. Не шутки! Иногда просто не работает с первого раза, но такое редко. Однажды настаивало мне что "нет подписчиков", хотя вон они есть, никуда не девались, код написан, не менял. Рестарт аппа почти всегда помогает. Асинхронная инициализация это вам не шутки, наверняка где-то racing conditions, но почти всегда работает. Ах это "почти", как ты прекрасно!... Залез было в отладчике, но через полчаса отложил на потом.

2) Иногда перестает работать код релоад. Вот ты поменял, нажал релоад, а оно на экране старая версия. Предыдущий раз подхватывало. Да, изменение записано в файл. Да, подождал чтобы packager подхватил. Нет, ошибки никуда не рисует.

3) добавил textinput — не показывает ввод текста. Поставил ему чтобы его увидеть цветной background — нету такового на экране. Как будто нету компонента. Поставил ему initial value значение — нарисовало тупо текст как в <Text>, но не редактируется, и ощущение, что высота его 1 пиксель, потому что налазит на него нижележащий компонент. Оказывается, нужно явно прописать высоту. Какую? А 40 попугаев прописать, будет как родной. DPI/системные дефолтные шрифты/акцессибилити/large text — не слышали.

4) добавил новую либу в проект, написал require ее — обрадовало "babelHelpers.typeof is not a function" и full stop. Пишут, packager --resetCache помогает. Запустил, та же ошибка. Закомментировал require назад — та же ошибка. Еще раз потом ресетнул кеш — не помогло, та же ошибка. Еще раз ресетнул и перезапустил весь апп — ошибка пропала, нигде не ругается, но белое окно, инициализационных сообщений нет. Девелопмент остановлен, режим WTF, незапланированные сношения с фреймворком, гуглинг, дебаггинг (собственно это и сподвигло написать псто).

Вот codenameone тоже поделка такая же, что особый подход нужен, и особая к нему passion, чтобы из него конфету сделать, но, господа реактовцы, хороших намерений одних мало, если взяли не Жабу чтобы лепить самолет, а коричневый пластилин (javascript). Нужно хоть ошибки куда-то выводить хотя бы, хоть как-то пластилин компенсировать! Поделки поделками, но говенный материал должен быть оправдан великолепным исполнением изделия, а где оно?

SannySanoff
Java programming JavaScript v8project.blogspot.com

А вот когда в жабоскрипт введут опциональную типизацию и напишут (только благодаря этому! потому что смогут!) на нем наконец-то серверный Spring (springframework.org), он будет медленнее запускаться (startup) чем жабовый или быстрее? Вангую что к тому времени процессоры подтянутся и будут все те же 30-40 секунд.
SannySanoff
programming fun Неспособные освоить велосипед обречены его переизобретать.

React (javascript framework) приключения. Особенно понравились имена некоторых js файлов. И эти люди нам пеняют нам на SomeFactorySingletonFrameworkBuilder-ы 8)

medium.com

SannySanoff
Google А вот Chromecast.

Придумал кто-то в гугле девайс. Девайс простой, одним концом тыкается в HDMI (в телевизор), а другого конца у него нет (вру, конечно, в нем есть USB дырка для питания 5 вольт через проводок в соседний USB разъем в телевизоре, получается Вечный Кайф).

Внутри девайса аппаратные аудио-видео кодеки и Wi-Fi с веб-сервером, и небольшое место для микро-программ, которые тоже вертятся на местном ЦПУ и умеют показывать заголовки и логотипы поверх видео не телевизоре, куда он воткнут.

Сверхлегкая установка: если девайс включен в 5 вольт и не видит знакомой Wifi сети, он запускает wifi-хотспот, который виден с венды или с андроеда (линух не проверял), там ты запускаешь софтинку, оно соединяется, уговаривает его перейти на домашний wifi, и дальше все уже в родной сети, все видят друг друга.

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

А дальше гугловое счастье: открытый SDK, и извращайтесь в указанных рамках как хотите.

А рамки хитрые: SDK работает только под андроедом, под IOS и под Google Chrome (который работает под остальными платформами).

Злой, коварный гугл. Гугл контролирует (смотрим конфигурацию с десктопом)
1) апдейты в девайс — и стало быть протокол, которым девайс общается с инициатором
2) google chrome chromecast addon — реализацию протокола на стороне инициатора и javascript API
3) галерею приложений, которые могут вертеться на девайсе (хостит всё у себя)

Но тем не менее, пространство для маневра есть, и остаток этого поста — про манёвр.

Первоначально SDK к этому всем не было, и можно было втыкать на телеке только в Ютуб и еще в несколько сайтов. Потом chromecast addon в гугле допилили, и можно кастить таб в бровзере. Почему таб? Потому что внутри хрома можно получить картинку из таба и звук из таба, зажать это в видеопоток и сказать железке, торчащей в телевизоре, играть его over wifi. А если в табе открыто чисто mp4 видео, то можно его даже отдавать железке как есть, оригинальный поток.

Но народ хотел играть любое видео. Поэтому какие-то умники откомпилировали под NaCl весь ffmpeg, и пережимают видео с диска на лету во время отдачи. NaCl — это такая платформа тоже под хром, с байткодом, который сначала эффективно транслируется в машинный код, но без фишек типа garbage collection, потому что в него компилят с языка C/C++ всякие Doom-ы и ffmpeg-и.

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

(На фоне этого Apple TV конечно размахивает лозунгом "а у нас всё — просто работает" и внизу лозунга приписано мелкими буквами "под MacOS и iOS конечно".)

Это всё очень забавно, и всё это заради только того, шобы не сувать HDMI кабель из ноута или телефона в dumb телек, и посмотреть на телеке south park.
SannySanoff
Java programming JavaScript Мучаюсь (кайфую) с RSA под бровзерами на жабоскрипте.

Вопрос "нафига"? Ответ: потому что сервер писал не я, а на сервер нужно отправлять XMLSec (xml с зашифрованными фрагментами). Да, овер HTTPS, да, я в курсе, что идиотизм. Ключ вшит в код, да, идиотизм, под названием легаси.

Основной проект на GWT, то есть компилируется с жабы на жабоскрипт. Короче, bouncy castle (java open source security framework) был прикручен мною уже давно но под IE 8 оно втыкает, выскакивал диалог, что жабоскрипт перетрудился, не хотите ли его отдохнуть. Тыканье "да продолжай сцуко" (чекбокс отсутствует) после 50 кликов меня утомило, но всё же захотелось посмотреть, сколько реально времени оно скушает.

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

Для того, чтобы RSA вообще заработало под IE, надо было перевести его в continuation-passing-style с трамплинами (или как это там называют профессора), чтобы их запускать по таймеру. Короче, вооружился рефакторилкой, перевёл, прооптимизировал чтобы работало непрерывными чанками по 500 миллисекунд, замедилось всё процентов на 20%, зато фурычит и диалоги не выскакивают. IE8 работал минут 10-11.

Делается (RSA encode + RSA decode) * 2 REST запроса, и внутри там еще сигнатура считается, тоже чтото на RSA основано.

95% времени оно сидит в операции умножения по модулю ( A * B % C ), которая реализована с помощью алогоритма Montgomery Product . Короче, все так делают. Все три числа большие, несколько сотен десятичных знаков каждое.

В bouncy castle этот алгоритм реализован на жабе с лонгами (long ints). Лонгов в жабоскрипте нету, GWT использует свою LongLib : эмуляцию на объекте с тремя полями целочисленными, по 22 бита на поле (всего выходит 66 бит, 64 стало быть влазит с головой). Лонг там такой:
{ l: 3984394, m: 31231902, h: 9878989987 }. Библиотека содержит умножение деление и весь остальной балаган. Лонги немутабельны, постоянно создается новый объект как результат любой операции.

Решил быть ушлым и забацать те же операции на мутабельном объекте, чтобы без аллокаций, и вдобавок чтобы отличаться, сделал на массиве a[0],a[1],a[2]. За основу взял существующую GWT LongLib, ибо хороша.

— убрал из внутреннего цикла все ссылки на глобальные переменные и this, засунул все в локальные переменнуе.
— заинлайнил в основной цикл всё что мог, все сложения и сдвиги
— убрал всякие проверки на ноль и обходы в умножениях интов, потому что там всегда будет реально везде не ноль и вообще прооптимизировал некоторое умножение лонгов, потому что там в них всегда реально 32 бита только нижние
— прооптимизировал повторные присвоения типа += , которые авторы сделали для красоты кода, сделал деревья выражений со скобками и теперь в локальных переменных только многажды упоминаемые значения.
— второй множитель передал не массивом (b[0],b[1],b[2]), а двумя аргументами b0 и b1, так как b2 всегда ноль, упростился вызывающий код, ушел временный массив.
— в самом конце взял сгенерированный JS код, убрал в нем ~~a[0], оставил a[0], потому что там в жабоскрипт переменной и так целочисленное изза предварительных вычислений.

По результатам: IE8 — говно и в данной задаче неюзабелен. Также фаерфоксу чото поплохело.

IE8(core i7 920): 800 сек -> 165 сек
IE9: ? → 7 сек
IE10: 22 → 5 сек
Хром: 4 → 2 сек
Опера 24: 5 → 6 сек
FF 23/Linux: 17 → 47 сек.
FF 31/Linux: 12 → 22 сек.
samsung I9082, browser : 40 → 12 сек
ipad: safari 84 → 15 sec
ipad: chrome 306 → 110 sec

По результатам профайлера в хроме GC занимал 20%, стал занимать 5%. Мелочь, а приятно.
Хром под IPAD втыкает потому что iOS анально огорожен и не позволяет JIT, а сафари там само себе его разрешает.
SannySanoff
programming gwt GWT умер. Нет, он еще выглядит как живой, но анальная огороженность (см ниже) его таки настигла. Да, революция была, но контр-революция победила. Мы всегда будем помнить тебя, GWT, прощай.

Технические подробности:

Одним из китов GWT была отладка в бровзере. Ты написал на JAVA очередную функцию (метод), нажал Run/Debug, и в бровзер с компилятора пришла javascript заглушка, и когда javascript выполнялся, управление (через GWT Development Mode бровзерный плагин) передавалось в JDK отладчик по ихнему протоколу, и ты пошагово шел по своей JAVA функции, модифицируя DOM в бровзере разными вызовами и рисуя гуй. Наблюдая переменные, устанавливая conditional breakpoints и прочие вкусняшечки, которые есть в JAVA.

Для тех кто в танке: я по шагам шел по JAVA коду в моей няшной IDE, а в бровзере в результате манипулировался DOM. Или провел мышкой над элементом, а мне IDE остановилось на JAVA точке останова в onmouseover клиентском коде, и там в аргументе функции был event.

Делалось это всё посредством гениально продуманной цепочки, в которую входил как один из компонентов бровзерный плагин (написанный на языке Ц), который автоматически активизировался в начале HTML странички.

Года 3 назад они (тогдашние авторы GWT) убили Firefox Plugin, потому что "каждая новая версия ФФ вносила какие-то изменения в то, как писать плагин и мы задолбались, а вот хром рулит!"

Умельцы же взяли код и держали этот ФФ плагин живым для новых версий ФФ. Потому что под ФФ он работал в 3 раза быстрее чем в хроме (в хроме там работает сразу несколько процессов, и межпроцессное общение занимает больше времени, так что и страница грузилась дольше и работала медленнее)

Года полтора назад они (авторы GWT) стали писать Super Dev Mode плагин, как альтернативный экспериментальный режим отладки. Это такая хрень, которая использует browser source maps (в жабоскрипте) таким образом, что у тебя, если я правильно понимаю, в бровзере показуется исходник на JAVA, и ты по нему шагаешь пошагово...и больше ничего. Переменные javascript у тебя с java кодом общего ничего не имеют, разные scopes, никакого evaluate java expression нету.

Короче, эта вся новая отладка в бровзере (супротив IDE) — бутафория. Для галочки. Ну или от совсем плохой жизни. В принципе, я успешно отлаживал изредка и сгенерированный GWT жабоскрипт, сгенерив его в читабельном виде, но то совсем в клинических случаях, и редко.

Но главное — зачем они это делают, зачем убивают гениальную идею? Я не понимал. Я относил это к БАО (см Лурк), думал, что первоначальные девелоперы из GWT ушли, а оставшаяся школота плавно сажает самолет в бездну.

На GWT я года полтора с тех пор не писал, уйдя в мобильный девелопмент, так что немного отстал от жизни, а в это время они зарелизили новую версию, и сообщили ( gwtproject.org ) : где-то в 2014 году мы убиваем клёвую отладку, а экспериментальная анально-ограниченная становится основной, хоть ее никто кроме хрома и не поддерживает вообще. А причиной (та-дам!) становится то, что Хром перестает поддерживать NPAPI плагины по причине (та-дам!) багов, дыр и сложности этой поддержки!! ( blog.chromium.org ). Взамен NPAPI предлагают какую-то несусветную фигню, в полной мере осознавая, что она не покрывает вообще никак то, что что покрывалось NPAPI, и надеясь, что экосистема в будушем доэволюционирует блаблабла ...

Регресс, сцуко, idiocracy(TM) и БАО . Как же скоро это всё у нас наступило!
SannySanoff
programming q Про мобильные платформы, производительность и javascript, кусок по линку из #2446477

"""Философия Javascript (если у него вообще есть философия) такова, что вы вообще не должны иметь возможности узнать, что именно происходит там с памятью. Точка. Это настолько невероятно оторвано от того, как реальные люди пишут мобильные приложения, что у меня нету даже слов чтобы выразить это. Видите ли, мы, яблокодеры под iOS, не верим в garbage collectors, и мы думаем, что андроидщики рехнулись. Я подозреваю, что андроидщики думают, что мы рехнулись по причине нашего прямого управления памятью. Но знаете ли вы, в чём у наших двух абсолютно оппозиционных групп есть консенсус? В том, что абсолютно рехнувшиеся — это чуваки, которые пишут на Javascript под мобильные ОС."""

Да там кроме джаваскрипта еще и веб-рендерилки — страшное тормозное нечто. Тяжко под мобло писать всякое динамическое HTML5, тяжко. В статье, кстати, еще и пророчества, что АРМ скоро умрет, не выдержав конкуренции с интелом.
SannySanoff
Java programming iOS Забил на эклипс с его битыми плагинами, поставил нетбинс, под него и установил нечто под названием codenameone (поставляется как plugin). Я, как любитель трансформаций исходного кода, не могу не поделиться теперь.

Короче, существует некий проект XMLVM, они берут байткод Java или даже CLR, преобразуют его в XML, потому что они любят XSL Transformations делать, затем трансформируют его так и эдак, и на выходе получают javascript, objective c и что-то там еще. Результирующий код — это ahead of time компиляция байткода.

Короче, в нашем случае оно компилится в objective c, и плюс там куча bindings к ios api, на java/native же, то есть на жабе пишешь прямо

UIWindow window = new UIWindow(UIScreen.mainScreen().getBounds());
ArrayList<UIViewController> list = new ArrayList<UIViewController>();
list.add(new WelcomePage());
controller = new UITabBarController();
controller.setViewControllers(list);
window.addSubview(controller.getView());

и так далее, и оно генерит objective-c код, который даже потом собирается. Понятное дело, что для всего используемого JRE оно тоже генерит С код, сколько надо. А код выходит вот такой:

XMLVM_ENTER_METHOD("org.xmlvm.demo.xokoban.GameController", "moveMan", "?")
XMLVMElem _r0, _r1 .....;
_r7.o = me;
_r6.i = 0;
_r5.i = 1;
_r0.o = ((org_xmlvm_demo_xokoban_GameController*) _r7.o)->fields.org_xmlvm_demo_xokoban_GameController.man_;
if (_r0.o == JAVA_NULL) goto label14;
_r0.o = ((org_xmlvm_demo_xokoban_GameController*) _r7.o)->fields.org_xmlvm_demo_xokoban_GameController.man_;
XMLVM_CHECK_NPE(0)

и так далее.

Короче, это всё круто, только генерится оно небыстро, и в конце компиляции это ж компилится посредством xcode, а откуда оно у меня на линуксе в процессе девелопмента?

Так что некие перцы взяли и поверх всего этого накатали уровень абстракции, абстрагируют UI, Filesystem, еще несколько подсистем, не все конечно. Короче, и реализация этого всего под несколько платформ, в том числе обычная десктопная Java, и вот, iOS (через XMLVM), и андроид там тоже есть, только XMLVM там ни при чём, оно прямо компилится. Процедура откомпилил-запустил занимает около 5 секунд в случае с десктопной жабой, то есть для девелопмента вроде даже и ничего.

Для целого класса applications это очень даже ничего, например вот взять juick advanced и порезав на куски портануть на ихний UI, после чего получить его под IOS.

Более того, там сбоку в XMLVM (возвращаемся от codenameone назад к немему) приписан еще android compatibility layer, то есть можно написать так, что андроидский проект прямо соберется для ios, то есть вот инфраструктура вся готова, мейкфайлы, изрядно (по сравнению с нулём) андроидского API предлагается.

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

Смысл моего поста в том, чтобы донести до масс

* названия проектов, о которых я вот не знал раньше или слышал краем уха
* факт, что оно зреет и удивительно зрелое уже сейчас (XMLVM)
* факт, что XMLVM это не только академическая компилялка байткода, а там уже подстелено изрядно соломки под разные нужды.

---------------------

Ну а еще я слышал, что где-то есть интерпретатор жабы на жабе же написанный. Это означает, что девелопить можно под этот интерпретатор, то есть ну вы поняли. Залить интерпретатор жабы на девайс, а дальше уже идет то, что я сейчас уже успешно делаю на LUA, только с нормальной типизацией и без всяких там лишних вызовов objective c. А когда уже надевелопился, откомпилировать — и вуаля.

Короче, у меня новый мысль для думания перед сном. Я в возбуждении. Мой внутренний структуральнейший компьютерный лингвист в возбуждении.
SannySanoff
programming gwt БАО Раннее предупреждение о БАО ( lurkmore.to ), назревающей в GWT.

Проникшие на ключевые позиции проекта извращенцы хотят отнять у нас главную фишку GWT, а именно, Hosted Mode (Dev Mode), отладку в Java IDE. Вместо этого нам предлагается в будущем отлаживать сразу жабоскрипт (!), а в утешение говорится что мы замапим вам source code жабы на javascript с использованием source maps, имеются в виду судя по всему "#pragma line" в приложении к javascript, новый стандарт, которого пока еще нигде нету.

Ясное дело, что никаких drop frame, evaluate expression с автокомплишнами, условных брекпойнтов там нету, т.к. это javascript runtime, который вообще у кого как, "зато работает во всех бровзерах".

Активные разрушители пишут (что собственно и вызвало сей пост): "мы надеемся, что альфа-тестерам понравится, и они еще и законтрибутят в проект, так шо постепенно этот режим [отладка жавоскрипта] сможет заменить классический Hosted Mode (Dev Mode)"

Источник: developers.google.com

Запасаем тушенку.
SannySanoff
programming непонятно Проблема: мой javascript application нормально работает на десктопных webkit, ненормально работает на встроенном в ipad webkit-бровзере. Отладчика и инспектора в нём нету, руками писать влом.

Решение: некие перцы (искать "weinre") написали хитрый javascript, линк на который вставляешь в свою динамическую страницу и он передает на свой сервер всё что видит в текущем документе (via DOM API), а ты подключившись к этому серверу, в приятном виде наблюдаешь, наподобие firebug, всё, до чего тот может достать.

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

Собственно вопрос.

Вот у них две версии. Первая версия написана на Жабо, в ней встроенный jetty, 20 классов на жабе, сервлет там принимающий, и раздающий, зависимости. UI инспектора написан на бровзерном javascript, дофига всего там.

Версия 2.0 написана на node.js. Сам я на node.js не писец. Навскидку открыл сервер-сайдный js и увидел там такое (внимание, на дворе 2012 год):

return '<ul id="files">' + files.map(function(file){
var icon = ''
, classes = [];

if (useIcons && '..' != file) {
icon = icons[extname(file)] || icons.default;
icon = '<img src="data:image/png;base64,' + load(icon) + '" />';
classes.push('icon');
}

return '<li><a href="'
+ join(dir, file)
+ '" class="'
+ classes.join(' ') + '"'
+ ' title="' + file + '">'
+ icon + file + '</a></li>';

}).join('\n') + '</ul>';
}

Это школьники? У них про template engines не в курсе? И про какое-нибудь model-view хотя бы.. Зачем node.js? Почему жабоскрипт на сервере? Почему это всё? Отчего деградация? По сравнению с первой версией отчетливо каменный век.

Непонятно.

Идет вторая версия без зависимостей, НО сетапится посредством местного для node.js менеджера пакетов "npr", о котором по ходу дела и узнал. Пакетных менеджеров развелось, пропасть: у скалы своё, мавены всякие еще есть, перлы, лиспы, все норовят. C умилением взираю на зоопарк.