Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

evaluate WatermelonDB #3

Open
yzorg opened this issue Nov 8, 2018 · 0 comments
Open

evaluate WatermelonDB #3

yzorg opened this issue Nov 8, 2018 · 0 comments

Comments

@yzorg
Copy link
Owner

yzorg commented Nov 8, 2018

This project will have multiple implementations of the UI layer. I recently heard a podcast about
WatermellonDB and it sounds like the best fit available.

I think the real-time nature of file system (when a developer is working, and tools like compilers and bundlers are running) means that I want the UI to render from a local data cache, and changes to the local data need to be reflected (React/Vue re-render). I want the UI to be fast, which means the *data sync* will be happening *after* the cached directory list is shown. So it would be best if the app had a local, in-browser data store that was also reactive. WatermelonDB seems to fit the bill, when no others do.

When reviewing other local data libraries I kept thinking: Why can't someone just solve synchronization? But if WMDB gives me reactivity, then I think I think synchronization is solvable.

Others had promise, like GunDB, but that project seemed to spend a lot of time/effort on signing data, and other "distributed trust" scenarios that seemed way out from what I'm looking for. (Keep in mind, I'm trying to keep "first load" experience snappy, i.e. a Javascript code budget that Addy Osmani would be proud of.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant