Re: [w3ctag/design-reviews] OffscreenCanvas new commit() and DedicatedWorker.requestAnimationFrame (#288)

I'm glad alternative solutions are being considered.

I'd like to take a step back and suggest that maybe the goal of allowing unmodified native apps to run um ... unmodified is maybe not such a great goal for the web?

Native apps have all kinds of issues when ported to the web. Some issues off the top of my head

* The kinds of apps we're talking about (non-event driven, ie, games) are usually resource intensive.

The web doesn't have a good solution here. In order for users to have a good experience those apps need to be redesigned to stream resources so they are usable quickly. Refactoring so say the first level can be played while the other 29 levels download is likely not a smaller amount of work. They may also need extra work to cache their resources so on second visit they don't take another 5-30 minutes to start as they redownload assets.

* Most native apps (mobile - there are 10x more mobile apps than PC) are not mouse friendly as they are designed for touch only. That means in order to be useful on the web they need their interfaces redesigned. 

* Most native apps except to have different versions generated at compile time per platform whereas most web apps are expected to run everywhere. 

  This has issues like for example a cut/copy/paste where a web app will leave it to the browser to handle cut/copy/paste. A native app will hard code checking for Ctrl-C on PC and Cmd-C on Mac. This doesn't work on the web.  Worse, a native app expects to just be able to read the clipboard on demand but the web requires the user to paste and the app to wait for a paste event. Even games benefit from being able to paste names, paste into chat, paste passwords into login screens, etc...

What these and other issues mean is that bringing native apps to the web and having the experience be good for the user requires lots of work. If that work is not spent then all users get is really poor experiences turning them off to the web. The amount of work to refactor these apps to be event driven is tiny compared to the amount of work required to make them good experiences on the web. 

In other words, this goal of making spin loops magically work is basically saving native apps only a few percent of the work they really need while at the same time encouraging bad experiences for users since native app people can then just barf out their apps, no thought given.

* oh hey, it runs but only on windows! Sucks to be web

* oh hey, it runs but takes several minutes to start every few days. Web sucks doesn't it

That doesn't seem like a win for anyone.



---

Just for fun I went looked up the code for Lumberyard and Unreal

main calls RunMainLoop

https://github.com/aws/lumberyard/blob/0b34452ef270f6b27896858dc7899c9796efb124/dev/Code/Launcher/WindowsLauncher/Main.cpp

RunMainLoop

https://github.com/aws/lumberyard/blob/e881f3023cc1840650eb7b133e605881d1d4330d/dev/Code/Launcher/LumberyardLauncher.h

Checking Unreal

WinMain calls GuardedMain

https://github.com/EpicGames/UnrealEngine/blob/release/Engine/Source/Runtime/Launch/Private/Windows/LaunchWindows.cpp

GuardedMain

https://github.com/EpicGames/UnrealEngine/blob/f509bb2d6c62806882d9a10476f3654cf1ee0634/Engine/Source/Runtime/Launch/Private/Launch.cpp


In either case I doubt it would take more than 1-4 hours to throw in a few statics and/or singletons to take things off the stack and expose the main loop to be event driven. That matches my own experience of making a few native apps event driven. In my case it took 20-40 minutes.

It seems arguable that if native devs aren't willing to put in that small amount of time to make their apps event driven then they aren't likely to do any of the other work required to bring their app to the web and so this path of supporting spin loops is only really enabling bad experiences from thoughtless quick and dirty recompiles instead of thoughtful ports.

Anyway, just a thought.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/288#issuecomment-418584363