In the first instance, the original code is readable and tells me exactly what's what. In your example, you're sacrificing readability for being clever.
Clear code(even if verbose) is better than being clever.
This is pretty impressive. A lot of people underestimate the amount of work required to make something available offline. Planning the syncing architecture alone is a monumental task, especially at the scale Notion operates. I built a custom sync solution for my own app, Brisqi (https://brisqi.com), and it took me weeks to get it right, albeit with some trade-offs.
Kudos to the Notion engineering team for achieving this milestone.
I didn't like Tailwind initially, but after using it for a week, it's hard to go back to regular CSS or even SCSS. I have a project that uses SCSS, and sometimes I wish I was using Tailwind instead, it makes the workflow so much easier.
I'd highly recommend people try out Tailwind for a week on their projects before giving up on it.
That said, I haven't tried DaisyUI so no opinions on that.
This might work for B2C startups, but not so much for B2B. In B2B, people need to see a working product that clearly saves them time or money. The sales cycle is longer, and landing page tactics alone usually aren’t effective.
A better approach is to talk to as many potential customers as possible early on. Collect emails, show a rough prototype, get feedback, and iterate. Then, when you’re ready to launch, go back to those same people, email them, show what’s changed, and demo how the product delivers real value.
If I were to do it all over again, I’d simplify things even further. I’d start by testing the idea with just the offline version. For syncing, I’d focus on syncing the data itself, just the database records and not the user actions. Instead of replaying every action, I’d track which records were modified and sync only those. No need to capture what changed, just that record got changed. Hopefully that makes sense.
The business is doing alright, but what really keeps me going is that the app is something I genuinely wanted for myself. I use it all the time, it's always open in the background, so that keeps me motivated.
This was refreshing to read! More apps should be local-first. If the user does not want to sync their data to cloud, they should have that option.
I’ve been building the offline-first (or local-first) app Brisqi[0] for a while now, it was designed from the ground up with the offline-first philosophy.
In my view, a local-first app is designed to function completely offline for an indefinite period. The local experience is the foundation, not a fallback and cloud syncing should be a secondary enhancement, not a requirement.
I also don’t consider apps that rely on temporary cache to be offline-first. A true offline-first app should use a local database to persist data. Many apps labeled as “offline-first” are actually just offline-tolerant, they offer limited offline functionality but ultimately depend on reconnecting to the internet.
Building an offline-first app is certainly more challenging than creating an online-only web app. The syncing mechanism must be reliable enough to handle transitions between offline and online states, ensuring that data syncs to the cloud consistently and without loss. I’ve written more about how I approached this in my blog post[1].
Built a privacy focused Kanban board app called Brisqi - https://brisqi.com
It's offline-first, has one-time payment plans and has a clean, simple design.
Check it out!
I built an offine-first task management app with Kanban setup called Brisqi because I needed an app that worked anywhere without relying on an internet connection. Whether you’re in a corporate setting, dealing with spotty Wi-Fi, or just prefer more privacy, staying productive shouldn’t depend on being online.
It’s lightweight, private, and gives you full control without relying on the cloud.
That said, I'll change my mind here and agree on using std library, but I'd still have separate 'key' assignment here for more clarity.