Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I chose Clojure/CouchDB for a new site

blog.urbantastic.com

Post reply on HN
Print view View original

21–30 of 35 posts

Re: Why I chose Clojure/CouchDB for a new site

#21

Post by icey »

patio11 wrote: post #20
icey wrote: post #11

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

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

Maybe the question should be "What happens if javascript is disabled?".

I do think that it's important today because there are still web browsers, especially in the mobile space, where people will not have javascript or more specifically AJAX available.

I think it's especially pertinent when talking about social anything kind of sites, where people are going to be likely to try to access it from a mobile device.

I don't see it as an issue of responsibility as much as I see it as a customer service issue.

Re: Why I chose Clojure/CouchDB for a new site

#22

Post by liminalist »

patio11 wrote: post #20
icey wrote: post #11

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

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

As long as you're fine with web crawlers not seeing your content, people not building mashups based on your HTML, and so forth, be as much of a heartless bastard as you want. But do keep in mind that Googlebot is the biggest disabled user in the world. If blind people can't see it, search engines can't see it. And if search engines can't see your website, who cares about you?

Re: Why I chose Clojure/CouchDB for a new site

#23

Post by neeson »

icey wrote: post #11

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

Author here. Here's the relevant line in the post:

"[..]web browsers are not the only clients that will use Urbantastic. Mobile devices, search engine spiders, screen readers for people with disabilities, and RSS readers all need the same data but in different forms. Accommodating any of these is simply a matter of dropping a different rendering front-end in front of the common JSON data server."

It's not up yet, but I'm working on a front end intended for non-javascript users. It will also serve blackberry users, IE6 users, and spiders.

It will be a /much/ simpler site, but you'll be able to get everything done on it. I figured it's easier to separate it out than try to shoehorn every use into one format.

The general principle is that I'm going to design for the large majority of the users - and use Javascript capability I can to make it an excellent experience. Then create a simplifed mirror for the minority uses. Gmail took this route and I think it's worked well for them.

Re: Why I chose Clojure/CouchDB for a new site

#24

Post by neeson »

Xichekolas wrote: post #10
smanek wrote: post #8

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

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

Which the server ignores, but the Javascript parses and uses to figure out where it is.

Re: Why I chose Clojure/CouchDB for a new site

#25

Post by neeson »

smanek wrote: post #8

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

There's a layer (written in Clojure) between the client and CouchDB which does authentication, permissions, etc.

Re: Why I chose Clojure/CouchDB for a new site

#26

Post by icey »

neeson wrote: post #23
icey wrote: post #11

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

Author here. Here's the relevant line in the post: "[..]web browsers are not the only clients that will use Urbantastic. Mobile devices, search engine spiders, screen readers for people with disabilities, and RSS readers all need the same data but in different forms. Accommodating any of these is simply a matter of dropping a different rendering front-end in front of the common JSON data server." It's not up yet, but…

Bizarre. Everything from "The Language" down wasn't there when I read this earlier. I guess I must have been having connection problems.

Anyways, thanks for following up - this is a great way to handle clients without Javascript.

Re: Why I chose Clojure/CouchDB for a new site

#27

Post by tdavis »

neeson wrote: post #23
icey wrote: post #11

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

Author here. Here's the relevant line in the post: "[..]web browsers are not the only clients that will use Urbantastic. Mobile devices, search engine spiders, screen readers for people with disabilities, and RSS readers all need the same data but in different forms. Accommodating any of these is simply a matter of dropping a different rendering front-end in front of the common JSON data server." It's not up yet, but…

So you've taken the idea of progressive enhancement and reversed it? Zeldman would be rolling in his grave... if he were dead, anyway. I've always found it easier to go the other way: make a site that works on everything, then just add bells, whistles, and enhancements with Javascript as you feel compelled to do so. Doing it this way, I find places I was going to use pure JS where there was no real value-add to it.

Re: Why I chose Clojure/CouchDB for a new site

#28

Post by Xichekolas »

neeson wrote: post #24
Xichekolas wrote: post #10

Earlier quoted context omitted.

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

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

Ah, yeah it'd make much more sense to have all the html handy at once instead of requesting them one at a time.

So in the case of that link... org.html has all the html fragments it needs for anything that can be done on that page in a hidden div?

A neat idea for sure, thanks for sharing... (now off I go to play with it!)

Re: Why I chose Clojure/CouchDB for a new site

#29

Post by teej »

liminalist wrote: post #22
patio11 wrote: post #20

Earlier quoted context omitted.

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

As long as you're fine with web crawlers not seeing your content, people not building mashups based on your HTML, and so forth, be as much of a heartless bastard as you want. But do keep in mind that Googlebot is the biggest disabled user in the world. If blind people can't see it, search engines can't see it. And if search engines can't see your website, who cares about you?

There is a world of difference between blind people using your site versus search engines reading your site.

Re: Why I chose Clojure/CouchDB for a new site

#30

Post by Hexstream »

patio11 wrote: post #20
icey wrote: post #11

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

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

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

You don't have to "fake the presence of comparable functionality" (and in most cases you simply can't).

What you can and should do is support the subset of functionality raw HTML and CSS sans Javascript can achieve. No one will blame you for not supporting highly dynamic features that can't possibly be achieved without javascript without javascript.

Post reply on HN