[HN Gopher] Local-First Web Development
___________________________________________________________________
Local-First Web Development
Author : bubblehack3r
Score : 237 points
Date : 2023-02-19 13:35 UTC (9 hours ago)
(HTM) web link (localfirstweb.dev)
(TXT) w3m dump (localfirstweb.dev)
| yonz wrote:
| Yonz here, one of the people helping connect local-first builders
| on https://lfw.dev/
|
| Lots of comments here, and r/programming are missing the point of
| local-first. Without local-first, there is no reasonable way to
| fix the fragmented and siloed nature of data in today's products.
| Local-first systems rely on data living in user space (vs.
| product silo), creating an avenue for reusable, portable, and
| composable data.
|
| Let's take movie streaming to break this down.
|
| 1. Composability: Our viewing history is siloed in Netflix,
| Disney, Apple TV, and Prime Video. You could access better
| recommendations if these platforms merged your viewing history.
|
| 2. Re-usability: Say you signup for Hulu. Since the collaborative
| filtering model doesn't have any information on you, it takes a
| while for you to get good recommendations. Even worse still, this
| prevents new startups from being able to compete.
|
| 3. Portability: Web2 companies have almost perfected lock-in
| models, and this is primarily because you can't move your data.
| Most people learned the hard way trying to mastodon.
|
| /> Local-first at a high level tackles these by moving data
| storage to user space (not offline but local-first). Yielding
| newfound capabilities for:
|
| - ML trained on all your movie-watching history
|
| - Single source of truth for your relationships as opposed to
| your connections on Twitter, LinkedIn, Instagram, etc., and their
| specific handles. If you want to partition by platform, you can
| still do it.
|
| - User-owned private keys and historical data create exciting
| opportunities to skip signups and re-use historical data with new
| applications.
|
| - Death to spinners!
|
| Quick responses to some of the common themes,
|
| - Conflict-free sync is hard, but it is not complexity for the
| sake of complexity; with in-device/p2p conflict resolution, you
| can finally have a world free of spinners.
|
| - This is not native app development where your app state is a
| warm cache for BE source of truth.
|
| - Yes, it creates a world where you can use apps offline, which
| is always a good thing.
|
| - No, its not a service or a stack. It is more of an ideology and
| can't guarantee people won't abuse it.
| vouwfietsman wrote:
| Isn't the direction we're taking with networking and connectivity
| kind of making this irrelevant? I always feel like local-first is
| a good idea but I am actually never without internet connection,
| and building a truly local-first anything is significantly more
| complicated than the alternative of "always online" for most
| domains, even if you use various helper libs. A lot of the pages
| talk about privacy reasons as well, but I don't get that either,
| if you want privacy then you want encryption, not local-first
| development.
|
| Finally, in the end what you want to do with your work is to
| share it, meaning that "doing" your work is for a large part
| "sharing" your work, which is fundamentally not local-first.
|
| Maybe I am the odd one out here.
| LAC-Tech wrote:
| Been involved in projects like software adoption in remote aid
| posts in Papua New Guinea that don't even have roads, and
| Agtech apps in deep rural Australia.
|
| Even with Starlink there will still be places that stuff needs
| to work offline.
| realPubkey wrote:
| It is not about being offline. It is more about running queries
| locally which makes them fast enough that you do not even need
| a loading spinner [1]. Imagine your whatsapp client would have
| to do a http request on each UI interaction.
|
| [1] https://rxdb.info/offline-first.html
| dmak wrote:
| That sounds exactly like offline capabilities?
| mkraft wrote:
| It's not only about being able to operate disconnected for long
| periods it's also about handling network partitions and being
| able to achieve consensus without a single source node.
| franky47 wrote:
| Saying that offline, local-first apps aren't relevant because
| "almost everyone is always online" rings similar to saying
| accessibility isn't relevant because almost everyone can use
| their eyes.
|
| As for sharing, that's very much application dependent:
| personal data could benefit from being shared across a user's
| device, but not with third parties.
| jakelazaroff wrote:
| _> Saying that offline, local-first apps aren 't relevant
| because "almost everyone is always online" rings similar to
| saying accessibility isn't relevant because almost everyone
| can use their eyes._
|
| It's true, and that "almost" is smaller than you think!
| There's a concept called temporary disability which shifts
| the meaning of "disability" from "some permanent crippling
| condition" to "unable to do X thing in a given moment".[1]
|
| For example, one place I regularly go without reliable
| Internet is... the subway! There's no signal between
| stations, so if I need access to something I have to make
| sure it's downloaded first.
|
| My grocery store also has a basement with no cell reception.
| Imagine if the notes app with my grocery list required an
| Internet connection!
|
| [1] https://mas.to/@carnage4life/109840772570956275
| locustous wrote:
| > building a truly local-first anything is significantly more
| complicated than the alternative of "always online" for most
| domains
|
| It is more complicated. It works best when the user has a
| distinct data bucket that is exclusively theirs. A note taking
| app. Personal finance. But they may have multiple devices so
| syncing is desirable.
|
| This use case is reasonably common and turns out to be
| relatively simple to do.
|
| If you have shared data between users. If you have a
| significant amount of data that just requires being online to
| interact with the system. Then it has pretty minimal benefits
| over just centralizing the data and it should be avoided to
| minimize complexity.
| darau1 wrote:
| > I am actually never without internet connection
|
| You are part of a very small minority. The fact is, the
| majority of the world can't always be online, and so can't be
| properly served by always-online applications.
| wellpast wrote:
| Local-first goes beyond privacy and offline, but nevertheless I
| think it serves those goals better in fairly obvious ways.
|
| I'm a programmer and artist that works with various non local-
| first tools (ranging from project management/task
| collaboration, diagramming, programming--iterating and
| generating code, etc) and the thing I want more than anything
| is the fast, tightly integrated experience you get from desktop
| apps. (The web tech stack is all oriented around consumer-first
| and not producer-first.)
|
| We need a streamlined tech stack for desktop-first
| applications. Which probably involves a p2p (*ish) connection
| and sharing mechanism (nostr looks interesting for this), CRDTs
| or other patterns, and -- why is this so friggin hard -- tools,
| frameworks and libraries for cross-platform _desktop_ apps (and
| don 't say you can't retain OS-specific touchpoints when doing
| this).
| iamwil wrote:
| What kind of tight integrated experience are you imagining?
| Is it integration with 3rd party API services? Or with other
| desktop apps on the same local computer? Or something else?
| KrugerDunnings wrote:
| Why would you need CRDT for this traditional OT, this always
| turns into some weird political debate about
| decentralisations.
|
| The complexity has not necessarily something to do with
| consensus algo, where CRDT are not best in class, but what if
| your creative app is using some compute shader for some
| visual effect? This is not possible without WebGPU, and then
| still someone has to do the work of porting all of this.
| worksonmine wrote:
| Why is not wanting every action one takes on the web
| getting collected, analyzed and sold considered a "weird
| political debate"?
| ianopolous wrote:
| 100% agree. I want a web where using web apps is private
| by default. Been working on an attempt to move towards
| this: https://peergos.org/posts/a-better-web
| bob1029 wrote:
| I agree with this sentiment. Our networks are only getting
| faster.
|
| Keeping 100% of the application state in _exactly one_ place
| can eliminate entire universes of problems.
|
| If you are building an app that doesn't actually need to talk
| to outside things, then sure. Go 100% client-side.
|
| The dragon is having 1 foot in each swimming pool. 50/50 state
| spread evenly across client & server.
| iamwil wrote:
| It does, but I think we no longer live in that kind of
| environment. Distributed is the norm, and trying to shoehorn
| it into a mental model where everything is all in the same
| place adds a kind of accidental complexity to our underlying
| stack for simplicity at the very top.
|
| As an aside, with the future as a (potential) interplanetary
| species, networks can't beat the speed of light, so we'll
| have to figure this out then!
| hem777 wrote:
| How about having the state 100% on server AND on client? No
| dragons, no problems.
| ohgodplsno wrote:
| Then you get to deal with conflict resolution, which is a
| rare dragon that is kind of confusing and sometimes has to
| ask the user which state they'd like to keep.
| treis wrote:
| Keeping them in sync is the dragon
| mlajtos wrote:
| CRDT is the dragon slayer
| iamwil wrote:
| It's the sword that we needed! But it doesn't take us all
| the way. There are semantic conflicts that are difficult
| for CRDTs to solve alone.
| sekao wrote:
| Think about longevity. Whether I'm writing, drawing, making
| music, or anything else important to my life, will I still be
| able to view/edit that data in 20 years? Granted, even with
| offline-friendly software I may need to port it to new
| platforms and make sure I back up the data, but at least I have
| a chance. The data I still have from 20 years ago is far more
| precious to me than I thought it would be back then. Data that
| can only be accessed through an external party is ephemeral and
| it will inevitably disappear one day.
| [deleted]
| fauigerzigerk wrote:
| You are right to talk about the data first and foremost. 20
| year old software is very rarely useful (yes there are
| exceptions) but the data is often just as valuable as before
| or even more so.
|
| That is why I much prefer a web app that lets me download my
| data in an open and well documented format to a desktop app
| that locks my data into some obscure proprietary format or
| even into a particular device.
| vidarh wrote:
| I'm without internet connection multiple times a week on
| average because mobile networks are far from flawless (I live
| in that very rural place where you'd expect to not have regular
| connectivity called London). I don't necessarily care so much
| about "true" local first as 1) something where at least some
| care has been taken to ensure it can keep working while
| offline, 2) with respect to privacy, I halfway agree with you,
| but bigger than privacy to me is portability, for example if it
| turns out I can't trust the current provider. But defaulting to
| not shipping my data to a server somewhere is a good way of
| increasing trust. That said, I want encryption _too_.
| crispinb wrote:
| With waves of climate change disasters sweeping at an
| increasing rate across the world, and resulting wars being
| almost inevitable in the next few decades, you are unlikely to
| have always-on internet for the entirety of your life. My
| region (first world, in a wealthy nation) has had its
| infrastructure (roads and comms alike) largely destroyed twice
| in the last year or so. As we're rich, it gets built back, but
| that takes time. I've been stung enough from weeks'-long
| outages and periods of isolation to never again completely rely
| on an internet connection. I do use software that requires a
| connection, but not for anything critical.
| wellpast wrote:
| Where does "Web" come in here? All of the links are for local-
| first principles, CRDTs.
|
| One of the reasons I love the local-first movement is that it
| puts desktop back into the center of things. I want fast, rich
| creative tools integrated with my OS but I want synchronization
| and collaboration. This is what local-first aims for, was my
| understanding.
|
| Ideally "Web" (ie browser tech) steps aside for first-class
| desktop producer/creative-focused apps.
| lupire wrote:
| For the new generation, the Internet is the Web. HTTP is part
| of the standard stack like IP, even if you don't need or use
| hypertext.
| iamwil wrote:
| What are rich creative tools? Do you mean something like Figma
| or Photoshop? Or are there other tools in that category, like
| tools for creative writing?
| aeharding wrote:
| I've been really happy with CouchDB + PouchDB at
| https://financier.io
|
| You can do unique things like offer a trial period without
| syncing (database wholly in browser), which allows for
| ridiculously quick onboarding. And then when the user signs up
| for a paid plan, you just hook up CouchDB and the data syncs
| right on over.
|
| The sync mechanism works so damn well. It's really cool how easy
| it is to implement a Google Docs-like sync mechanism with
| conflict resolution baked in.
| inportb wrote:
| It works so damn well until it finds itself in a Firefox
| private window :)
|
| PouchDB does have rather expensive adapters that use memory or
| LocalStorage. Almost twice the size as the base package
| (minified).
| locustous wrote:
| I use this model as well. It is a hidden gem for quickly
| building an awesome local first web app.
|
| I'm really surprised more companies don't pick this stack.
| dasil003 wrote:
| One of the things that's exciting to me about local-first web
| development is how it bridges the gap between a full-blown native
| app and full-blown web service.
|
| Native apps have high install friction and a lot of nasty cross-
| platform tradeoffs. Even though there's always a cohort here
| (rightly) commenting on how much of a step backwards the web is
| for GUI app development, one has to admit that we are past the
| time where a truly cross-platform, install-less native app SDK
| can be created and cross the chasm to universal adoption. Web
| tech is what we have, worse is better, yada yada.
|
| Accepting that reality, one of the implications of the web and
| cloud-storage is that the server component tends to be heavy.
| While it's convenient for users to have their data centralized in
| the cloud for consistency and access on multiple devices, this
| does incur some significant overhead in terms of account
| managment, authentication, and database hosting.
|
| The thing that I find really cool about local-first web
| development is that it reopens the door for hobbyist and micro-
| ISV apps that can served cheaply as static files, where the
| customer pays for the compute and stores the data. There are lots
| of potential micro-apps, which don't require network effects or
| large data storage, that could be built this way and avoid
| incurring significant ops overhead for the developer. Obviously
| it runs counter to user expectations today, but I think a lot
| people might also appreciate useful apps that don't have $5/month
| subscription as table stakes just to keep the lights on. Also, it
| doesn't have to be a binary proposition, there could be
| accounts/sync functionality optional. Most of all, as a
| developer, it's exciting to have the ability to try out an idea,
| with optionality to ramp it up into a full SaaS, or scale it down
| without an abrupt rug-pull on the early adopters.
| krab wrote:
| Why should the SDK be install-less? IMHO it's enough if the app
| makes it into the Windows store, Apple store and any Linux
| format.
| throwawaaarrgh wrote:
| [flagged]
| testTED wrote:
| PWA "complicated" keeps getting less so.
| jFriedensreich wrote:
| "Why build on an open standards based platform when we can pay
| apple 100$ /year and beg to publish and not remove our precious
| native app"
| revskill wrote:
| Native app requires re-download to upgrade. There's no such
| need for web apps.
|
| Native apps to me is just another kind of vendor-lockin.
| pjmlp wrote:
| PWAs and ChromeOS specific APIs.
| LAC-Tech wrote:
| Which ones are those?
|
| Safari has service workers and indexedDB support.
| pjmlp wrote:
| PWAs require re-download to upgrade and possible re-
| installation, if kicked off application cache.
|
| Additionally Web is turning into ChromeOS thanks Chrome
| hegemony, see Project Fugu.
| bt4u wrote:
| [dead]
| paulgb wrote:
| The _first_ in local-first is relevant. These aren't local-only
| apps that are unaware of the network (as is typical with native
| apps), they are applications that can sync data among instances
| and combine concurrent offline changes by different users.
|
| That's where the complexity comes in. Desktop apps have the
| same inherent complexity, they just resolve it by leaving it up
| to the user to email report_marks_changes_fina_final.docx
| instead of having the software resolve it.
| iamwil wrote:
| You mean, "report_marks_changes_fina_final_v2_normalized_v3_a
| ctual_final.docx" I've seen how corporate tax people pass
| file versions around email.
| fauigerzigerk wrote:
| _> That's where the complexity comes in. Desktop apps have
| the same inherent complexity, they just resolve it by leaving
| it up to the user to email
| report_marks_changes_fina_final.docx instead of having the
| software resolve it._
|
| Unfortunately, software often cannot resolve it either. I
| keep coming back to CRDTs admiring their conceptual
| simplicity, but in the end there's always some semantic
| constraint that turns out to be very hard to resolve without
| actual centralised database transactions.
|
| Or take your own example, which is about text documents.
| CRDTs give you a guarantee that after syncing everyone up,
| everyone gets the same bytes in the same order. But in order
| to arrive at a semantically coherent document, you ultimately
| need coordination on a higher level than that.
| hobobaggins wrote:
| The key bullets are listed at the top:
|
| 1. data co-located with its UI
|
| 2. works offline
|
| 3. synchronizes between clients
|
| 4. lets its users own their data
|
| So, except for #3, exactly like classic desktop apps that store
| data in local files. (#3 used to be called "peer-to-peer
| networking").
|
| The modern equivalent of classic desktop apps (not that they've
| gone away) are mobile app stores. Mobile apps are installed and
| run locally on a phone, even though a key part _in their business
| model_ is that most frequently sync back data to their server-
| side.
|
| What's _technically_ different between these and "local-first"?
| Nothing.
|
| In #4, there's only an implied contract (not even explicit) that
| the local-first will be not doing "bad" things (like connecting
| server-side and then sending data there without user permission.)
| There's no technical limitation that keeps the app from doing
| that, though.
|
| In other words, "local-first" seems to be a somewhat meaningless
| buzzword or critique about a business model, not a technical
| design.
| iamwil wrote:
| When comparing desktop apps to web apps, we often forget that
| web apps came to dominate because they have a massive advantage
| when it comes to distribution.
|
| It's much easier to go to a URL than to download and install
| software, not to mention the process of maintaining the upgrade
| versions. With web apps, there are no dialog boxes that
| interrupt you when you're firing up the app to get stuff done.
|
| So while it's not mentioned in the local-first software
| manifesto, I'd add that we'd want to retain the property of
| easy distribution of web apps, and it's not just sync between
| clients.
| l8again wrote:
| This isn't about desktop vs web apps. Plenty of desktop apps
| (or mobile apps) use a centrally located database server side.
| So, #3 (synchronize between clients) is about merging data
| using CRDTs in a distributed manner without requiring a
| centrally located database.
|
| A better way to think about it is Google Docs (as a desktop app
| or web app really doesn't matter), and it offers real-time
| collaboration on a single doc between users without using a
| centrally located database.
| rs999gti wrote:
| So what is this? Shipping SQL lite or something similar with all
| web projects, with an async process for eventual sync with HQ
| data and systems?
| remram wrote:
| > SQL lite
|
| You mean SQLite?
|
| To answer your question, this is not a technical product, it is
| a call for action and a collection of resources.
| benatkin wrote:
| This looks to be curation, but one of the things on there in a
| prominent position isn't the best choice IMO. RxDB is what I
| might call an Empty-Core project, where you can't do simple stuff
| without the paid plugins.
| [deleted]
| mf2hd wrote:
| Crashing Brave browser on iOS.
| mjtechguy wrote:
| +1
| yonz wrote:
| Just wild! checkout the source code the page isn't doing
| much: https://github.com/localfirstweb/localfirstweb.dev
| Alifatisk wrote:
| Works fine on Firefox iOS
| rqtwteye wrote:
| I didn't even think it's possible for a site to take down a
| browser completely. Nice work!
| lupire wrote:
| A site can't take down a browser. A browser can take itself
| down if it doesn't like a site.
| remram wrote:
| Just like you can't make coffee, you can only instruct a
| coffee machine to make coffee itself.
|
| Or you can't convince someone, you can only have them
| convince themselves if they like your arguments.
| [deleted]
| ctxc wrote:
| Isn't that the same thing?
| unxdfa wrote:
| Give me 5 minutes with my abysmal Angular skills.
| bravura wrote:
| Many things where it would take me 10 minutes to look up a
| library or API thing I don't know from memory. From today:
|
| * Write me a Python Fabric script to control an SSH session in
| the following ways: ...
|
| * "What does torchaudio.load do if num_frames exceeds the end of
| the file"?
|
| * "What's a typical conn_max_age in django for conn_max_age and
| why?"
|
| * "One-liner to create django secret key and use flyctl secrets
| set"
|
| * "Fix this toml:"
|
| * etc.
|
| It's also amazing rubber duck debugging.
| https://en.wikipedia.org/wiki/Rubber_duck_debugging
| [deleted]
| oblib wrote:
| I'm surprised they list PouchDB but not CouchDB for local first
| software.
|
| PouchDB is fine for trivial local first apps, but not for
| anything that's critical.
|
| CouchDB, on the other hand, is a very robust app that can be used
| by multiple local-first apps and those apps can access and share
| that data, and back it up on a separate local and/or remote
| CouchDB.
|
| PouchDB and CouchDB used together are a pretty sweet and solid
| platform to build a Cloud and/or local first on app on.
| [deleted]
| iamwil wrote:
| probably because you can't run CouchDB on the browser. You do
| need it as something for PouchDB to talk to, however.
| EGreg wrote:
| Okay two things.
|
| 1) I gave a talk about doing local-first web development that web
| developers should watch or read at least:
| https://qbix.com/blog/2020/01/02/the-case-for-building-clien...
|
| 2) I recently learned about AbsurdSQL! It's absurdly amazing for
| this! https://hackaday.com/2021/08/24/sqlite-on-the-web-absurd-
| sql...
| yonz wrote:
| Would love to have you share your learnings with the community.
|
| This is the first time I'm hearing about QBIX. Feel free to
| send a PR with a short description to be considered for the
| page.
| EGreg wrote:
| Sure, would be very happy to. Send it where? I am going to
| message you on Keybase.
| rkagerer wrote:
| It amuses me how this is positioned like it's something new and
| radical :-).
| [deleted]
| RcouF1uZ4gsC wrote:
| What is interesting is that local first applications were the
| Microsoft vision in the 1990s with a Windows computer acting as
| your home hub and syncing over the internet.
|
| The Sun and later Google vision is the network is the computer.
| For better or worse, the Sun/Google vision is ascendent now.
| wellpast wrote:
| But will there be a local-first Renaissance with desktop apps
| returning to focus? (Not sure - unlikely? - but, man, as a
| creative, I really hope so.)
| tmpz22 wrote:
| Building desktop apps remains a chore. A lot of crossplatform
| frameworks are promising (Electron, Flutter, etc) but ask any
| developer building series enterprise applications in those
| tools how fun it is and they will tell you it is not
| _encouraging_.
| iamwil wrote:
| What are the main challenges when building cross platform
| desktop apps today?
| iamwil wrote:
| How come? I don't understand how the creative part figures
| into a desktop app focus?
|
| I'm guessing it's because you like the responsiveness of
| desktop apps for tools in the creative space like photoshop?
| Or is it something else?
| sergioisidoro wrote:
| I am learning MobX State tree, and using the references to
| objects in a tree, with normalisation (ensuring you don't have
| duplicates in the tree, etc). It's impossible not to think that
| state management is getting closer and closer to client databases
| for more complex apps.
|
| I'm really hoping WebAssembly will finally bridge the backend and
| the frontend data structures seamlessly, because right now we are
| getting to the point of keeping 2 separate data schemas, which is
| a huge waste of effort.
| realPubkey wrote:
| Using RxDB as state management there is much you get for free
| like sharing the state between multiple browser tabs and
| reusing a singe replication socket even when the user has
| opened 1000ths of tabs.
| yonz wrote:
| Being able to have storage and network transparent business
| logic is something that I get really excited about. In my mind
| I want a GraphQL interface (ORMis) for a database that acts
| like a wire protocol.
|
| These two links have the same zip code:
| https://www.sqlite.org/np1queryprob.html
| https://engineering.fb.com/2020/03/02/data-infrastructure/me...
| iainmerrick wrote:
| The "examples" section just has a framework, a tutorial and a
| demo app. What are some actual examples of this in the wild?
| ghiculescu wrote:
| There's way too many options on this site. It's intimidating! How
| should I know which DB to use? I just wanna build stuff.
|
| For local-first to succeed as a concept, it would gain a lot from
| having a Rails equivalent that people can get started on. If that
| exists, promote just that and hide all the other options.
| clairity wrote:
| why doesn't rails have a local-first equivalent? it's something
| i'd love to see, as many apps can benefit.
|
| back in the day, we built a real-time sports stats app on top
| of rails and firebase (before it was gobbled up by google) that
| provided some affordances in that regard, but truly offline
| first--saving locally, then syncing when online--would be a
| great rails use case.
| yonz wrote:
| I get your argument, cargo really gave Rust a leg up.
|
| Unfortunately we are far from having a go to platform. The
| community page's primary objective is to get the word out and
| connect local first builders.
| yunohn wrote:
| They said Rails, not Rust. Like Django for Python.
|
| I guess the answer is that JS/TS has never had a stack
| comparable to those py/rb behemoths.
| LAC-Tech wrote:
| _There's way too many options on this site. It's intimidating!
| How should I know which DB to use? I just wanna build stuff._
|
| Multi-master systems - which you have if the same data is being
| written to by multiple devices - are complicated, and there's
| no one size fits all solution. The different approaches all
| have different trade offs.
|
| A good place to start might be "what do I think should happen
| when two bits of data that were updated independently are
| merged?".
| anonym29 wrote:
| Is this So-Mo-Lo or no, is it Lo-So-Mo?
|
| (S.V. reference)
| gfodor wrote:
| I built a thing called webspaces for 3D html worlds based on
| these principles.
|
| https://gfodor.medium.com/rebooting-the-web-in-3d-with-websp...
| college_physics wrote:
| It feels like the web becomes exciting again. A bit confusing
| with all the orthogonal directions but very much alive and
| promising
| jacooper wrote:
| Ironic using discord for such a project. Maybe try matrix?
| toastal wrote:
| Nah, IRC and XMPP MUC
| jacooper wrote:
| Both are beaten by matrix now.
| toastal wrote:
| In what way? Not in mature stable clients or in system
| resources for hosting a server. There's issues around the
| centralization of Matrix.org and I've seen many cases where
| folks spun up then spun down a Matrix server 'cause it
| costs too much to run. In the case of Disroot, the closed
| their server to open an XMPP server instead.
|
| https://disroot.org/de/blog/matrix-closure
| Arathorn wrote:
| you're running on 2018 vintage data. plus there is no
| centralisation on matrix.org (beyond it being the biggest
| server), as has been pretty obvious in the situations
| where matrix.org has gone offline.
| remram wrote:
| Neither of those thing are local-first, e.g. you can't search
| or compose messages while offline. Then again chat apps hold
| little interest when offline.
| mlajtos wrote:
| Chat apps like Discord hold valuable content and having it
| offline searchable would be really nice. Also, replying
| offline.
| vore wrote:
| I'm sure a lot of the technologies on the list (like Yjs!) are
| well-designed and reliable, but I would _not_ touch GUN with a
| ten foot pole. The code is absolutely inscrutable (what does any
| of this do? https://github.com/amark/gun/blob/master/lib/axe.js),
| the creator has failed to sufficiently explain any of the
| underlying mechanisms without complete hand-waving (what on earth
| is a "hypothetical amnesia machine" that supposedly underpins all
| of GUN? The creator has literally never given any kind of
| coherent explanation of it) -- it's just pure snake oil.
| [deleted]
| NickBusey wrote:
| Loading this site causes Brave browser on iOS to hard crash.
| Impressive.
| christophilus wrote:
| Yep. Guess I'll just read the comments.
| Etheryte wrote:
| Given that every iOS browser uses the same engine under the
| hood, this sounds like a Brave problem. Safari and Chrome are
| fine.
| yonz wrote:
| Woww, is this still happening? its literally a barebones jekyll
| page https://github.com/localfirstweb/localfirstweb.dev
|
| Not sure what we can fix, does https://lfw.dev also crash
| (redir to localfirstweb)
| makingstuffs wrote:
| Yeah it does also crash
| jamesgpearce wrote:
| Author here. I'll try and fix this. I have a suspicion it's the
| CSS glow behind the logo since everything else is the most
| stupid basic HTML you could imagine.
| [deleted]
| kept3k wrote:
| Can confirm. Was looking forward to reading this and then BAM.
| Exit
| canadiantim wrote:
| Great list!
|
| Has anyone tried ElectricSQL? Looks amazing.
|
| The ability to effectively use multi-tenant SQLite but aggregate
| shared data into a postgres database is amazing. And they help
| you with migrations etc. This is exactly the ideal setup I've
| been looking for!
| javaunsafe2019 wrote:
| Wow, and I'm here and thinking who needs this, what problems
| are solved here by adding that complexity and don't see any
| real benefit from the producer side perspective and that's
| where the costs are.
| canadiantim wrote:
| Using a multi-tenant SQLite setup helps ensure user data is
| separated into their own databases and won't be inadvertently
| queried by other users. Users can then choose to share the
| data they want to either via peer-to-peer or by aggregating
| to a postgres database.
|
| But the main benefit to me would be that user data will be
| more private and protected and configurable.
|
| This gives someone much more fine-grained control over their
| data and how their data is stored. I think it ultimately
| makes the attack vector space smaller for any client data.
| dgf49 wrote:
| Me as a service provider I would just want to keep the data
| seperated at my backend. I guess Ill need it anyways for
| some usecases. And after that why should I bother adding
| complexity to ship that data to the client side?
| ncallaway wrote:
| Right, but then you're not building a local-first app. of
| course the tools that are useful for building a local-
| first app won't be that relevant to you if that's not
| what you're doing!
| [deleted]
| jFriedensreich wrote:
| there are many options if you do not care how conflicts are
| resolved and last win or some unknown but deterministic change
| wins is ok, but if you care to write bullet proof app specific
| conflict resolution without any data loss there is no real
| alternative to pouchdb + couchdb (except reimplementing something
| similar manually)
|
| also worth noting is that offline first is about way more than
| just working offline, yes full offline scenarios are more and
| more rare, but offline first apps provide reliable and instant
| interactivity where any user action is has a latancy of 1 to 10
| ms max and no data is lost. and works as well on crappy mobile as
| on a high speed landline.
___________________________________________________________________
(page generated 2023-02-19 23:00 UTC)