I have always liked the idea of local first. The problem with it though, is that it almost always suck or isn't that important or both.
At least for myself, I barely use any local first software. The software that I do use that is local in any important sense of the word is basically local-only software. I realize this every time I lose connection on my phone. It becomes pretty much a pretty bad camera compared to my Sony.
I live in a country were I have good 3G speed pretty much everywhere so internet connectivity is never an issue, not even on moving things like trains or boats. The very few times I have been flying or whatever I simply don't do any work because it's usually uncomfortable anyway.
This is the main reason I don't really care about local first and have been diving into Phoenix Liveview the last couple of weeks. The productivity boost I get and cool realtime apps it empowers me to build is more important to me than the dream of making local first web apps. A realtime demo of things updating with multiplayer functionality is a far easier sell than "look, the app works even when I turn on flight mode". And honestly, in like 99% of the time, it is also more useful.
I have done local first web apps before and it is always such a pain because syncing is a near impossible problem to solve. What happens if you and someone else have done changes to the same things like 2 hours or more ago? Who even remembers which value is correct? How do you display the diffs?
No matter what you do, you probably need to implement some kind of diffing functionality, you need to implement revisions because the other guy will complain that the changes were overwritten and so on. There is just so many issues that is very hard to solve and require so much work to be done that it isn't worth it unless you are a large team with a lot of resources. You end up with a complicated mess of code that is like git but worse in every way.
It's easier to simply say the app doesn't work offline because we rarely are offline and no one will pay for the effort required. Unfortunately.
Fascinating how far technology use and philosophy has diverged between generations.
I'm old school and local first. I don't own a smart phone and I host my own music, video and I read real books and ebooks I download and read from an off line eReader.
Then I compare with the modern man who streams his music, video, buys audio books as a service, uses only web browser applications, and then bitterly complains when the internet goes down, or when the prices of his apps go up, or when his favourite music or movie disappears from the service provider and so on and so on.
So not only a complete loss of control and computing autonomy, but also a financial drain as well when counting the cost of all the apps and services.
Mean while, I'll happily chug along, local first, and if the internet doesn't work, at most my web browsing and email suffers, but since I do have my reference libraries, documentation and interpreters available locally, I can still get work done until the internet comes back up.
Yeah I kind of agree with what you're saying, the main issue for me is that I work in web dev and very few people are like you are and would pay for local first software. I have a hard time even convincing people I know hate cloud spyware shit to use local first alternatives that require just a little more setup.
I would love to make all my work local first but when the users are requesting other things I have to oblige. The feature list is long and the time is short. I simply can't spend a lot of time on making a sucky git alternative for when conflicts happen. When doing work on my spare time projects I want to make as much as possible in the little time that I do have, so local first is pretty much on the bottom of the list. Personally, I tried to build a music library but it's very hard today since you can't get music legally in a good cheap way. Illegally by torrenting is also hard because no one torrents music anymore.
I do keep a library of movies but I rarely visit it and stream new movies with torrent software. Basically everything else, like work, is mostly online based today so there is not really much to do locally anymore except photo editing and watching movies for me. Of course, I do still develop on my machine but as soon as I get stuck on something I need the internet to look up some reference or whatever and if I don't have the internet I can't get emails or chat messages from colleagues or push my code anyway so then I can only work for a short while.
I completely hate most cloud software and prefer local first but my issue is that no one except nerds on hackernews really cares about it and it is too much work for little gain. I actually are in a process to rewrite a side project that I hope to one day be a business from a local-first react project to a phoenix liveview. Why? Because I think the realtime aspects of the project will bring in more customers and it's far easier to maintain the state. So again, less work and more features I will actually get paid for.
If I ever make it to a stable business, I will probably make a small portion of the app work offline because I know some customers will like it when they use it under ground.
Convenience is king. As life piles up (errands, parenting, everything), cognitive capacity goes down and the more the user wants a "push button do everything" solution. They'll trade autonomy for ultra-convenience + a dropped internet connection now and then. I'm somewhere in the middle, but I see why people do either.
People just don't care (anymore) unless it affects them personally. I have no idea if it used to be like that or if is a function of modern society where you get accustomed to it due to a lifestyle that is good for the majority of the time.
Some people like me cares too much about too much and thinks a lot about stuff like this. I wish more people would care about more things but it just ain't so.
You can implement local-first with the merging strategy of last-write-wins, which is equivalent as any cloud app where the server is the source of truth. But now you automatically get all the other benefits of local-first:
- you can use it offline and expect changes to merge when coming back online. With the caveat that changes may be lost, but it's at least possible to have pending changes, you don't even have that option on cloud apps
- easier to develop, no more developing custom API backends
"à la", there is no diacritic on "la". "à" means (roughtly) "to" and there is a diacritical mark to distinguish it from "a" as in "il a", "he has". But "la" means "the", like "le" but female, and there is no need to distinguish it from any other homograph.
It's a personal blog made for fun. Both features made me smile. What's the problem? The kind of attitude you're displaying here just depresses me. Makes me lose faith in humanity.
I personally don't think it should be toggleable, it is their choice how to setup their site. You eigther like or you don't.
But you can easily remove the dom element that displays the cursors if the content is interesting to you and the cursors are the only thing preventing you from reading it..
It's just distracting. I didn't read to the end because it got so annoying. Now I don't give you any shit if you want to do fun shit on your private blog (hell mine was only accessible via telnet for quiet some time) but don't expect people to not be annoyed. :)
Everything is annoying to somebody. Software doesn't have to always be optimized to minimize annoyances. Sometimes it's just fun to optimize it for your own amusement, and a personal blog (which this is) gets a pass from me.
>Everything is annoying to somebody. Software doesn't have to always be optimized to minimize annoyances.
This is just not true, but in any case, don't get your point. The author has all the right to add anything to his blog, it's just that a lot of people will find it annoying and will stop reading, like some people mentioned here.
If the author thinks the cursors are worth the people not reading the actual content, then good for him.
And by the same token many will find it the signature of a distinct and memorable personality and be more likely to recall it over the long term. If they like adding quirks that create a lasting impression to a subset of people, good for them!
Which part? The second sentence is just my opinion, and you're free to disagree. :)
My point is that somebody will always find reasons for not wanting to read an article. Whether that's because they don't like the color scheme, font, or any other style choice. You can't please everyone with design. I think we can agree that that statement is objectively true.
So given that, a personal blog is the right place to do whatever pleases the author the most, instead of optimizing for metrics that impact engagement, or whatever nonsense KPIs developers are asked to optimize for in their day job. People interested in the content can always choose to consume it however they prefer instead (thankfully, the web is still open in this sense). In this case you can disable JavaScript, use reader mode, a custom stylesheet, or any other barebones browser instead. Considering this article is directed at a technical audience, any of these should work for you.
The problem for me (not parent) is that it is distracting to the point where I gave up reading the article. I have ADD, and it just made it impossible for me to focus on the content, which is unrelated to whether or not I may find it amusing as an idea.
Edit: and yes, I could've used Reader Mode of course, but I didn't think of it at the time.
The blog looked like something discussing an important topic for the owner and not primarily for entertainment.
People lost their bearing about if and when stupid visuals ruin or not their message, derail attention. And they stopped caring as well. They just want to make something funny looking, this is a primary motivation, coming up with stupid ideas and pushing it anywhere and everywhere. I belive this is a problematic attitude in the age of pretension. Which made me to loose my faith in humanity.
For me it's simply that I don't care about the opinions of anyone who thinks this is a fun feature to overlay their text content. On a front-page or experimental sub-page? Sure. On an article? I'm done.
Might make me a killjoy but there's a time and place for everything.
The problem is that it's annoying. I agree with the first post, I am not going to read this while flies are moving in my screen. Besides, if those are other people's cursors, that's kind of creepy.
If you lose faith in humanity because of this, you should look into it.
I think is the goofiest and most lovely feature. It gave me a weird sense of community presence while reading (and most people keep their cursors off the text anyway)
I really dislike this. Sure...it's fun, but where did I "sign up" to allow others to see where my mouse pointer is? How do I disable it? What else, from my machine, is being captured and broadcast?
I think this is a good place to plug prefers-reduced-motions, which is a setting to signal that the user doesn't want unneeded motion on the screen. I don't think many sites support it, but (as someone who finds this very annoying) I wish more did.
Its somewhat amusing every time this blog comes up on the front page and 50% of the comments are about the pointers. I guess its a good way to generate activity around the post haha
For someone who always complains about design choices, it's quite ironic that he ended up putting mouse cursors flying around, obstructing your view and constantly distracting. At the Blacksmith's House...
I love local first, but I struggle with how to monetize truly local-first applications. I know that's not everyone's favorite topic, but I've got bills to pay and payroll to make. Our product is about 80% local-first, with live collaboration and image hosting needing a server. I plan to change that eventually, but I worry that jailbreaking the app in this way will lead to financial troubles.
Obsidian's model seems nice: base app is free, and then payment for the networked portions like sync+publish. However, there's little data available on how well this works and how big of a TAM you need to make it sustainable. Or if it's even possible without an enterprise revenue channel.
For those interested in building robust local-first + collaborative apps, I've been using Yjs for a few years now and have overall really enjoyed it. Multi-master collaboration also poses some stimulating technical and design challenges if you're looking for new frontiers beyond the traditional client-server model.
Local-first isn’t a good model for projects that need to monetize. I’ve given this a lot of thought as well. I think it only makes practical sense for apps that exist to serve a public benefit.
Yeah at the end of the day, we'll do what lets us keep doing. It does suck that local-first seemingly does not have monetary alignment with public benefit though. A robust local-first app (if we're including syncronization too) is very expensive to make. It's become a bit easier in the past couple of years though.
> Local-first isn’t a good model for projects that need to monetize.
It worked all the way through the 80s, 90s, and most of the 00s. It brought Adobe, Ableton and many others to their dominant market positions, despite rampant piracy. It works for a lot of games, still.
Developers shooting themselves in the foot by providing applications for free or 4.99 usd for user growth. Now it feels more like B2B at scale than B2C.
Thank you for articulating this so well. This is the core of why local-first applications can’t be effectively monetized. Users expect the best things for free or very cheap, and that’s mostly incompatible with the local-first concept.
They're probably generating far less revenue now than if they started to kidnap and enslave people for profit. At what revenue does it start "working"?
Humoring your ridiculous comparison, no that’s not true.
Revenue maximization given mission constraints is usually the goal. SaaS is simpler, more economic and generally aligns incentives between parties better.
There are many things where a one time cost makes sense, though.
So you're saying they've reached peak revenue? The best they can do is stabilize? And that's why we've reached a point that it wasn't working but now it is?
>It worked all the way through the 80s, 90s, and most of the 00s. It brought Adobe, Ableton and many others to their dominant market positions, [...] What’s changed?
To clarify the conversation, "local-first" vs "cloud-based" is inadvertently getting muddied up with revenue models such as single-payment vs ongoing subscriptions. Those are 2 separate concepts.
Adobe/Ableton/Quicken desktop software still run locally on the users computer. Adobe Photoshop can save ".psd" files locally on the computer. But they have ongoing subscription fees and if users don't keep up the payments, they lose functionality or stop working.
Instead, what people often mean by local-first is "local _data_ stored on my computer as a 1st-class concept". The Single-Source-Of-Truth of data is preferably on my home computer and the cloud is just a convenient replica for backup or sharing. Ideally, the local-first data is also a an open format instead of a proprietary opaque blob. Examples would be local-first Obsidian (markdown files stored locally on computer) -- vs -- Notion (notes stored in the cloud). Or local-first NextCloud instead of cloud-based DropBox.
As your examples showed, local-first software can be monetized via subscriptions.
OTOH, if I need a network connection to verify my subscription status for the software to work in the first place it eliminates one of the main benefits.
A bunch of things changed fundamentally in ways that will never go back. As a consequence shrink-wrap software licensing is dead and will never return, sorry :( That happened because:
1. Users expect apps to keep working in the face of platform regressions and policy changes, for "free" (no unexpected extra charges). In the 90s Microsoft went through heroics to make buggy apps work on Windows 95 because if someone bought Windows 95 and an app broke, the user returned Windows to the store and got a refund. In 2024 if Microsoft or Apple ship a buggy OS update and it breaks your app (which they do), the user returns your app to the store and gets a refund. They don't see the platforms changing around them, they just know that your thing worked yesterday, today it doesn't, it's your fault, fix it.
This lack of 100% solid backwards compatibility means it's not feasible to sell a program once and let users keep it forever. They won't keep up their end of the bargain and, by the way, governments will always take their side and not yours so don't think you can just wash your hands of such problems via a EULA. Open source apps can get away with this because there was no purchase to begin with, commercial apps cannot.
2. App Stores happened. That means users can leave reviews and star ratings. In the 90s if you sold an app that happened to crash regularly if you pressed a certain combination of buttons, well, maybe three months later a magazine reviewer would notice or maybe they wouldn't. At any rate it hardly mattered unless you had some kind of unusually high level of bugginess and that fact spread through word of mouth.
In 2024 if you ship a version with even very obscure bugs users affected by it will immediately start leaving negative reviews. You have to fix this or else your app will become unpopular and you'll lose money, but again, this means a continuous stream of updates which everyone gets, which requires ongoing revenue to pay for it.
3. Collaboration happened. In the 90s networks were weak and most computer users worked alone. If Fred bought Office 2000 and you were still using Word 95, then it was expected that Fred would just know this somehow and also know how to use the "Save as" dialog box to save in Word 95 format. It was also expected that Fred's employer would provide a synchronous LAN fileshare using SMB where Fred could store a file. This was OK because remote work wasn't really a thing, and people tended to work in the same physical building. Because apps did releases so rarely and file writes were all synchronous/SMB supported file locks, this complexity was just about tractable albeit only as long as users had a high tolerance for computer nonsense. In the modern era collaboration is expected to Just Work without users having to phone up their mates to find out what app version they're using. That means everyone has to be on the same version, which means everyone has to get all the updates all the time, which means they all benefit from ongoing work by the company, which means a subscription. Plus we expect to be able to work from anywhere in the world, and from devices that don't support synchronous networked filesystems like iPads which means a custom per-app server farm. Those costs also matter here, see my other comment for why the Dropbox trick doesn't really work that well.
You ask why games don't seem to be affected by this. They are affected by this and they adopt a few strategies:
• Primarily target games consoles. Way more stable platforms with way fewer regressions.
• Adopt subscription payments too. See: MMORPGs.
• Keep costs low and hope they can cover them from the sales revenue as the player base expands.
• Just don't support games for more than a few months after they launch. That works because games are short-lived things usually. If the game is broken a year after release a few hard-core fans will care but most people have completed the...
So then it sounds like we have to resensitize people to the upgrade treadmill and make people intolerant of it, so we'll have an incentive to get our software right the first time. If hardware engineers can get their products right once and for all, then why can't we? Are we lesser engineers? I suspect so.
Well, hardware engineers make mistakes too but they're covered by us software guys :) Drivers are full of workarounds for buggy hardware. And when things can't be hacked around with a firmware update hardware sometimes needs entire product recalls .... something we fortunately don't have to worry about.
A lot of game developers can afford to "ship it and forget it" because game consoles don't break APIs, and Windows has generally best-in-class backwards compatibility. MacOS and mobile operating systems, less so.
Depends on who the target customer is. As an enterprise I'd love to pay for a local application wherever possible. Oracle and MS still make billions on what are effectively local database applications.
For consumers projects - especially desktop - it's more difficult. Many would rather pirate software than pay a few hundred dollars a year for a licence. However, the advent of highly controlled app stores has mitigated this somewhat.
Yep. Local-first is further commoditizing software.
Users will refrain from paying a subscription if their app version works and they don't need updates. The good old buy-a-license with 1 year of updates will likely make a big comeback. Local-first software, at least in lix universe [0], does not have fixed recurring maintenance costs like running servers. The elimination of fixed recurring maintenance costs will lead to a proliferation of "hobby apps" that are undercut by price/make it free altogether.
Which is wonderful for users that want that and are savvy enough to understand the limitations! However, hobby apps will not be able to afford designers or support or long-lived servers. As long as the social contract is clear, it's a net win. The issue comes when end-users expect the same level of support and continued updates from hobbyists as they got from commercialized apps. Spoiler alert: They absolutely do, at least in B2C. (Or in this case, H2C?)
> The issue comes when end-users expect the same level of support and continued updates from hobbyists as they got from commercialized apps.
Maybe. Doesn't change the fact that software will be more commoditized.
If software switching costs get close to 0 [because data is owned and can be opened by any other app], pricing pressure will get intense. Investors love cloud SaaS because they can rent-seek and extract margins of >80%. It's unlikely that apps that do not own and lock-in customer data can rent-seek to such a degree. If they do that, users will switch to the next best solution.
The product is not just the program. People don't just care about function, they care about how the app makes them feel, how it affects how they think others perceive them, etc. -- the companies that can afford to market and make their experiences sexy will run laps around purely functional apps that can't, no matter how well they solve the problem (unfortunately). Good marketers and designers do not have the same proclivities towards working for free as developers do.
The hope is that the markets are large enough that niche apps can carve out a healthy revenue with a more personal, "homegrown" experience. This is where my product lives, and so far it's worked well enough.
Also, switching cost is never zero or even close to it. The user still has to click a button. I know it sounds like I'm being facetious, but coming from a large-scale B2C industry, a single button click is an enormous obstacle.
For most use cases the solution should be evident further down the road. Overwhelming majority of why a server is needed is data sync between clients. Self-hosting should have it's moment where a simple user-maintainable server solution emerges. Then you could just offer a plugin to that platform - a bit like how Synology works already.
I've mostly been cloud free this way. I do send (sometimes encrypted) backups/copies elsewhere, but those are exceptions. And it works well across many client devices (and remote via DNS/forwarding).
But the reality is that there’s plenty of hobby app businesses that do the one time sale revenue model.
The internet is rife with stories of hobbyists who would love to give adobe $500 to just buy their software outright. Many Adobe competitors offer exactly this!
What exactly do you mean by “hobby apps?” I’m slightly confused because it is pretty common to describe open source projects and the like as hobbyist programming, with all the expectations of customer service (specifically, none) that that entails.
If somebody is taking money for something, it isn’t really a hobby, it is a job. It might be a poorly paid one, but they still have an ethical obligation to their customers, to meet some standards of merchantability and provide some level of customer service.
But if you mean, “apps that hobbyists use” then that makes more sense. There’s nothing wrong with producing a toolkit that a hobbyist can use to write their own apps of course. It is like producing hand tools—you have an ethical obligation to make sure the tools themselves are reasonably free of defects but of course you don’t have to provide customer support for the treehouse!
I refer to open source projects, indie hackers, and one man shows with "hobby apps."
Distribution (specifically maintenance) becoming cheaper will enable those people to compete/provide enough value to customers that larger companies face downward pricing challenges.
You're not the first person that I hear having the exact same issue, and it's a very real one.
IMHO, the problem isn't with local-first application themselves. The problem is that our economic system rewards players responsible for vendor-locking (and any sort of similar practices), while providing no support (or even livelihood) for folks focusing on delivering a great product free of artificial restrictions.
Lots of photo, art, music and other hobby software is for purchase rather than subscription.
Off the top of my head Topaz Labs is a company that offers a suite of photo tools for purchase. They are aimed at both professionals and high end hobbyists.
I bought iExplorer which lets me sanely treat my iPhone like an external disk … and I bought Mountain Duck which lets me mount remote sftp as a disk in Finder …
I once bought Paste (a clipboard manager for Mac). However, they later switched to a subscription model, and I decided not to make a new purchase. Then Raycast, which is free, came out, and I stopped using Paste altogether.
Ha. I just realized it is 10 years since me, Alexei and Oleg launched our CRDT demo on HN. Funnily enough, it featured this mouse-cursor trick as well. It was a demo of the lib. It was August 2014 if I remember correctly. The post was submitted by Dan Abramov. Nostalgie.
Did CRDTs and local-first advance much since 2014? There is a bunch of research, way more CRDT libs on GitHub, but (somewhat) successful businesses you can count on one hand.
I guess, that is the actual challenge - figure out the business model.
It seems there’s a lot more availability of collaborative text editing features in SaaS apps I think due to the availability of convergent rich text data structures. Those seem to have democratized that specific feature. But I don’t see “local-first” with user-owned data or true decentralized apps being successful as businesses yet.
That’s a cop out answer and hardly the whole truth.
Their business model was give away and capture. Give away much of the possible revenue stream in order to lock in students, learning centers, governments, offices, and hobbyists.
That method of success has been well documented and replicated world wide.
The above method is how Google’s horrible products are currently winning.
Google is a serial murderer of its own products and services yet governments, schools, and companies fall over themselves to use Google products.
> Google is a serial murderer of its own products and services yet governments, schools, and companies fall over themselves to use Google products.
I doubt Gmail is going anywhere anytime soon, even more so on the workspace plans and for our company anyway that's the biggest Google product we bought into, ignoring Adsense, which is also going nowhere anytime soon.
Google drive also seems like one of those long support products but regardless for enterprise trusting a single cloud provider to host all your data is a disaster waiting to happen and most have on prem plus two clouds
This is not part of the requirements for localfirst, it's part of the eventual goals. Here linear meet the requirements because you can continue to edit offline, and if they have a server outage then you don't lose your data because you have a local copy.
However a collaborative software is of course useless in the long term if you can't collaborate anymore.
When users subscribe they should be purchasing a license that renews periodically. Local-first apps should validate the license (based on its expiry) by connecting to the internet to ensure users are subscribed. If they're not subscribed or they don't have internet access, they cannot use pay-walled features. You should offer a free, fair, and robust export tool for those not subscribed, though unfortunately not many companies do this.
What am I missing here? The drawback is of course when customers don't have internet access but are still valid subscribers, so they lose access to pay-walled features. One option would be to only offer annual licenses (infrequent license checking), another would be to offer a complementary 7 day license extension for the short-term until the user reconnects to the internet (grace period).
Stop giving away your value proposition for free. Get paid fairly.
Part of the ethos of local-first is permanent ownership of software over subscription services. Sure, it's not technically in the name, but it's very much part of the background for TFA.
Why would one sell permanent ownership of a networked product? I've been seeing the rise of "lifetime" subscription levels (pay once) for SaaS products, but I'm curious as to what the actual long-term economics of it are.
If your cost of operations is not a one-time cost per user, I don't see how you can avoid a subscription model.
> Why would one sell permanent ownership of a networked product?
You wouldn't. Maybe TFA has an extreme interpretation of local-first, but the entire point of the article is eliminating the last vendor-controlled server from certain kinds of apps so that the user can own the software forever.
Obviously this doesn't work for all apps, and it sounds like OP may have one that needs some form of network component. In that case what you propose would work very well.
You can charge the user once upfront, possibly after a free trial. 37 signals are trying it out with once.com. As a developer, you are in control of how local-first your application should be.
The way we handle it is: subscribing = full access, non-subscribing = read-only access. Philosophically we'd probably not be viewed as "true" local-first software given this constraint, but like you said: we can't give away our value prop for free.
I build a self-hosted application (so I guess that qualifies as local-first), how I monetize it: one-time payment to get the product, then yearly (optional) paid support/updates.
I am not too worried about piracy, as that is a battle you'll never win (games have been fighting this game for a long time). Create a good product that solves a real issue, get in front of people, and provide a good service, so that they are happy to support you in the future (either for updates on this product or for building new products).
At the $800 - $2500 price range, that sounds awesome, but I'm in a market where $50 is considered outrageous. It's self-inflicted pain, I know, but we make it work.
I actually also started with a very low price ($19 on CodeCanyon 13 years ago), but slightly increased the price over time to match the benefits.
Lately, I've also switched who I target. Before I was going more for basic website owners, that maybe don't even have a business. There were many problems with this: those customers don't really need such detailed analytics, they maybe don't have the technical expertise to self-host, they don't care about privacy as much, they would rather go for free or very cheap solutions, etc. Now I'm focused more on business and web agencies, which also enables the higher price (for them this is actually cheap, as Hotjar for example has plans starting at $800/month, while this is a one-time payment).
Going for the big customers is a lot easier than B2C, unless you have good distribution or get lucky to get viral.
Also, your product seems to be a good use-case for the current AI boom. You could upsell your current users with AI-generate assets for their game (characters, maps, etc). Host your own text-to-image model, and add an UI in your app. Maybe have a tokens-based system for paying for the generations.
Certainly! It's what we do currently-- it's just not viewed as "true local-first" if you do this, as there's a server-auth-dependency by definition. Local-first has a bit of FOSS-esque philosophy mixed in. (Which I love! But... also gotta make money to keep the lights on.)
Them being not monetizable by you is exactly the reason why I should use them. You could charge me for a copy of the software, but that won't last forever like subscription cloud crapware does.
One improvement of the first "super-naive" approach is to break down the state into a whole hierarchy of files, rather than a single file. This helps reduce (but not eliminate) conflicts when multiple clients are making changes to different parts of the state.
Moving pointers mean most people (including me) will never read the actual content, so we might as well discuss why someone would choose to alienate their potential audience in this manner.
Some people also just want to have fun on the internet, remember Myspace, Tumblr etc? These sites were hardly functional, inclusive or accessible but they sure were fun.
I've been dreaming of Apple Notes and Obsidian doing what the author suggests. The approach seems similar to Delta Lake's consistency model, which is using object storage like S3, and yet allows concurrent writers and readers: https://jack-vanlightly.com/analyses/2024/4/29/understanding....
Edge compute :D Have data distributed "wherever" (client, server) to perform computations "wherever".
Using a video editor as an example: The video editor running locally means videos can be rendered for free with the user's hardware. Great for hobbyists (or a free-tier!), bad for large projects that would take too long to render. Have "edge compute" and hobbyists can use the free-tier while large projects can render on the cloud.
The new Freenet[1]. Edge compute on stereoids, fully decentralized applications and data. No distinction between server/client, everything is a network node.
All true but I would say the motivations are not same for each cycle.
> First there were mainframes with thin dumb clients. Classic client-server.
Computers were very expensive so would be too expensive to have smart clients. The driving force is cost.
> Then came thick clients, where some processing happened on the local terminal and some on the server.
Computers became cheaper and we had to deliver more things to a growing number of users. The driving force is dual combo of declining cost and increasing demand to do more.
> Technology advanced far enough to install programs locally that ran only locally. The 80's and 90's were quite the decades.
Costs kept going down, computation power kept going up and things became more decentralized so you could do much more at the client side without having to deal with a big server. The driving force was still declining cost and democratization of computers.
> Someone had a bright idea to build server-based applications that could be accessed via a dumb web browser.
That was in order to deal with the issue of managing at scale. The driving force was software management and focus on velocity of change.
> That went on for a while, and people realized that things would be better if we did some processing in JavaScript.
To provide the richness of experience they missed from the 80's/90's locally installed programs.
> Now the push continues to do more and more computation locally.
I would say that in addition to the usual drivers, now there is an aspect of graceful handling of issues introduced by network deficiency (brought due to over-reliance on server-heavy brower-light applications and the generally growing network hungriness) + increased awareness of privacy concerns.
> Can't wait for the next cycle.
Maybe server-side democratization/aggregation and continued emphasis on strengthening local experience.
Fully agree regarding the motivations. The thing many young devs don't realize that there's a reason for doing things a certain way. It's not "just because this is the best way to build everything."
The thing many young devs don't realize that there's a reason for doing things a certain way. It's not "just because this is the best way to build everything."
90% of the modern tech industry is monkey-see-monkey-do.
Plenty of devs on HN who are vocally proud that they don't think about how the things they build work, they just build.
That's not the tech industry, that's just everything.
And that's generally fine. We're good at imitation. It's not that most people can't have their own thoughts, but they save that for things that are more important than work -- or at least I hope that's the case.
I teach IT and the thing I try to drill home; the entirety of IT is NOT intelligent design, it's evolution (for BUSINESS, not for tech) -- which includes a whole lot of vestigial stupidity and awfulness.
> The driving force was software management and focus on velocity of change
That might have been the motivation for some at the beginning, but the reason cloud-only is now dominant is the SaaS + lock-in model that guarantees recurring revenue for the software company.
Specifically because investors cared more about MRR and ARR than any specific numbers - this conversion is really what turned everything into a SaaS company.
Let's not forget the hassle when you don't have one source of truth. Life before Dropbox and the like wasn't super fun.
I think this is an underestimated factor at play. It's super nice to not have deal with that issue, and be able to switch between computers seamless without worrying about whether your data is accurate/up to date.
Lock in and recurring revenue is not something new for SaaS. Most ERP systems and similar business systems was sold like this way before. But with the added hassle that you had to manage a server locally yourself.
Sometimes I think people just go straight to "corporations must be evil" because of ignorance/it feels good to blame the "Big guy" one can't relate to.
I wouldn't call it because of lock-in and more because we dropped the fiction that software is a thing that has a one-time cost and having people manage license keys is more expensive than its worth from support tickets alone. It's always been ARR it's just that the only software that was able to sell was huge amounts of units of $Software 2023/2024/2025 to smooth over the churn.
People get mad at you, the software vendor, if you don't provide indefinite support to bits-in-a-box they paid $60 for 5 years ago (or 10 years ago if it's government) or make them buy a support contract but if you just charge it as in all-in-one subscription for the same price they're suddenly happy to pay it.
As for the next cycle, the internet computer protocol is an interesting punt - a distributed network of servers, with replication and a degree of anonymity, where people host and pay for compute
It seems almost too obvious to say that the best model, if cost, size, performance, etc are no longer limiting factors, is to run code in both client and server. Advantages of server: no need to distribute code, and data naturally more consistent. Advantages of client: offline accessibility, speed of light limitation on performance. Of course, in the real world, you have additional tradeoffs, but those I described are probably timeless and universal rules.
> To provide the richness of experience they missed from the 80's/90's locally installed programs.
I agree with GP: the 80s and 90s were quite the decades. Back then it was normal to have, say, a 3D modelling / rendering software on your computer (like 3DS Max). And something to create music yourself. And a software allowing you to do DTP (with the 'D' even standing for Desktop). We already had IDEs and some of us had Emacs / vi(m).
Computers were used both for work and leisure and they were certainly used in creative ways, to produce "stuff", to experiment.
They were more than simply passive devices made to purely consume AI-generated crap.
And we already had BBSes then the Internet. We had Usenet newsgroups. By the mid to late 90s we had Nestcape and "alltheweb", then Google.
It was local first, but with access to the world's knowledge, basically.
And we had games and networked games: I was playing Warcraft II over the Internet in the mid-nineties and Counter-Strike in beta in 1999.
At that point it was kinda peak civilization, before the gamification of search engines / enshitification of everything. Lootboxes weren't a thing. Seeing ten zombies mindlessly consuming poor content at a bus stop wasn't a thing yet.
And I don't think the move to web-first / browsers-first / ultra-slow mono-threaded JavaScript first (JS was really pathetic at the beginning) empowered users: it was a step back, going years and years back in capabilities compared to what we have locally on our computers.
And, today, if you want to create something in 3D, you'll be using Blender. For music, you'll use something local too. For DTP: same thing. Heck, you'll be creating websites / webapps using a mostly local-first solution.
I do think this last quarter of a century the Web has destroyed the experience, not enriched it. It has turned users into dumb consumers of content.
Sure, I can order stuff on Amazon in two clicks (which I do) and it's more convenient than using eBay to order that video tape of "Le Mans" in the mid nineties (which I did too): but Amazon is just more consumerism.
And it's not just dumb consumerism: it's accompanied with total surveillance and insecurity.
To me in the 80s and 90s computers had, compared to their capabilities, way more richness of experience than most experience today.
What did I not have back then? Hmmm. Access to my broker in real-time: that's one I use a lot. Oh, wait, I'm using my broker's desktop app.
As a fun sidenote, HN would have worked fine on Netscape in the nineties. I could have typed this comment on a 486.
The "richness" of the enshitified Web: I just don't see it. We had the Web. And it was a better Web.
I was a kid at the time so my glasses may be quite rosy. But, it was cool how much space had no computers in it. I was a nerdy kid, and always looking forward to getting back to my computer. But, now there’s no escaping the things. Or going back to them.
Maybe I'm just getting old and it's all nostalgia but I had exactly the same experiences during the 80s and 90s. I also thought web forums where a big step backwards when compared to usenet groups.
In pre-internet times I loved reading computer magazines, sure they where full of ads and hyped some bullshit products but at least there where no clickbait titles or AI generated articles. There was some real useful content. You also kind of knew all the authors of the magazines and their style.
Software piracy also was a physical process, we shared floppy disks on the schoolyard and exchanged "arcane" knowledge of how to unpack it (arj / pkzip).
I also often wonder if as a civilization we really need this enormous speedup of everything. We humans can barely handle multitasking. We can compile huge amounts of ultra complex code insanely fast but we can't think faster to come up with the ideas and also can't handle complexity in our minds better than before. On the contrary, I often feel urged to rush software development.
Local/mainframe is a well known “cycle of reincarnation” in software. We are currently in what I call the "mainframe 2.0" era, or maybe even "mainframe 3.0" depending on how far back you go. (The cloud is just the mainframe.)
And as a network admin I am pushing to have all of our office computers replaced with thin clients, and centralizing all of our compute resources on a single machine that is probably running Windows Server 2022. The current year is 2024. This architecture was cutting edge in the 1990s. I'm over 30 years behind the curve on this.
Can one apply a conflict resolving replication over the network using a zip archive? Genuinely asking; having a master-less distributed “database” that can be … distributed like a file sounds like it would solve a lot of portability problems.
if conflict resolution has to happen in the network layer -> tbd. it seems like apps that have built-in conflict resolution can resolve conflicts.
zip archives will play a role. i am pushing for "zipped repositories" internally, precisely for portability. but also because it makes the UX of using apps with conflict resolution like any other file-based software: simple.
btw my rfc led to another one https://github.com/orgs/opral/discussions/2975. if we agree on the proposal, i will follow up soon with a "okay, we have repos now. let's zip them for portability"
> But file syncing is a “dumb” protocol. You can’t “hook” into sync events, or update notifications, or conflict resolution. There isn’t much API; you just save files and they get synced. In case of conflict, best case, you get two files. Worst — you get only one :)
Sync services haven't evolved much. I guess, a service that would provide lower APIs and different data structures (CRDTs, etc.) would be a hacker's dream. Also, E2EE would be nice.
And if they closed the shop, I would have all the files on my devices.
305 comments
[ 3.2 ms ] story [ 269 ms ] threadAt least for myself, I barely use any local first software. The software that I do use that is local in any important sense of the word is basically local-only software. I realize this every time I lose connection on my phone. It becomes pretty much a pretty bad camera compared to my Sony.
I live in a country were I have good 3G speed pretty much everywhere so internet connectivity is never an issue, not even on moving things like trains or boats. The very few times I have been flying or whatever I simply don't do any work because it's usually uncomfortable anyway.
This is the main reason I don't really care about local first and have been diving into Phoenix Liveview the last couple of weeks. The productivity boost I get and cool realtime apps it empowers me to build is more important to me than the dream of making local first web apps. A realtime demo of things updating with multiplayer functionality is a far easier sell than "look, the app works even when I turn on flight mode". And honestly, in like 99% of the time, it is also more useful.
I have done local first web apps before and it is always such a pain because syncing is a near impossible problem to solve. What happens if you and someone else have done changes to the same things like 2 hours or more ago? Who even remembers which value is correct? How do you display the diffs?
No matter what you do, you probably need to implement some kind of diffing functionality, you need to implement revisions because the other guy will complain that the changes were overwritten and so on. There is just so many issues that is very hard to solve and require so much work to be done that it isn't worth it unless you are a large team with a lot of resources. You end up with a complicated mess of code that is like git but worse in every way.
It's easier to simply say the app doesn't work offline because we rarely are offline and no one will pay for the effort required. Unfortunately.
I'm old school and local first. I don't own a smart phone and I host my own music, video and I read real books and ebooks I download and read from an off line eReader.
Then I compare with the modern man who streams his music, video, buys audio books as a service, uses only web browser applications, and then bitterly complains when the internet goes down, or when the prices of his apps go up, or when his favourite music or movie disappears from the service provider and so on and so on.
So not only a complete loss of control and computing autonomy, but also a financial drain as well when counting the cost of all the apps and services.
Mean while, I'll happily chug along, local first, and if the internet doesn't work, at most my web browsing and email suffers, but since I do have my reference libraries, documentation and interpreters available locally, I can still get work done until the internet comes back up.
I would love to make all my work local first but when the users are requesting other things I have to oblige. The feature list is long and the time is short. I simply can't spend a lot of time on making a sucky git alternative for when conflicts happen. When doing work on my spare time projects I want to make as much as possible in the little time that I do have, so local first is pretty much on the bottom of the list. Personally, I tried to build a music library but it's very hard today since you can't get music legally in a good cheap way. Illegally by torrenting is also hard because no one torrents music anymore.
I do keep a library of movies but I rarely visit it and stream new movies with torrent software. Basically everything else, like work, is mostly online based today so there is not really much to do locally anymore except photo editing and watching movies for me. Of course, I do still develop on my machine but as soon as I get stuck on something I need the internet to look up some reference or whatever and if I don't have the internet I can't get emails or chat messages from colleagues or push my code anyway so then I can only work for a short while.
I completely hate most cloud software and prefer local first but my issue is that no one except nerds on hackernews really cares about it and it is too much work for little gain. I actually are in a process to rewrite a side project that I hope to one day be a business from a local-first react project to a phoenix liveview. Why? Because I think the realtime aspects of the project will bring in more customers and it's far easier to maintain the state. So again, less work and more features I will actually get paid for.
If I ever make it to a stable business, I will probably make a small portion of the app work offline because I know some customers will like it when they use it under ground.
Some people like me cares too much about too much and thinks a lot about stuff like this. I wish more people would care about more things but it just ain't so.
You can implement local-first with the merging strategy of last-write-wins, which is equivalent as any cloud app where the server is the source of truth. But now you automatically get all the other benefits of local-first:
- you can use it offline and expect changes to merge when coming back online. With the caveat that changes may be lost, but it's at least possible to have pending changes, you don't even have that option on cloud apps
- easier to develop, no more developing custom API backends
- multi-player
I've seen this before on an article that hit the HN front page; was it this same blog?
And more importantly, why would anyone in their right mind think this "feature" is a good idea?
Ostensibly, the goal of writing a blog post is for others to read it.
Don’t use Chrome then.
But you can easily remove the dom element that displays the cursors if the content is interesting to you and the cursors are the only thing preventing you from reading it..
Use reader mode in your browser.
This is just not true, but in any case, don't get your point. The author has all the right to add anything to his blog, it's just that a lot of people will find it annoying and will stop reading, like some people mentioned here.
If the author thinks the cursors are worth the people not reading the actual content, then good for him.
Which part? The second sentence is just my opinion, and you're free to disagree. :)
My point is that somebody will always find reasons for not wanting to read an article. Whether that's because they don't like the color scheme, font, or any other style choice. You can't please everyone with design. I think we can agree that that statement is objectively true.
So given that, a personal blog is the right place to do whatever pleases the author the most, instead of optimizing for metrics that impact engagement, or whatever nonsense KPIs developers are asked to optimize for in their day job. People interested in the content can always choose to consume it however they prefer instead (thankfully, the web is still open in this sense). In this case you can disable JavaScript, use reader mode, a custom stylesheet, or any other barebones browser instead. Considering this article is directed at a technical audience, any of these should work for you.
Edit: and yes, I could've used Reader Mode of course, but I didn't think of it at the time.
People lost their bearing about if and when stupid visuals ruin or not their message, derail attention. And they stopped caring as well. They just want to make something funny looking, this is a primary motivation, coming up with stupid ideas and pushing it anywhere and everywhere. I belive this is a problematic attitude in the age of pretension. Which made me to loose my faith in humanity.
Might make me a killjoy but there's a time and place for everything.
If you lose faith in humanity because of this, you should look into it.
The feature is really fun and fitting on dimden's page; it's really distracting on this blog
document.querySelector('.pointers').remove();
Yeah, at the time I thought "who the hell thought this would be a good idea?"
Unless you’ve selectively disabled features, then everything you do and every metric your browser captures.
Did you make the window full screen? Tattled.
Did you change default font or size? Tattled.
Did you visit any site with tracking beacons? Tattled.
Do you use a laptop or phone? Then sensor data and eye tracking are on the table for tattling.
Does your machine have WiFi on? Did you expressly turn off device discovery for connected networks? No? Tattled.
The only way to remain private is not to have family, friends, coworkers, or neighbors.
The weakest security links are those not under your control.
https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...
Obsidian's model seems nice: base app is free, and then payment for the networked portions like sync+publish. However, there's little data available on how well this works and how big of a TAM you need to make it sustainable. Or if it's even possible without an enterprise revenue channel.
For those interested in building robust local-first + collaborative apps, I've been using Yjs for a few years now and have overall really enjoyed it. Multi-master collaboration also poses some stimulating technical and design challenges if you're looking for new frontiers beyond the traditional client-server model.
I would like to make open core software for a living but local first would take away the last reasonable venue for monetisation in those cases.
It worked all the way through the 80s, 90s, and most of the 00s. It brought Adobe, Ableton and many others to their dominant market positions, despite rampant piracy. It works for a lot of games, still.
What’s changed?
There's a large spectrum of extreme profits before every getting to that point.
In any case, folks are free to try local apps for their business and post results.
Revenue maximization given mission constraints is usually the goal. SaaS is simpler, more economic and generally aligns incentives between parties better.
There are many things where a one time cost makes sense, though.
To clarify the conversation, "local-first" vs "cloud-based" is inadvertently getting muddied up with revenue models such as single-payment vs ongoing subscriptions. Those are 2 separate concepts.
Adobe/Ableton/Quicken desktop software still run locally on the users computer. Adobe Photoshop can save ".psd" files locally on the computer. But they have ongoing subscription fees and if users don't keep up the payments, they lose functionality or stop working.
Instead, what people often mean by local-first is "local _data_ stored on my computer as a 1st-class concept". The Single-Source-Of-Truth of data is preferably on my home computer and the cloud is just a convenient replica for backup or sharing. Ideally, the local-first data is also a an open format instead of a proprietary opaque blob. Examples would be local-first Obsidian (markdown files stored locally on computer) -- vs -- Notion (notes stored in the cloud). Or local-first NextCloud instead of cloud-based DropBox.
As your examples showed, local-first software can be monetized via subscriptions.
1. Users expect apps to keep working in the face of platform regressions and policy changes, for "free" (no unexpected extra charges). In the 90s Microsoft went through heroics to make buggy apps work on Windows 95 because if someone bought Windows 95 and an app broke, the user returned Windows to the store and got a refund. In 2024 if Microsoft or Apple ship a buggy OS update and it breaks your app (which they do), the user returns your app to the store and gets a refund. They don't see the platforms changing around them, they just know that your thing worked yesterday, today it doesn't, it's your fault, fix it.
This lack of 100% solid backwards compatibility means it's not feasible to sell a program once and let users keep it forever. They won't keep up their end of the bargain and, by the way, governments will always take their side and not yours so don't think you can just wash your hands of such problems via a EULA. Open source apps can get away with this because there was no purchase to begin with, commercial apps cannot.
2. App Stores happened. That means users can leave reviews and star ratings. In the 90s if you sold an app that happened to crash regularly if you pressed a certain combination of buttons, well, maybe three months later a magazine reviewer would notice or maybe they wouldn't. At any rate it hardly mattered unless you had some kind of unusually high level of bugginess and that fact spread through word of mouth.
In 2024 if you ship a version with even very obscure bugs users affected by it will immediately start leaving negative reviews. You have to fix this or else your app will become unpopular and you'll lose money, but again, this means a continuous stream of updates which everyone gets, which requires ongoing revenue to pay for it.
3. Collaboration happened. In the 90s networks were weak and most computer users worked alone. If Fred bought Office 2000 and you were still using Word 95, then it was expected that Fred would just know this somehow and also know how to use the "Save as" dialog box to save in Word 95 format. It was also expected that Fred's employer would provide a synchronous LAN fileshare using SMB where Fred could store a file. This was OK because remote work wasn't really a thing, and people tended to work in the same physical building. Because apps did releases so rarely and file writes were all synchronous/SMB supported file locks, this complexity was just about tractable albeit only as long as users had a high tolerance for computer nonsense. In the modern era collaboration is expected to Just Work without users having to phone up their mates to find out what app version they're using. That means everyone has to be on the same version, which means everyone has to get all the updates all the time, which means they all benefit from ongoing work by the company, which means a subscription. Plus we expect to be able to work from anywhere in the world, and from devices that don't support synchronous networked filesystems like iPads which means a custom per-app server farm. Those costs also matter here, see my other comment for why the Dropbox trick doesn't really work that well.
You ask why games don't seem to be affected by this. They are affected by this and they adopt a few strategies:
• Primarily target games consoles. Way more stable platforms with way fewer regressions.
• Adopt subscription payments too. See: MMORPGs.
• Keep costs low and hope they can cover them from the sales revenue as the player base expands.
• Just don't support games for more than a few months after they launch. That works because games are short-lived things usually. If the game is broken a year after release a few hard-core fans will care but most people have completed the...
For consumers projects - especially desktop - it's more difficult. Many would rather pirate software than pay a few hundred dollars a year for a licence. However, the advent of highly controlled app stores has mitigated this somewhat.
Users will refrain from paying a subscription if their app version works and they don't need updates. The good old buy-a-license with 1 year of updates will likely make a big comeback. Local-first software, at least in lix universe [0], does not have fixed recurring maintenance costs like running servers. The elimination of fixed recurring maintenance costs will lead to a proliferation of "hobby apps" that are undercut by price/make it free altogether.
[0] https://github.com/opral/monorepo/blob/main/lix/README.md
Maybe. Doesn't change the fact that software will be more commoditized.
If software switching costs get close to 0 [because data is owned and can be opened by any other app], pricing pressure will get intense. Investors love cloud SaaS because they can rent-seek and extract margins of >80%. It's unlikely that apps that do not own and lock-in customer data can rent-seek to such a degree. If they do that, users will switch to the next best solution.
The hope is that the markets are large enough that niche apps can carve out a healthy revenue with a more personal, "homegrown" experience. This is where my product lives, and so far it's worked well enough.
Also, switching cost is never zero or even close to it. The user still has to click a button. I know it sounds like I'm being facetious, but coming from a large-scale B2C industry, a single button click is an enormous obstacle.
The internet is rife with stories of hobbyists who would love to give adobe $500 to just buy their software outright. Many Adobe competitors offer exactly this!
It's not like many professional services manage the long-lived part, either, is it?
I have much more confidence in my WebDAV server still being around in a decade than pretty much any cloud-based service.
If somebody is taking money for something, it isn’t really a hobby, it is a job. It might be a poorly paid one, but they still have an ethical obligation to their customers, to meet some standards of merchantability and provide some level of customer service.
But if you mean, “apps that hobbyists use” then that makes more sense. There’s nothing wrong with producing a toolkit that a hobbyist can use to write their own apps of course. It is like producing hand tools—you have an ethical obligation to make sure the tools themselves are reasonably free of defects but of course you don’t have to provide customer support for the treehouse!
Distribution (specifically maintenance) becoming cheaper will enable those people to compete/provide enough value to customers that larger companies face downward pricing challenges.
IMHO, the problem isn't with local-first application themselves. The problem is that our economic system rewards players responsible for vendor-locking (and any sort of similar practices), while providing no support (or even livelihood) for folks focusing on delivering a great product free of artificial restrictions.
Is any company making money in software without an enterprise revenue channel, aside from games? Do regular people “buy software” anymore?
Off the top of my head Topaz Labs is a company that offers a suite of photo tools for purchase. They are aimed at both professionals and high end hobbyists.
Edit: I also recently bought Sublime text, several Jetbrains products and some other utilities.
I bought iExplorer which lets me sanely treat my iPhone like an external disk … and I bought Mountain Duck which lets me mount remote sftp as a disk in Finder …
… and some other things…
That repo is long abandoned https://github.com/gritzko/swarm
Did CRDTs and local-first advance much since 2014? There is a bunch of research, way more CRDT libs on GitHub, but (somewhat) successful businesses you can count on one hand.
I guess, that is the actual challenge - figure out the business model.
Their business model was give away and capture. Give away much of the possible revenue stream in order to lock in students, learning centers, governments, offices, and hobbyists.
That method of success has been well documented and replicated world wide.
The above method is how Google’s horrible products are currently winning.
Google is a serial murderer of its own products and services yet governments, schools, and companies fall over themselves to use Google products.
Capture is a valid, and proven, revenue strategy.
I doubt Gmail is going anywhere anytime soon, even more so on the workspace plans and for our company anyway that's the biggest Google product we bought into, ignoring Adsense, which is also going nowhere anytime soon.
Google drive also seems like one of those long support products but regardless for enterprise trusting a single cloud provider to host all your data is a disaster waiting to happen and most have on prem plus two clouds
https://news.ycombinator.com/item?id=37491239
It's easier to build a cloud based subscription business.
However a collaborative software is of course useless in the long term if you can't collaborate anymore.
When users subscribe they should be purchasing a license that renews periodically. Local-first apps should validate the license (based on its expiry) by connecting to the internet to ensure users are subscribed. If they're not subscribed or they don't have internet access, they cannot use pay-walled features. You should offer a free, fair, and robust export tool for those not subscribed, though unfortunately not many companies do this.
What am I missing here? The drawback is of course when customers don't have internet access but are still valid subscribers, so they lose access to pay-walled features. One option would be to only offer annual licenses (infrequent license checking), another would be to offer a complementary 7 day license extension for the short-term until the user reconnects to the internet (grace period).
Stop giving away your value proposition for free. Get paid fairly.
Why would one sell permanent ownership of a networked product? I've been seeing the rise of "lifetime" subscription levels (pay once) for SaaS products, but I'm curious as to what the actual long-term economics of it are.
If your cost of operations is not a one-time cost per user, I don't see how you can avoid a subscription model.
You wouldn't. Maybe TFA has an extreme interpretation of local-first, but the entire point of the article is eliminating the last vendor-controlled server from certain kinds of apps so that the user can own the software forever.
Obviously this doesn't work for all apps, and it sounds like OP may have one that needs some form of network component. In that case what you propose would work very well.
I am not too worried about piracy, as that is a battle you'll never win (games have been fighting this game for a long time). Create a good product that solves a real issue, get in front of people, and provide a good service, so that they are happy to support you in the future (either for updates on this product or for building new products).
Lately, I've also switched who I target. Before I was going more for basic website owners, that maybe don't even have a business. There were many problems with this: those customers don't really need such detailed analytics, they maybe don't have the technical expertise to self-host, they don't care about privacy as much, they would rather go for free or very cheap solutions, etc. Now I'm focused more on business and web agencies, which also enables the higher price (for them this is actually cheap, as Hotjar for example has plans starting at $800/month, while this is a one-time payment).
Going for the big customers is a lot easier than B2C, unless you have good distribution or get lucky to get viral.
- He writes about UX but there's no dark mode!
- The cursors are really distracting!
- The yellow background color makes it unreadable!
- Some comment about the actual content of the post
Check the today's twin post on the same subject: https://news.ycombinator.com/item?id=40772955
Comments are 100% on the point, both bland and boring.
Then came thick clients, where some processing happened on the local terminal and some on the server.
Technology advanced far enough to install programs locally and they ran only locally. The 80's and 90's were quite the decades.
Someone had a bright idea to build server-based applications that could be accessed via a dumb web browser.
That went on for a while, and people realized that things would be better if we did some processing in JavaScript.
Now the push continues to do more and more computation locally.
Can't wait for the next cycle.
Edge compute :D Have data distributed "wherever" (client, server) to perform computations "wherever".
Using a video editor as an example: The video editor running locally means videos can be rendered for free with the user's hardware. Great for hobbyists (or a free-tier!), bad for large projects that would take too long to render. Have "edge compute" and hobbyists can use the free-tier while large projects can render on the cloud.
https://freenet.org/
> First there were mainframes with thin dumb clients. Classic client-server.
Computers were very expensive so would be too expensive to have smart clients. The driving force is cost.
> Then came thick clients, where some processing happened on the local terminal and some on the server.
Computers became cheaper and we had to deliver more things to a growing number of users. The driving force is dual combo of declining cost and increasing demand to do more.
> Technology advanced far enough to install programs locally that ran only locally. The 80's and 90's were quite the decades.
Costs kept going down, computation power kept going up and things became more decentralized so you could do much more at the client side without having to deal with a big server. The driving force was still declining cost and democratization of computers.
> Someone had a bright idea to build server-based applications that could be accessed via a dumb web browser.
That was in order to deal with the issue of managing at scale. The driving force was software management and focus on velocity of change.
> That went on for a while, and people realized that things would be better if we did some processing in JavaScript.
To provide the richness of experience they missed from the 80's/90's locally installed programs.
> Now the push continues to do more and more computation locally.
I would say that in addition to the usual drivers, now there is an aspect of graceful handling of issues introduced by network deficiency (brought due to over-reliance on server-heavy brower-light applications and the generally growing network hungriness) + increased awareness of privacy concerns.
> Can't wait for the next cycle.
Maybe server-side democratization/aggregation and continued emphasis on strengthening local experience.
90% of the modern tech industry is monkey-see-monkey-do.
Plenty of devs on HN who are vocally proud that they don't think about how the things they build work, they just build.
And that's generally fine. We're good at imitation. It's not that most people can't have their own thoughts, but they save that for things that are more important than work -- or at least I hope that's the case.
We need regulation or liability, yesterday.
That might have been the motivation for some at the beginning, but the reason cloud-only is now dominant is the SaaS + lock-in model that guarantees recurring revenue for the software company.
to Snowflake - https://archive.ph/WLmYA
I think this is an underestimated factor at play. It's super nice to not have deal with that issue, and be able to switch between computers seamless without worrying about whether your data is accurate/up to date.
Lock in and recurring revenue is not something new for SaaS. Most ERP systems and similar business systems was sold like this way before. But with the added hassle that you had to manage a server locally yourself.
Sometimes I think people just go straight to "corporations must be evil" because of ignorance/it feels good to blame the "Big guy" one can't relate to.
People get mad at you, the software vendor, if you don't provide indefinite support to bits-in-a-box they paid $60 for 5 years ago (or 10 years ago if it's government) or make them buy a support contract but if you just charge it as in all-in-one subscription for the same price they're suddenly happy to pay it.
Sounds a bit like Bill Gates' vision from the 90's of people subscribing to Windows, and paying a bit each time they turn the computer on.
I agree with GP: the 80s and 90s were quite the decades. Back then it was normal to have, say, a 3D modelling / rendering software on your computer (like 3DS Max). And something to create music yourself. And a software allowing you to do DTP (with the 'D' even standing for Desktop). We already had IDEs and some of us had Emacs / vi(m).
Computers were used both for work and leisure and they were certainly used in creative ways, to produce "stuff", to experiment.
They were more than simply passive devices made to purely consume AI-generated crap.
And we already had BBSes then the Internet. We had Usenet newsgroups. By the mid to late 90s we had Nestcape and "alltheweb", then Google.
It was local first, but with access to the world's knowledge, basically.
And we had games and networked games: I was playing Warcraft II over the Internet in the mid-nineties and Counter-Strike in beta in 1999.
At that point it was kinda peak civilization, before the gamification of search engines / enshitification of everything. Lootboxes weren't a thing. Seeing ten zombies mindlessly consuming poor content at a bus stop wasn't a thing yet.
And I don't think the move to web-first / browsers-first / ultra-slow mono-threaded JavaScript first (JS was really pathetic at the beginning) empowered users: it was a step back, going years and years back in capabilities compared to what we have locally on our computers.
And, today, if you want to create something in 3D, you'll be using Blender. For music, you'll use something local too. For DTP: same thing. Heck, you'll be creating websites / webapps using a mostly local-first solution.
I do think this last quarter of a century the Web has destroyed the experience, not enriched it. It has turned users into dumb consumers of content.
Sure, I can order stuff on Amazon in two clicks (which I do) and it's more convenient than using eBay to order that video tape of "Le Mans" in the mid nineties (which I did too): but Amazon is just more consumerism.
And it's not just dumb consumerism: it's accompanied with total surveillance and insecurity.
To me in the 80s and 90s computers had, compared to their capabilities, way more richness of experience than most experience today.
What did I not have back then? Hmmm. Access to my broker in real-time: that's one I use a lot. Oh, wait, I'm using my broker's desktop app.
As a fun sidenote, HN would have worked fine on Netscape in the nineties. I could have typed this comment on a 486.
The "richness" of the enshitified Web: I just don't see it. We had the Web. And it was a better Web.
I also often wonder if as a civilization we really need this enormous speedup of everything. We humans can barely handle multitasking. We can compile huge amounts of ultra complex code insanely fast but we can't think faster to come up with the ideas and also can't handle complexity in our minds better than before. On the contrary, I often feel urged to rush software development.
That was an elitist Web. That's not a better Web.
Remember flash? It was just too power hungry to run on phones.
Today's phones are stronger than yesterday's computers.
It's only a problem when a company jumps on fad and uses technology in a way that is trendy, without understanding the why behind it.
Commonized PCs are a wonderful thing
A repository as a file is self-contained, tracks changes by itself, and is, therefore, free from vendor lock-in. Here is my draft RFC https://docs.google.com/document/d/1sma0kYRlmr4TavZGa4EFiNZA...
zip archives will play a role. i am pushing for "zipped repositories" internally, precisely for portability. but also because it makes the UX of using apps with conflict resolution like any other file-based software: simple.
btw my rfc led to another one https://github.com/orgs/opral/discussions/2975. if we agree on the proposal, i will follow up soon with a "okay, we have repos now. let's zip them for portability"
Sync services haven't evolved much. I guess, a service that would provide lower APIs and different data structures (CRDTs, etc.) would be a hacker's dream. Also, E2EE would be nice.
And if they closed the shop, I would have all the files on my devices.