101–110 of 494 posts
1. People don't work alone and need to collaborate 2. People value convenience over privacy and security 3. Cloud is easy.
I can't believe so many replies are struggling with the easy answer: privacy, security, "local first", "open source", "distributed", "open format" etc etc etc are developer goals projected onto a majority cohort of people who have never, and will never, care and yet hold all the potential revenue you need.
Earlier quoted context omitted.
> There's no easy way to keep sync, either. Look at CAP theorem. You can decide which leg you can do without, but you can't solve the distributed computing "problem". Best is just be aware of what tradeoff you're making. Git has largely solved asynchronous decentralized collaboration, but it requires file formats that are ideally as human understandable as machine-readable, or at least diffable/mergable in a way wher…
Git works, but it leaves conflict resolution up to the user. It's good for a tool for professional users, but I don't see it being adopted for mainstream use.
People say git is too "complex" or "complicated" but I never saw end users succeeding with CVS or Mercurial or SVN or Visual Sourcesafe the way they do with Git.
"Enterprise" tools (such as business rules engines) frequently prove themselves "not ready for the enterprise" because they don't have proper answers to version control, something essential when you have more than one person working on something. People say "do you really need (the index)" or other things git has but git seemed to get over the Ashby's law threshold and have enough internal complexity to confront the essential complexity of enterprise version control.
I don't understand why we have servers in the first place for any kind of local appliance, they ARE a server already, 256mb of flash costs pennies for storing hundreds of thousands of metrics - almost enough for a year!
Local-first was the first kind of app. Way up into the 2000s, you'd use your local excel/word/etc, and the sync mechanism was calling your file annual_accounts_final_v3_amend_v5_final(3).xls But also nowadays you want to have information from other computers. Everything from shared calendars to the weather, or a social media entry. There's so much more you can do with internet access, you need to be able to access re…
There's no easy way to merge changes, but if you design around merging, then syncing becomes much less difficult to solve.
Local-first was the first kind of app. Way up into the 2000s, you'd use your local excel/word/etc, and the sync mechanism was calling your file annual_accounts_final_v3_amend_v5_final(3).xls But also nowadays you want to have information from other computers. Everything from shared calendars to the weather, or a social media entry. There's so much more you can do with internet access, you need to be able to access re…
I wouldn't call local Excel/Word/etc "local-first". The "-first" part implies that the network is used for secondary functionality, but the apps you're talking about are fully offline. IMO local-first definitionally requires some form of networked multi-device collaboration or sync.
I’ve been working on https://with.audio which is a local app. I think there should be way more local apps with sync capabilities. I haven’t finished the sync feature in WithAudio and you have very nice ideas there. Specially the eventual consistency. That’s what will work. But I must say for sure the most difficult part of local apps is debugging customer issues. For someone who is used to logs and traces and metrics…
if i develop it as a webapplication, then i can do all the work on my computer, test with various browsers and deliver a working result. if the customer has issues, i can likely reproduce them on my machine.
but if it was a desktop application, my feeling was that testing would be a nightmare. i would have to set up a machine like my client, or worse visit the client and work with them directly, because my own machine is just to different from what the client uses. also not to forget distribution and updates
in short: web -> easy. desktop -> difficult.
The author’s journey is probably just starting. I had this exact mindset about 10 years ago. Long story short: distributed systems are hard. A linear log of changes is an absolute lie, but it is a lie easy to believe in.
Compared to what?
Personally I think PWAs are a bit confusing for consumers as they think "It's a website, i won't be able to use it offline." and if they get reminded that they can use it offline they usually forget.
Why would they think "its a web-site"? PWAs just look like normal phone apps. In fact, many "normal" phone apps are basically just a web-site inside a thin wrapper. So the difference is largely academic in many cases.
It's not giving a "I'm installing an application" vibe, it is giving "I am creating a shortcut to a website" vibes. Apps are installed via the app store, not as weird quasi-bookmarks in your browser.
As a user the simple answer is that I'll always use a regular application instead of a "local-first" web app when I have the ability. "Local-first apps" are the worst of everything - crappy, dumbed down web UI; phoning home, telemetry, and other privacy violations; forced upgrades; closed source, etc. At work, I don't have a choice, so it's Google Docs or Office 365 or whatever. And in that context it actually makes…
"Local-first apps" are the worst of everything - crappy, dumbed down web UI along with no privacy. which apps are you talking about here? that description doesn't make any sense to me.
Earlier quoted context omitted.
> There's no easy way to keep sync, either. Look at CAP theorem. You can decide which leg you can do without, but you can't solve the distributed computing "problem". Best is just be aware of what tradeoff you're making. Git has largely solved asynchronous decentralized collaboration, but it requires file formats that are ideally as human understandable as machine-readable, or at least diffable/mergable in a way wher…
I feel like git set back mainstream acceptance of copy-and-merge workflows possibly forever. The merge workflow is not inherently complicated or convoluted. It's just that git is. When dvcses came out there were three contendors: darcs, mercurial and git. I evaluated all three and found darcs was the most intuitive but it was very slow. Git was a confused mess, and hg was a great compromise between fast and having a…