Гениальная идея писать все библиотеки на C++ и юзать их в браузере через WASM, в чем подводные камни?
У библиотек есть одна проблема. Они работают только с тем языком (в лучшем случае - тем ABI, грубо говоря платформой), под которое они сделаны. И истинной кроссплатформенности особо нет.
Поэтому даже простые либы (вроде каких-то API-клиентов) приходится дублировать на многих языках, чтобы их могли юзать и в браузере, и в мобильных приложениях, и в десктопных, и на сервере (а там вообще целый зоопарк языков).
C++ обладает почти полной кроссплатформенностью, и это "почти" в основном обусловлено браузерами.
Так было до недавних пор. А сейчас есть wasm.
Отсюда идея, писать такие библиотеки на C++, юзать их в разных языках, делая обертки, а в браузерах (и Node.js) - юзать с помощью компиляции в WASM.
Один код, куча платформ. Ну и бонусом - быстродействие (далеко не везде, но местами полезно).
Так вот, какие тут подводные камни кроме:
1. C++ сложный язык, мало специалистов.
2. Несколько коряво, что модуль WASM надо сначала подгрузить и выполнить, и весь код должен этого ждать и лишь потом с ним работать.
3. Ну и самое очевидное: в WASM не особо удобно работать с DOM, BOM. Но раз уж мы хотим кроссплатформенность, то это само собой. Мы можем все это делать в обертках.
Сергей Сергей, ну в рамках мелких проектов, над которыми я работаю (не pet, но мелочь) я могу реализовать это. Но интересует мнение опытных людей, стоит ли, насколько оно странно. Оно ведь явно странно, но важно понять насколько оно странно и плохо. Может оно в будущем захватит мир, или найдет свою нишу и будет там применяться, или это очередной бред который не применяют не из-за сырости технологий (WASM), а потому что бред.
В своё время "js на сервере" было странно, хотя были какие-то jvm-штуки. Бредовость идеи останется в истории, когда от реализации идеи пойдёт ощутимая польза.
ThunderCat, хе-хе, а ведь и правда, похоже. Похоже на Java-апплеты в браузерах.
Но факт в том, что Java-апплетов в браузерах больше нет, видимо слишком дырявая технология получилась, да и быстродействием уж точно не славилось. Как раз у Java-приложений часто очень медленная "первичная прогрузка", а в браузере это никуда не годится.
А WebAssembly вроде не имеет особых дыр (им серьезно занимались серьезные ребята, которым он нужен для серьезных дел, а не только для этих модулей), и имеет высокое быстродействие. И он в браузерах есть.
Хотя... Вот как раз тут становится понятным один из подводных камней. Если WebAssembly вдруг в браузерах не станет, то мне с этими либами мало не покажется.
matroshin, для Rust есть байндинги к DOM и другому браузерному API для WASM, но этим мало кто пользуется, так как на деле получается медленно (сам WASM то быстро работает, но вот постоянная передача данных через границу WASM<->JS это самое узкое место), а так же занимает значительно больше место (на JS можно целые огромные приложения уместить в пару сотен килобайт, на WASM обычный Hello World в DOM весит 1.5 мегабайта WASM + 0.5МБ JS обертки)
А emscripten для C/С++ гораздо хуже отрезает неиспользуемый код чем wasm-bindgen для Rust
а деле получается медленно (сам WASM то быстро работает, но вот постоянная передача данных через границу WASM<->JS это самое узкое место)
Может и узкое. Но, думаю, что какие-то алгоритмы оно все же ускорит. Особенно, если обрабатываемых данных много и их все можно отправить разом и разом получить результат...
Ну, а основная цель у меня даже не в быстродействии, а в том, чтобы алгоритмы реализовывать один раз, а работало везде. Выше верно сказали, это очередная попытка сделать Java :)
на WASM обычный Hello World в DOM весит 1.5 мегабайта WASM + 0.5МБ JS обертки
А зачем DOM в WASM? А без DOM, если использовать всякие там строки, числа и т.п., использовать только STL и то по минимуму, то будет килобайт 200 всего лишь. Обертку на JS не мерял, но тоже не такая уж большая.
Aleksandr-JS-Developer, зачем pet, я могу в реальном проекте, хоть и маленьком, такой эксперимент провести. И вы немного не в ту степь, тут не про портирование C++ библиотек через WASM (в этом-то и так ясно, что он имеет смысл, и ничего странного). Тут про написание суперкроссплатформенных библиотек именно с нуля.
Strannyk, ну вообще у любого хорошего сервиса должно быть API, а у любого API (кроме простейших, где 2-3 роута всего) должны быть клиентские библиотеки-обертки на разных языках. Тем более, что там порой не просто отправка запросов, а еще и какие-то алгоритмы, связанные с этим, utils для всей этой кухни...
А писать каждую библиотеку заново и в дальнейшем все это развивать в таком виде - не любая компания может себе позволить.
должны быть клиентские библиотеки-обертки на разных языках.
Любой хороший сервис предоставляет rest-api (всё таки про сервис говорите), написать пару post-get запросов к сервису на любом популярном языке не вызывает проблем.
У библиотек есть одна проблема. Они работают только с тем языком (в лучшем случае - тем ABI, грубо говоря платформой), под которое они сделаны. И истинной кроссплатформенности особо нет.
Ну и в чем проблема? Есть разные языки под разные задачи и есть разные ОС под те же разные задачи. Когда появляется реальная необходимость в переносимости либы/приложений это реализуют. Когда это никому не нужно этого не делают, т.к. это сложно и долго. Если вы спросите почему нет одной ОС для всех, можно спросить почему нет одного ЯП или одного фреймворка под JS, который будет уметь всё и иметь производительности как на языке C.
calculator212, все что вы пишете в своем комменте, не разделяет, скажем, Google, у которого к каждому сервису куча именно готовых оберток на разных языках.
Каких "пару post-get запросов к сервису"? Я же специально обозначил, что речь НЕ ИДЕТ про такие простые случаи, где все API состоит из 2-3 роутов, и большего клиентам и не нужно.
Там не пара, это серьезное API (как ВКонтакте API, например). Здесь приложение (скажем, альтернативный клиент для Android) будет юзать почти все, что есть в API. А это сотни разных запросов.
Конечно, такое приложение разрабатывает команда, и она могла бы сама написать обертку... но это заняло бы у нее время и деньги.
Средний
Средний
Средний
