4 ms·
It "solves" it by not solving it - WebAssembly doesn't do UIs, that component is still built in HTML. The wasm functions are just doing the expensive computati
by notatoad 9y ago
It "solves" it by not solving it - WebAssembly doesn't do UIs, that component is still built in HTML. The wasm functions are just doing the expensive computation. I think there's been some work to build DOM apis in languages that compile to wasm, but for the most part the workflow is to create your UI in markup or standard javascript and then call out to wasm functions to do things, or else building the UI in WebGL (e.g. games)
- solarkraft 9y agoAnd that's how it solves an additional problem. You don't have a GUI toolkit pre-defined if you start out with c++ (yes, it takes freedom, but gives ease of development, which seems to be today's currency).
- clouddrover 9y ago> WebAssembly doesn't do UIs, that component is still built in HTML Your UI could be HTML, but equally it could be a WebGL-based UI. Some UI libraries already use OpenGL as a backend so adding support for a WebGL backend shouldn't be too hard.
- solarkraft 9y agoCan you point me to them? Thinking about using HTML to build an app with good UX lets magic smoke leave my head.
- baq 9y agoQt should work.
- jcelerier 9y agoonly QtQuick thiugh, Qt Widgets aren't really optimized for GL
- pjmlp 9y agoQt Widgets are kind of legacy, as all new development efforts are focused on QML.
- jcelerier 9y agoare they ? the latest version has a bunch of new things: https://wiki.qt.io/New_Features_in_Qt_5.10 https://wiki.qt.io/New_Features_in_Qt_5.10 and the git seems relatively active: https://github.com/qt/qtbase/tree/dev/src/widgets https://github.com/qt/qtbase/tree/dev/src/widgets
- pjmlp 9y agoC++ Widgets are focused on desktop applications, for mobile and embedded devices, QML is the only way to go.
- contrarian_ 9y agoQt solves almost the same problems as a browser, all it's missing is sandboxing and fetching resources over the network.
- baq 9y ago...which the browser convenietly provides, hence my suggestion to use it, targeting webassembly and webgl.
- clouddrover 9y agoQt can work in the browser. Here's a Qt blog post talking about their Emscripten support: https://blog.qt.io/blog/2015/09/25/qt-for-native-client-and-emscripten/ https://blog.qt.io/blog/2015/09/25/qt-for-native-client-and-... You can also stream Qt applications via WebGL (runs server side, UI streamed to the browser): https://blog.qt.io/blog/2017/07/07/qt-webgl-streaming-merged/ https://blog.qt.io/blog/2017/07/07/qt-webgl-streaming-merged... Some asm.js Qt examples: http://vps2.etotheipiplusone.com:30176/redmine/projects/emscripten-qt/wiki/Demos http://vps2.etotheipiplusone.com:30176/redmine/projects/emsc... Some WebAssembly Qt examples: https://github.com/msorvig/qt-webassembly-examples https://github.com/msorvig/qt-webassembly-examples
- contrarian_ 9y ago> but equally it could be a WebGL-based UI Then you might as well ship a native binary. Beyond cross-compilation and window system bindings, there aren't many more portability concerns. But then you're rebuilding the browser, so the question is whether you can do it better than Google/Microsoft/Apple by including only the truly necessary bloat for your use-case. Bonus: you get to avoid browser politics.
- clouddrover 9y ago> Then you might as well ship a native binary. It isn't an either\or choice. You can do both. WebAssembly gives your application a "zero install" option and native gives you better performance.