Comment by socalgal2
12 hours ago
Unity in the browser fails basic interactions like copy and paste. All WASM paint on an Canvas apps on the browser have similar issues with non-english input, accessability, integration with tihngs like dictionaries, password managers, etc...
So, no, do not do Wasm + Canvas
To be clear, I am not suggesting the WASM canvas approach for ordinary web pages. WASM is for things that are unto themselves full-fledged applications, with the convenience of instant access to running them in a sandbox on any platform. The game described in the article certainly makes more sense with WASM than HTML5, as it uses web APIs for doing something that isn't displaying a standard web page but instead needs to conform to a specific set of characteristics to provide a consistent and polished user experience.
Also, while Unity doesn't, features like canvas copy-pasting can be implemented manually or by another framework. Non-English input works fine with WASM; if it doesn't render, it's because the application developer didn't include a font that supports those characters, since there's no fallback-font kind of thing going on. But this stuff is exactly the same as developing any kind of non-web application; if the framework doesn't provide a feature, you have to provide it yourself. It needs to be approached from an application development perspective rather than a web development perspective; you don't get the freebies of web, both the good and the bad, but this gives you much more control and capability.
The only reason to use the web is because it reaches everywhere. you then hoble it by making it not work in 2/3rds of the world you might as well have just shipped a native app.
Also, I think you're under estimating the amount of work required. No one wants your custom solutions. They want the OS solution. They want their OS IME that they use in every app, not the one you built from scratch for your "blat pixels to the page" app. They want their passkeys from their OS, which are only available via web features and are not available from "blat pixels to the page" apps. They want their auto correct to use all the words in their local OS dictionary but that's not available to "blat pixels to the page" apps. I could list several more issues like this
You appear to be misinformed. OS-level features like IMEs and dictionaries work in WASM as they do with any native application. There is nothing special about HTML elements that enables them in a way that doesn't work with WASM; they are, after all, OS features, not HTML features, and the browser is just another native application. If somebody chooses not to integrate OS features in their application, that's a reason not to use their application, but it really has nothing to do with WASM in any way whatsoever.
> The only reason to use the web is because it reaches everywhere. you then hoble it by making it not work in 2/3rds of the world you might as well have just shipped a native app.
I also think this is a ridiculously reductionist take. While I myself consider language support a priority (and incidentally, happen to believe for instance most Linux distros have long kneecapped the spread of Linux by not being accessible to non-Latin users) [and conversely believe WASM does not hobble language support, otherwise I would not be interested in it], that is not even close to "the only reason" to use the web. There are plenty of people in the world who host websites in only their native language. Even if you don't care to support foreign languages, deploying to the web gives you (a) instant cross-platform support with comparatively low effort and (b) zero friction to users, who can instantly use your application without an installation process which itself entails security risks. Would the use of WASM for a niche English text adventure put off Chinese users who might otherwise play the game if only it was written in HTML5? Probably not, they were never going to play the game in the first place.