What's wrong with gun.js?
2 min read
What is gun.js?
This should be easier than it is to explain, but like many fast-moving open-source projects, definitions and capabilities change rapidly, often with shared oversight. Let's start with the broadest definition for 'What is GUN?' and work towards the more specific.
1 -"GUN is an ecosystem of tools that let you build community run and encrypted applications." 2 - GUN is an open-source project. 3 - GUN from a technology perspective is a protocol for synchronizing data in graph format.
So, it's an ecosystem, project and protocol. Ok, but why do so many people call it a database? The need for a decentralized offline-first way to store data is likely the requirement that drives people to refer to gun as a database. Naming aside, this
stuff is transformational but why does it seem so underappreciated?
Here's how I will use the terms if I blog more about the project:
GUN = concept gun.js = concrete
Characteristic of gun.js
- Offline first
- Eventually consistent (cAP)
"Technically, gun.js is a graph synchronization protocol with a lightweight embedded engine, capable of doing 20M+ API ops/sec in just ~9KB gzipped size." -again, from GUN project readme
So, What's Wrong?
This not only sounds amazing it is amazing. I've been using it for a year now and it's changed the way I think about apps and the ownership of data. So why aren't more developers using it? I'm genuinely interested in hearing from devs who have tried it and moved on to other decentralized storage or decided to stick with Firebase. Please leave a comment below and share your perspective and experiences.
*This post could have been a tweet, but you know... length.