3 ms·

> desktop application: the software is on your PC, the files are on your PC, you can use it forever Not really, creative DRM is common in desktop applications.

> desktop application: the software is on your PC, the files are on your PC, you can use it forever Not really, creative DRM is common in desktop applications. > does not interoperate with the native environment at all. you can't even read/write to files Not true with new web APIs that expose traditionally native functionality like Bluetooth and the FileSystem. > cloud-service, eternally rented, may go out of service at any time Lots of web apps are being built for offline usage with new offline-oriented web APIs. Web apps can also be packaged as offline Chrome Apps or "native" apps with Electron. > p2p networks are impossible in browsers, everything is centralized Not true, WebRTC was designed to address this and is already supported in all major browsers.

the8472 9y ago
> Not true, WebRTC was designed to address this and is already supported in all major browsers. False, you cannot build decentralized p2p networks on webrtc because you always need a signalling server. the session establishment protocol needs one-time tokens which need to be exchange some way, which means you can't build a self-sustaining network. For example Kademlia DHTs require the ability to quickly send requests to peers you have not contacted before (that's why it's UDP-based). If that requires a session setup and teardown every time that negates the advantages of iterative lookups, even if you could decentralize that part. > Not really, creative DRM is common in desktop applications. None of the ones I'm using on a daily basis have DRM. > Not true with new web APIs that expose traditionally native functionality like Bluetooth and the FileSystem. My understanding is that the FileSystem API is an emulation of a filesystem that stores things in a database in the browser profile. That's not interoperability with native. IPC, file access and sockets are some cuicial features for interoperability. > Lots of web apps are being built for offline usage with new offline-oriented web APIs. Web apps can also be packaged as offline Chrome Apps or "native" apps with Electron. aiui chrome apps are dead except on chromebooks. those offline-apis (service workers) don't give you portability, depend on the browser cache and so on. that gives them volatility. And Electron... well, that just makes it another desktop framework which does provide interoperability with native, I guess I'm kinda ok with that case. But you don't really need wasm then, you can just link to existing libraries. A bit of a pity though that mozilla canceled its positron implementation, would have been nice having two implementations. But that's besides the point. As I said previously, it's not about the best possible outcome you can achieve with the technology, it's how it will be applied to the masses. And that's where I think it will be used as a tool to move more users into walled gardens.

the8472 9y ago

> Not true, WebRTC was designed to address this and is already supported in all major browsers. False, you cannot build decentralized p2p networks on webrtc because you always need a signalling server. the session establishment protocol needs one-time tokens which need to be exchange some way, which means you can't build a self-sustaining network. For example Kademlia DHTs require the ability to quickly send requests to peers you have not contacted before (that's why it's UDP-based). If that requires a session setup and teardown every time that negates the advantages of iterative lookups, even if you could decentralize that part. > Not really, creative DRM is common in desktop applications. None of the ones I'm using on a daily basis have DRM. > Not true with new web APIs that expose traditionally native functionality like Bluetooth and the FileSystem. My understanding is that the FileSystem API is an emulation of a filesystem that stores things in a database in the browser profile. That's not interoperability with native. IPC, file access and sockets are some cuicial features for interoperability. > Lots of web apps are being built for offline usage with new offline-oriented web APIs. Web apps can also be packaged as offline Chrome Apps or "native" apps with Electron. aiui chrome apps are dead except on chromebooks. those offline-apis (service workers) don't give you portability, depend on the browser cache and so on. that gives them volatility. And Electron... well, that just makes it another desktop framework which does provide interoperability with native, I guess I'm kinda ok with that case. But you don't really need wasm then, you can just link to existing libraries. A bit of a pity though that mozilla canceled its positron implementation, would have been nice having two implementations. But that's besides the point. As I said previously, it's not about the best possible outcome you can achieve with the technology, it's how it will be applied to the masses. And that's where I think it will be used as a tool to move more users into walled gardens.