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