25 ms·

Offline is just online with extreme latency

470 points by samwillis 4y ago

excalibur 4y ago
Relevant xkcd: https://xkcd.com/2224/ https://xkcd.com/2224/
kkfx 4y ago
Offline does not necessarily mean connected AT ALL, witch means not necessarily "local first" but "only local". Means on my iron, so under my control. For the local first part, witch means "casually connected systems", the extra layer of complexity offer another layer of control and resilience: an autonomous car, capable of limited inertial navigation, with full local maps, routing capabilities etc can move even without GPS. Sure, it's more costly and complex than a connected-only car, but it's FAR safer to use. Similarly an autonomous ship is far safer than a connected only one, for obvious reason. Similarly in human terms local people with local power are FAR more resilient and effective than meat-based dysfunctional robots tied to some procedure. A VERY small simple example: I'm moved to France from Italy some years ago, now I decide to convert my perfectly valid Italian driving license in a local one. There is an automated (long) procedure. When I start it I've have had to give a scan of my Italian driving license witch happen to be expired and so got renewed BEFORE the procedure complete. In a resilient system I simply can upload the new one, sure this act trigger some extra actions, but extra actions who will happen anyway, only just after a bigger delay. Did you remember the Toyoda model vs the Ford one? Well, local first it's the same. At any scale.
ggm 4y ago
Mike St Johns talked about DNSSEC bootstrap timers in the context of a VM on the shelf, brought live 4+ years later: how do you update the Trust Anchor for a cold VM image which is very old?
fastball 4y ago
I'd go one step further, and say offline is just real-time with extreme latency. This is what we realized when re-tooling our app for offline use – anything we build that enables offline use will by its nature enable real-time collaboration.
- mfbx9da4 4y ago
  Example? I don't see the link
  - arve0 4y ago
    When you do not rely on ACID for data consistency, you need to architect for eventual consistency. For example CRDT on collaborative editing a text document.
- pvh 4y ago
  Just so!
0zemp1c 4y ago
yeah, no offline means no expectation of a response, that is very different than an extremely delayed response
- _xivi 4y ago
  The point is to bridge online and offline and make apps more robust If it works locally and there's no need for syncing or communication in the first place then yeah, problem solved!
- mysterydip 4y ago
  Like saying "blindness is the same as a really long blink". One has an expectation of seeing again, the other has no guarantees.
mfbx9da4 4y ago
I don't think "Offline Is Just Online with Extreme Latency" is a useful concept because it doesn't encapsulate the key difference: pessimistic or optimistic UI. For example, say you have a form. If you built it thinking online first you'll probably have some pessimistic UI which shows a spinner and waits for the server to respond with ok/error. You can't simply think, okay since we're offline, more latency -> show spinner for longer. You have to re-architect things so that the UI is optimistic, commits to a local database and that local database is synced up to the server when you come online. In my experience optimistic UI is way more complex to build. Many times the complexity is worth it though.
- Karellen 4y ago
  > You have to re-architect things so that the UI is optimistic, commits to a local database and that local database is synced up to the server when you come online. Isn't that exactly what the article argues for though? > This kind of idea would move you away from a product full of API calls to one based on data synchronization.
- klabb3 4y ago
  Those cases should both be solved with optimistic UI, so there’s no difference. You can have a little checkmark to indicate that it’s synced, like many chat apps do. > In my experience optimistic UI is way more complex to build. Many times the complexity is worth it though. Yeah, can attest to this. I’m working on an app[1] that strikes the trifecta: p2p, real-time and offline first. All of those things combined makes the amount of tooling, design patterns and resources available shrink to a tiny sliver compared to a typical web-based tech stack. I have researched probably 100 projects that sound promising but almost all have been a poor fit for one reason or another. I opted to build almost everything from scratch. Kudos to the JS ecosystem. They are way ahead in this space, with rxdb, watermelon, yjs, automerge etc. Unfortunately I couldn’t use any of them because I use a split-language stack. [1]: https://payload.app/ https://payload.app/
  - dustingetz 4y ago
    to add to this - rotate CRUD mindset to CQRS, now you have a start event and an end event, this is the extent of the pending sync state which can be afforded to the user at any granularity - document level, message level, form or field level, etc. The cost is that other view queries don't reflect the pending event, only the view that issued the command has an association to the event. Which is usually the UX you want. Consider a master/detail form app where you insert a new record into a collection, but the view is sorted/filtered/paginated and your new record does not match the criteria and therefore vanishes. That is never the right UX. A less surprising alternative UX is to limit record creation to a specific form for the business rules of creation, and that form exists in the context of a specific collection view with business rules around newly created entities of that kind, with an invariant that newly created entities will always appear at the top or bottom of that collection (e.g. new messages are always added to the bottom of the chat history view). Now the optimistic update bypasses the database and simply writes through to the view optimistically and then when the ack is eventually received it seamlessly changes state without any UI jank. Now you can send many new messages rapidly and if the nth message fails and the rest of the messages went through you get a properly located error. With a CRUD mindset, probably the form is simply disabled until each individual insert succeeds - which means your chat app cannot keep up with you typing!
coldtea 4y ago
Online is just offline with extreme latency for any new data fetch/processing (an http roundtrip or more for each interaction with your data) someone else being in control of the programs you use, forcing changes and updates whenever they like, renting them as a service, your data hostage, snooped at, sold to advertisers a limited UI experience based on the DOM and browser APIs crappy OS integration (often) ads
- goodpoint 4y ago
  ...and more surveillance.
- govolckurself 4y ago
  Whoa now. Don't go after the cash cow! It's so much harder to rent-seek when people just run regular programs that don't require 10 gigs of RAM and internet access. But where's the career promotion in that?
- JadeNB 4y ago
  > (often) ads This one doesn't have much to do with online vs. offline except that you have to be online to see the "latest and greatest" ads. Stale ads can perfectly well be shown offline.
  - coldtea 4y ago
    Traditionally they weren't on offline software though. It's an online-era thing, and it thrives on online-ness, both for getting the "new" ads and for sending impressions and telemetry back. Even on modern offline-software-with-ads it's usually a glorified web view.
    - hgsgm 4y ago
      Most of my paid online software from non-monopolist providers doesn't have ads.
      - coldtea 4y ago
wheelerof4te 4y ago
Someday, in the far, far 90s, we had LAN. And everything worked. Now, you need 5Mbit speeds just to collaborate. Funny how the tech "progressed".
- _xivi 4y ago
  Too bad you can't use LAN to work from home
  - qtzfz 4y ago
    You use VPNs with more or less the same result.
  - bayindirh 4y ago
    Well, every WAN is a LAN when looked from a sufficient distance. DSL & Cable encapsulates Ethernet. City-wide networks are again Ethernet. In fact, everything is Ethernet with some routers between. So, you're actually using a mixed-carrier Enthernet LAN with a couple of NATs in the way. You can build another LAN on your LAN with VPN, too.
    - _xivi 4y ago
      I know you can use ethernet to build a network but if you build a global network with 90s technology, you'll get what?... the internet like we know today but worse. What problem was solved? That was my point responding to OP. We actually progressed and we are facing new challenges.
      - bayindirh 4y ago
        We're still using 90s technology. We only have faster switches, quicker routers, a couple of standards for faster connections, and some tools which disguise or repurpose deep packet inspection as "software defined networking". A country wide router still can stay in service for a decade. Residential FTTx installations consist of a TelCo class switch, maybe a router, compact DSLAMs if you have DSL service and a couple of fibers in, tens of fibers out for FTTH customers. It's faster hardware on the same stack. Nothing more, nothing less. ...and, oh, link-speed (transparent) DPI equipment in key places for lawful interception.
marginalia_nu 4y ago
Alexa, write me a witty response mentioning IP over Avian Carriers.
PhilipRoman 4y ago
Speaking of this, anyone have suggestions for an offline-tolerant distributed filesystem? Basically a dozen devices which get a few minutes/hours of internet access per day/week and not necessarily at the same time. I've considered Git but not sure how much overhead it adds.
- cesarb 4y ago
  > Speaking of this, anyone have suggestions for an offline-tolerant distributed filesystem? Basically a dozen devices which get a few minutes/hours of internet access per day/week and not necessarily at the same time. I've considered Git [...] If you've considered git, I would suggest looking at git-annex (https://git-annex.branchable.com/ https://git-annex.branchable.com/), which is tuned for that kind of mostly-offline use case.
- samwillis 4y ago
  Conflict resolution is the issue here. Effectively sync systems like DropBox and iCloud do this by flagging conflicting edits when you come back online and duplicate files (new a new file name) so there is no data loss. For a lower level file system though that's not really possible as you may be running databases, or other data models, that need to understand conflict resolution themselves.
  - em-bee 4y ago
    why would you share a database over a distributed filesystem, other than for backup purposes where you only have a single source so you should never get a conflict?
    - BlueTemplar 4y ago
      See cryptocurrencies.
  - PhilipRoman 4y ago
    For my personal use case I don't really care about conflicts - they could be crudely resolved by a timestamp or even randomly. Having backups in the event of a conflict would be good. Files are never updated incrementally, just added, renamed or deleted.
astatine 4y ago
I would argue that it really is the other way around - online is just offline with instant synchronisation
- em-bee 4y ago
  that's how any SPA should be written
eur0pa 4y ago
No?
croes 4y ago
He is not talking about offline applications but online applications with offline functionality. Since the rise of cloud applications and electron based applications I'm back at writing faster than the application can process my input. And I'm not a fast typist.
- capableweb 4y ago
  > Since the rise of cloud applications and electron based applications I'm back at writing faster than the application can process my input. And I'm not a fast typist. If the application you're using (the one(s) you're referring to when you say "cloud applications") is sending the key input to the backend and waits to render it client-side until it received a response, it's doing something horribly wrong and if that's how they write things, you probably want to avoid that for a multitude of reasons. Please name and shame though, so others can avoid it too :) Same goes for Electron-based applications, there is no reason they'd block showing the text you inputted, and if they just use <input/> without doing anything egregious, you really shouldn't be able to type faster than characters appearing on the screen, something is really, really wrong then, and I don't think it's because of Electron.
  - postdb 4y ago
    Seen that on mattermost, it is poorly written React or other SPA. It is one of reason why SPA get so much hate around.
  - tsbischof 4y ago
    I issues with Outlook Web App (M365) often. Dropped characters are not so common, but it is common for the cursor to bug out and insist on returning the to start of a line with each new character.
    - tonyarkles 4y ago
      Are you using Firefox? I had that problem consistently with OWA, but I recently switched to primarily Safari on an old MacBook and don’t recall having it happen recently.
adql 4y ago
Yeah and riding 1000cc bike is just like driving the bicycle with Extreme Speed /s > In the case of webRTC, I've seen so many projects do this where they’re like, “It‘s peer-to-peer! You just connect to the signaling server and then the things talks!” That’s not really peer-to-peer cause you've got a server. If you've already got a server...my advice is: don't mess around with peer-to-peer stuff, just use that server. The prevalence of NAT really did a number on ability to have properly p2p communication. And, well, rampant insecurity of default user setups making most internet connection be at the very least behind "only allow outgoing traffic or traffic initiated by user" type of firewall. Even if you make all that nice code with each user having it nice and secure private key and having to accept someone's public key to start communicating there is still problem with distribution and ascertaining that user is really who they are. And even if they are, well, they can be compromised, so your local app also have to be very secure or else the potential malware can just go between your contacts and compromise everyone using the app. Or, you can just use SaaS and don't worry about it, or at the very least not worry about more than one app having ability to compromise your system
- klabb3 4y ago
  NAT is definitely the villain but their are other things as well. You still need a discovery system to find who you want to connect with. An ip isn’t very good because it moves around, and DNS is too slow to be operationally viable. And even if you solve those you have an N^2 problem in the naive solution, and to reduce that you need mesh networks which just don’t have the QoS we’ve come to expect (to my meager knowledge). Imo we should be able to find a better middle ground, because full decentralization is insanely hard. If we had federated standards and tooling like web and email, but for modern use cases, I’d be a happy man. Despite (or perhaps because) the tech craze over the last decade, the developments of such open and useful standards leaves a lot to be desired. Almost everything cool these days is some app with perhaps an api that is branded as a “platform”. We’re basically treading water.
zaporozhets 4y ago
This sounds like something one might say during an LSD trip
jancizmar 4y ago
Well, nice, but who is going to make the money?
samwillis 4y ago
It's a bit like when smart phones happed we started doing ui "mobile first" as it easer to scale up a mobile UI to desktop, it's easier to start "offline first" and move to constantly online (even collaborative) than to start online first and add "offline" eventual consistency later. There is much chat about real-time collaborative apps, but the reality is that most people are working async most of the time. If you start with the concept of offline first, with eventual consistency for collaborative work, you implement all of the same conflict resolution as if you are implementing a real-time app with conflict resolution. Then adding real-time collaboration later is easy. This is where CRDTs (conflict free replicated datatypes) work better than OT (operational transforms). OT need more supervision from the server, the further you diverge from the servers state the more likely there will be a corruption. CRDTs are inherently designed to work with massive diversion and no central authority, really they are offline first.
tigerlily 4y ago
Nah. Offline is online with extreme immediacy. Get out there and DO IT NOW!
reportgunner 4y ago
What do we do about timeouts when dealing with extreme latency though.
- realPubkey 4y ago
  Just retry each X seconds. Also browsers have a navigator.onLine property which emits an event at the exact time the client is online again. I am doing this with rxdb and it works great.
jiggywiggy 4y ago
With apps I do this. I download the entire rest api. Often 5-10 mb.Entire api is versioned, every content update leads to new live version. And app works offline and super fast. Queue the api updates by default. And cache images / videos. Pretty doable. And api is rarely queried.
dccoolgai 4y ago
There is _one_ thing that can allow "two machines in the same room to talk to each other without sending a request to a server farm in Virginia". It does require the _first_ request to populate the app: Web Bluetooth. Unfortunately it's only implemented in Chrome,but it does work.
- realPubkey 4y ago
  P2P in browser was improved a lot in the past years. Your two machines could now connect via WebRTC and then send data to each other directly, no need for bluetooth. This works great and has a low latency. With rxdb you could even realtime-sync the whole application state [1] without connection to a server farm in virginia. [1] https://rxdb.info/replication-p2p.html https://rxdb.info/replication-p2p.html
- pvh 4y ago
  We tried Web Bluetooth in a project. It was extremely flaky. Notably it also only works as a server, so you cant peer two browsers over it either.
dariosalvi78 4y ago
an email client is a good example: you can read and send emails also offline (at least with most clients that keep a decent cache) and only synchronise when connected. But that works for some services, not all.
trevorg75 4y ago
SaaS has ruined the development landscape.
throwawaaarrgh 4y ago
Does your laptop have 200 terabytes of memory, 50 petabytes of storage, and 10,000 CPUs? No? Then it's not really the same thing is it? There are things you can never do on your laptop. Offline is limiting, in many ways. You know how I know? I grew up in the 90s. Online is a magical godsend of capability and functionality. Offline is cute. Online is what we dreamed of. Should you have offline modes? Of course. Should you have some offline-first applications? Of course. Is offline just online with extreme latency? Of course it isn't. Use your brain. Think.
muhaaa 4y ago
IF you can solve data sync for your application, local first is simple & easy to develop and feels very responsive for users. Lots of business applications are now in that range. 10MB of ERP data is like 1 year of operating a medium sized company is the equivalent of a picture of my cat.
phendrenad2 4y ago
TL;DR: This is about offline communications and not the world in general. It also assumes that communication is achievable. In the real world (offline and online), we have problems with that. When you attempt to communicate online you are often redirected "through the gift shop" so you can be shown the exact number of ads such that you statistically won't give up and pick up the phone (and I'm sure phonecalls will have pre-roll ads at some point too). In fact, ad-hoc random person-to-person communications online are gatekept by "the algorithm" which would rather answer your question directly to keep you from meeting another warm body online.
amelius 4y ago
"Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway." https://en.wikiquote.org/wiki/Andrew_S._Tanenbaum https://en.wikiquote.org/wiki/Andrew_S._Tanenbaum The latency, however ...
- systemtest 4y ago
  LTO-9 tapes do 45TB compressed, 18TB uncompressed. And uses around 0.23 cubic decimeter of storage. A European station wagon with the rear seats folded takes 1555 liters, with 95% utility that is 6422 tapes. That wagon can hold 289 Petabyte of compressed data From Amsterdam to Rotterdam, it takes about an hour to get your data to its destination. That is roughly 640 Terabits per second. For comparison, AMS-IX peaked at 11 Terabits per second last year.
  - lozf 4y ago
    What happens when you add the time to restore that all that data once you get to Rotterdam?
    - amelius 4y ago
      That depends on how many tape drives you have at the destination.
  - seabass-labrax 4y ago
    A fair comparison with AMS-IX would perhaps need to factor in the time spent reading/writing the tapes though. Compressed LTO-9 tapes can be fully read in about 12.5 hours, so assuming for sake of argument that your car contains 6422 compressed tapes with a total of 289PB of data on them already, and that you have (a rather expensive) array of 26 LTO-9 drives at your disposal in Rotterdam, you'll need about 130 days to fully read their data. The hour of driving across Holland is rather insignificant compared to that. All in all, you get 'only' 26 GB per second, limited to that only by having 26 drives.
keybits 4y ago
I'm excited about ElectricSQL as an enabler in this space: https://electric-sql.com/docs/overview/technical-intro https://electric-sql.com/docs/overview/technical-intro They're using SQLite on device with a sync service online. Their team have credentials that give me confidence: https://electric-sql.com/about/team https://electric-sql.com/about/team
- britannio 4y ago
  I have high hopes for ElectricSQL given that the co-inventors of CRDTs are on the team! It's like building a generative AI startup with authors of the transformer paper.
  - thruflo 4y ago
    Thanks! We’ve just opened up a call for design partners[0] if you (or any teams out there) might be interested in collaborating with us :) [0] https://next.electric-sql.com https://next.electric-sql.com
- yonz 4y ago
  James is speaking at the next local-first meetup. https://lfw.dev https://lfw.dev
deleted 4y ago
[deleted]
hamsterbase 4y ago
Couldn't agree more. I just developed a local-first read later software using CRDT technology. aka https://hamsterbase.com/ https://hamsterbase.com/ 1. all data is stored locally, one page corresponds to one CRDT file. CRDT file is a single source of information 2. use sqlite as cache for query and full text search. 3. use the version of CRDT as the file name. It is guaranteed that there will be no duplicate file names and never file content changes. Only files are deleted and added. In this architecture Users could synchronize their data with any intermediate media. Such as hard disk, iCloud, http interface, webdav. It is guaranteed that there will always be no conflicts.
- wg0 4y ago
  These ideas seem pretty doable for a single user note taking app but as soon as you include another collaborator, you've a whole another problem of different levels of conflicts, CRDTs and what not. Becomes lot more harder when you have some 100 agents in the field, taking orders on their mobile devices and you have to do full double entry book keeping even when offline.
  - mgkimsal 4y ago
    And... you've got a large list of customer, contact and historical info to allow access to. Sending that down to people so they have it locally becomes at least a bit of a privacy/security concern.
  - hamsterbase 4y ago
    This solution is suitable for processing documents. For example, figma uses a technique similar to CRDT. It is not suitable for processing orders.
    - preseinger 4y ago
      if two different users modify the same version of the same document in different ways, how do you resolve that conflict without losing information?
jongjong 4y ago
Except for all the people who died before the internet was invented. They were completely offline.
deleted 4y ago
[deleted]
alberth 4y ago
I've always thought of it as: Offline is Persistent, Online is Ephemeral. e.g. physical books can last centuries, an online blog - not so much.
6367529256 4y ago
[flagged]
6367529256 4y ago
&#^
titzer 4y ago
FTA: > Unfortunately, some of the open technologies for building more local-first, p2p applications just aren’t there yet. Like Peter’s point on webRTC. I guffawed at this. I mean, seriously. In the days before the internet was widespread, like mid-90s, there were actually multi-player games that worked over LANs, both IP and IPX. Somehow, people were able to configure multiple computers to talk to each other with this funny numbers called "addresses" or something. DNS existed of course, but you could also add to /etc/hosts, Novell had a thing, everyone had a thing. The problem is that somewhere around the mid 2000s or early 2010s we forgot that anything networking-related could be based around non-web protocols and stacks. What a disservice we've done ourselves. Not that I'm advocating people type in IP addresses or have to set up their own DNS servers or admin their own LANs, but wow, it's like part of our collective brains is just missing.
- Spivak 4y ago
  The bar is higher now which is what has really changed. Your thing has to work on every network, through multiple levels of NAT, without copy-pasting ip addresses or updating system files, often across multiple platforms. WebRTC is the focus because it won by a huge margin, other p2p protocols are a footnote. Everything uses WebRTC whether it actually has a web client or not.
- hgsgm 4y ago
  What happen is that dads realize that it's easier to write , maintain, and monetize multi-client software that runs primarily on the dev's computer and pushes some of the UI to the client, than multi-client software that runs primarily in the client computers.
- fnordpiglet 4y ago
  I think it’s more than forgetting. I didn’t forget for sure. But what is easily forgotten is why we moved from local p2p to internet brokered services. It’s mostly simplicity. By hosting all the state and discovery, match making, etc, in a remote service outside the local network and RF environment, you dramatically simplify everything to “configure the local tcp stack.” The 50’s-2010 world wasn’t awesome and things were super fragile, tedious, poor compatibility, etc etc. The move to service based approach meant protocols were homogenous and compatible, implementations were simple, state management easy, reliability near perfect, etc. You even get to ensure everyone has basically the same software since all the real software is in the service and there’s exactly one version on earth. In the bad old days you referred to, every device around you had some ragged edge version dependency graph of everything from the device to its network card through to the end user experience. It was a miracle anyone ever played Red Alert on the LAN. People always talk about “how expensive” it is to send packets to Oregon to turn on your lightbulb in seattle. But the cost is already fully loaded and paid for. If you didn’t notice it, maybe that’s because it’s actually not more expensive? Yes latencies are higher, and that’s literally the only downside I can imagine. But it is a lot more reliable, flexible, simpler to deploy in any environment, robust.
quartz 4y ago
I’d frankly be happy with more apps just being offline tolerant. Surely google maps knows I live in NYC by now but if I’m between stations on the subway the odds of me being able to pan around at various zoom levels is surprisingly low. Surely basic semi-static highway and geographic information could be locally stored (this basic information used to fit in a spiral bound book we’d keep in the back seats of our cars). iMessage just gives up if a message can’t go out rather than queuing it. Heck most weather apps won’t even show me the previously downloaded forecast if there’s no network, they just show “-“ or a sad cloud image.
- moritzwarhier 4y ago
  Re: Google I assume they still have the "offline maps" feature, but you set it up and select regions by yourself. I have no idea why they haven't automated that using their location tracking and AI features. Re: iMessage Yes that's a shame. Only excuse I can imagine is there should be some timeout by how much a message is allowed to be delayed. And because of SMS delivery etc this would probably cause a lot of complexity (cellular has its own queueing system, at least here, and it's unreliable)
  - hgsgm 4y ago
    Android GMaps has done this for years already.
fnordpiglet 4y ago
This seems to miss the fact that the cloud providers basic service is a highly discoverable highly available way of advertising endpoints and managing highly durable and resilient state in a distributed system. Yes you can do that locally. It’s just really fragile and difficult. The ability to collaborate between two local machines by using a well known service remotely that’s always available means even when the neighboring laptops lid is shut and reopened things work because the only real dependency that laptop has was its tcp stack. The other laptop doesn’t have to deal with the interruption, try to figure out when it’s come back online, renegotiate connectivity, figure out any state drift and reconcile state, etc etc. Bonus is it works the same when you take your laptop to the bathroom to take a crap as it did when it was 2ft away. I’m not even going to go into the pitiful state of adhoc local protocols and hardware stacks.
aequitas 4y ago
I think that boils down to CAP theorem and whether or not you want to shift the problems onto the user. With collaborative tools like chat or shared document editing. It's far easier for the system to deal with and for the user to conceptualise an availability error like not being connected to the WiFi or the cloud provider being down for a moment. Than it would be to deal with consistency errors like conflict resolution and asynchronous communication, eg: high volume chat channels/threads where responses arrive out of order or too late to be relevant. It's just easier to switch to a different tool like IM or phone when one cloud tool is down so you can quickly discus the topic there, that to postpone your mental train for when everything is eventual consistent. Or to switch to the 'offline' tools we already have, like e-mail, which require you to rethink your train of though to the different medium. Also central authorization and authentication are not to be overlooked. Those problems also suffer heavily when partitioned.
muyuu 4y ago
The other way to see it is that offline is the outmost possible edge computing. Or that offline is zero network latency for the stuff you have on your computer. Or that offline is, when functional, like online but without surrendering all control over your computing to someone else. All these metaphors have their own limited scope where they are true and most appropriate.
karanveer 4y ago
damn bruh, you just opened my eyes
jessmartin 4y ago
If you're interested in this sort of thing, there's a good group of folks who are building local-first libraries and software congregating at https://localfirstweb.dev/ https://localfirstweb.dev/ They have had a few meetups so far which have been really good (including PVH speaking at the first one). And many of the local-first builders are hanging in their Discord.
toolslive 4y ago
Yes and storage is just a high latency message to yourself in the future. This means everything that is in use in high latency communications can be used for storage.
- faxmeyourcode 4y ago
  Reminded me of this SIGBOVIK paper - "Harder drives: hard drives we didn't want or need" http://tom7.org/harder/\ http://tom7.org/harder/\
  - Joker_vD 4y ago
    Okay, that section on chainsaws was brilliant, and is somehow the sanest part of the paper: the following text gets progressively crazier.
vrglvrglvrgl 4y ago
[dead]
gspencley 4y ago
What's old is new again. Remember when there was no "cloud" and just locally executing software with local persistence? I want very much to return to that. There are a few use cases for me, personally, where SaaS / "the cloud" makes sense but for 99% of what I use a computer for, I want local only. I don't want my application to require an active Internet connection. I don't want it sending data to someone else's computer. Probably most importantly, I don't want the software that I pay for to change on me without my direct opt-in. The fact that we have articles about offline-first, cloud is "optional" is hilarious when this was just normal every day software only a few short years ago. I can't stand how trend-happy our industry is. "The Cloud" and "SaaS" solved a few problems for a few people ... but we went all in as if there were no alternatives and those of us who don't require mobility and would prefer that we can choose when to "upgrade" and what data to "share" were left behind.
- hunterloftis 4y ago
  I fondly remember locally-executing software with local persistence by default. To provide a counterpoint, though, during that time my entire family shared one desktop PC. Looking around me, right now: work macbook, personal linux laptop, smartphone, steam deck. I suspect that the workflows that were "fine" in 1995 would really wear on me today. Especially the ones that involve migrating documents from place-to-place for collaboration while trying to maintain a canonical master copy somehow. Today, because of de-facto reliance on the cloud, "setting up" a new machine - regardless of its OS - takes me about 20 minutes. If my laptop fell off of my bike, that would suck, but I wouldn't irretrievably lose important data. There are downsides to the current cloud-first paradigm too, of course. But I don't think it's _all_ downside.
  - gspencley 4y ago
    Yeah I never said it was "all" downside. I never migrated the majority of what I do to "the cloud" and I have multiple devices, laptops etc. in my house. Setting up a new Linux install takes me about 20 minutes. Wouldn't know about Windows. Then again, I probably use way fewer "services" / "apps" than most people. It's funny, I've always been a very tech savvy computer nerd. I've developed software for a living for 25 years. But the older I get and the more the industry changes the less I find I use "modern tech" as a consumer. I'm also not thinking back to 1995. This all started, in my memory, following the "mobile revolution" at the tail-end of the 00s. That's when more and more software that I use every day stopped selling perpetual licenses and started charging monthly subscriptions. Everything went "mobile first" and "cloud first" and it got more and more persistent as the 2010s went on. On a positive note, there is some software that used to be inaccessible due to price, like Avid's Pro Tools, that I can now afford thanks to the switch in pricing models. But even if it took me an entire weekend to set up a new device, I think that I would still prefer that over needing literally everything to have Internet access. It removes the control from me, the user, and places it in the hands of "the corporation." They can change the software without my consent. They can suffer outages (to be fair we can have local hardware failures too but it's under my control which makes a difference). I remember almost returning my PS4 when it required me to connect it to the Internet just to be able to use it on first boot.
shadowgovt 4y ago
Similarly, files are just a one-way pipe to an unknown process to be executed at some indeterminate future time (ranging from "now" to "never").
CalChris 4y ago
In related news … Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.
trasz4 4y ago
Online is just offline with the caching layer missing.
pyinstallwoes 4y ago
Offline is just online with 0 degree lightcone.
mpweiher 4y ago
Funny, I think online is just offline with extreme latency and variance...
samstave 4y ago
One thing that seems to have gone out the window, to a certain extenet, is the idea of DR, Business Continuity and resiliency for a few key reasons: 1. Cloud is not cheap, so doing a proper DR in a loud environment is going to price out small/medium businesses. 2. Most customers don't have staff skilled in the realms of "what if" disasters, and have not tooled to spin up a copy quickly in a new region/provider should their site get nuked. 3. Most cloud customers have zero plan for what to do when cutoff from their cloud providers, because of above. - It would be cool to pay for "ghost infrastructure" (I dont know if this exists already) But... the idea would be that as you build out your VPC/whatever environment, the cloud provider creates a ghost version of that infra in every other reegion (meaning all the configs and everything are mirroed to a repo at the other locations and allow one to spin up a complete copy of primary infa wherever one likes, and youre basically paying a small amount for a clean, up-todate DR copy of the environment as "a cost of doing business" but in the event you needto, load a snapshot of everything (sans actual data - thats extra) to just launch the environment... We built this manually in the past (manually meaning the ability to launch an instant VPC and migrate traffic to it... but this was a few years back and I am sure that its far more mature in the real world now... So what options do people have today?
davnicwil 4y ago
> Why can’t we do this easily yet? Well, because it's distributed computing. Distributed computing is hard... really hard! Especially for applications requiring any level of real-time-ish interactivity between different users. Two computers talking to each other in a room via a server in Virginia is not absurd. The physical distance is abstracted over completely, the application engineer needn't think about that at all, that's the beauty and point of protocols like tcp/ip. What cannot be abstracted over is the single source of truth in the networked system (the server) that makes a whole class of really hard problems go away. So as much as you can describe the remote server as a problem, because of latency perhaps, it is a vastly lesser problem than the distributed computing ones that'd be introduced in the alternative! That is the basic reason why things are the way they are, it's really not absurd or surprising at all, in my opinion.
gadders 4y ago
My pet peeve are mobile apps that work with good connectivity (mobile or wifi), and also work with no connectivity at all, but when there is patchy connectivity take a minute or so to decide which mode to work in. Spotify I'm looking at you. Especially on screens that absolutely should not need to request data from the server to render information.
chrismorgan 4y ago
Sometimes you can tell that you’re offline. Sometimes you can tell that you’re online. The real trouble is when you have an unreliable connection. That’s the worst of all available worlds, when systems fall apart in a wide variety of troublesome ways.
- genewitch 4y ago
  oh, like my starlink. I can't use it for VoWiFi, because it drops for a couple seconds every minute. So i use it to download, only. It also works for any VoD streaming service (youtube, netflix, etc), but will not work for live streams. Can't use it for gaming, then again with CGNAT on my main ISP i can't use it for gaming really, either. However stuff like matrix works fine on starlink, because it will eventually be able to phone home and do all of the queued transfers, and that's fine.
eric-burel 4y ago
"Build-time rendering is just pre-computed request-time rendering" lead to a whole lot of innovations in the JavaScript ecosystem and allowed a continuum of intermediate approaches to emerge
toss1 4y ago
>>>It almost sounds like a form of resilient design (i.e. progressive enhancement) if you think about it — the cloud as an optional, layered enhancement of your application. Now that’s a paradigm shift! This is literally what was pioneered by Lotus Notes 32 years ago. When everything was local, their rich-content databases could work just fine locally and also replicate on any desired schedule with other copies of the same databases/apps. The model was explicitly Seldom-Connected, so you could run stand-alone in a remote location for weeks and send/receive updates whenever you got to a phone line, or could have it collecting/distributing updates every N seconds on a persistent connection. A vastly superior model to everything I've seen since, and it is too bad that they, and especially IBM blew it with the weird programmability models and corporate-extract-every-dollar approach. Acting as if this is a somehow new concept is just a display of cluelessness, but it is good to see good concepts getting some attention (again).
lucasyvas 4y ago
This resonates a lot but there are substantial issues with offline-first for many apps, like permissions. Maybe a simpler way to put it - if what you are building requires client/server for security guarantees, cloud is IMO an easier delivery model than forcing your customer run their own database. Cloud is infinitely better operationally for these users. If they want to control the versioning, then on-prem is the answer. If permission modelling is no issue, offline first plus sync is optimal I think.
frereubu 4y ago
The older I get, the more skeptical I get about any article / comment / whatever that uses the word "just" in this way. "X is just Y", "Do do X you just need to do Y". It's almost always a trite oversimplification to an extent that it falls apart as soon as you start thinking about it in detail - as the comments here suggest.
glonq 4y ago
On my last project, we built a configuration/collection tool for sensors installed in remote locations. For certain operations, our failure mode was "the user will have to go online so the app can resolve things, then can go back to the remote location and try again". After folks explained that this could require a multi-day, multi-tens-of-thousands-of-dollars journey for the customer, we re-architected parts of the system to be tolerant of offline failures but still resilient and secure and saved the customer a potential round trip back to the field.
budoso 4y ago
Sounds like an opportunity for a new JS framework, because nobody wants to write this stuff themselves
syngrog66 4y ago
when I design new software I bias/default to CLI, monolithic, local-hosted, and offline-only, first. Then only if and when I have a good pressing reason to give it a GUI, or make it client/server, or require connectivity, or be cloud-hosted, do I carry out a refactor/redesign to add those features. And even after I apply the refactor/redesign I strive hard to maintain a UX configuration which retains all those original default qualities. Maintaining them side by side with the added alternate modes. Maybe its an age/era thing. Because I'm increasingly surprised when folks DONT use this approach. Felt like a design no-brainer. The private term I've coined for this philosophy is CLIFMO.
ilrwbwrkhv 4y ago
Rxdb pouch and couchdb. All forgotten tools to build wonderful offline products.
ranting-moth 4y ago
It's worth mentioning that the blog's author is not an expert on the matter. I really don't agree with the title or the article.
mensetmanusman 4y ago
Latency, bandwidth, signal to noise, etc. are all different by orders of magnitude
account-5 4y ago
Nearly everything about that article depressed me. I want just offline applications and if I need it in the very limited times I do, opt-in to cloud. All this "everything" is online is bullshit.
dcow 4y ago
We are beyond fucked in terms of any effort to build local-first software. Notably: 1. product people and interaction designers don't understand or care about the difference, which isn't strictly their fault, because 2. users don't understand (heck some even want a team of engineers making sure the DB doesn't drop their writes all day every day) and only care when the software can reasonably be used offline anyway, which means 3. standards, protocols, and platforms have baked in dependence on servers (oauth, tls, ip, mobile device native apis, the goddamned entire browser, etc.) for example, you can't do anything on iOS in the background unless you have a server sending the devices silent push notifications every 5 seconds ... also 4. true offline with anything more than 1 client is a distributed system and instantly hard, so 5. the entire tech community is not trained to build offline applications, we're trained to glue react UIs onto CRUD backends because thats how you 10x your SAAS revenue in valuation over 3 years. I am lucky enough to have worked on a few products where we did have to care about offline and it still ended up being relegated to the realm of "obscure edge case", for all intents and purposes. So you end up continually justifying why you're spending resources on supporting these weirdos who don't have reliable internet connections. Sigh. /rant These days, I do honestly think that some things just need to be online. The internet is meant to be a globally addressable network. You're not supposed to have these little islands of accidentally private because-we-ran-out-of-addresses-and-hacked-the-shit-out-of-the-protocol-(NAT) networks. You're not supposed to be afraid of someone sending port 22 on your laptop an ssh handshake because the crypto is good. The whole IP world is supposed to be zero trust. We dropped IPv6 scopes because they were a crazy idea for a different world where we all ran federated networks and whatever. The real point of "local first" in our modern world is about data ownership. If we can do anything as a community to help move the needle and get to a better place, it's building applications where clients truly own the data and the server just provides convenience and redundancy. Give clients cryptographically strong identities. Use webauthn. Sign requests. Trust users with their own data. Help users be sovereign and we solve lots of privacy and centralization issues all at once. /soapbox
ftxbro 4y ago
> "A lot of the time we're using the techniques to build aircraft carriers when what we really need is a bicycle: something simple, something personal, something that can take you where you need to go and that responds to you alone (and is a heck of a lot easier to maintain and operate)." sounds like "Linux is a semi-truck with 20 gears to operate. Windows is more like a car. TempleOS is a motorbike. If you lean over too far, you'll fall off. Don't do that."
oblib 4y ago
I made a version of an offline first app using PouchDB and CouchDB running on a Digital Ocean server. And a version that used a CouchDB installed on a local server (Raspberry Pi). There are a few ways to do that using those tools, and it's very easy to implement. I thought it was great, especially using a locally installed CouchDB, but my users didn't really care, and I mean not a bit. I don't have any big corporate users but there are some pretty big businesses and I could not convince them to run a DB on their side. They did not want to fuss with it. Some of them have been using my apps for over a decade and there's not been any serious issues of downtime so there is no sense of urgency even though I've made it clear that can happen, and the importance of having their data onsite, in their possession. I use it for my own accounts on my apps. CouchDB makes that very easy to do by itself. It's a built-in feature.

470 points by samwillis 4y ago

Relevant xkcd: https://xkcd.com/2224/ https://xkcd.com/2224/

kkfx 4y ago

Offline does not necessarily mean connected AT ALL, witch means not necessarily "local first" but "only local". Means on my iron, so under my control. For the local first part, witch means "casually connected systems", the extra layer of complexity offer another layer of control and resilience: an autonomous car, capable of limited inertial navigation, with full local maps, routing capabilities etc can move even without GPS. Sure, it's more costly and complex than a connected-only car, but it's FAR safer to use. Similarly an autonomous ship is far safer than a connected only one, for obvious reason. Similarly in human terms local people with local power are FAR more resilient and effective than meat-based dysfunctional robots tied to some procedure. A VERY small simple example: I'm moved to France from Italy some years ago, now I decide to convert my perfectly valid Italian driving license in a local one. There is an automated (long) procedure. When I start it I've have had to give a scan of my Italian driving license witch happen to be expired and so got renewed BEFORE the procedure complete. In a resilient system I simply can upload the new one, sure this act trigger some extra actions, but extra actions who will happen anyway, only just after a bigger delay. Did you remember the Toyoda model vs the Ford one? Well, local first it's the same. At any scale.

ggm 4y ago

Mike St Johns talked about DNSSEC bootstrap timers in the context of a VM on the shelf, brought live 4+ years later: how do you update the Trust Anchor for a cold VM image which is very old?

fastball 4y ago

I'd go one step further, and say offline is just real-time with extreme latency. This is what we realized when re-tooling our app for offline use – anything we build that enables offline use will by its nature enable real-time collaboration.

mfbx9da4 4y ago
Example? I don't see the link
- arve0 4y ago
  When you do not rely on ACID for data consistency, you need to architect for eventual consistency. For example CRDT on collaborative editing a text document.
pvh 4y ago
Just so!

0zemp1c 4y ago

yeah, no offline means no expectation of a response, that is very different than an extremely delayed response

_xivi 4y ago
The point is to bridge online and offline and make apps more robust If it works locally and there's no need for syncing or communication in the first place then yeah, problem solved!
mysterydip 4y ago
Like saying "blindness is the same as a really long blink". One has an expectation of seeing again, the other has no guarantees.

mfbx9da4 4y ago

I don't think "Offline Is Just Online with Extreme Latency" is a useful concept because it doesn't encapsulate the key difference: pessimistic or optimistic UI. For example, say you have a form. If you built it thinking online first you'll probably have some pessimistic UI which shows a spinner and waits for the server to respond with ok/error. You can't simply think, okay since we're offline, more latency -> show spinner for longer. You have to re-architect things so that the UI is optimistic, commits to a local database and that local database is synced up to the server when you come online. In my experience optimistic UI is way more complex to build. Many times the complexity is worth it though.

Karellen 4y ago
> You have to re-architect things so that the UI is optimistic, commits to a local database and that local database is synced up to the server when you come online. Isn't that exactly what the article argues for though? > This kind of idea would move you away from a product full of API calls to one based on data synchronization.
klabb3 4y ago
Those cases should both be solved with optimistic UI, so there’s no difference. You can have a little checkmark to indicate that it’s synced, like many chat apps do. > In my experience optimistic UI is way more complex to build. Many times the complexity is worth it though. Yeah, can attest to this. I’m working on an app[1] that strikes the trifecta: p2p, real-time and offline first. All of those things combined makes the amount of tooling, design patterns and resources available shrink to a tiny sliver compared to a typical web-based tech stack. I have researched probably 100 projects that sound promising but almost all have been a poor fit for one reason or another. I opted to build almost everything from scratch. Kudos to the JS ecosystem. They are way ahead in this space, with rxdb, watermelon, yjs, automerge etc. Unfortunately I couldn’t use any of them because I use a split-language stack. [1]: https://payload.app/ https://payload.app/
- dustingetz 4y ago
  to add to this - rotate CRUD mindset to CQRS, now you have a start event and an end event, this is the extent of the pending sync state which can be afforded to the user at any granularity - document level, message level, form or field level, etc. The cost is that other view queries don't reflect the pending event, only the view that issued the command has an association to the event. Which is usually the UX you want. Consider a master/detail form app where you insert a new record into a collection, but the view is sorted/filtered/paginated and your new record does not match the criteria and therefore vanishes. That is never the right UX. A less surprising alternative UX is to limit record creation to a specific form for the business rules of creation, and that form exists in the context of a specific collection view with business rules around newly created entities of that kind, with an invariant that newly created entities will always appear at the top or bottom of that collection (e.g. new messages are always added to the bottom of the chat history view). Now the optimistic update bypasses the database and simply writes through to the view optimistically and then when the ack is eventually received it seamlessly changes state without any UI jank. Now you can send many new messages rapidly and if the nth message fails and the rest of the messages went through you get a properly located error. With a CRUD mindset, probably the form is simply disabled until each individual insert succeeds - which means your chat app cannot keep up with you typing!

coldtea 4y ago

Online is just offline with extreme latency for any new data fetch/processing (an http roundtrip or more for each interaction with your data) someone else being in control of the programs you use, forcing changes and updates whenever they like, renting them as a service, your data hostage, snooped at, sold to advertisers a limited UI experience based on the DOM and browser APIs crappy OS integration (often) ads

goodpoint 4y ago
...and more surveillance.
govolckurself 4y ago
Whoa now. Don't go after the cash cow! It's so much harder to rent-seek when people just run regular programs that don't require 10 gigs of RAM and internet access. But where's the career promotion in that?
JadeNB 4y ago
> (often) ads This one doesn't have much to do with online vs. offline except that you have to be online to see the "latest and greatest" ads. Stale ads can perfectly well be shown offline.
- coldtea 4y ago
  Traditionally they weren't on offline software though. It's an online-era thing, and it thrives on online-ness, both for getting the "new" ads and for sending impressions and telemetry back. Even on modern offline-software-with-ads it's usually a glorified web view.
  - hgsgm 4y ago
    Most of my paid online software from non-monopolist providers doesn't have ads.
    - coldtea 4y ago

wheelerof4te 4y ago

Someday, in the far, far 90s, we had LAN. And everything worked. Now, you need 5Mbit speeds just to collaborate. Funny how the tech "progressed".

_xivi 4y ago
Too bad you can't use LAN to work from home
- qtzfz 4y ago
  You use VPNs with more or less the same result.
- bayindirh 4y ago
  Well, every WAN is a LAN when looked from a sufficient distance. DSL & Cable encapsulates Ethernet. City-wide networks are again Ethernet. In fact, everything is Ethernet with some routers between. So, you're actually using a mixed-carrier Enthernet LAN with a couple of NATs in the way. You can build another LAN on your LAN with VPN, too.
  - _xivi 4y ago
    I know you can use ethernet to build a network but if you build a global network with 90s technology, you'll get what?... the internet like we know today but worse. What problem was solved? That was my point responding to OP. We actually progressed and we are facing new challenges.
    - bayindirh 4y ago
      We're still using 90s technology. We only have faster switches, quicker routers, a couple of standards for faster connections, and some tools which disguise or repurpose deep packet inspection as "software defined networking". A country wide router still can stay in service for a decade. Residential FTTx installations consist of a TelCo class switch, maybe a router, compact DSLAMs if you have DSL service and a couple of fibers in, tens of fibers out for FTTH customers. It's faster hardware on the same stack. Nothing more, nothing less. ...and, oh, link-speed (transparent) DPI equipment in key places for lawful interception.

marginalia_nu 4y ago

Alexa, write me a witty response mentioning IP over Avian Carriers.

PhilipRoman 4y ago

Speaking of this, anyone have suggestions for an offline-tolerant distributed filesystem? Basically a dozen devices which get a few minutes/hours of internet access per day/week and not necessarily at the same time. I've considered Git but not sure how much overhead it adds.

cesarb 4y ago
> Speaking of this, anyone have suggestions for an offline-tolerant distributed filesystem? Basically a dozen devices which get a few minutes/hours of internet access per day/week and not necessarily at the same time. I've considered Git [...] If you've considered git, I would suggest looking at git-annex (https://git-annex.branchable.com/ https://git-annex.branchable.com/), which is tuned for that kind of mostly-offline use case.
samwillis 4y ago
Conflict resolution is the issue here. Effectively sync systems like DropBox and iCloud do this by flagging conflicting edits when you come back online and duplicate files (new a new file name) so there is no data loss. For a lower level file system though that's not really possible as you may be running databases, or other data models, that need to understand conflict resolution themselves.
- em-bee 4y ago
  why would you share a database over a distributed filesystem, other than for backup purposes where you only have a single source so you should never get a conflict?
  - BlueTemplar 4y ago
    See cryptocurrencies.
- PhilipRoman 4y ago
  For my personal use case I don't really care about conflicts - they could be crudely resolved by a timestamp or even randomly. Having backups in the event of a conflict would be good. Files are never updated incrementally, just added, renamed or deleted.

astatine 4y ago

I would argue that it really is the other way around - online is just offline with instant synchronisation

em-bee 4y ago
that's how any SPA should be written

eur0pa 4y ago

No?

croes 4y ago

He is not talking about offline applications but online applications with offline functionality. Since the rise of cloud applications and electron based applications I'm back at writing faster than the application can process my input. And I'm not a fast typist.

capableweb 4y ago
> Since the rise of cloud applications and electron based applications I'm back at writing faster than the application can process my input. And I'm not a fast typist. If the application you're using (the one(s) you're referring to when you say "cloud applications") is sending the key input to the backend and waits to render it client-side until it received a response, it's doing something horribly wrong and if that's how they write things, you probably want to avoid that for a multitude of reasons. Please name and shame though, so others can avoid it too :) Same goes for Electron-based applications, there is no reason they'd block showing the text you inputted, and if they just use <input/> without doing anything egregious, you really shouldn't be able to type faster than characters appearing on the screen, something is really, really wrong then, and I don't think it's because of Electron.
- postdb 4y ago
  Seen that on mattermost, it is poorly written React or other SPA. It is one of reason why SPA get so much hate around.
- tsbischof 4y ago
  I issues with Outlook Web App (M365) often. Dropped characters are not so common, but it is common for the cursor to bug out and insist on returning the to start of a line with each new character.
  - tonyarkles 4y ago
    Are you using Firefox? I had that problem consistently with OWA, but I recently switched to primarily Safari on an old MacBook and don’t recall having it happen recently.

adql 4y ago

Yeah and riding 1000cc bike is just like driving the bicycle with Extreme Speed /s > In the case of webRTC, I've seen so many projects do this where they’re like, “It‘s peer-to-peer! You just connect to the signaling server and then the things talks!” That’s not really peer-to-peer cause you've got a server. If you've already got a server...my advice is: don't mess around with peer-to-peer stuff, just use that server. The prevalence of NAT really did a number on ability to have properly p2p communication. And, well, rampant insecurity of default user setups making most internet connection be at the very least behind "only allow outgoing traffic or traffic initiated by user" type of firewall. Even if you make all that nice code with each user having it nice and secure private key and having to accept someone's public key to start communicating there is still problem with distribution and ascertaining that user is really who they are. And even if they are, well, they can be compromised, so your local app also have to be very secure or else the potential malware can just go between your contacts and compromise everyone using the app. Or, you can just use SaaS and don't worry about it, or at the very least not worry about more than one app having ability to compromise your system

klabb3 4y ago
NAT is definitely the villain but their are other things as well. You still need a discovery system to find who you want to connect with. An ip isn’t very good because it moves around, and DNS is too slow to be operationally viable. And even if you solve those you have an N^2 problem in the naive solution, and to reduce that you need mesh networks which just don’t have the QoS we’ve come to expect (to my meager knowledge). Imo we should be able to find a better middle ground, because full decentralization is insanely hard. If we had federated standards and tooling like web and email, but for modern use cases, I’d be a happy man. Despite (or perhaps because) the tech craze over the last decade, the developments of such open and useful standards leaves a lot to be desired. Almost everything cool these days is some app with perhaps an api that is branded as a “platform”. We’re basically treading water.

zaporozhets 4y ago

This sounds like something one might say during an LSD trip

jancizmar 4y ago

Well, nice, but who is going to make the money?

samwillis 4y ago

It's a bit like when smart phones happed we started doing ui "mobile first" as it easer to scale up a mobile UI to desktop, it's easier to start "offline first" and move to constantly online (even collaborative) than to start online first and add "offline" eventual consistency later. There is much chat about real-time collaborative apps, but the reality is that most people are working async most of the time. If you start with the concept of offline first, with eventual consistency for collaborative work, you implement all of the same conflict resolution as if you are implementing a real-time app with conflict resolution. Then adding real-time collaboration later is easy. This is where CRDTs (conflict free replicated datatypes) work better than OT (operational transforms). OT need more supervision from the server, the further you diverge from the servers state the more likely there will be a corruption. CRDTs are inherently designed to work with massive diversion and no central authority, really they are offline first.

tigerlily 4y ago

Nah. Offline is online with extreme immediacy. Get out there and DO IT NOW!

reportgunner 4y ago

What do we do about timeouts when dealing with extreme latency though.

realPubkey 4y ago
Just retry each X seconds. Also browsers have a navigator.onLine property which emits an event at the exact time the client is online again. I am doing this with rxdb and it works great.

jiggywiggy 4y ago

With apps I do this. I download the entire rest api. Often 5-10 mb.Entire api is versioned, every content update leads to new live version. And app works offline and super fast. Queue the api updates by default. And cache images / videos. Pretty doable. And api is rarely queried.

dccoolgai 4y ago

There is _one_ thing that can allow "two machines in the same room to talk to each other without sending a request to a server farm in Virginia". It does require the _first_ request to populate the app: Web Bluetooth. Unfortunately it's only implemented in Chrome,but it does work.

realPubkey 4y ago
P2P in browser was improved a lot in the past years. Your two machines could now connect via WebRTC and then send data to each other directly, no need for bluetooth. This works great and has a low latency. With rxdb you could even realtime-sync the whole application state [1] without connection to a server farm in virginia. [1] https://rxdb.info/replication-p2p.html https://rxdb.info/replication-p2p.html
pvh 4y ago
We tried Web Bluetooth in a project. It was extremely flaky. Notably it also only works as a server, so you cant peer two browsers over it either.

dariosalvi78 4y ago

an email client is a good example: you can read and send emails also offline (at least with most clients that keep a decent cache) and only synchronise when connected. But that works for some services, not all.

trevorg75 4y ago

SaaS has ruined the development landscape.

throwawaaarrgh 4y ago

Does your laptop have 200 terabytes of memory, 50 petabytes of storage, and 10,000 CPUs? No? Then it's not really the same thing is it? There are things you can never do on your laptop. Offline is limiting, in many ways. You know how I know? I grew up in the 90s. Online is a magical godsend of capability and functionality. Offline is cute. Online is what we dreamed of. Should you have offline modes? Of course. Should you have some offline-first applications? Of course. Is offline just online with extreme latency? Of course it isn't. Use your brain. Think.

muhaaa 4y ago

IF you can solve data sync for your application, local first is simple & easy to develop and feels very responsive for users. Lots of business applications are now in that range. 10MB of ERP data is like 1 year of operating a medium sized company is the equivalent of a picture of my cat.

phendrenad2 4y ago

TL;DR: This is about offline communications and not the world in general. It also assumes that communication is achievable. In the real world (offline and online), we have problems with that. When you attempt to communicate online you are often redirected "through the gift shop" so you can be shown the exact number of ads such that you statistically won't give up and pick up the phone (and I'm sure phonecalls will have pre-roll ads at some point too). In fact, ad-hoc random person-to-person communications online are gatekept by "the algorithm" which would rather answer your question directly to keep you from meeting another warm body online.

amelius 4y ago

"Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway." https://en.wikiquote.org/wiki/Andrew_S._Tanenbaum https://en.wikiquote.org/wiki/Andrew_S._Tanenbaum The latency, however ...

systemtest 4y ago
LTO-9 tapes do 45TB compressed, 18TB uncompressed. And uses around 0.23 cubic decimeter of storage. A European station wagon with the rear seats folded takes 1555 liters, with 95% utility that is 6422 tapes. That wagon can hold 289 Petabyte of compressed data From Amsterdam to Rotterdam, it takes about an hour to get your data to its destination. That is roughly 640 Terabits per second. For comparison, AMS-IX peaked at 11 Terabits per second last year.
- lozf 4y ago
  What happens when you add the time to restore that all that data once you get to Rotterdam?
  - amelius 4y ago
    That depends on how many tape drives you have at the destination.
- seabass-labrax 4y ago
  A fair comparison with AMS-IX would perhaps need to factor in the time spent reading/writing the tapes though. Compressed LTO-9 tapes can be fully read in about 12.5 hours, so assuming for sake of argument that your car contains 6422 compressed tapes with a total of 289PB of data on them already, and that you have (a rather expensive) array of 26 LTO-9 drives at your disposal in Rotterdam, you'll need about 130 days to fully read their data. The hour of driving across Holland is rather insignificant compared to that. All in all, you get 'only' 26 GB per second, limited to that only by having 26 drives.

keybits 4y ago

I'm excited about ElectricSQL as an enabler in this space: https://electric-sql.com/docs/overview/technical-intro https://electric-sql.com/docs/overview/technical-intro They're using SQLite on device with a sync service online. Their team have credentials that give me confidence: https://electric-sql.com/about/team https://electric-sql.com/about/team

britannio 4y ago
I have high hopes for ElectricSQL given that the co-inventors of CRDTs are on the team! It's like building a generative AI startup with authors of the transformer paper.
- thruflo 4y ago
  Thanks! We’ve just opened up a call for design partners[0] if you (or any teams out there) might be interested in collaborating with us :) [0] https://next.electric-sql.com https://next.electric-sql.com
yonz 4y ago
James is speaking at the next local-first meetup. https://lfw.dev https://lfw.dev

deleted 4y ago

[deleted]

hamsterbase 4y ago

Couldn't agree more. I just developed a local-first read later software using CRDT technology. aka https://hamsterbase.com/ https://hamsterbase.com/ 1. all data is stored locally, one page corresponds to one CRDT file. CRDT file is a single source of information 2. use sqlite as cache for query and full text search. 3. use the version of CRDT as the file name. It is guaranteed that there will be no duplicate file names and never file content changes. Only files are deleted and added. In this architecture Users could synchronize their data with any intermediate media. Such as hard disk, iCloud, http interface, webdav. It is guaranteed that there will always be no conflicts.

wg0 4y ago
These ideas seem pretty doable for a single user note taking app but as soon as you include another collaborator, you've a whole another problem of different levels of conflicts, CRDTs and what not. Becomes lot more harder when you have some 100 agents in the field, taking orders on their mobile devices and you have to do full double entry book keeping even when offline.
- mgkimsal 4y ago
  And... you've got a large list of customer, contact and historical info to allow access to. Sending that down to people so they have it locally becomes at least a bit of a privacy/security concern.
- hamsterbase 4y ago
  This solution is suitable for processing documents. For example, figma uses a technique similar to CRDT. It is not suitable for processing orders.
  - preseinger 4y ago
    if two different users modify the same version of the same document in different ways, how do you resolve that conflict without losing information?

jongjong 4y ago

Except for all the people who died before the internet was invented. They were completely offline.

deleted 4y ago

[deleted]

alberth 4y ago

I've always thought of it as: Offline is Persistent, Online is Ephemeral. e.g. physical books can last centuries, an online blog - not so much.

6367529256 4y ago

[flagged]

6367529256 4y ago

&#^

titzer 4y ago

FTA: > Unfortunately, some of the open technologies for building more local-first, p2p applications just aren’t there yet. Like Peter’s point on webRTC. I guffawed at this. I mean, seriously. In the days before the internet was widespread, like mid-90s, there were actually multi-player games that worked over LANs, both IP and IPX. Somehow, people were able to configure multiple computers to talk to each other with this funny numbers called "addresses" or something. DNS existed of course, but you could also add to /etc/hosts, Novell had a thing, everyone had a thing. The problem is that somewhere around the mid 2000s or early 2010s we forgot that anything networking-related could be based around non-web protocols and stacks. What a disservice we've done ourselves. Not that I'm advocating people type in IP addresses or have to set up their own DNS servers or admin their own LANs, but wow, it's like part of our collective brains is just missing.

Spivak 4y ago
The bar is higher now which is what has really changed. Your thing has to work on every network, through multiple levels of NAT, without copy-pasting ip addresses or updating system files, often across multiple platforms. WebRTC is the focus because it won by a huge margin, other p2p protocols are a footnote. Everything uses WebRTC whether it actually has a web client or not.
hgsgm 4y ago
What happen is that dads realize that it's easier to write , maintain, and monetize multi-client software that runs primarily on the dev's computer and pushes some of the UI to the client, than multi-client software that runs primarily in the client computers.
fnordpiglet 4y ago
I think it’s more than forgetting. I didn’t forget for sure. But what is easily forgotten is why we moved from local p2p to internet brokered services. It’s mostly simplicity. By hosting all the state and discovery, match making, etc, in a remote service outside the local network and RF environment, you dramatically simplify everything to “configure the local tcp stack.” The 50’s-2010 world wasn’t awesome and things were super fragile, tedious, poor compatibility, etc etc. The move to service based approach meant protocols were homogenous and compatible, implementations were simple, state management easy, reliability near perfect, etc. You even get to ensure everyone has basically the same software since all the real software is in the service and there’s exactly one version on earth. In the bad old days you referred to, every device around you had some ragged edge version dependency graph of everything from the device to its network card through to the end user experience. It was a miracle anyone ever played Red Alert on the LAN. People always talk about “how expensive” it is to send packets to Oregon to turn on your lightbulb in seattle. But the cost is already fully loaded and paid for. If you didn’t notice it, maybe that’s because it’s actually not more expensive? Yes latencies are higher, and that’s literally the only downside I can imagine. But it is a lot more reliable, flexible, simpler to deploy in any environment, robust.

quartz 4y ago

I’d frankly be happy with more apps just being offline tolerant. Surely google maps knows I live in NYC by now but if I’m between stations on the subway the odds of me being able to pan around at various zoom levels is surprisingly low. Surely basic semi-static highway and geographic information could be locally stored (this basic information used to fit in a spiral bound book we’d keep in the back seats of our cars). iMessage just gives up if a message can’t go out rather than queuing it. Heck most weather apps won’t even show me the previously downloaded forecast if there’s no network, they just show “-“ or a sad cloud image.

moritzwarhier 4y ago
Re: Google I assume they still have the "offline maps" feature, but you set it up and select regions by yourself. I have no idea why they haven't automated that using their location tracking and AI features. Re: iMessage Yes that's a shame. Only excuse I can imagine is there should be some timeout by how much a message is allowed to be delayed. And because of SMS delivery etc this would probably cause a lot of complexity (cellular has its own queueing system, at least here, and it's unreliable)
- hgsgm 4y ago
  Android GMaps has done this for years already.

fnordpiglet 4y ago

This seems to miss the fact that the cloud providers basic service is a highly discoverable highly available way of advertising endpoints and managing highly durable and resilient state in a distributed system. Yes you can do that locally. It’s just really fragile and difficult. The ability to collaborate between two local machines by using a well known service remotely that’s always available means even when the neighboring laptops lid is shut and reopened things work because the only real dependency that laptop has was its tcp stack. The other laptop doesn’t have to deal with the interruption, try to figure out when it’s come back online, renegotiate connectivity, figure out any state drift and reconcile state, etc etc. Bonus is it works the same when you take your laptop to the bathroom to take a crap as it did when it was 2ft away. I’m not even going to go into the pitiful state of adhoc local protocols and hardware stacks.

aequitas 4y ago

I think that boils down to CAP theorem and whether or not you want to shift the problems onto the user. With collaborative tools like chat or shared document editing. It's far easier for the system to deal with and for the user to conceptualise an availability error like not being connected to the WiFi or the cloud provider being down for a moment. Than it would be to deal with consistency errors like conflict resolution and asynchronous communication, eg: high volume chat channels/threads where responses arrive out of order or too late to be relevant. It's just easier to switch to a different tool like IM or phone when one cloud tool is down so you can quickly discus the topic there, that to postpone your mental train for when everything is eventual consistent. Or to switch to the 'offline' tools we already have, like e-mail, which require you to rethink your train of though to the different medium. Also central authorization and authentication are not to be overlooked. Those problems also suffer heavily when partitioned.

muyuu 4y ago

The other way to see it is that offline is the outmost possible edge computing. Or that offline is zero network latency for the stuff you have on your computer. Or that offline is, when functional, like online but without surrendering all control over your computing to someone else. All these metaphors have their own limited scope where they are true and most appropriate.

karanveer 4y ago

damn bruh, you just opened my eyes

jessmartin 4y ago

If you're interested in this sort of thing, there's a good group of folks who are building local-first libraries and software congregating at https://localfirstweb.dev/ https://localfirstweb.dev/ They have had a few meetups so far which have been really good (including PVH speaking at the first one). And many of the local-first builders are hanging in their Discord.

toolslive 4y ago

Yes and storage is just a high latency message to yourself in the future. This means everything that is in use in high latency communications can be used for storage.

faxmeyourcode 4y ago
Reminded me of this SIGBOVIK paper - "Harder drives: hard drives we didn't want or need" http://tom7.org/harder/\ http://tom7.org/harder/\
- Joker_vD 4y ago
  Okay, that section on chainsaws was brilliant, and is somehow the sanest part of the paper: the following text gets progressively crazier.

vrglvrglvrgl 4y ago

[dead]

gspencley 4y ago

What's old is new again. Remember when there was no "cloud" and just locally executing software with local persistence? I want very much to return to that. There are a few use cases for me, personally, where SaaS / "the cloud" makes sense but for 99% of what I use a computer for, I want local only. I don't want my application to require an active Internet connection. I don't want it sending data to someone else's computer. Probably most importantly, I don't want the software that I pay for to change on me without my direct opt-in. The fact that we have articles about offline-first, cloud is "optional" is hilarious when this was just normal every day software only a few short years ago. I can't stand how trend-happy our industry is. "The Cloud" and "SaaS" solved a few problems for a few people ... but we went all in as if there were no alternatives and those of us who don't require mobility and would prefer that we can choose when to "upgrade" and what data to "share" were left behind.

hunterloftis 4y ago
I fondly remember locally-executing software with local persistence by default. To provide a counterpoint, though, during that time my entire family shared one desktop PC. Looking around me, right now: work macbook, personal linux laptop, smartphone, steam deck. I suspect that the workflows that were "fine" in 1995 would really wear on me today. Especially the ones that involve migrating documents from place-to-place for collaboration while trying to maintain a canonical master copy somehow. Today, because of de-facto reliance on the cloud, "setting up" a new machine - regardless of its OS - takes me about 20 minutes. If my laptop fell off of my bike, that would suck, but I wouldn't irretrievably lose important data. There are downsides to the current cloud-first paradigm too, of course. But I don't think it's _all_ downside.
- gspencley 4y ago
  Yeah I never said it was "all" downside. I never migrated the majority of what I do to "the cloud" and I have multiple devices, laptops etc. in my house. Setting up a new Linux install takes me about 20 minutes. Wouldn't know about Windows. Then again, I probably use way fewer "services" / "apps" than most people. It's funny, I've always been a very tech savvy computer nerd. I've developed software for a living for 25 years. But the older I get and the more the industry changes the less I find I use "modern tech" as a consumer. I'm also not thinking back to 1995. This all started, in my memory, following the "mobile revolution" at the tail-end of the 00s. That's when more and more software that I use every day stopped selling perpetual licenses and started charging monthly subscriptions. Everything went "mobile first" and "cloud first" and it got more and more persistent as the 2010s went on. On a positive note, there is some software that used to be inaccessible due to price, like Avid's Pro Tools, that I can now afford thanks to the switch in pricing models. But even if it took me an entire weekend to set up a new device, I think that I would still prefer that over needing literally everything to have Internet access. It removes the control from me, the user, and places it in the hands of "the corporation." They can change the software without my consent. They can suffer outages (to be fair we can have local hardware failures too but it's under my control which makes a difference). I remember almost returning my PS4 when it required me to connect it to the Internet just to be able to use it on first boot.

shadowgovt 4y ago

Similarly, files are just a one-way pipe to an unknown process to be executed at some indeterminate future time (ranging from "now" to "never").

CalChris 4y ago

In related news … Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.

trasz4 4y ago

Online is just offline with the caching layer missing.

pyinstallwoes 4y ago

Offline is just online with 0 degree lightcone.

mpweiher 4y ago

Funny, I think online is just offline with extreme latency and variance...

samstave 4y ago

One thing that seems to have gone out the window, to a certain extenet, is the idea of DR, Business Continuity and resiliency for a few key reasons: 1. Cloud is not cheap, so doing a proper DR in a loud environment is going to price out small/medium businesses. 2. Most customers don't have staff skilled in the realms of "what if" disasters, and have not tooled to spin up a copy quickly in a new region/provider should their site get nuked. 3. Most cloud customers have zero plan for what to do when cutoff from their cloud providers, because of above. - It would be cool to pay for "ghost infrastructure" (I dont know if this exists already) But... the idea would be that as you build out your VPC/whatever environment, the cloud provider creates a ghost version of that infra in every other reegion (meaning all the configs and everything are mirroed to a repo at the other locations and allow one to spin up a complete copy of primary infa wherever one likes, and youre basically paying a small amount for a clean, up-todate DR copy of the environment as "a cost of doing business" but in the event you needto, load a snapshot of everything (sans actual data - thats extra) to just launch the environment... We built this manually in the past (manually meaning the ability to launch an instant VPC and migrate traffic to it... but this was a few years back and I am sure that its far more mature in the real world now... So what options do people have today?

davnicwil 4y ago

> Why can’t we do this easily yet? Well, because it's distributed computing. Distributed computing is hard... really hard! Especially for applications requiring any level of real-time-ish interactivity between different users. Two computers talking to each other in a room via a server in Virginia is not absurd. The physical distance is abstracted over completely, the application engineer needn't think about that at all, that's the beauty and point of protocols like tcp/ip. What cannot be abstracted over is the single source of truth in the networked system (the server) that makes a whole class of really hard problems go away. So as much as you can describe the remote server as a problem, because of latency perhaps, it is a vastly lesser problem than the distributed computing ones that'd be introduced in the alternative! That is the basic reason why things are the way they are, it's really not absurd or surprising at all, in my opinion.

gadders 4y ago

My pet peeve are mobile apps that work with good connectivity (mobile or wifi), and also work with no connectivity at all, but when there is patchy connectivity take a minute or so to decide which mode to work in. Spotify I'm looking at you. Especially on screens that absolutely should not need to request data from the server to render information.

chrismorgan 4y ago

Sometimes you can tell that you’re offline. Sometimes you can tell that you’re online. The real trouble is when you have an unreliable connection. That’s the worst of all available worlds, when systems fall apart in a wide variety of troublesome ways.

genewitch 4y ago
oh, like my starlink. I can't use it for VoWiFi, because it drops for a couple seconds every minute. So i use it to download, only. It also works for any VoD streaming service (youtube, netflix, etc), but will not work for live streams. Can't use it for gaming, then again with CGNAT on my main ISP i can't use it for gaming really, either. However stuff like matrix works fine on starlink, because it will eventually be able to phone home and do all of the queued transfers, and that's fine.

eric-burel 4y ago

"Build-time rendering is just pre-computed request-time rendering" lead to a whole lot of innovations in the JavaScript ecosystem and allowed a continuum of intermediate approaches to emerge

toss1 4y ago

>>>It almost sounds like a form of resilient design (i.e. progressive enhancement) if you think about it — the cloud as an optional, layered enhancement of your application. Now that’s a paradigm shift! This is literally what was pioneered by Lotus Notes 32 years ago. When everything was local, their rich-content databases could work just fine locally and also replicate on any desired schedule with other copies of the same databases/apps. The model was explicitly Seldom-Connected, so you could run stand-alone in a remote location for weeks and send/receive updates whenever you got to a phone line, or could have it collecting/distributing updates every N seconds on a persistent connection. A vastly superior model to everything I've seen since, and it is too bad that they, and especially IBM blew it with the weird programmability models and corporate-extract-every-dollar approach. Acting as if this is a somehow new concept is just a display of cluelessness, but it is good to see good concepts getting some attention (again).

lucasyvas 4y ago

This resonates a lot but there are substantial issues with offline-first for many apps, like permissions. Maybe a simpler way to put it - if what you are building requires client/server for security guarantees, cloud is IMO an easier delivery model than forcing your customer run their own database. Cloud is infinitely better operationally for these users. If they want to control the versioning, then on-prem is the answer. If permission modelling is no issue, offline first plus sync is optimal I think.

frereubu 4y ago

The older I get, the more skeptical I get about any article / comment / whatever that uses the word "just" in this way. "X is just Y", "Do do X you just need to do Y". It's almost always a trite oversimplification to an extent that it falls apart as soon as you start thinking about it in detail - as the comments here suggest.

glonq 4y ago

On my last project, we built a configuration/collection tool for sensors installed in remote locations. For certain operations, our failure mode was "the user will have to go online so the app can resolve things, then can go back to the remote location and try again". After folks explained that this could require a multi-day, multi-tens-of-thousands-of-dollars journey for the customer, we re-architected parts of the system to be tolerant of offline failures but still resilient and secure and saved the customer a potential round trip back to the field.

budoso 4y ago

Sounds like an opportunity for a new JS framework, because nobody wants to write this stuff themselves

syngrog66 4y ago

when I design new software I bias/default to CLI, monolithic, local-hosted, and offline-only, first. Then only if and when I have a good pressing reason to give it a GUI, or make it client/server, or require connectivity, or be cloud-hosted, do I carry out a refactor/redesign to add those features. And even after I apply the refactor/redesign I strive hard to maintain a UX configuration which retains all those original default qualities. Maintaining them side by side with the added alternate modes. Maybe its an age/era thing. Because I'm increasingly surprised when folks DONT use this approach. Felt like a design no-brainer. The private term I've coined for this philosophy is CLIFMO.

ilrwbwrkhv 4y ago

Rxdb pouch and couchdb. All forgotten tools to build wonderful offline products.

ranting-moth 4y ago

It's worth mentioning that the blog's author is not an expert on the matter. I really don't agree with the title or the article.

mensetmanusman 4y ago

Latency, bandwidth, signal to noise, etc. are all different by orders of magnitude

account-5 4y ago

Nearly everything about that article depressed me. I want just offline applications and if I need it in the very limited times I do, opt-in to cloud. All this "everything" is online is bullshit.

dcow 4y ago

We are beyond fucked in terms of any effort to build local-first software. Notably: 1. product people and interaction designers don't understand or care about the difference, which isn't strictly their fault, because 2. users don't understand (heck some even want a team of engineers making sure the DB doesn't drop their writes all day every day) and only care when the software can reasonably be used offline anyway, which means 3. standards, protocols, and platforms have baked in dependence on servers (oauth, tls, ip, mobile device native apis, the goddamned entire browser, etc.) for example, you can't do anything on iOS in the background unless you have a server sending the devices silent push notifications every 5 seconds ... also 4. true offline with anything more than 1 client is a distributed system and instantly hard, so 5. the entire tech community is not trained to build offline applications, we're trained to glue react UIs onto CRUD backends because thats how you 10x your SAAS revenue in valuation over 3 years. I am lucky enough to have worked on a few products where we did have to care about offline and it still ended up being relegated to the realm of "obscure edge case", for all intents and purposes. So you end up continually justifying why you're spending resources on supporting these weirdos who don't have reliable internet connections. Sigh. /rant These days, I do honestly think that some things just need to be online. The internet is meant to be a globally addressable network. You're not supposed to have these little islands of accidentally private because-we-ran-out-of-addresses-and-hacked-the-shit-out-of-the-protocol-(NAT) networks. You're not supposed to be afraid of someone sending port 22 on your laptop an ssh handshake because the crypto is good. The whole IP world is supposed to be zero trust. We dropped IPv6 scopes because they were a crazy idea for a different world where we all ran federated networks and whatever. The real point of "local first" in our modern world is about data ownership. If we can do anything as a community to help move the needle and get to a better place, it's building applications where clients truly own the data and the server just provides convenience and redundancy. Give clients cryptographically strong identities. Use webauthn. Sign requests. Trust users with their own data. Help users be sovereign and we solve lots of privacy and centralization issues all at once. /soapbox

ftxbro 4y ago

> "A lot of the time we're using the techniques to build aircraft carriers when what we really need is a bicycle: something simple, something personal, something that can take you where you need to go and that responds to you alone (and is a heck of a lot easier to maintain and operate)." sounds like "Linux is a semi-truck with 20 gears to operate. Windows is more like a car. TempleOS is a motorbike. If you lean over too far, you'll fall off. Don't do that."

oblib 4y ago

I made a version of an offline first app using PouchDB and CouchDB running on a Digital Ocean server. And a version that used a CouchDB installed on a local server (Raspberry Pi). There are a few ways to do that using those tools, and it's very easy to implement. I thought it was great, especially using a locally installed CouchDB, but my users didn't really care, and I mean not a bit. I don't have any big corporate users but there are some pretty big businesses and I could not convince them to run a DB on their side. They did not want to fuss with it. Some of them have been using my apps for over a decade and there's not been any serious issues of downtime so there is no sense of urgency even though I've made it clear that can happen, and the importance of having their data onsite, in their possession. I use it for my own accounts on my apps. CouchDB makes that very easy to do by itself. It's a built-in feature.