5 ms·

> If desktops could make a platform where I can write my app in one language, host it on my own server and get global distribution running in a sandboxed enviro

> If desktops could make a platform where I can write my app in one language, host it on my own server and get global distribution running in a sandboxed environment then I'd consider it. It was called Java and ironically people hated it because it was sluggish and didn't use native widgets. Now we have webapps which reinvent the GUI on almost every site and have built in 100ms+ latencies. Go figure. > The web distribution model is just so much nicer for users and devs. No app stores, no install/uninstall process, no access to system internals. No ability to use it at all in an area with shitty network, no consistency, no integration, no respect for OS themes, no ability to continue using old versions if something is wrong with the new one... > I can deploy an app today and just send a link to my friends for them to use it. It takes a day just to put together an app store submission with all the necessary screenshots and configuration, not to mention the lengthy review process which could then deny me permission to launch. On Windows you could put your binary and libraries in a zip file and distribute to users in any variety of ways, including via web hosting. Macs could do the same thing with Application Bundles or their single-file applications before that.

anhanhanh 5y ago
> On Windows you could put your binary and libraries in a zip file and distribute to users in any variety of ways, including via web hosting. Would you really do that though? Or would you run a random exe from a random zip hosted from a random website?
- citrin_ru 5y ago
  If you trust a developer - why not? And if not then an app store model is not a panacea - there are examples of pushing fraudulent/malicious app into them. Better sandboxing would be welcome, but it coming to desktop slowly (and it typically can only limit damage from a malicious app, but not prevent it fully). Web-apps come with own security trade-off: infrastructure can have poor security and data can be leaked (and or destroyed) by hackers, a government can request all you data without you knowing about this, your data can be abused by an web-app creator e. g. sold to an Ad targeting company.
- AnIdiotOnTheNet 5y ago
  Literally all the time. Don't get me wrong, I'd much prefer if Windows had implemented proper application sandboxing.
BackBlast 5y ago
You have a lot of gripes. > It was called Java and ironically people hated it because it was sluggish and didn't use native widgets. First, Java is in use on plenty of systems. It has all but disappeared as a serious client side system - but not because of performance. Java failed more because it failed to meet market expectations, especially in ease of use. Other solutions were more agile in creating better platforms on the client side. > Now we have webapps which reinvent the GUI on almost every site This is not an impediment to adoption. This is clearly seen on such successful historical software like winamp which intentionally abandoned fitting the mold. X has not historically had much consistency at all for GUI. Xlib, Motive, GTK, Qt/KDE, at any given time there has been many options to pick from. You do lose system-consistency, and that can be a negative. However, you gain platform consistency in your application appearing the same on pretty much every device. It's not a total negative. > and have built in 100ms+ latencies. Go figure. Webapps do not need to hit the backend for every little thing. That latency requirement really depends on how much data is appropriate to send to the client and the development philosophy of the developer. For personally owned data it can certainly live on the client and have a replication stream to the cloud system and have no built-in network latency. This is not a hard requirement for a webapp. > No ability to use it at all in an area with shitty network, no consistency, no integration, no respect for OS themes, no ability to continue using old versions if something is wrong with the new one... Webapps (PWAs, electron, cordova, and websites for that matter) can all work offline if they are designed that way. Just like native software can be built to require the mothership to do anything and behave just like a traditional website. This issue is more mindset than fundamental to the technology. You hit the OS integration side pretty hard. The software solves a problem, its success depends on that. All this integration is simply a list of "nice to haves". The market has shown time and time again that spending too much on your hobby features rather than what the customer's actually want is not a long term winning devopment strategy. Look at it from the user side. If some slightly slower, loud looking software solves my problem 200% better than my current native solution - I'm switching.

anhanhanh 5y ago

> On Windows you could put your binary and libraries in a zip file and distribute to users in any variety of ways, including via web hosting. Would you really do that though? Or would you run a random exe from a random zip hosted from a random website?

citrin_ru 5y ago
If you trust a developer - why not? And if not then an app store model is not a panacea - there are examples of pushing fraudulent/malicious app into them. Better sandboxing would be welcome, but it coming to desktop slowly (and it typically can only limit damage from a malicious app, but not prevent it fully). Web-apps come with own security trade-off: infrastructure can have poor security and data can be leaked (and or destroyed) by hackers, a government can request all you data without you knowing about this, your data can be abused by an web-app creator e. g. sold to an Ad targeting company.
AnIdiotOnTheNet 5y ago
Literally all the time. Don't get me wrong, I'd much prefer if Windows had implemented proper application sandboxing.

BackBlast 5y ago

You have a lot of gripes. > It was called Java and ironically people hated it because it was sluggish and didn't use native widgets. First, Java is in use on plenty of systems. It has all but disappeared as a serious client side system - but not because of performance. Java failed more because it failed to meet market expectations, especially in ease of use. Other solutions were more agile in creating better platforms on the client side. > Now we have webapps which reinvent the GUI on almost every site This is not an impediment to adoption. This is clearly seen on such successful historical software like winamp which intentionally abandoned fitting the mold. X has not historically had much consistency at all for GUI. Xlib, Motive, GTK, Qt/KDE, at any given time there has been many options to pick from. You do lose system-consistency, and that can be a negative. However, you gain platform consistency in your application appearing the same on pretty much every device. It's not a total negative. > and have built in 100ms+ latencies. Go figure. Webapps do not need to hit the backend for every little thing. That latency requirement really depends on how much data is appropriate to send to the client and the development philosophy of the developer. For personally owned data it can certainly live on the client and have a replication stream to the cloud system and have no built-in network latency. This is not a hard requirement for a webapp. > No ability to use it at all in an area with shitty network, no consistency, no integration, no respect for OS themes, no ability to continue using old versions if something is wrong with the new one... Webapps (PWAs, electron, cordova, and websites for that matter) can all work offline if they are designed that way. Just like native software can be built to require the mothership to do anything and behave just like a traditional website. This issue is more mindset than fundamental to the technology. You hit the OS integration side pretty hard. The software solves a problem, its success depends on that. All this integration is simply a list of "nice to haves". The market has shown time and time again that spending too much on your hobby features rather than what the customer's actually want is not a long term winning devopment strategy. Look at it from the user side. If some slightly slower, loud looking software solves my problem 200% better than my current native solution - I'm switching.