6 ms·

IMHO and we're worse off for it. I still keep around non-web versions of old software like Picassa that are so much better than the web alternatives now being

IMHO and we're worse off for it. I still keep around non-web versions of old software like Picassa that are so much better than the web alternatives now being offered. We've given up a lot for being able to run in a web browser. Web UI is janky and fussy and time consuming to use. I've been using computers since 1988, and the UI now is the worst it's ever been for anything other than dicking around doing half-assed work.

dangus 4y ago
These are some seriously rose tinted glasses. What I remember about computers in the 90’s was incompatibility and inconsistency. The last paragraph of the article is worth revisiting. I couldn’t use the same features between Windows and Mac, and the Linux version of commercial apps would barely work if they existed at all. Fighting with codecs, flash player, macromedia, incompatible file formats, ActiveX, RealPlayer, etc. No way to easily extend functionality in the way that web based apps’ APIs offer. How do you connect information between two unrelated applications in the 90’s? The answer is that you didn’t! On top of that, plenty of applications are still just regular local applications. We can use Picassa as an example. Many of its alternatives are not even web-based, including Apple Photos (native app, does not require iCloud or Internet at all), Adobe Lightroom, and many free alternatives like gThumb. The thing is, most web-based applications are web-based because the web is so powerful and useful. For example, VSCode would lose its powerful extension ecosystem if it wasn’t web-based. The whole reason it’s so successful is that any web developer can make an extension easily. On top of that, the app works the same on Mac, Windows, Linux, even inside a web browser. What would we gain by the app no longer being based on web technologies that wouldn’t be offset by the lost functionality? Offline apps are still developed, and they’re developed for uses where that makes more sense. For example, DaVinci Resolve, Affinity Photo, and Final Cut Pro are all regular non-web applications, because that’s what makes sense for them.
- mike_hearn 4y ago
  It can be spun both ways. - Fighting with codecs? Indeed, gone if you use the web because one or two browser makers force a lowest common denominator codec on everyone to keep their own IP costs low. Would your use case benefit from a higher quality codec and you're willing to pay for it? Pound sand, you get what Mozilla wants you to get even if you don't use Firefox. - Flash player? Indeed, gone because one man didn't like it. Would you benefit from the highly artist friendly timeline and vector art system Flash had, the compact binary format, the powerful animation system? Did you enjoy animated web comics made by people with tons of artistic skill and no coding abilities? Pound sand, you get CSS animations and you can roll the rest on your own (which nobody does). - How do you connect information between two unrelated applications in the 1990s? Wow, pick your poison. DCOM/OLE was the most advanced implementation of this, but Apple had OpenDoc. Apps could expose components that implemented standardized APIs, they could expose sophisticated object models allowing you to reflect and script them from many kinds of language, they had a more powerful equivalent of iframing and so on. What does web tech give you that can match this? Nothing! If two web apps can connect to each other it's because of a bespoke integration. Browsers think they're drawing scientific documents so they don't have any notion of a page having an API. Every web API is a horrible hack in which you pretend some code is actually a pile of "documents". Schemas, API conventions, tooling, language binding is all totally scattershot. There's not really any such thing as just scripting a web app from a language of your choice like Windows managed decades ago, it's all custom each and every time. "most web-based applications are web-based because the web is so powerful and useful" Will have to disagree with that. The web lacks many basic features once considered essential. People like making web apps for the desktop (not mobile) because of things like sandboxing, convenient server connectivity, "instant on" without (un)installation, clickable URLs without extra effort, no piracy risks, monitoring and metrics coming for free, blurred lines between documents and apps etc. Basically because of the stuff that browsers happen to expose as an artifact of their implementation and evolution path. There's other reasons too (e.g. Microsoft/Apple dropped the ball on window management, a ball picked up by tabbed browsers) but I won't try and make a comprehensive list of all of them here. That's a future project :) Oh, also and hugely importantly, because distributing desktop apps is much harder than it should be - there's lots of legacy tech and platform differences making it awkward. That's absolutely fixable though. In fact, my new startup is getting ready to launch a tool that makes distributing desktop apps as easy as distributing web apps. It's not quite launched yet but there's a mailing list form you can fill out at https://hydraulic.software https://hydraulic.software if you're interested. The goal here is to start at the beginning: make it easy to distribute apps outside the browser, and then start to explore platforms that retain most of the benefits of a browser whilst fixing their weak points. It should be especially useful for the community of developers interested in building decentralized apps, which are a very poor fit for web tech.
  - dangus 4y ago
    That’s the thing about the old way of interfacing with applications, it was different on every platform, limiting its usefulness in practice. REST APIs are universal. I think it’s telling that you’re working on a startup to fix desktop app distribution problems, even though there are dozens of distribution methods for desktop apps. The fact that commercial installer software companies still operate is telling. The distribution model of the web is precisely what is so amazing about it. It is already decentralized. It has zero distribution friction. Sure, if you buy some SaaS app, that’s not really decentralized, but I can download a self-hosted app (e.g., nextcloud), install it on my server, and now I can interface with it and “run the application” from any system in the world instantly. It can also talk to other systems that aren’t even running on my server or in my country. The web already solved distribution. More than solved it. That’s why everyone is using it.
    - mike_hearn 4y ago
      A REST API is really an app specific network protocol that happens to build on HTTP instead of TCP. It's not actually an API in the sense we're talking about above. Most obviously there's no standard way for a web server to say "I implement this standard typed interface X", and even if there was, there's no way to ask browsers to enumerate all the web apps the user "has" that implements interface X because browsers don't have any notion of a user "having" an app to begin with. That's sometimes beneficial, and sometimes it just means things can't integrate with each other. In contrast stuff like DCOM/OLE supported tons of features that REST doesn't even try to address so it's an apples/oranges comparison to a large extent. Don't get me wrong - decoupling the app APIs from the underlying operating systems has advantages, and I'm not trying to bring DCOM back, but clearly the advantages aren't that huge because on mobile a more modern take on the exact same concepts stomped web tech completely. Everyone wants native Android/iOS apps and they want them so badly that companies will write the same app frontend twice to satisfy that need. "The distribution model of the web is precisely what is so amazing about it. It is already decentralized. It has zero distribution friction." True, but this is engineering. There are always tradeoffs. It gets this zero distribution friction by simply ignoring any use cases that don't fit its document-oriented model. Most obviously, every approach to making the web support poor or non-existent connectivity is terrible and has never gained traction, but that's a problem. Many, many apps need to be able to run offline. Anything that manages a critical process of any kind simply cannot handle being served from the cloud as a web app: • Industrial control • Medical • Servers themselves • Military • Much gaming (you play games when you're bored, why are you bored, maybe because you don't have the internet ...) • Anything to do with managing the network itself • Anything where latency is critical (can't beat the speed of light) • Airgapped for security etc. Apps in these fields don't just experience friction when trying to use the web, they experience a brick wall. Then there are the many, many apps that struggle to ram their square pegs into the round hole of a browser, e.g. embedded devices struggle because browsers won't automatically discover them, because browsers are slowly turning the screws on requiring TLS but the TLS model doesn't really work for embedded devices you connect to locally. Developer tools. And so on and so forth. Finally, there are other common distribution use cases browsers don't even try to support: • Downgrading if the server ships a regression. "Regression" doesn't have to mean bug or outage, it can mean deliberate UI redesign, hence all the screaming whenever web apps change their UI layouts. Your workforce productivity can drop overnight because some SaaS shipped a new UI nobody asked for, and you're just screwed at that point. If it didn't come at a good time for your business or the new version is a downgrade for you, once again the web cordially invites you to try pounding sand. It might help you feel better. • Apps that aren't controlled by a single organization (hence why web apps suck for the blockchain/decentralization community - Bitcoin 0.1 wasn't a web app for good reasons). • Apps that need to keep working even if the originating organization goes bankrupt. • Apps that need to separate data storage from software distribution. The origin concept doesn't make this easy.

dangus 4y ago

These are some seriously rose tinted glasses. What I remember about computers in the 90’s was incompatibility and inconsistency. The last paragraph of the article is worth revisiting. I couldn’t use the same features between Windows and Mac, and the Linux version of commercial apps would barely work if they existed at all. Fighting with codecs, flash player, macromedia, incompatible file formats, ActiveX, RealPlayer, etc. No way to easily extend functionality in the way that web based apps’ APIs offer. How do you connect information between two unrelated applications in the 90’s? The answer is that you didn’t! On top of that, plenty of applications are still just regular local applications. We can use Picassa as an example. Many of its alternatives are not even web-based, including Apple Photos (native app, does not require iCloud or Internet at all), Adobe Lightroom, and many free alternatives like gThumb. The thing is, most web-based applications are web-based because the web is so powerful and useful. For example, VSCode would lose its powerful extension ecosystem if it wasn’t web-based. The whole reason it’s so successful is that any web developer can make an extension easily. On top of that, the app works the same on Mac, Windows, Linux, even inside a web browser. What would we gain by the app no longer being based on web technologies that wouldn’t be offset by the lost functionality? Offline apps are still developed, and they’re developed for uses where that makes more sense. For example, DaVinci Resolve, Affinity Photo, and Final Cut Pro are all regular non-web applications, because that’s what makes sense for them.

mike_hearn 4y ago
It can be spun both ways. - Fighting with codecs? Indeed, gone if you use the web because one or two browser makers force a lowest common denominator codec on everyone to keep their own IP costs low. Would your use case benefit from a higher quality codec and you're willing to pay for it? Pound sand, you get what Mozilla wants you to get even if you don't use Firefox. - Flash player? Indeed, gone because one man didn't like it. Would you benefit from the highly artist friendly timeline and vector art system Flash had, the compact binary format, the powerful animation system? Did you enjoy animated web comics made by people with tons of artistic skill and no coding abilities? Pound sand, you get CSS animations and you can roll the rest on your own (which nobody does). - How do you connect information between two unrelated applications in the 1990s? Wow, pick your poison. DCOM/OLE was the most advanced implementation of this, but Apple had OpenDoc. Apps could expose components that implemented standardized APIs, they could expose sophisticated object models allowing you to reflect and script them from many kinds of language, they had a more powerful equivalent of iframing and so on. What does web tech give you that can match this? Nothing! If two web apps can connect to each other it's because of a bespoke integration. Browsers think they're drawing scientific documents so they don't have any notion of a page having an API. Every web API is a horrible hack in which you pretend some code is actually a pile of "documents". Schemas, API conventions, tooling, language binding is all totally scattershot. There's not really any such thing as just scripting a web app from a language of your choice like Windows managed decades ago, it's all custom each and every time. "most web-based applications are web-based because the web is so powerful and useful" Will have to disagree with that. The web lacks many basic features once considered essential. People like making web apps for the desktop (not mobile) because of things like sandboxing, convenient server connectivity, "instant on" without (un)installation, clickable URLs without extra effort, no piracy risks, monitoring and metrics coming for free, blurred lines between documents and apps etc. Basically because of the stuff that browsers happen to expose as an artifact of their implementation and evolution path. There's other reasons too (e.g. Microsoft/Apple dropped the ball on window management, a ball picked up by tabbed browsers) but I won't try and make a comprehensive list of all of them here. That's a future project :) Oh, also and hugely importantly, because distributing desktop apps is much harder than it should be - there's lots of legacy tech and platform differences making it awkward. That's absolutely fixable though. In fact, my new startup is getting ready to launch a tool that makes distributing desktop apps as easy as distributing web apps. It's not quite launched yet but there's a mailing list form you can fill out at https://hydraulic.software https://hydraulic.software if you're interested. The goal here is to start at the beginning: make it easy to distribute apps outside the browser, and then start to explore platforms that retain most of the benefits of a browser whilst fixing their weak points. It should be especially useful for the community of developers interested in building decentralized apps, which are a very poor fit for web tech.
- dangus 4y ago
  That’s the thing about the old way of interfacing with applications, it was different on every platform, limiting its usefulness in practice. REST APIs are universal. I think it’s telling that you’re working on a startup to fix desktop app distribution problems, even though there are dozens of distribution methods for desktop apps. The fact that commercial installer software companies still operate is telling. The distribution model of the web is precisely what is so amazing about it. It is already decentralized. It has zero distribution friction. Sure, if you buy some SaaS app, that’s not really decentralized, but I can download a self-hosted app (e.g., nextcloud), install it on my server, and now I can interface with it and “run the application” from any system in the world instantly. It can also talk to other systems that aren’t even running on my server or in my country. The web already solved distribution. More than solved it. That’s why everyone is using it.
  - mike_hearn 4y ago
    A REST API is really an app specific network protocol that happens to build on HTTP instead of TCP. It's not actually an API in the sense we're talking about above. Most obviously there's no standard way for a web server to say "I implement this standard typed interface X", and even if there was, there's no way to ask browsers to enumerate all the web apps the user "has" that implements interface X because browsers don't have any notion of a user "having" an app to begin with. That's sometimes beneficial, and sometimes it just means things can't integrate with each other. In contrast stuff like DCOM/OLE supported tons of features that REST doesn't even try to address so it's an apples/oranges comparison to a large extent. Don't get me wrong - decoupling the app APIs from the underlying operating systems has advantages, and I'm not trying to bring DCOM back, but clearly the advantages aren't that huge because on mobile a more modern take on the exact same concepts stomped web tech completely. Everyone wants native Android/iOS apps and they want them so badly that companies will write the same app frontend twice to satisfy that need. "The distribution model of the web is precisely what is so amazing about it. It is already decentralized. It has zero distribution friction." True, but this is engineering. There are always tradeoffs. It gets this zero distribution friction by simply ignoring any use cases that don't fit its document-oriented model. Most obviously, every approach to making the web support poor or non-existent connectivity is terrible and has never gained traction, but that's a problem. Many, many apps need to be able to run offline. Anything that manages a critical process of any kind simply cannot handle being served from the cloud as a web app: • Industrial control • Medical • Servers themselves • Military • Much gaming (you play games when you're bored, why are you bored, maybe because you don't have the internet ...) • Anything to do with managing the network itself • Anything where latency is critical (can't beat the speed of light) • Airgapped for security etc. Apps in these fields don't just experience friction when trying to use the web, they experience a brick wall. Then there are the many, many apps that struggle to ram their square pegs into the round hole of a browser, e.g. embedded devices struggle because browsers won't automatically discover them, because browsers are slowly turning the screws on requiring TLS but the TLS model doesn't really work for embedded devices you connect to locally. Developer tools. And so on and so forth. Finally, there are other common distribution use cases browsers don't even try to support: • Downgrading if the server ships a regression. "Regression" doesn't have to mean bug or outage, it can mean deliberate UI redesign, hence all the screaming whenever web apps change their UI layouts. Your workforce productivity can drop overnight because some SaaS shipped a new UI nobody asked for, and you're just screwed at that point. If it didn't come at a good time for your business or the new version is a downgrade for you, once again the web cordially invites you to try pounding sand. It might help you feel better. • Apps that aren't controlled by a single organization (hence why web apps suck for the blockchain/decentralization community - Bitcoin 0.1 wasn't a web app for good reasons). • Apps that need to keep working even if the originating organization goes bankrupt. • Apps that need to separate data storage from software distribution. The origin concept doesn't make this easy.