Comment by shawnz | Hacker News Reader

Comment by shawnz | Hacker News Reader

This author is making an assumption that progressive enhancement exists only so that people who are browsing without Javascript can have a better experience. Of course, this isn't true. Progressive enhancement is a good thing because it encourages you to be as descriptive as possible at every layer of your technology stack.

Why does it matter in practice? Well, there's more than one reason, but consider that not every user agent is a browser with a person sitting in front of it. Your website also should be interpretable by content indexers like search engines, accessibility devices like screen readers, and so on.

Some services don't fit this model and really are better off being designed like desktop applications written in HTML and JS. But in my experience, most services can be modelled more like websites without making the design any more difficult to reason about, and almost all users' experiences are bettered by it.

First, the accessibility argument is a red herring that I'm getting frustrated people continue to try to throw around. Screen readers support JS, okay? Let's put this argument to bed.

http://words.steveklabnik.com/emberjs-and-accessibility

Okay, thank you for letting me get that off my chest.

Second, one nice thing about "embracing 100% JavaScript" that I talk about in the post is that it requires you to implement a really solid JSON API, because your web site is now a true client that consumes an API. This makes it really easy to integrate with third-party services that consume your content. I agree that putting content behind JavaScript sucks; I'm just advocating that the content be JSON (or some other normalized format), not HTML.

"I agree that putting content behind JavaScript sucks; I'm just advocating that the content be JSON (or some other normalized format), not HTML."

Ah, so don't put it "behind JavaScript", but put it in a format that a browser can't natively handle in a sane way. And use a grab-bag general object format instead of one that has built-in semantic definitions that are be useful in a document context, like, idunno, <strong> <em> <p> <a> ?

Also, I've very rarely (if ever) seen something I'd describe as a "solid JSON API".

Can you give an example of one of your sites with a "really solid JSON API"? I'm afraid there's a gap in this definition, as good APIs are rare and good JSON APIs with a single client are virtually non-existant.

Here's Bustle's: http://www.bustle.com/api/v1/sections/home.json

It needs run through a pretty-iffier, of course, but seems straightforward to me.

Reply on news.ycombinator.com