But here's the problem, these data-structures are used very differently than client/server developers are used to. These are immutable data-structures. Once you change them you get a new hash, and you have to figure out the semantics for sharing that hash around.
-
Show this thread
-
No matter how much data you work with in client/server development you get to treat it like a global mutable state. CouchDB/PouchDB allow you to deceive yourself into believing you have the same thing until you get enough conflicts.
1 reply 4 retweets 8 likesShow this thread -
This is the biggest challenge of Offline, the biggest challenge for the Decentralize Web, and possibly even Edge Computing. Teaching developers to work with decentralized data-structures is harder than teaching them a new programming language.
6 replies 13 retweets 45 likesShow this thread -
This is a completely different programming model, but it's one we'll need to migrate to because our data needs are growing faster than available mobile bandwidth and that isn't changing.
8 replies 2 retweets 20 likesShow this thread -
Replying to @mikeal
It’s because any ”offline web app” solution is, inherently, extremely complex because data syncing. 99% of projects, while maybe they would be better with it, don’t have the resources to implement that. IMHO the implementation details behind it don’t matter.
2 replies 0 retweets 1 like -
Replying to @thomasfuchs
There are data-structures that get syncing "for free." The problem is that they aren't the data-structures we're used to and when we try to do syncing on our old primitives we have to write syncing by hand.
1 reply 0 retweets 1 like -
Replying to @mikeal
Idk, I’ve heard so many times of “automatic syncing” and it never is actually automatic. My first large project was, incidentally, an offline mobile app in 1999/2000 with hundreds of Palms syncing to a Oracle database. Oh the woes. :)
1 reply 0 retweets 0 likes -
Replying to @thomasfuchs
git is pretty automatic :) the only conflicts are when two people legitimately changes the same thing. there aren't ever conflicts because people touched the same file or because of the state of the repo was slightly different when they made their changes.
2 replies 0 retweets 0 likes -
Replying to @mikeal @thomasfuchs
It seems (but perhaps i'm a step behind) that looking only at parts of data for finding conflicts is inherently flawed. Even git's conflict detection can't catch that your removal of some function broke my new use of it. This feels over simplified.
1 reply 0 retweets 0 likes -
Replying to @littlefyr @thomasfuchs
It's not that you only look at parts, it's that you can tell if anything in a large graph changed because the hash changed and you can operate on just the branch with the change to resolve the conflict.
1 reply 0 retweets 0 likes
But then teams also have conventions about merging changes from "master" back into branches often, to reduce the chance of ugly conflicts. The true power of git requires a paradigm shift, letting go of the idea of a single source of truth.
-
-
You may have noticed that we're having a hard time with this not only in the tech world but in society at large. :)
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
