Why I chose Clojure/CouchDB for a new site
blog.urbantastic.com
Why I chose Clojure/CouchDB for a new site
1–10 of 35 posts
Re: Why I chose Clojure/CouchDB for a new site
#2Great to see a production site using couchdb. Please keep a running account of how it's working.
Re: Why I chose Clojure/CouchDB for a new site
#3"crowdsourcing and micro-volunteering"? wow.
Re: Why I chose Clojure/CouchDB for a new site
#4Interesting idea, serving all HTML static and combining that on client side with the dynamic content using JavaScript. And having a pure JSON server. Sounds ground breaking to me, anyone know of other sites/frameworks that would work like this?
Re: Why I chose Clojure/CouchDB for a new site
#5Interesting idea, serving all HTML static and combining that on client side with the dynamic content using JavaScript. And having a pure JSON server. Sounds ground breaking to me, anyone know of other sites/frameworks that would work like this?
No, but I've head a suspicion for a while that something like Erlang could actually be useful for doing web stuff if, instead of doing much in the way of templates (Erlang is not fun for strings, IMO), it concentrated on sending and receiving JSON.
Re: Why I chose Clojure/CouchDB for a new site
#6[deleted]
Re: Why I chose Clojure/CouchDB for a new site
#7This is very interesting, but I'm wondering what the cost to users is by pushing most of the computation down to their browser? Certainly, for most of us here, that's not an issue, but what about the person running an older desktop without much processing power and/or RAM?
Re: Why I chose Clojure/CouchDB for a new site
#8All the HTML in Urbantastic is completely static. All dynamic data is sent via AJAX in JSON format and then combined with the HTML using Javascript. Put another way, the server software for Urbantastic produces and consumes JSON exclusively. HTML, CSS, Javascript, and images are all sent via a different service (a vanilla Nginx server).
Wait ... so if he wants to populate the static HTML with information from a database, the client side javascript has to access the database directly? And his database is internet accessible/viewable? That seems bad ...
Re: Why I chose Clojure/CouchDB for a new site
#9Interesting idea, serving all HTML static and combining that on client side with the dynamic content using JavaScript. And having a pure JSON server. Sounds ground breaking to me, anyone know of other sites/frameworks that would work like this?
"serving all HTML static and combining that on client side with the dynamic content using JavaScript"
So baked into this is lack of support for clients without javascript.
I guess I understand if this is a conscious lack of support for the many lynx/noscript/etc users out there (I'm not going to do that myself and so the architecture is not an option).
But what about search engine crawlers, hasn't javascript + search always been an issue?
Re: Why I chose Clojure/CouchDB for a new site
#10All the HTML in Urbantastic is completely static. All dynamic data is sent via AJAX in JSON format and then combined with the HTML using Javascript. Put another way, the server software for Urbantastic produces and consumes JSON exclusively. HTML, CSS, Javascript, and images are all sent via a different service (a vanilla Nginx server). Wait ... so if he wants to populate the static HTML with information from a datab…
No, presumably the client clicks on something, which calls an action on his server via xhr, which does some server-side logic (say, update the cart and compute a new total) and returns a json packet, which the client then uses to update the page.
Without knowing the specific details, I'd imagine the json response has directives for what static html to load if needed, which results in more xhr requests to get those files. The client side js simply needs to know how to process the json it's given, it doesn't need to know any business/persistence info.
What I'm curious about is how he handles urls (if everything is xhr, then the url will always stay the same, which is kind of a pain for linking to specific stuff, unless you do anchor workarounds like Facebook does). Also, I'd be curious if he uses the static html files as templates (injecting data into them clientside) or just has a TON of tiny html fragments.