Сообщение Re[2]: что не так с WebAssembly? от 21.03.2025 11:32
Изменено 21.03.2025 11:36 bnk
Re[2]: что не так с WebAssembly?
Здравствуйте, D. Mon, Вы писали:
DM>Ява-апплеты хотя бы на Яве можно было писать. А тут десяток лет из языков нормально доступны были лишь сильно неудобные, низкоуровневые, на которых никто писать не хочет. А GC и нормальных API для взаимодействия с браузером и миром не было. Ну и смысл неочевиден, разница по скорости с JS часто не так велика, чтобы много усилий на переход тратить, а по размеру так и вовсе часто все плохо.
IMHO для веб-приложений webassembly малоплоезно.
Но есть куча "числодробительных", "парсинговых", "файловых", "обработка изображений" и прочих библиотек, которые не имеют UI, и которые доступны допустим как nuget.
Теперь это все достаточно просто скомпилировать в webassembly и вызывать просто как библиотечную функцию из javascritpt, с приемлемой производительностью, и все локально.
DM>Ява-апплеты хотя бы на Яве можно было писать. А тут десяток лет из языков нормально доступны были лишь сильно неудобные, низкоуровневые, на которых никто писать не хочет. А GC и нормальных API для взаимодействия с браузером и миром не было. Ну и смысл неочевиден, разница по скорости с JS часто не так велика, чтобы много усилий на переход тратить, а по размеру так и вовсе часто все плохо.
IMHO для веб-приложений webassembly малоплоезно.
Но есть куча "числодробительных", "парсинговых", "файловых", "обработка изображений" и прочих библиотек, которые не имеют UI, и которые доступны допустим как nuget.
Теперь это все достаточно просто скомпилировать в webassembly и вызывать просто как библиотечную функцию из javascritpt, с приемлемой производительностью, и все локально.
Re[2]: что не так с WebAssembly?
Здравствуйте, D. Mon, Вы писали:
DM>Ява-апплеты хотя бы на Яве можно было писать. А тут десяток лет из языков нормально доступны были лишь сильно неудобные, низкоуровневые, на которых никто писать не хочет. А GC и нормальных API для взаимодействия с браузером и миром не было. Ну и смысл неочевиден, разница по скорости с JS часто не так велика, чтобы много усилий на переход тратить, а по размеру так и вовсе часто все плохо.
IMHO для пользовательско интерфейса в веб-приложениях webassembly малоплоезно. Здесь javascript справляется отлично.
Но есть куча "числодробительных", "парсинговых", "файловых", "обработки изображений" и прочих библиотек, которые не имеют UI, и которые доступны допустим как nuget (для .net например)
Теперь это все достаточно просто скомпилировать в webassembly и вызывать просто как библиотечную функцию из javascritpt, с приемлемой производительностью, и все локально.
DM>Ява-апплеты хотя бы на Яве можно было писать. А тут десяток лет из языков нормально доступны были лишь сильно неудобные, низкоуровневые, на которых никто писать не хочет. А GC и нормальных API для взаимодействия с браузером и миром не было. Ну и смысл неочевиден, разница по скорости с JS часто не так велика, чтобы много усилий на переход тратить, а по размеру так и вовсе часто все плохо.
IMHO для пользовательско интерфейса в веб-приложениях webassembly малоплоезно. Здесь javascript справляется отлично.
Но есть куча "числодробительных", "парсинговых", "файловых", "обработки изображений" и прочих библиотек, которые не имеют UI, и которые доступны допустим как nuget (для .net например)
Теперь это все достаточно просто скомпилировать в webassembly и вызывать просто как библиотечную функцию из javascritpt, с приемлемой производительностью, и все локально.