Live data from Hacker News

Hoodie: very fast web app development

hood.ie

91–100 of 155 posts

Re: Hoodie: very fast web app development

#91
post #60

Earlier quoted context omitted.

Okay, first off, let's discuss a standard three tier webapp architecture: Browser Server DB You get some HTML/CSS/JS from the server, you display stuff to the user. As the user interacts with your app, HTTP requests hit your server which processes them. As needed, the server will make requests to the DB, which will reply with data, which then gets passed back to the browser. Everyone knows how this stack works, I hop…

If my phone has no signal I'd rather see an error message. I don't want the app to pretend everything is fine when that's not the case. If I press "Delete" in the app, don't pretend the thing is deleted if it's not really deleted yet, that's deceptive. What if I take off on my boat and I press "Send" and your app says "Sent!" but it's really not sent because now I've left the coast--your app just lied to me.

Dropbox and iCloud have the same issue. They seem to be accepted by users. It is also possible to get status information telling you if you are fully synced or not.

Re: Hoodie: very fast web app development

#92
post #12

Earlier quoted context omitted.

are you on Windows or Linux? Would be great if you could help us to migrate it. hoodie is basically CouchDB + node.js, nothing fancy. We just do local DNS magic, creating *.dev domains like http://pow.cx/ , that is only compatible with Mac atm

Have you guys seen syncpoint? Although having said that, syncpoint seems to have been removed from github.

It was an old experiment of mine. See upthread for the Couchbase Lite stuff that has replaced it.

Re: Hoodie: very fast web app development

#93
post #90
post #60

Earlier quoted context omitted.

Okay, first off, let's discuss a standard three tier webapp architecture: Browser Server DB You get some HTML/CSS/JS from the server, you display stuff to the user. As the user interacts with your app, HTTP requests hit your server which processes them. As needed, the server will make requests to the DB, which will reply with data, which then gets passed back to the browser. Everyone knows how this stack works, I hop…

Great answer. Tiny nitpick: the next version of TouchDB is called Couchbase Lite. We call it that b/c it is made by Couchbase and is lighter than TouchDB. Couchbase for Mobile is what we call the umbrella (including our Sync Gateway which adds multi-user access control with more scale and flexibility than CouchDB, but compatible with the same sync protocol). Of course it's all open source with a very active community…

Thanks for the correction.

Re: Hoodie: very fast web app development

#94
post #78
post #8

Hey there, other @hoodiehq dev here. Here is a bit longer intro to Hoodie: http://hood.ie/intro.html And a presentation from earlier at @berlinjs including a live demo: https://www.youtube.com/watch?v=X3Ttb0BD8pg

Nice presentation. In the description of back end modules, you mention payments as a future capability. What kind of payment service would you be able to work with? (I don't see how you could handle card details in the Hoodie architecture). Thanks.

we definitely won't send any credit card information to a hoodie server. Instead we use a service like stripe, but then receive the payment notifications or errors, which lets us notify the user if payment worked or not.

Re: Hoodie: very fast web app development

#95
post #12

Earlier quoted context omitted.

are you on Windows or Linux? Would be great if you could help us to migrate it. hoodie is basically CouchDB + node.js, nothing fancy. We just do local DNS magic, creating *.dev domains like http://pow.cx/ , that is only compatible with Mac atm

I'm on windows 8 primarily, but I also run osx and mint. I'm going to check this out on osx first, if all is good, I can help ensure windows compatibility.

that's great, thanks!

Re: Hoodie: very fast web app development

#96

Earlier quoted context omitted.

hi 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…

"Moment of clarity" is a great cue. To me, Hoodie is enormously empowering (which is why I'm part of the Hoodie team). As a self-taught, non comp-sci frontend dev with a humanities degree I can get all the backend/DB stuff sorted, definitely, but I'd actually rather not. It's difficult and occasionally arcane. I don't enjoy it. And, let's face it, I can make terrible mistakes. With Hoodie, I can quickly build apps by…

> on a solid, proven base

[Citation Needed]

Re: Hoodie: very fast web app development

#97
post #81

I know everyone hates that question.. (I hate it too), but what about non-js users or, maybe more importantly, SEO or crawlers? Honestly, this is what is holding me back to go pure client-side for most of my projects.. I know there's the phantomJS server-side hack but how does that work in practice? Also, something else that really trouble me with javascript client-side is that, often, when something bugs, everything…

> but what about non-js users or, maybe more importantly, SEO or crawlers

Hoodie is more of a tool for applications, with user authentication etc, so SEO is not relevant here. I wouldn't build a public website with Hoodie.

> Also, something else that really trouble me with javascript client-side is that, often, when something bugs, everything just stop working

Yes. That's something we have to handle if we want dynamic web apps build on web technologies. But there are great tools today that help you 1. prevent JavaScript by automated testing in all the browsers / OS 2. track JavaScript errors, e.g. with errorception. And 3. todays browsers are more relaxed about errors, they try to continue running the app, even if one function errored out.

> Is there a better solution than a hard-refresh? Would a first-level try/catch solve this problem

If you can keep the state of an app and store user's data immediately, there is no big problem to reload the page, I do that in several occasions at minutes.io, the user usually doesn't realize, it's very fast.

Re: Hoodie: very fast web app development

#99

Very cool :). A few questions. What is the strategy is for concurrent modification of data? What are the consistency guarantees for the sync operation?

In the current implementation, CouchDB takes care of it. In case of a conflict, both versions are kept, with one winner. The other version can be recovered and the conflict resolved, both automatically with a worker process or by the user.
Post reply on HN