Live data from Hacker News

Local-first software (2019)

inkandswitch.com

121–130 of 136 posts

Re: Local-first software (2019)

#121

> ... cloud apps depend on the service continuing to be available: if the service is unavailable, you cannot use the software, and you can no longer access your data created with that software. This means you are betting that the creators of the software will continue supporting it for a long time — at least as long as you care about the data. Although there does not seem to be a great danger of Google shutting down…

Many far smarter people have said this before, far more eloquently than I can, but in short: Cloud Computing (and SASS even more so) is little more than just another attempt to recreate access/info monopolies, essentially the same profit proposition as existed with closed source software, while pretending to be one of the cool kids and use politically more acceptable (but in this context rather meaningless) terms lik…

> Cloud Computing (and SASS even more so) is little more than just another attempt to recreate access/info monopolies

Maybe this is true of some commercial cloud companies, but "cloud" computing is much larger in scope than you make it sound. There is a whole shadow PaaS/SaaS world used primarily by various research communities, for instance, often called "grid" instead of cloud, wherein nearly everything is publicly funded and the value proposition is web-based access to data stores, HPC clusters, etc, instead of every individual hacking their own data science environment on their laptop.

Re: Local-first software (2019)

#122

The No Spinners thing seems to be my professional niche. Every job I’m tasked at cleaning up a poorly performing native app. And it’s always caused by developers writing views like web apps, posting their server requests as views open and fire up a spinner to wait. It’s not that hard to have a caching strategy. And then your native app feels like a native app.

that's not caching, that's the optimistic UI from the referenced paper that you are describing

Re: Local-first software (2019)

#123

Earlier quoted context omitted.

A lot research has been done in this. The OP article is on the same topic - offline-first and local-first stores exists: whether as DBs (pouch/couch) or as data structures (CRDTs or OTs) like yjs. These automatically sync to the cloud. Usage is lower, as most commercial applications prefer cloud lockin.

>> How do you sync data between devices if you don't use cloud? > [...] These automatically sync to the cloud. [...]

They do need to talk to each other. But yes, yjs can actually sync over ipfs/dat, or direct webrtc as well. Those are options too.

Re: Local-first software (2019)

#124
post #72
post #43

This is the 3rd time in a week a "Local-First software" overview has been submitted and the 2nd time it's made the front page here. I'm pretty surprised about that because I'm about to release a local-first, offline-first, option for an app I make. This article also quickly moves past "local-first" software to conflict resolution which, in my opinion, is a distinctly different issue. It's certainly not reason enough…

Unhosted.org [1] mentions the remoteStorage protocol [2] as one of the options for storing user data separate from an application. [1] https://unhosted.org/adventures/7/Adding-remote-storage-to-u... [2] https://remotestorage.io/

remoteStorage is pretty cool, and it's a shame that neither it nor something like it has really taken off yet. The spec has some rough edges, though—in particular the protocol requires a smart server to handle the network requests, when it should be fairly straightforward to define a "static" profile that can turn most commodity dumb hosts (Neocities, GitHub Pages, etc.) into a user store. I'm convinced that this seemingly minor design tweak would give remoteStorage a new life and cause it to spread like wildfire.

The spec gets periodically refreshed/resubmitted. It last happened a couple of months ago and is set to expire at the end of the year.

Re: Local-first software (2019)

#125
post #43

This is the 3rd time in a week a "Local-First software" overview has been submitted and the 2nd time it's made the front page here. I'm pretty surprised about that because I'm about to release a local-first, offline-first, option for an app I make. This article also quickly moves past "local-first" software to conflict resolution which, in my opinion, is a distinctly different issue. It's certainly not reason enough…

> If we have a standard for saving contacts data on the client side that any app could access this would give users and developers options to create and use new apps and features that all use the same data. [...] There may be other ways of achieving this right now, but I am not aware of them.

This is the content providers design that was heavily touted in the early-ish days of Android.

https://youtu.be/QBGfUs9mQYY?t=352

Re: Local-first software (2019)

#126
post #56

I think there's probably a market for a personal cloud, which probably sounds dumber than personal computer did in the 80s. What I mean by that is a computer somewhere in the garage, like a furnace, with enough compute and storage to drive all the devices and appliances in a house. In this model, devices do not have CPUs or memory, only input/output and a network chip. The way this would work is for the computer in t…

You might want to look at the following open-source software:

- nextcloud - a system with appliance-like apps that do these sorts of things

- proxmox - a vm system that allows you to deploy VMs and containers including appliance-like templates

https://en.wikipedia.org/wiki/Nextcloud

https://nextcloud.com/

https://en.wikipedia.org/wiki/Proxmox_Virtual_Environment

https://www.proxmox.com/

Re: Local-first software (2019)

#127

> ... cloud apps depend on the service continuing to be available: if the service is unavailable, you cannot use the software, and you can no longer access your data created with that software. This means you are betting that the creators of the software will continue supporting it for a long time — at least as long as you care about the data. Although there does not seem to be a great danger of Google shutting down…

Many far smarter people have said this before, far more eloquently than I can, but in short: Cloud Computing (and SASS even more so) is little more than just another attempt to recreate access/info monopolies, essentially the same profit proposition as existed with closed source software, while pretending to be one of the cool kids and use politically more acceptable (but in this context rather meaningless) terms lik…

I don't think that's the full picture. There are lots of good reasons for small and medium-sized providers of b2c software to prefer SaaS and cloud delivery over on-premises that aren't anything to do with access/info monopolies.

For example as a small provider you'll just kill all your velocity if you try to deliver on-prem to a number of large enterprises. They will all have different upgrade policies, testing and approval policies, different approved hardware etc etc and pretty soon you will suffer a death from 1000 cuts and not be able to deliver anything.

For example, I had a client once say to me that we had to replace postgres in our stack with Oracle because that was their approved database. Even though we had to support the stack. I had a client delay us by 6 months because they decided to order super bleeding-edge network cards (which I repeatedly said we didn't need) then these cards turned out to take ages to deliver, when they arrived they didn't work with the "corporate approved" version of linux they insisted on using for another couple of months etc.

In a saas you don't have to deal with any of those things. You do the one-off (painful) third-party vendor approval process, go through all the infosec audits etc but after that you own the stack and can run it the way you want.

If you want to change the hardware layout and it's on prem you have to go cap-in-hand to the client and get them to stump up cash, wait months while physical boxes get allocated, racked up etc. If you're in-cloud, you make a change to terraform, check it in and it gets pushed out through your CI/CD pipeline.

If you want to roll changes to all your customers that's really easy as a SaaS/cloud offering whereas it's very hard if they're each on-prem.

etc etc

It's easy to be cynical, but there are very significant benefits to the vendor of this model. There can also be benefits to the customer too.

In addition, in my experience when you deal with a big enterprise customer you are contractually committed to providing "transition assistance" when the contract ends (even if your company goes bust) and returning data in mutually-agreed open formats. So vendor lockin doesn't really apply eithre.

Re: Local-first software (2019)

#128

The No Spinners thing seems to be my professional niche. Every job I’m tasked at cleaning up a poorly performing native app. And it’s always caused by developers writing views like web apps, posting their server requests as views open and fire up a spinner to wait. It’s not that hard to have a caching strategy. And then your native app feels like a native app.

that's not caching, that's the optimistic UI from the referenced paper that you are describing

You can call it Tomato or Tomatoe.
Post reply on HN