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.
> Offline-First is a software paradigm where the software must work as well offline as it does online.
I've been building offline-first apps[0] for quite a while in both desktop and mobile space.
I have a different definition[1] of what an offline-first app is:
Offline-first apps are apps which can run and function completely offline or without needing the internet for an indefinite amount of time. To offline-first apps, providing all functionality offline is the "primary objective" and any online functionality such as syncing to cloud is secondary.
Also, I personally don't consider an app using temporary cache to store data to be an offline-first app. It must use a local database. Sometimes the "offline-tolerant" apps are confused with offline-first apps. Offline-tolerant apps often provide partial functionality and eventually need an internet connection to sync data.
I understand that. It's totally dependent on your needs. If you need to run multiple docker containers or VMs, then you need that power and I get that, I'd need it too in that case.
Agreed. I'm still on Ivy Bridge(3rd gen) quad-core i7(laptop). Its fast for all my development needs. I put SSD couple of years ago and its quite snappy.
Agreed, I came to the same conclusion. Both my PC laptop and MacBook Air have glossy displays but MacBook one reflects back less light which makes it easier to work with.
I use to think along the same lines. However due to nature of my work, I switch between a MacBook and PC quite often. When I go from MacBook to a laptop with 1080p resolution, I could see why people prefer higher resolutions. Font rendering and entire experience of reading on a computer becomes so much better.
That's true, but if you compare the resale value of PCs and MacBooks, you'll find that MacBooks(even with outdated OS) have higher resale value. Therefore, this is a bit of a tricky situtation for PCs since they can't be sold for much.
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.