12 ms·

Why I chose Clojure/CouchDB for a new site

81 points by neeson 18y ago

geuis 18y ago
Great to see a production site using couchdb. Please keep a running account of how it's working.
herval 18y ago
"crowdsourcing and micro-volunteering"? wow.
asmosoinio 18y ago
Interesting 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?
- davidw 18y ago
  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.
- timf 18y ago
  "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?
  - Zak 18y ago
    I think something like this is a better fit for something more application-like and less web page with dynamic content. I suspect Google will eventually start supporting Javascript as this sort of design becomes more popular.
    - patio11 18y ago
      I suspect Google will eventually start supporting Javascript as this sort of design becomes more popular. The future started more than two years ago, actually. You can experimentally verify it for yourself -- my understanding is that they use a combination of heuristics and actual evaluation. For example, putting an invisible div on your web page stuffed with keywords is usually a one way trip to smackdown city. Put an invisible div on your web page and make it visible in response to pushing a button and they will index the content much of the time. They are known to spend extra resources to make sure popular techniques do not cause their algorithms to break. (From a SEO perspective I'd suggest being one step behind the cutting edge on innovations like that. 100% JSON site? Cutting edge, probably uncrawlable. Shopping cart rendered using Prototype? Works fine.)
- jamesbritt 18y ago
  Hoodwink.d used this idea http://redhanded.hobix.com/-h/hoodwinkDDayOneForcingTheHostToAttendTheParty.html http://redhanded.hobix.com/-h/hoodwinkDDayOneForcingTheHostT... And there was another framework that did essentially the same thing, using DHTML and AJAX to create the page from a blank slate. But I cannot recall the name.
- anr 18y ago
  Apparently it is a trend with FP guys :-) HAppS (a Haskell framework) has also advocated this: "HAppS does not come with a server-side templating system. We prefer the pattern of developing static web pages and using AJAX to populate them with dynamic content." http://happs.org/ http://happs.org/
deleted 18y ago
[deleted]
bmj 18y ago
This 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?
- Xichekolas 18y ago
  Probably just a judgment call he'd have to make about his users, but your machine would have to be pretty old and slow to not be able to manipulate the few kilobytes of text that is a typical web page.
smanek 18y ago
All 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 ...
- Xichekolas 18y ago
  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.
  - smanek 18y ago
    Makes much more sense. Thanks
  - neeson 18y ago
    So far, all the HTML that a given page will need is part of the same document. The templates for the dynamic content are all stored inside a hidden div. I expect that eventually this will cause too much of an up-front load time, so I'm planning on having the JS load bundles of it on demand. Reducing total HTTP requests is a big usability win, in my experience. To answer your URL question, I use attributes, like this: http://urbantastic.com/org.html?id=org-8srmt85mtf8t http://urbantastic.com/org.html?id=org-8srmt85mtf8t Which the server ignores, but the Javascript parses and uses to figure out where it is.
icey 18y ago
So if the user has javascript disabled, nothing on the site works?
- peregrine 18y ago
  IMO people who disable javascript might as well just use lnyx or something. Javascript is the current and future web and nothing is going to change that so get over it.
  - icey 18y ago
    Any Blackberry released before the Bold does not come with AJAX support. I'm going to go out on a limb and say that maybe they should think about how the site will work without Javascript.
  - kragen 18y ago
    You're not familiar with TimBL's Principle of Least Power, I see. The majority of the web pages I visit work fine without JavaScript (I use the NoScript extension) and they look a lot better in Firefox than in lynx, or even links.
- patio11 18y ago
  The costs of supporting clients with disabled Javascript increases constantly. As Javascript frameworks get increasingly feature-rich, regular users expect more out of their Internet experience, and development techniques mature, it gets easier and more mandatory to do more in Javascript and harder and more expensive to fake the presence of comparable functionality using HTML, forms, etc. The revenue generated by supporting clients with disabled Javascript is not increasing at nearly the rate support costs are. I know many technically apt people get up in arms over this, but there comes a point where going into your browser settings (which 99%+ of users will never do), scrolling down to the section marked I Hope You Know What You're Doing, and unchecking boxes means you are affirmatively opting for a second-class experience. I know the rejoinder: "Blind people can't use your site, you heartless bastard!" It is highly likely that my site and software will be suboptimal to them. It is also highly likely that my site and software will be suboptimal to people who, through no fault of their own, are illiterate. Both of these are tractable issues if someone wants to throw sums of money which are many multiples of my budget to fixing them. I have yet to hear a good reason for why that someone must be me. [Edit to clarify: this is not specifically related to the site I have in my profile, but it could be very easily.]

81 points by neeson 18y ago

geuis 18y ago

Great to see a production site using couchdb. Please keep a running account of how it's working.

herval 18y ago

"crowdsourcing and micro-volunteering"? wow.

asmosoinio 18y ago

Interesting 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?

davidw 18y ago
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.
timf 18y ago
"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?
- Zak 18y ago
  I think something like this is a better fit for something more application-like and less web page with dynamic content. I suspect Google will eventually start supporting Javascript as this sort of design becomes more popular.
  - patio11 18y ago
    I suspect Google will eventually start supporting Javascript as this sort of design becomes more popular. The future started more than two years ago, actually. You can experimentally verify it for yourself -- my understanding is that they use a combination of heuristics and actual evaluation. For example, putting an invisible div on your web page stuffed with keywords is usually a one way trip to smackdown city. Put an invisible div on your web page and make it visible in response to pushing a button and they will index the content much of the time. They are known to spend extra resources to make sure popular techniques do not cause their algorithms to break. (From a SEO perspective I'd suggest being one step behind the cutting edge on innovations like that. 100% JSON site? Cutting edge, probably uncrawlable. Shopping cart rendered using Prototype? Works fine.)
jamesbritt 18y ago
Hoodwink.d used this idea http://redhanded.hobix.com/-h/hoodwinkDDayOneForcingTheHostToAttendTheParty.html http://redhanded.hobix.com/-h/hoodwinkDDayOneForcingTheHostT... And there was another framework that did essentially the same thing, using DHTML and AJAX to create the page from a blank slate. But I cannot recall the name.
anr 18y ago
Apparently it is a trend with FP guys :-) HAppS (a Haskell framework) has also advocated this: "HAppS does not come with a server-side templating system. We prefer the pattern of developing static web pages and using AJAX to populate them with dynamic content." http://happs.org/ http://happs.org/

deleted 18y ago

[deleted]

bmj 18y ago

This 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?

Xichekolas 18y ago
Probably just a judgment call he'd have to make about his users, but your machine would have to be pretty old and slow to not be able to manipulate the few kilobytes of text that is a typical web page.

smanek 18y ago

All 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 ...

Xichekolas 18y ago
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.
- smanek 18y ago
  Makes much more sense. Thanks
- neeson 18y ago
  So far, all the HTML that a given page will need is part of the same document. The templates for the dynamic content are all stored inside a hidden div. I expect that eventually this will cause too much of an up-front load time, so I'm planning on having the JS load bundles of it on demand. Reducing total HTTP requests is a big usability win, in my experience. To answer your URL question, I use attributes, like this: http://urbantastic.com/org.html?id=org-8srmt85mtf8t http://urbantastic.com/org.html?id=org-8srmt85mtf8t Which the server ignores, but the Javascript parses and uses to figure out where it is.

icey 18y ago

So if the user has javascript disabled, nothing on the site works?

peregrine 18y ago
IMO people who disable javascript might as well just use lnyx or something. Javascript is the current and future web and nothing is going to change that so get over it.
- icey 18y ago
  Any Blackberry released before the Bold does not come with AJAX support. I'm going to go out on a limb and say that maybe they should think about how the site will work without Javascript.
- kragen 18y ago
  You're not familiar with TimBL's Principle of Least Power, I see. The majority of the web pages I visit work fine without JavaScript (I use the NoScript extension) and they look a lot better in Firefox than in lynx, or even links.
patio11 18y ago
The costs of supporting clients with disabled Javascript increases constantly. As Javascript frameworks get increasingly feature-rich, regular users expect more out of their Internet experience, and development techniques mature, it gets easier and more mandatory to do more in Javascript and harder and more expensive to fake the presence of comparable functionality using HTML, forms, etc. The revenue generated by supporting clients with disabled Javascript is not increasing at nearly the rate support costs are. I know many technically apt people get up in arms over this, but there comes a point where going into your browser settings (which 99%+ of users will never do), scrolling down to the section marked I Hope You Know What You're Doing, and unchecking boxes means you are affirmatively opting for a second-class experience. I know the rejoinder: "Blind people can't use your site, you heartless bastard!" It is highly likely that my site and software will be suboptimal to them. It is also highly likely that my site and software will be suboptimal to people who, through no fault of their own, are illiterate. Both of these are tractable issues if someone wants to throw sums of money which are many multiples of my budget to fixing them. I have yet to hear a good reason for why that someone must be me. [Edit to clarify: this is not specifically related to the site I have in my profile, but it could be very easily.]