Local-first web development

Dear community,

there is a growing movement in the web development community that is rethinking the exchange of data between client and server, especially to write applications that work well offline. Its called local-first web development: https://localfirstweb.dev/

I stumbled across this term again when I read this blog post by Kyle Mathews, known as the creator of Gatsby: Bricolage | Some notes on Local-First Development

In my opinion, Meteor would also be a good candidate to go in this direction. It offers a clear API to access the data through publications (for reading data) and methods (for changing them). Since the early days, methods are built in way, that data is immediately changed in Minimongo and updated later by the server. Extending minimongo and the server side with synchronization capabilities (or replacing these components altogether) would bring local-first development to Meteor without changing the core data concept of Meteor. I can imagine that apps strictly following this concept could offer offline-capability with no or minimal changes.

There’s a Github issue by @storyteller from 2021 with some discussion: Improve offline support 🛌 · meteor/meteor · Discussion #11656 · GitHub Also this forum contains posts asking for help to build offline-first applications. Unfortunately, I cannot find some kind of best practice to build this feature with Meteor. On the other hand, I’d really like to see this as core feature based on the existing concepts and APIs

What do you think about it?


It should have been discussed somewhere here: Seeking Community Input: Meteor.js Roadmap


I’m all for it, there is GroundDB that needs updating in this regard and would be a perfect fit into this. For now the best start is to implement service workers for now.
What I think is needed in terms of data:

  1. Some way to specify what is needed for full offline usage and then persist that data locally.
  2. When requested by user or when network available sync the data to server or save to file.

Of course there is a lot more, but this is the start, I think.


Since Meteor already includes infrastructure to handle data on the client side it seems that much of the tooling to support offline operations is already in place. Now taking the steps necessary to support actual offline use in a “standardized” way seems a reasonable investment considering the upside. I would just generally very much prefer if the resulting API would prioritize simplicity over features. Reconciling data sets with various degrees of staleness is usually a hard proposition and it is easy to get sucked into a rabbit hole of complexity.


Note that some meteor tool commands are not yet offline compatible either. If I want to run a meteor command while being offline and meteor detected a newer version for update before I became offline then the command halts forever since the download does never succeed.


This is mentioned in the linked discussion. People should upvote the respective posts if they think it’s important

I’d like to link a related post, which came up >2 weeks ago but seemed to be missed by many: Setup meteor app to be offline first - #20 by trusktr

1 Like

It will be a good feature.