[HN Gopher] Building Local-First Flutter Apps with Riverpod, Dri...
       ___________________________________________________________________
        
       Building Local-First Flutter Apps with Riverpod, Drift, and
       PowerSync
        
       Author : kobieps
       Score  : 28 points
       Date   : 2025-05-06 20:48 UTC (4 days ago)
        
 (HTM) web link (dinkomarinac.dev)
 (TXT) w3m dump (dinkomarinac.dev)
        
       | account-5 wrote:
       | Why not just use sqlite instead of drift?
        
         | kobieps wrote:
         | Probably easier to ask an LLM, but here goes: drift gives you
         | type-safe queries which lets you catch any errors at compile
         | time instead of runtime (which is the case with sqlite). There
         | are other benefits but that's probably the main one.
        
         | taormina wrote:
         | It's still SQLite. Drift as an ORM they are using on top of
         | SQLite.
        
       | doawoo wrote:
       | As a newer user of Flutter I found Riverpod to be extremely heavy
       | and have a lot more mental overhead than using stateless widgets
       | with Hooks.
       | 
       | Any particular reason you personally prefer Riverpod?
        
         | dinko7 wrote:
         | Hi, author of the article here.
         | 
         | Any state management approach requires you to adapt your way of
         | thinking, whether that be BLoC, Riverpod, Redux or anything you
         | want to use.
         | 
         | Rivepod gained popularity because it's really simple to pick
         | up: create a Notifier, create a Provider for it, and observe,
         | while some other approaches require additional boilerplate,
         | setup, and understanding.
         | 
         | Your approach would work if you are only observing that state
         | from a single widget, which might not always be the case.
         | Additionally, assuming useState is using setState under the
         | hood means it will rebuild the whole widget on change, while
         | with Riverpod, you have the flexibility to wrap any part of a
         | complex widget into a Consumer or listen to only part of the
         | exposed state on the Notifier with .select().
         | 
         | To put it simply: - Notifiers are used for app state - Hooks
         | are used for ephemeral state (local widget state)
         | 
         | Hope this clears it bit for you.
        
           | doawoo wrote:
           | Great summary, it does indeed! Thanks for taking the time to
           | reply
        
         | vin047 wrote:
         | Riverpod does a lot more than just state management - it also
         | handles dependency injection and reactive caching.
         | 
         | Here's a great guide on using Riverpod:
         | https://codewithandrea.com/articles/flutter-state-management...
        
       | sgt wrote:
       | Would this work with Flutter Web as well?
        
         | kobieps wrote:
         | Yes
        
           | sgt wrote:
           | Flutter Web used to be pretty slow but I note that it has
           | improved substantially in the last 2 years.
        
       | zerr wrote:
       | I wonder why Flutter didn't gain traction in US. It seems to be
       | more or less popular in poor countries and even less in Europe.
       | But in US it seems to be quite a no name. Why US is so
       | JavaScript-centric?
        
         | dleeftink wrote:
         | > poor countries
         | 
         | Ah yes, those fluttering countries and their fluttery ways
        
         | vin047 wrote:
         | There are a lot more JS and Native developers compared to
         | Flutter/Dart developers in the West. Plus fear-mongering around
         | Google dropping development of Flutter.
        
       | hosh wrote:
       | Let's be clear. This post describes an architecture that is
       | offline-first, not local-first.
       | 
       | One of the main goals of local-first is so that the user of a
       | local-first application owns their own data. (See Martin
       | Kleppmann's paper on this).
       | 
       | As such, local-first applications don't necessarily have a
       | concept of a central server. `git` is local-first, though most
       | teams synchronize to a hub such as Github or Gitlab. This is a
       | design principle to get away from having to sync to the cloud,
       | making it more difficult to monetize as a SAAS. There seems to be
       | a growing trend of people promoting offline-first applications as
       | local-first, but structuring it to still lock people's data into
       | their SAAS. (If you want to lock them in, then say so -- call it
       | offline-first).
       | 
       | A true local-first mobile app would allow me to collaborate with
       | someone in the same room using Bluetooth, even out somewhere
       | where I don't have wifi, cell service or Starlink
       | 
       | See:
       | 
       | - https://martin.kleppmann.com/papers/local-first.pdf
       | 
       | - https://www.inkandswitch.com/essay/local-first/ (Same, but in
       | html)
        
       ___________________________________________________________________
       (page generated 2025-05-10 23:00 UTC)