2 ms·

> I simply won't use a dedicated app for anything that can be done in a web browser. In 2023, what app experience is still impossible to do in the browser? Th

> I simply won't use a dedicated app for anything that can be done in a web browser. In 2023, what app experience is still impossible to do in the browser? The only things I can come up with are apps requiring access to outside hardware or files. There are now several entirely unique ways in which a AAA gaming experience could be delivered to a client browser. If we can ship resident evil frames to a Chromebook at 30+fps, is there anything we can't do?

anonymousab 4y ago
I believe the discord app has some weird limitations around global shortcuts and push-to-talk when you use the browser tab instead of the desktop app. One use case also used to be that you would use a browser tab for one discord account and the desktop app for another, but container tabs + browser profile switching made that less necessary. And then discord eventually added support for multiple accounts.
- miohtama 4y ago
  Discord chat works fine in a browser. It is only call options (audio and video codecs?) that give headache.
- bob1029 4y ago
  > global shortcuts and push-to-talk I think we are just 1 tiny browser API away from this one being solved too. If we can agree on a way to capture the pointer device, I'm sure we could figure out a reasonable way to capture certain user-defined keys. The actual key that is subscribed to can be abstracted away by using some registration API. I think this would eliminate key logger concerns (you'd have to ask the user for every key on their keyboard) E.g.: RequestGlobalHotkey('my-hotkey-id', 'Discord Push to Talk'); and then if the user presses it, we call something like OnGlobalHotkey(e) where the arg contains 'my-hotkey-id' and keypress state.
Xorlev 4y ago
> The only things I can come up with are apps requiring access to outside hardware or files That's not even 100% true either [1]. For instance, you can flash Android devices from the browser. The example in [2] talks to an attached Arduino device. [1]: https://support.google.com/chrome/answer/12576972 https://support.google.com/chrome/answer/12576972 [2]: https://developer.chrome.com/articles/usb/ https://developer.chrome.com/articles/usb/
OkayPhysicist 4y ago
Discord optimizes streaming your gameplay by injecting DLLs into your game when you go to stream it (I discovered this, and the setting to disable it, after trying to figure out how the hell Puzzle Pirates could crash due to being streamed). I would be very. Very, very surprised to learn a website could do that. Hell, any streaming of whatever separate application you're running seems like it shouldn't be possible from a website.
- bob1029 4y ago
  Not sure why DLL injection is required or possible (beyond any native browser shenanigans). Screen capture API has been a thing for a while now: https://developer.mozilla.org/en-US/docs/Web/API/Screen_Capture_API https://developer.mozilla.org/en-US/docs/Web/API/Screen_Capt... It has a UX almost identical to discord with regard to screen/application capture experience.
toast0 4y ago
The two things I can think of are: a) communication protocols that aren't encapsulated in http(s), websockets, or webrtc. There's good reasons for some of this, and it's not that limiting, since popular protocols tend to grow some of these encapsulations to circumvent lazy firewalls, but it sticks out to me. Additionally, a page/app can't run a server for other browsers to connect to, it's got to be intermediated with a separate server; it would be difficult to make an offline LAN multiplayer game work. b) reliable non-interactive push messaging and/or background connectivity. Again, there's good reasons, and you wouldn't like every page/app to have this capability, but this capability enables good offline usability by fetching data when available and pushing user driven updates when available. For example, Email should be offline capable, and it should have nearly all the messages that were available when last the device had connectivity, and it should let me compose new messages and replies and queue them until connectivity returns. Maybe it should even speak IMAP and SMTP, but JMAP is probably good enough and browser accessible. Same with other messaging systems, assuming they have queued messages and aren't online only.

anonymousab 4y ago

I believe the discord app has some weird limitations around global shortcuts and push-to-talk when you use the browser tab instead of the desktop app. One use case also used to be that you would use a browser tab for one discord account and the desktop app for another, but container tabs + browser profile switching made that less necessary. And then discord eventually added support for multiple accounts.

miohtama 4y ago
Discord chat works fine in a browser. It is only call options (audio and video codecs?) that give headache.
bob1029 4y ago
> global shortcuts and push-to-talk I think we are just 1 tiny browser API away from this one being solved too. If we can agree on a way to capture the pointer device, I'm sure we could figure out a reasonable way to capture certain user-defined keys. The actual key that is subscribed to can be abstracted away by using some registration API. I think this would eliminate key logger concerns (you'd have to ask the user for every key on their keyboard) E.g.: RequestGlobalHotkey('my-hotkey-id', 'Discord Push to Talk'); and then if the user presses it, we call something like OnGlobalHotkey(e) where the arg contains 'my-hotkey-id' and keypress state.

Xorlev 4y ago

> The only things I can come up with are apps requiring access to outside hardware or files That's not even 100% true either [1]. For instance, you can flash Android devices from the browser. The example in [2] talks to an attached Arduino device. [1]: https://support.google.com/chrome/answer/12576972 https://support.google.com/chrome/answer/12576972 [2]: https://developer.chrome.com/articles/usb/ https://developer.chrome.com/articles/usb/

OkayPhysicist 4y ago

Discord optimizes streaming your gameplay by injecting DLLs into your game when you go to stream it (I discovered this, and the setting to disable it, after trying to figure out how the hell Puzzle Pirates could crash due to being streamed). I would be very. Very, very surprised to learn a website could do that. Hell, any streaming of whatever separate application you're running seems like it shouldn't be possible from a website.

bob1029 4y ago
Not sure why DLL injection is required or possible (beyond any native browser shenanigans). Screen capture API has been a thing for a while now: https://developer.mozilla.org/en-US/docs/Web/API/Screen_Capture_API https://developer.mozilla.org/en-US/docs/Web/API/Screen_Capt... It has a UX almost identical to discord with regard to screen/application capture experience.

toast0 4y ago

The two things I can think of are: a) communication protocols that aren't encapsulated in http(s), websockets, or webrtc. There's good reasons for some of this, and it's not that limiting, since popular protocols tend to grow some of these encapsulations to circumvent lazy firewalls, but it sticks out to me. Additionally, a page/app can't run a server for other browsers to connect to, it's got to be intermediated with a separate server; it would be difficult to make an offline LAN multiplayer game work. b) reliable non-interactive push messaging and/or background connectivity. Again, there's good reasons, and you wouldn't like every page/app to have this capability, but this capability enables good offline usability by fetching data when available and pushing user driven updates when available. For example, Email should be offline capable, and it should have nearly all the messages that were available when last the device had connectivity, and it should let me compose new messages and replies and queue them until connectivity returns. Maybe it should even speak IMAP and SMTP, but JMAP is probably good enough and browser accessible. Same with other messaging systems, assuming they have queued messages and aren't online only.