RxDB

Dark mode was a mistake 🤦🏼🌗 It does not save your battery, most of the web ignores it, and it measures worse to read. You do not save power. Purdue measured this: at the 30% to 50% brightness auto-brightness keeps most phones at, dark mode saves 3% to 9% on an OLED screen. The same paper found Google News at 20% brightness in light mode draws the same power as that app at 50% brightness in dark mode. And on an LCD the backlight is on either way, so there is nothing to save at all. Most websites do not have a dark mode. Only 13% of web pages implement it. So some of your tabs are dark, and then you switch to the next one and stare straight into the sun ☀️. The prefers-color-scheme media query has been in every major browser since 2019. Seven years later, 87% of the web ignores your setting. Reading is harder in dark mode. Dobres and colleagues measured it: Two text sizes, a dark room and daylight. Light text on dark background in a dark room was the worst case in the entire study, and the gap widened as the text got smaller. Just adjust your screen brightness! It works on every website instead of 13% of them, it costs nobody a second design to maintain, and it fixes the real problem: Your screen is too bright. #darkmode #webdev #uxdesign

REST APIs grow with every feature you ship. Sync endpoints do not grow at all. In a REST app every feature adds a route, and every route adds validation, tests, documentation, and one more thing that can break. Ship features for a year and you maintain hundreds of endpoints nobody dares to touch. A local-first app works differently. Per entity you only need the sync endpoints: pull changes, push changes, and a change stream for live updates. 3 routes per entity. That is the whole API. A new feature is then a database query on the client. Reorder a list, filter a table, mark everything as read, CRUD: no new route, no backend deployment. The data is already on the device. Even the error handling shrinks with it. In a REST app every request can fail, so every screen carries its own loading state and retry logic. With a sync engine all of that lives in one place: the sync keeps retrying in the background while the user keeps working. And the cache problem disappears. The local database is not a cache of the server, it is the state itself. Nothing to invalidate, nothing to refetch. Count the endpoints in your API. Each one is code you maintain forever. #localfirst #offlinefirst #syncengine

WebMCP is underrated! 🤖🤝🧑 The current web is built for one target group: humans 🧑. Pages, buttons and forms are designed for human eyes and human hands. An AI agent has to pretend to be human to use them, it takes screenshots and guesses where to click. WebMCP adds a second target group: agents 🤖. Your website registers JavaScript functions with a name, a description and an input schema. An agent can then call searchProducts or addToCart directly, in the browser, inside the user's logged-in session. No scraping, no separate API, no API keys. And the agent is not locked to a single website. It lives in the browser, across tabs. It can read the recipe on a cooking website in one tab and put the missing ingredients on your shopping list on the supermarket website in the next tab. Two websites that do not know each other, combined into one workflow. The spec comes from engineers at Google and Microsoft. It was first published in August 2025, and nine months later Chrome announced an origin trial at Google I/O. Web standards usually crawl for years before they reach a browser. This one did not. That pace tells you how much priority Google gives it. The problem it solves is real and it grows every month. Agents that browse by screenshot are 8x slower compared to WebMCP, they break when the layout changes, and they burn tokens on pixels and html. Structured tool calls already won on the desktop and on the server, that is what MCP is. The browser will follow. Big tech has a name for where this is going: "the agentic web". My bet: within two years, "does your app expose tools for agents" becomes a normal question in frontend teams, the same way "is your site responsive" once did. #webmcp #agenticweb #webdev

SEO is dying. And I say that as someone whose whole marketing strategy was SEO. Traffic from Google was the main growth channel for RxDB, the local-first JavaScript database I maintain. Write deep technical articles, rank for the right keywords, and the developers find you. This worked for years. In recent months the pattern broke. We still rank the same for our relevant keywords, some even better than before. But traffic keeps going down, month after month (see chart below). Daily clicks are down about a third since February. Rankings flat, clicks falling. When rankings stay and clicks disappear, the searchers went somewhere else. I see two reasons. First, many developers no longer ask Google at all. They ask ChatGPT or Claude and never see a search results page. Second, even when they use Google, the AI Overview at the top answers their question before they scroll. The links below it might as well not exist. You cannot fix this with more SEO. An answer engine does not send traffic, it gives answers. So the goal shifts: instead of ranking in the search results, your product has to be the answer the model gives. That means showing up where the models learn: - Reddit threads, Stack Overflow answers, Wikipedia, GitHub discussions - Documentation a machine can quote. RxDB ships an llms.txt file for exactly this - Users who talk about your product on the public internet, in their own words That last one is the important part. Honest posts and comparisons written by real users are the new backlinks. You cannot buy them with an ad budget. You earn them with a product that is worth talking about. SEO rewarded whoever wrote the best page. AI rewards whoever the internet talks about. That is the game we are all playing now. If you run a website: open your Search Console and compare clicks against impressions over the last 12 months. Did they split apart? I want to know if this hits everyone or mostly developer tools. #seo #rxdb #devtools

Your app breaks the moment the wifi drops. Not in some rare edge case. In an elevator, on a train, in the parking garage under the office. The user taps a button, a spinner shows up, and nothing happens. The text they typed is gone, state is lost. Most apps do not even tell them what went wrong. This happens because most apps are built as if the network is a given anytime. Every tap becomes a HTTP-request, every screen waits for a response from a server. On the fast office wifi where the app was developed, this feels fine. On a phone that moves through the real world, it falls apart. The device in your user's pocket is a full computer with a fast CPU and gigabytes of storage. But most apps treat it as a dumb screen for a backend. There is a different way to build this. Keep the data on the device. Read and write locally, so every interaction responds instantly. Then sync the changes with the server in the background, when a connection is there. When the wifi drops, the user keeps working and does not even notice. The network becomes an optimization, not a requirement. This is not a new idea. Your email client has worked this way for decades. You can read and write mail in a tunnel, and it syncs later. Nobody calls that offline support. It is just how email works. Users will not ask for offline support. They will say the app feels slow, or that it lost their input, and then they are gone. I work on this problem every day with RxDB, a database that runs inside the app and syncs in the background. But the principle matters more than the tool: stop treating the network as a given. It never was. What was the last app that lost your data when the connection dropped? I read every answer. #localfirst #offlinefirst #rxdb

The lead of the Solid project, Jesse Wright, built a replication plugin for RxDB. Your app's database can now sync into a data pod that the user owns. If you have not followed Solid: it is the project started by Tim Berners-Lee, the inventor of the web, to fix who owns data online. Every person gets a pod, a personal data store on a server they choose. Apps do not keep your data in their own backend. Instead they ask for access to a part of your pod, and the user can revoke that access at any time. The data belongs to the user. The app is just a view on it. But so far this idea was missing a client-side story. A Solid app still needs offline support, fast local queries, reactivity, and conflict handling, and the pod alone does not give you any of that. This is where RxDB comes in. The RxDB replication protocol is backend-agnostic: you provide a pull handler and a push handler, and any backend can become a sync target. Jesse Wright (Solid project lead, PhD candidate at Oxford) used that seam and built rxdb-solid. One call to replicateSolid() syncs an RxDB collection to and from a pod, one pod resource per document, with live replication, checkpoint-based pulls, and conflict resolution through RxDB's conflict handler. Here is why I think this combination matters. Local-first gave users ownership of the copy on their device. Solid gives them ownership of the copy on the server. Put together, the whole data path belongs to the user, and the app cannot lock anyone in. When the app dies, the data survives. To be clear, this is a young project. It is not published on npm yet. But the architecture is right. Repo: https://lnkd.in/e3Q43R3C (leave a star ⭐ if you want more community-built backends) If you build local-first apps I want to know: what would stop you from shipping an app where the user brings their own storage? #localfirst #rxdb #solidproject

⚠️ Your app is slower than it should be and you don't even realize it. Most developers are still building apps that BREAK the moment the internet drops… Meanwhile, users expect: • Instant load times • Real-time updates • Offline reliability Here's the truth 👇 If your app depends entirely on a backend… you've already lost. The shift is happening: local-first apps. Instead of waiting on APIs, your data lives inside the app: → Zero-latency queries → Works offline by default → Syncs in the background seamlessly That's exactly what RxDB enables. It's not just another database, it's a different way of thinking about app performance and user experience. Devs using it are building apps that: • Feel instant • Scale better • Work anywhere (even with bad internet) And yes… this is becoming the new standard. Check it out: https://rxdb.info/