Адекватный аналог CrossBridge для JS?
 

Проблема, объективно вытекающая из миграции AS3->JS.

Для каждой новой игры мы получали сишную библиотеку, с помощью CrossBridge (http://crossbridge.io/) паковали ее в swc-контейнер, который дальше включали в проект. Этот контейнер имел методы, которые торчали наружу и за которые его можно было дергать, а внутри контейнера был соответствующий класс, описывающий взаимосвязь этих методов с методами сишной библиотеки. Для простоты понимания - эта библиотека предназначена для генерации игровых данных и включает в себя 80-100 файлов, общий размер примерно 400к, около 12к строк кода. Сама библиотека используется для разработки и отладки. В продакшн-версии игра работает с сервером.

Теперь мне надо найти аналогичное решение для JS. Посмотрел Emscripten (http://kripken.github.io/emscripten-site/index.html), но что-то мне не показалось, что это то, что нужно. Нет, вероятно, с помощью Emscripten решить задачу можно, но нет ли способа попроще?

В принципе, я рассматривал вариант оставить все как есть, компилировать в swc, делать на его основе swf, цеплять к браузеру и лазить в него из JS, но что-то мне кажется флеш тут явно лишний.

Ни у кого не было опыта решения аналогичных задач?

Добавлено через 23 минуты
Кстати, нашел еще Native Client:
https://developer.chrome.com/native-client

Кто-нибудь пробовал использовать?

https://github.com/node-ffi/node-ffi - это работает через libffi (я не уверен, что это поддерживается в Виндовсе). Т.е. эти обвязки немного ограничены в том, что они могут делать, но, с другой стороны, это позволяет работать с библиотеками на Си из ж.скрипта. Опять же, только в Ноде, но, если для тестов, то другого и не нужно, наверное... или нужно?

Я остановился на Native Client.
Внешне выглядит именно так, как я и хотел - сишная программа упаковывается внутрь плагина как в контейнер, при этом есть возможность передавать в него вызовы со стороны js и по листенеру получать результаты работы кода внутри плагина.

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

Работает только в хроме, но этого достаточно.

А собирать нужно именно на Питоне?
Вобщем, все билд системы очень плохие, но если выбирать из плохого не самое плохое, то SCons - вполне подходит для таких целей. WAF - этo типа "улучшеный" клон SCons, но... ну вобщем это больное место. Я могу много плохого про них рассказать.
Из интересных (но опять же, плохих) вариантов: tup, но это на Си + чуть-чуть Луа. Плохо, но зато очень быстро.

А по поводу НаКла... и вообще подхода. Я понимаю, что лезу с наставлениями, но не проще ли было дать разработчикам примитивный сервер имитирующий настоящий? Если сервер не работает на "любимой" (я так понимаю, что Виндовс, иначе таких проблем не возникло бы?) операционной системе разработчика - то всегда можно спаковать его в минимальный ВМ (типа бизибокса) и дать разработчикам Вагрант файл, например.

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

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

Выглядит немного диковато, согласен.

Ну, в такой ситуации я бы сделал следующее:
1. SWIG + обвязки для Питона для сишной библиотеки (это при наличии нормальных ашек просто генерируется и ничего писать не нужно).
2. На Питоне пишется сервер с использованием чего-то типа SimpleHTTPServer - это примерно занимет один файл на 200-300 строчек.

Выгода в том, что на стороне клиента не будет разницы между тестовым и рабочим кодом. Ну и еще плюсы в том, что если подозревеать код сервера, то его легко отладить теми же GDB / PDB. НаКл выполняется в сендбоксе куда так просто не подобраться (для него нужен свой отладчик). Ну и он как бы живет очень полноценной и активной жизнью, общается с хостом и т.д.

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