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.
I don't think that's the right metaphor to use here, it exists at a different level than what I would consider "reinventing the wheel". That to me is more some attempt to make a novel outward-facing facet of the program when there's not much reason to do so. For example, reimplementing shared memory using a custom kernel driver as your IPC mechanism, despite it not doing anything that shared memory doesn't already do.
The difference between the examples is so trivial I'm not really sure why the parent comment felt compelled to complain.
Imo, if you read such code the first time, you may prefer the first. If you read it for the 20th time, you may prefer the second. Once you understand what you are doing, often one prefers more concise syntax that helps in handling complexity within a larger project. But it can seem a bit "too clever" in the beginning.
I think code clarity is subjective. I find the second easier to read because I have to look at less code. When I read code, I instinctively take it apart and see how it fits together, so I have no problem with the second approach. Whereas the first approach is twice as long so it takes me roughly twice as long to read.
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.
Note there is a slice of B2C products that are sold like he is thinking. I wanted a subscription to Polypane, got a free trial and ultimately my administrative assistant punched in our P-card number to their web site. I had to fill out paperwork to satisfy one of New York’s largest private employers, but the burden was all on me —- though there would have been no free trial for a product that didn’t exist and the paperwork wouldn’t have been so simple if it didn’t.
Hey, Polypane founder here hoping to get feedback and iterate ;)
Needing to fill in the paperwork for a saas is a PITA. Is there anything I could add to the site or elsewhere that would have made that easier for you?
My Uni has site licenses for many products such as Snagit 2025 and if I want a license for that the skids are greased. You did everything right from the viewpoint of an early adopter, in the future I guess your sales people could talk to our Central IT and negotiate something, if you send me an email I could try to find out how you would talk to.
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].
How has it been going? I've been thinking of trying this model but a bit worried about how much harder it would be to make it sustainable as a business
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.
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.
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.