Здравствуйте, kr510, Вы писали:

K>>>Круто! Только зачем?
EP>>* портирование готовых библиотек и приложений
EP>>* создание веб-приложений в которых и для клиентского и для серверного кода используется C++
K>Техническая сторона понятна, но по прежнему не понятно в чем "business case". На JS масса билиотек и фрейморков для написания UI, зачем еще надо вставлять в него C++.

Чтобы получить доступ к ещё большему колличеству библиотек. Например.

K>Люди пишут на С++, чтобы оптимизировать приложение для платформы.

Не только. Иногда это просто кросс-платформенность.

K>Как раз для того, чтобы сократить время загрузки runtime, убрать микро лаг при обработки событий и уменьшить потребляемую память. Всё это вернётся при конвертации.

Ты думаешь JS->C++ (UPD: опечатка, должно быть "C++ -> JS") будет хуже чем ручной JS?

EP>>* создание быстрого JS кода — там выходной JS получается со многими C++ оптимизациями
K>В это не верится совсем. Есть код на C++ скомпилированный в машинный код, теперь его конвертируешь в JS и интерпретируешь браузером. Странно очень звучит, что JS-посредником исполнение будет быстрее. Вероятно, это ошибка измерения.

Я не сказал что C++ -> JS работает быстрее native C++.
Я говорю что JS -> C++ (UPD: опечатка, должно быть "C++ -> JS") получается очень быстрым, быстрее чем ручной JS, и даже быстрее чем C#.

EP>>* кросс-платформенные приложения работающие на десктопах, мобильных устройствах и веб
K>Это громкое заявление. На мобильных устройствах использование HTML5+JS чтобы запускать конвертируемый C++ не сработает. Просто HTML5+JS — это тормоза и тупо проигрывает нейтив коду (ObjectiveC, Java). Не шансов что производительность HTML5+JS смогут подтянуть и это еще не считая интерпретатора C++ сверху всего.

Я имел в виду использование C++ как ядра приложения. То есть будет отдельно web-приложение, отдельно приложение для мобильных устройств (не-web), отдельно для десктопа. И везде ядро на C++.