4 ms·
Yes this has been a rather interesting development - it seems the purpose of the native apis is now becoming just to bootstrap the browser with the browser impl
by dman 8y ago
Yes this has been a rather interesting development - it seems the purpose of the native apis is now becoming just to bootstrap the browser with the browser implementors being the sole users of the native platform apis. Will be really interesting to watch what happens here long term.
Some open questions in my mind for this are
1. Will the browser evolve to cover every use case? (Like AAA games, high performance IO)
2. What does this do for hardware vendors? Think over the years the hardware vendors had a good working relationship with Operating System vendors to surface new ISAs / APIs and make them available to developers, who could build killer apps for end users. For client workloads now new ISAs dont do anything unless they somehow get exposed through the browser.
3. If you are not a browser vendor what options do you have for introducing new computing paradigms ?
4. As the number of developers doing native development reduces to engineers who are implementing browsers the market for debuggers / profilers for native client development reduces. What effect does this have on tooling quality.
Would love any thoughts / speculations / ideas about the above.
- jillesvangurp 8y agoA lot of this stuff is simply happening on merit. Nobody is being forced to use web based platforms, it just so happens to be a convenient option for a lot of developers. Games have no native look and feel because they typically roll their own UIs. That makes them suitable for running in a browser sandbox. However, performance tends to be critical as is low level access to e.g. 3D hardware. So a lot of games where this is important will likely stay native for as long that that is the faster option. However, as wasm improves and access to relevant features from browsers improves, that will become an interesting target for more game developers. Portability of games is important and a source of a lot of overhead. Targeting e.g. xbox, playstation, windows, osx, android, and IOS requires doing a lot of platform independent stuff. Most of the mainstream game engines are effectively doing a lot of similar stuff as web browsers and there's an increasing overlap in terms of technologies. I expect wasm to be a key enabler here. 2 and 3 are interesting because this vastly simplifies creating new formfactors. Look e.g. at magic leap launching their AR platform and partnering with Firefox to get their VR browser going on a completely new HW and SW plaform for AR. I'd say this creates lots of opportunities because this stuff is open source and standardized to the point where competing implementations are interoperable to a very large degree. So, for magic leap that means a lot of stuff out there, should just work (barring UX issues resulting from AR). 4, again merit. This stuff is happening because developers are voting with their feet and also raising the bar in terms of tool quality. Wasm means that there is actually a renaissance in tool quality and innovation for native development. Just look at what the Rust community is doing for WASM and embedded development. Lots of new tools, libraries, and technology aimed at supporting both.