4 ms·
Unlike a lot of comments here, I don't need to be sold on the concept. As luck would have it, I am actively building an app that runs mostly in the browser usi
by Lazare 14y ago
Unlike a lot of comments here, I don't need to be sold on the concept. As luck would have it, I am actively building an app that runs mostly in the browser using CouchDB, Kanso, and PouchDB. It's a pretty amazing tech stack; I get a local DB in the browser, which I can sync with the main DB in the cloud the client is connected. Plus I get some nice APIs for stuff like sessions, registering users, security, validation, etc.
I see you've already mentioned switching to PouchDB on your backend, and you're already using CouchDB for the cloud, so it seems like you're basically competing straight up against Kanso. So.... How is what you're doing different from what Kanso does? Why should I use Hoodie over Kanso?
I see this code in your docs:
hoodie.account.signUp('joe@example.com', 'secret')
hoodie.account.signIn('joe@example.com', 'secret')
Very nice. But Kanso has:
users.create('testuser', 'testing', {roles: ['example']}, function (err){});
session.login('testuser', 'testing', function (err, response){}});
Seems like six of one, half a dozen of the other. What's your killer feature? Kanso has shaky documentation and is currently more aimed at couchapps (they strongly assume that you'll serve your frontend code from CouchDB), but I'm not sure how that really differs from Hoodie. :)
If we take the overall architecture as a given (browser based app, PouchDB or equivalent for local storage, syncing with CouchDB in the cloud, and node workers handling the backend work), what's the focus of Hoodie that sets it apart from Kanso?
(In any case, nice stuff. I think the concept is great, and there's definitely room for several competing frameworks in this space.)
- janl 14y agoSpot on! We stole a lot of ideas from the whole CouchDB application space. @caolan, the Kan.so dev is currently looking into Hoodie as well. As far as originality, we choose a different design approach. We want to cater to people who barely get jQuery and give them a tool to build larger apps. We are building the technology downwards from that idea towards the bits and pieces we have. One of the fun things about Hoodie is that there is nothing technically new in it. Existing ideas and tools are just put together a different way.
- lifeisstillgood 14y agohi I am trying very hard not to be dumb, but this is beating me seemingly Kanso? and Hoodie both have JS stubs at the client and server end, these synch with each other, then synch with whatever you are using at client (say backbone) and server (node? CouchDB? My Postgres server behind my python app?) If thats roughly right, why do I do this? I control my server apps no? Why wrap them in another layer? Json->backbone is hardly a difficult synch operation - I mean its called synch(). I really am interested in understanding the philosophy and driving ideas here - everyone has a moment of clarity where they can see how to build an app or a framework, and how it will come together - I am not attacking you (yet !) - please describe your moment of clarity.
- janl 14y agop2p sync is actually a hard problem, you might want to look into the theory :) The value of Hoodie is putting everything together into a way that a jQuery / backbone dev can be productive with. It sounds like you are way more advanced, as such, you will have a way easier time managing all the pieces. > Why? Because we like building apps that way :)
- lifeisstillgood 14y agopeer-to-peer synch? So this is not client server? But browser to browser? WebRTC-enabled? Much cooler. And not even eventually consistent. Please point me at theories :-) jQuery / backbone dev can be productive with I am not clear on that - is that "someone who does not / cannot develop on a tradiational server backend (LAMP etc). How does Hoodie help them? How do you handle network downtime or two clients changing one backend resource with downtime? Why? - that was more what are the benefits to me as a LAMP / backbone dev to using Hoodie, as opposed to are you enjoying yourself, which seems evident :-)
- janl 14y agothis is many-client-server. p2p sync enables you opening your Hoodie app on your browser, smartphone and tablet at the same time and make it all work, even when some or all of the devices are offline for short or long periods of time :) > I am not clear on that - is that "someone who does not / cannot develop on a tradiational server backend (LAMP etc). How does Hoodie help them $ hoodie new app $ cd app $ jitsu create $ jitsu push (simplified) > How do you handle network downtime? Waiting. > or two clients changing one backend resource with downtime? p2p sync with conflict detection as provided by CouchDB. > that was more what are the benefits to me as a LAMP / backbone dev to using Hoodie, as opposed to are you enjoying yourself, which seems evident :-) While you are capable of doing all the heavy lifting, why not focus on building great apps? Or if your thing is running backends for people who build the apps, why not give them Hoodie and take the day off? :)
- gr2m 14y agoKey difference: kan.so is Couch specific. Hoodie is not. We do not try to make another nice library to wrap CouchDB. We try to make a nice JavaScript API for the most common backend tasks. We start with a dream API, and build from there.
- rgbrgb 14y agoThe biggest difference from where I'm sitting is that Kanso hasn't been updated in 10 months. https://github.com/kanso/kanso https://github.com/kanso/kanso
- sopooneo 14y agoForgive my ignorance, but CouchDB does not run in the browser, right? So am I correct that the "mostly in the browser" statement doesn't apply to that particular data store?