David Fahlander is the creator of Dexie.js, a tool to help web apps store data in browsers instead of servers.
David is passionate about the usage of APIs and software, loves C64 music and 6502 assembly language. David lives in Stockholm, Sweden, and is an old member of the C64 group triad alias daw.
How would you ELI5 (explain like I’m 5) your project, Dexie.js?
Web apps allow you to do lots of things online, like read books, browse things, write a diary, upload photos, or list your favorite food items. Some web apps stop working when the internet is down. This happens because they need a place to store the things you write, and they typically need the internet to store things somewhere far away.
Web apps don’t have to stop working when the internet is broken, because it is also possible to put things in something called an IndexedDB that sits in every browser. If programmers put things there, instead, the app would work whether internet connectivity was up or down.
One problem is that IndexedDB is hard to use. This is where Dexie.js comes in—it makes it easy and fun to use IndexedDB and create web apps that work no matter the status of your internet connection.
In the early days of Dexie.js, how did you find contributors? What were some things you could have done better?
Dexie was the first open source project I released. This was in 2014, and I needed Dexie.js for a personal project, but I thought it was so much more fun to put it out as open source.
I had been longing to do open source for several years. I understood that I would have to find ways to promote the library, so I started out by creating an article at CodeProject, which targeted people that wanted to learn about IndexedDB in detail.
I emailed someone at Mozilla who was one of the architects behind IndexedDB. I explained my creation, and he invited me to blog about it on Mozilla Hacks. After that, there were quite a few people expressing enthusiasm about the library. I think the article at Mozilla Hacks was what helped it reach people that would appreciate it.
One of the first issues, #22 “Dexie is not widely known”, stated, “This is the biggest issue with Dexie. SRSLY. I've been in search of Dexie for quite a while, but didn't know that it existed…” The issue also stated, “How can we solve this problem?”
That issue became a communication channel for people wanting to help promote the library. People contributed by registering the domain dexie.org, creating the landing page, creating a logotype, and handing it over to me. At Mozilla, they added a link from developer.mozilla.org to my library from its IndexedDB documentation page.
Contributors have dropped in over time. They're mostly library users who've found bugs or browser limitations that could be fixed or worked around in the library. Other contributors have been authors of other libraries that depend on Dexie. They've been extremely helpful and have contributed the most. All these contributions have been essential to keeping Dexie stable and reliable. I’ve also got a lot of help with website and documentation corrections.
Regarding things that I could have done better, I should have built concrete examples for various libraries. Samples about using Dexie in React and Angular were eventually provided by a contributor, and those have been very important for users.
What are your favorite development tools? What do you like about them?
Except for obvious tools like node, npm, git, Chrome debugger, and Firefox developer tools, I find the following tools being “must-have's” for me:
-
Visual Studio Code, because:
- it is fast and lightweight, looks nice and helps me stay productive,
- it has built-in typescript support,
- it gives me code completion,
- allows me to refactor easily (rename and move files, functions, vars, and classes).
-
jsfiddle.net, because:
- it allows me to test code instantly,
- it allows me to code in the browser.
-
stackblitz.com, because:
- it allows me to code in the browser (like JSFiddle), but this one is more modern,
- it allows me to create ES6 modules using both Typescript & React while having npm dependencies.
What kept you motivated to work over the years? What keeps your passion for 'APIs and software' alive?
I’ve received a lot of love from people in the form of contributions, nice messages in issues, and “thank you” emails over Dexie.js.
Last year, I even got some chocolate sent to me from overseas (from a WhatsApp developer), along with a long “thank you” letter! Nothing is more inspiring than this.
But some years ago, I started questioning if it was really worth it. I didn’t originally plan on spending 40-60 hours a week year after year on Dexie.js—hours that I would have been paid for if it had been for a customer.
Don't get me wrong, I love working with Dexie.js, but it is also an expensive hobby in the long term unless it leads to some benefit for my personal career and economy.
I realized I needed to find a way to help me do what I loved to do. I had to find a way to code on libraries like Dexie.js and somehow get paid for it. At first, I considered applying to Open Collective to get Dexie.js funded, but then I had another idea. I need to build a product that would complement Dexie.js in the “offline-first” space and release it under a freemium model.
That's the plan. That's what keeps me motivated right now. I’ve been sketching, thinking, and reiterating my ideas for endless evenings, nights, and holidays, and I think I have enough of a channel to test the idea once it reaches the MVP status (sometime next year, hopefully).
What were some obstacles you faced while coding for Dexie.js?
The first obstacle I faced was creating a Promise-based API on top of IndexedDB as IndexedDB transactions were not compatible with Promises in the browsers. Strange bugs and limitations in various browser implementations have also been an obstacle to navigate around.
How important is testing for your project? What tools do you use to test?
Without automated tests, a library could easily get stalled because no one would dare to change things. The more a library can be verified using automated tests, the greater the probability of it getting improved, extended, optimized, refactored, and even reduced in size.
Whenever a reproducible bug has been found in Dexie, I try to write a unit test that reproduces, it along with a bugfix. On every git push to any branch in the Dexie.js repository at Github, over 1400 assertions will be tested on several browsers with different combinations of add-ons applied to assure nothing has been broken.
For Dexie, testing on multiple browsers is important because the various browser-implementations of IndexedDB are far from perfect. Dexie needs to navigate around various browser issues. We have a lot of test assertions in Dexie.js that not just tests that the code does what it should, but also that this really works the intended way on all targeted browsers.
By automatically running unit tests on different browsers through Browserstack upon every git push, I’ve detected browser bugs (even when this wasn’t the intent of that test). I’ve been able to file some issues on both Mozilla and Webkit.
But I am, at the same time, against overdriven demands of unit testing. I have experienced how overdriven demands of having unit tests can have the opposite effect, as it may tie up the code and make it harder to refactor.
My philosophy is that tests should verify long-lived specifications and avoid testing functions and methods that have the potential to be refactored later.
What do you think is the best way for developers to network? What social media networks do you frequent?
I don’t think I’ve found any favorite medium for networking yet. I’ve created a Twitter and a Mastodon account, but I rarely use them. Most of the time, I find myself communicating on GitHub on issues in other projects or my own. I also like Medium, so I've created an account there as well. I’m planning to write some Medium posts soon.
What are your productivity hacks?
I use Google Docs for clearing up my thoughts, writing markdown docs for designing, planning ideas, and documenting code. I use a self-developed time tracker to track the time I spend throughout the workweek.
