The push for local-first is driven by a few key new technological capabilities that previously restricted client devices from running heavy local-first computing:
No, it kept web pages from running heavy local-first computing. Native apps have been capable of this for quite a long time.
This article is pretty egregious in conflating “client” with “web browser”, which is a pet peeve of mine.
I think it’s more like application developers will go to some lengths to only have to support one broadly accessible platform rather than about five (iOS, Android, macOS, Windows, and “linux” as though it were only one target. Sorry BSD folks and other OS super-minorities). I can’t really blame them.
I am a solo dev at a small company. I develop and maintain a CRUD app that magically works on iPads, phones, desktops, barcode scanners etc. All thanks to… just being a website.
I still broadly agree that native is preferable though
Seriously. While reading this I was thinking yes, I have seen this movie. Outlook/Exchange started going around this circle 25 years ago. Local storage makes the UI super fast, and search works great. But then you have to sync, which means you have conflicts, which are in general impossible to solve without interrupting and confusing the user and doing a ton of work to solve cases the product people don’t want to think about. So in the name of sanity you go back to remote storage. Now the illusion of consistency is easier to maintain, but the UI is high-latency and freezes all the time, and the backend is baking client behavior into their APIs all over the place. Sentiment turns the other way and somebody funds the project to flip back to local storage (usually as if they just invented the idea). Repeat forever.
I mean, heck, if you want to go back to 1990, this is the NFS vs. AFS argument.
I was a little dubious that its little chart showing 138 ms of latency between US west coast and eastern Europe was the best speed possible, so I did the math. How much is light speed the limiting factor vs overhead in our infrastructure? Fiber doesn’t go in straight lines after all. All numbers correct to within 1%.
Distance between Paris and San Francisco is 9000 km, which is 30 ms for light traveling in a vacuum. Light in fiber travels slower than in a vacuum, and the figures I’ve seen are about 2/3 c, so let’s call it 40 ms. And it needs to be a round trip, so make that 80 ms. That’s… actually distressingly close to the 138 ms figure provided. Who the heck made light so slow?!
Obviously the solution is to drill straight-line holes through the earth’s mantle and core in strategic places, so we don’t have to go the long way around the surface of the sphere. Or more helpfully… I wonder if there’s a market to be had in fiber with a higher speed of light?
I could almost take that seriously until they said the geologists visiting the tunnel would never sneak burritos. Students of all kinds, and the weirder professors, would routinely smuggle in tanks of compressed gas, heavy-duty electromagnets and elaborate socks knitted out of ablative paracord for a chance to catch a migrating burrito in the wild.
Thank you for this. I was previously unaware of America’s greatest infrastructure project, whose ambition exceeds my previous favourite, Muamar Qadafi’s crowning glory, the Great Man-made River.
There is “hollow core fibre”, but I am not sure to what extent it has been successful outside the lab. (The University of Southampton has a research centre developing the technology.)
Oooh, those look cool, thanks! Looks like it’s trying to creep out of the lab but not widespread yet. Most of the material I can find on it is also more about lower attenuation than higher speed, but still, it’s a wild idea.
Maybe bump it up to satellites in orbit and use full-speed light between them? Hard to beat the bandwidth of many fibers across the ocean floors that way though.
Looks like adding 200 km of altitude adds about 3% to the distance of the trip, + 400 km up and down. So your 9000 km trip becomes 9700 km. 9700 km / c = 32 ms, so about 20% faster. Significant, but also a lot of extra work.
If the distance at the surface is d, the fraction of a great circle is d/40000km, which is 2π*d/40000 radians. Extra distance is height * angle, 200km * 2π*d/40000 = d * π / 100
That’s not really true. The warmth and brightness of the sun are largely unrelated to the speed of light, and more related to the solid angle that the Earth occupies in the sphere of radiation emitted by the sun.
I have been a professional software developer for 20 years. I like to think of myself as being up on the world of web technologies. And I just truly don’t understand how I’m supposed to use a web app offline. How do I get to it to use it? Am I the only one who has this disconnect of usability? Because I love this, but it’s never made sense to me.
Theoretically, you use the web app once online. The app is cached forever, and works on local data from there on out, and syncs local data to the server when you’re online.
In practice, nothing is ever cached when you need it to be, so you have a store of offline data that you can only use when you’re online to reach the app. (This ought to be fixed by now, by putting everything the app needs to start up in the service worker, but it still seems like it always goes wrong somehow.)
It seems to me like browsers aren’t really made to handle “owning” data, it’s all set up and designed with the assumption that the source of truth is somewhere else. I’d never trust a browser to be the only place where something important was saved. But perhaps that’s just me?
I think the idea is generally that local storage is only a temporary cache, and gets synced with the server when online. “Local-first” isn’t local-only!
Often, as a user, I’d rather have a somewhat fragile local cache than no functionality at all when I go offline for a bit. But of course that depends on the app domain.
But, it’s an interesting idea… would you trust a browser-based app that used (say) a local sqlite db rather than LocalStorage, and didn’t have a server-based backing store at all?
I like it. Just “Save Page As…” and done. Add lightweight peer discovery and a replication protocol, and that could be a very interesting evolutionary niche.
Xememex is a multiuser TiddlyWiki from Intertwingled Innovations. It allows large groups of people to work together on intertwingled wikis that can share content. It is implemented as a serverless application on Amazon Web Services. […] Xememex is currently only available under commercial terms from Intertwingled Innovations.
Intertwingled, eh? Meanwhile the original Xanadu says “WE FIGHT ON”. I’d be more interested in the cult of Nelson if this community wasn’t so doggedly doubled-down on commercial licensing and weird ideas about copyright.
Somewhere between absolutely not and probably not. The browsers themselves is the part I don’t trust. Safari will nuke your site’s storage after some number of days without use, so it’s unacceptable to rely on local only approach for that browser. Beyond that their IndexedDB implementation is buggy and those bugs have been unfixed for years.
In Android device manufacturers sometimes purge the browser storage when the device is low on disk.
Firefox keeps “local files” locked inside the “origin private file system (opfs)” so you still can’t back up your data easily, even though they’re supposedly the browser of user freedom, allowing a user to store actual local files in the real file system is Too Dangerous.
Only chrome provides an API that will let a browser app read & write to a file or directory that actually exists in the real world.
So maybe I would trust that local only app in chrome.
You visit the url, but the browser doesn’t load those direct from the web these days but instead asks the service worker what to do first. The service worker provider the stored asset and it works even though you have no internet
No, it kept web pages from running heavy local-first computing. Native apps have been capable of this for quite a long time.
This article is pretty egregious in conflating “client” with “web browser”, which is a pet peeve of mine.
Web developers will adopt complex new storage and synchronization APIs rather than
go to therapywrite native apps.I think it’s more like application developers will go to some lengths to only have to support one broadly accessible platform rather than about five (iOS, Android, macOS, Windows, and “linux” as though it were only one target. Sorry BSD folks and other OS super-minorities). I can’t really blame them.
I am a solo dev at a small company. I develop and maintain a CRUD app that magically works on iPads, phones, desktops, barcode scanners etc. All thanks to… just being a website.
I still broadly agree that native is preferable though
Websites:
Obviously there’s a lot of benefits to native applications too, but it’s not like there’s no reason to prefer browsers as an application platform.
A Few more:
Seriously. While reading this I was thinking yes, I have seen this movie. Outlook/Exchange started going around this circle 25 years ago. Local storage makes the UI super fast, and search works great. But then you have to sync, which means you have conflicts, which are in general impossible to solve without interrupting and confusing the user and doing a ton of work to solve cases the product people don’t want to think about. So in the name of sanity you go back to remote storage. Now the illusion of consistency is easier to maintain, but the UI is high-latency and freezes all the time, and the backend is baking client behavior into their APIs all over the place. Sentiment turns the other way and somebody funds the project to flip back to local storage (usually as if they just invented the idea). Repeat forever.
I mean, heck, if you want to go back to 1990, this is the NFS vs. AFS argument.
I’m strongly in the local-first camp. I recognize the problems you describe, but we’re getting better at dealing with them.
Seems like there has been a lot of progress on better theoretical underpinnings (CRDTs etc.), which presumably is a good thing.
I was a little dubious that its little chart showing 138 ms of latency between US west coast and eastern Europe was the best speed possible, so I did the math. How much is light speed the limiting factor vs overhead in our infrastructure? Fiber doesn’t go in straight lines after all. All numbers correct to within 1%.
Distance between Paris and San Francisco is 9000 km, which is 30 ms for light traveling in a vacuum. Light in fiber travels slower than in a vacuum, and the figures I’ve seen are about 2/3 c, so let’s call it 40 ms. And it needs to be a round trip, so make that 80 ms. That’s… actually distressingly close to the 138 ms figure provided. Who the heck made light so slow?!
Obviously the solution is to drill straight-line holes through the earth’s mantle and core in strategic places, so we don’t have to go the long way around the surface of the sphere. Or more helpfully… I wonder if there’s a market to be had in fiber with a higher speed of light?
Chord tunnels would also be good for high-speed burrito delivery, as was shown in 2007.
I could almost take that seriously until they said the geologists visiting the tunnel would never sneak burritos. Students of all kinds, and the weirder professors, would routinely smuggle in tanks of compressed gas, heavy-duty electromagnets and elaborate socks knitted out of ablative paracord for a chance to catch a migrating burrito in the wild.
Thank you for this. I was previously unaware of America’s greatest infrastructure project, whose ambition exceeds my previous favourite, Muamar Qadafi’s crowning glory, the Great Man-made River.
There is “hollow core fibre”, but I am not sure to what extent it has been successful outside the lab. (The University of Southampton has a research centre developing the technology.)
Oooh, those look cool, thanks! Looks like it’s trying to creep out of the lab but not widespread yet. Most of the material I can find on it is also more about lower attenuation than higher speed, but still, it’s a wild idea.
Maybe bump it up to satellites in orbit and use full-speed light between them? Hard to beat the bandwidth of many fibers across the ocean floors that way though.
Adds a significant amount of distance too.
Looks like adding 200 km of altitude adds about 3% to the distance of the trip, + 400 km up and down. So your 9000 km trip becomes 9700 km. 9700 km / c = 32 ms, so about 20% faster. Significant, but also a lot of extra work.
Heh, π% in fact :-)
If the distance at the surface is d, the fraction of a great circle is d/40000km, which is 2π*d/40000 radians. Extra distance is height * angle, 200km * 2π*d/40000 = d * π / 100
If it were much faster, the Sun would be hotter and brighter I think.
That’s not really true. The warmth and brightness of the sun are largely unrelated to the speed of light, and more related to the solid angle that the Earth occupies in the sphere of radiation emitted by the sun.
Source: PhD in physics
All things equal, the radiation would be greater.
Source: E=mc^2
+1 Source
Wouldn’t fusion produce more energy if c were bigger in E = mc²?
I have been a professional software developer for 20 years. I like to think of myself as being up on the world of web technologies. And I just truly don’t understand how I’m supposed to use a web app offline. How do I get to it to use it? Am I the only one who has this disconnect of usability? Because I love this, but it’s never made sense to me.
Theoretically, you use the web app once online. The app is cached forever, and works on local data from there on out, and syncs local data to the server when you’re online.
In practice, nothing is ever cached when you need it to be, so you have a store of offline data that you can only use when you’re online to reach the app. (This ought to be fixed by now, by putting everything the app needs to start up in the service worker, but it still seems like it always goes wrong somehow.)
It seems to me like browsers aren’t really made to handle “owning” data, it’s all set up and designed with the assumption that the source of truth is somewhere else. I’d never trust a browser to be the only place where something important was saved. But perhaps that’s just me?
I think the idea is generally that local storage is only a temporary cache, and gets synced with the server when online. “Local-first” isn’t local-only!
Often, as a user, I’d rather have a somewhat fragile local cache than no functionality at all when I go offline for a bit. But of course that depends on the app domain.
But, it’s an interesting idea… would you trust a browser-based app that used (say) a local sqlite db rather than LocalStorage, and didn’t have a server-based backing store at all?
Yet another alternative to having a server side is tiddlywiki-style self-replicating single-file programs that simply happen to run in a web browser.
I like it. Just “Save Page As…” and done. Add lightweight peer discovery and a replication protocol, and that could be a very interesting evolutionary niche.
Intertwingled, eh? Meanwhile the original Xanadu says “WE FIGHT ON”. I’d be more interested in the cult of Nelson if this community wasn’t so doggedly doubled-down on commercial licensing and weird ideas about copyright.
Somewhere between absolutely not and probably not. The browsers themselves is the part I don’t trust. Safari will nuke your site’s storage after some number of days without use, so it’s unacceptable to rely on local only approach for that browser. Beyond that their IndexedDB implementation is buggy and those bugs have been unfixed for years.
In Android device manufacturers sometimes purge the browser storage when the device is low on disk.
Firefox keeps “local files” locked inside the “origin private file system (opfs)” so you still can’t back up your data easily, even though they’re supposedly the browser of user freedom, allowing a user to store actual local files in the real file system is Too Dangerous.
Only chrome provides an API that will let a browser app read & write to a file or directory that actually exists in the real world.
So maybe I would trust that local only app in chrome.
You visit the url, but the browser doesn’t load those direct from the web these days but instead asks the service worker what to do first. The service worker provider the stored asset and it works even though you have no internet
Time is a flat circle.
I believe that you will find that time is, in fact, a cube.