Jesus Christ, the usability nightmare of this website is worse than the goofy animated GIF they think is an exaggeration.
www.wired.comto get rid of the autoplaying video go fuck yourselves,www.wired.comto get rid of the assorted gigantic flyover bullshit.Use open-source software! Do not rely on “someone else’s computer”. Build your own locally hosted cloud! If you can use open-source hardware when doing so: awesome. If not, make at least sure that everything needed to run the system is open.
This article, as much as I agree with it, conflates cloud hosting and remote-only software design. Cloud hosting really is a prison, but mostly for developers that are lured by its convenience and then become dependent on its abstractions. What we experience today in most mainstream software isn’t necessarily coupled to cloud hosting, but is instead a conscious product design choice and business strategy to deny users power and control of their data. In short, cloud providers like AWS, Azure, and GCP are doing to software companies what those companies are doing to us. There is a way to use shared data centers without this kind of software design philosophy. As mobile continues to dominate, the solution we need likely involves remote servers but with a model that treats them with skepticism and caution, allowing data portability and redundancy across a variety of vendors. I should be able to attach a few hosting services to a software experience I use and transfer my data between them easily. The idea that local-first software is “freed from worrying about backends, servers, and [hosting costs]” is misleading, since my local device has to become the client and/or server if there is any connectivity happening over the internet. Wresting control of our data from the dominant software companies will require creating experiences that are not only different, but better, and doing that with a mobile phone passing between cell towers functioning as the server is a tall order. We have grown to expect more than intermittent connectivity with conflict resolution. Nonetheless, we absolutely should not accept the current remote-only software paradigm, but instead need to devise better ways to abstract how remote hosts are inhabited and create a simple multi-host option that is intuitive for consumers.
