TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Local-First Software (2019)

185 点作者 brodo将近 3 年前

13 条评论

lewisjoe将近 3 年前
While it seems natural to assume CRDTs as foundational tech for local-first softwares, do keep in mind designing CRDTs for your app&#x27;s state may not be an easy job.<p>It&#x27;s easy if all your app does is append to lists or keep a counter or deal with generic key&#x2F;value pairs. Designing CRDTs for these cases is super easy.<p>But the moment you have a semantic JSON that has a grammar to its structure, you are going to need your own conflict resolution algorithms that keeps the semantic structure of your state clean and valid. That requires a lot more than slapping in a Yjs integration or Automerge integration.
评论 #31602038 未加载
评论 #31602301 未加载
braden-lk将近 3 年前
This is the article that convinced me to build LegendKeeper on top of CRDTs&#x2F;yjs. :) It comes with a unique set of challenges, but it’s helped me make a more user friendly, performant product. Plus local-first tech like CRDTs tend to get you collaborative multiplayer out of the box, too.
评论 #31598500 未加载
评论 #31626276 未加载
pkdpic将近 3 年前
&gt;&gt;&gt;<p>Seven ideals for local-first software:<p>1. No spinners: your work at your fingertips<p>2. Your work is not trapped on one device<p>3. The network is optional<p>4. Seamless collaboration with your colleagues<p>5. The Long Now<p>6. Security and privacy by default<p>7. You retain ultimate ownership and control<p>&gt;&gt;&gt;<p>I love the idea of local-first software based on the name but Im having a hard time understanding these ideals. Skimming through the rest of the text doesn&#x27;t seem to be helping.<p>What exactly makes software local-first? Like in concrete practical terms?
评论 #31597340 未加载
nikivi将近 3 年前
I think that&#x27;s the future of making web apps working fast. Trying to build some things now with Replicache (<a href="https:&#x2F;&#x2F;replicache.dev" rel="nofollow">https:&#x2F;&#x2F;replicache.dev</a>) and Logux (<a href="https:&#x2F;&#x2F;logux.io" rel="nofollow">https:&#x2F;&#x2F;logux.io</a>).<p>Replicache is a paid service though so trying to make it work with Logux ideally together with a SolidJS app I am building.
评论 #31600463 未加载
评论 #31598053 未加载
Rygian将近 3 年前
I was fully unaware of this article when I posted [1] about my ideas on a Personal File System, and now I realize there is a lot of common ground between them.<p>I particularly like that this article gives specific, actionable advice to any application developer on how to improve their &quot;local-firstness&quot; (section &quot;How you can help&quot; towards the bottom).<p>[1] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=31527886" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=31527886</a>
wim将近 3 年前
I think the combination of these &quot;ideals&quot; makes a lot of sense. If you want the combination of a web app but with native-like performance, you kind of get to many items on the list automatically.<p>The web app we&#x27;re building now is kind of like an IDE (but for tasks&#x2F;planning, <a href="https:&#x2F;&#x2F;thymer.com" rel="nofollow">https:&#x2F;&#x2F;thymer.com</a>), and obviously waiting for round-trips in an editor is no good. We thought we&#x27;d just do &quot;some optimistic rendering&quot; but in the end found out that the combination of many of these &quot;ideals&quot; is actually really powerful:<p>If every millisecond counts when rendering, you want some sort of optimistic rendering and you can&#x27;t wait for round-trips. Because of that it makes sense to have all data available locally, and have the client sync back changes when there&#x27;s time. CRDTs are great for this, and then multiplayer support is kind of easy too. And now that you have data locally available anyway, you might as well cache it in IndexedDB, so it works offline too. And because now you want features to work offline (e.g. search), you need to do them on the client anyway, which means you can also have end-to-end-encryption.<p>With techniques like CRDTs becoming more popular, and web APIs becoming more stable (like for local storage, offline workers and built-in crypto), we&#x27;ll probably see a lot more true &quot;local-first&quot; web apps. It&#x27;s obviously not all perfect on the web yet though. Support for PWAs is still really limited, IndexedDB is quite a mess (slow, clunky API, and and too many different policies with regards to what gets deleted when by the browser), but it&#x27;s getting much easier.
hawski将近 3 年前
Spinners. The problem with many applications that store state across the network is that they do <i>not</i> have a spinner. Far too often I tap or click something and there is no indication whatsoever that something is happening, that my action was registered. Sometimes with modern styling I don&#x27;t even know if the thing I tapped was active. I always think then that the developer did not perceive it would be possible to not have an immediate connection to the mother-ship. I don&#x27;t even live in a place with bad mobile or home Internet. I have 4G network all the time, 1Gb fiber at home and the same thing happens over and over.<p>Spinners even in local context are often necessary. We just want to see them less, but I think that for an interactive application there must be an indication that the app is responding to what I do. In local context I could have a slow disk or even a network connected storage. Also spinners that spin for 30 seconds giving no indication of why am I waiting or what for make me sad.
eternityforest将近 3 年前
Local first software is super important. I think there&#x27;s a pretty big set of use cases for a non-CRDT model.<p>Instead of a CRDT, you can do the extremely pragmatic thing and take the lowest common denominator of various file sync systems(SyncThing, Android SAF providers, WebDAV, etc) as your example.<p>At any time you can:<p>* Read a file * Create a file * Delete a file * Rename a file * List files in a folder<p>And usually:<p>* Any file you make will be synced * You don&#x27;t know what gets synced first * You don&#x27;t know when sync will happen * A conflict could create a copy of the old file, or just delete it * The user may or may not fully trust all of the storage providers.<p>For any single-user app, or app where collaboration doesn&#x27;t need to be real time, you can usually just use SyncThing or Dropbox or rsync.<p>What we need, then, is the equivalent for multi-user collaborative apps, some kind of abstraction for a &quot;document&quot; on a server, that people can edit, with permissions and all that, and that has document-scoped pubsub.<p>Perhaps some kind of sqlite over the web protocol.<p>Or, perhaps something like SyncThing optimized for multiple users and documents with different permissions.<p>Local first might be more popular if people didn&#x27;t constantly have to reinvent it for every app, and there was one reusable abstraction people could use.<p>CRDTs are great, but not everything takes advantage of them anyway. Unless you can do P2P and lan sync, you often still have a single point of failure server.
tlavoie将近 3 年前
I&#x27;m curious, it seems to me like the stated objections to CouchDB&#x27;s approach aren&#x27;t that bad, at least for quite a few use cases:<p>- Client optimistically goes to POST a JSON document. If new, there is no _id field included. - If there is no conflict, it&#x27;s fine. - If there is a conflict, the server tells the client this. The client can try again, including the _id field of the current document version.<p>Could the CRDT process not be applied on the client looking to make an update? Or at least on the server side, where the client says, &quot;OK, I&#x27;ve included the current _id, please merge my version&quot;?<p>I have not attempted personally to use this at scale, but had prototyped a tool for small-scale collaboration on a project that seemed to function &quot;well enough.&quot; No CRDT merging, but then there was no expectation of typically trying to work on the same sentence simultaneously. This was basically as a client&#x2F;project assessment tool; any given project would start from taking a copy of a template DB on the server, then syncing and updating from that. From there, any sort of local-first changes were trivial, and easily synced back to the central location when back online.
egypturnash将近 3 年前
&gt; “Old-fashioned” apps continue to work forever, as long as you have a copy of the data and some way of running the software. Even if the software author goes bust, you can continue running the last released version of the software.<p>This is assuming they&#x27;re not trying to phone home to a server and make sure your license is up to date.<p>I keep on thinking that someday I&#x27;m going to want to take a multi-month sabbatical from the internet; being able to keep on using Illustrator to draw stuff during this time is going to require finding a crack for it, as well as for the suite of plugins I depend on. Possibly a polite inquiry to the plugin developers will reveal the existence of a secret long-term offline mode available to people who&#x27;ve been helpful parts of the beta program for a while, or spur the creation of one, but I sure do not expect Adobe to cut me any slack despite being a paid user since the beginning of their subscription mode, nor do I expect them to release an official crack as one of their last acts before closing their doors forever.
stuaxo将近 3 年前
I&#x27;m glad someone has written this down, a lot of us probably think this but don&#x27;t bother.
PainfullyNormal将近 3 年前
&quot;Local-First software.&quot; Isn&#x27;t that just a desktop application that syncs?
Minor49er将近 3 年前
The in-page anchors are broken in this article. Clicking on the linked phrases &quot;later section&quot; or &quot;section on collaboration&quot; don&#x27;t move to those sections on the page
评论 #31599157 未加载