HN Explorer

Ask HN: Is unobtrusive javascript/gracefully degradation important anymore?

11 points by ashchristopher ↗ HN
Twitter's new interface doesn't degrade gracefully (thought they do link to old twitter). What are the communities thoughts on this subject? I am working on a project and I spend 60% of my front-end time making sure that it works without JS even though I have every intention of it being used with JS enabled? Is it a waste of time? Should I focus on releasing the product and to hell with degrading gracefully?

8 comments

[ 3.0 ms ] story [ 34.2 ms ] thread
CPops
Devoting such a significant percentage of your time and resources to what likely amounts to less than 1% of your users doesn't sound like a wise business decision in most circumstances.
homecoded
I'd say this is about right. Even mobile devices have great JavaScript abilities nowadays. Think Android or iPhone. I am still using an ancient Sony Ericsson with Opera Mini and JavaScript works surprisingly well.

Besides, I like you attitude. Making stuff work for everyone is a great and noble goal! Unfortunately, that's only worth your time if your goal is to learn, not to earn money.

kls
I second this, we actually did significant research on this at our firm and the reality is developing JavaScript based UI's reduces UI development effort significantly, there are several factors that contribute to this from an event based programming model, to not having to transfer state between layers. Sufficient to say a white paper could be written on that subject alone.

Anyway, progressive enhancement kills all of the advantages of JavaScript application with the exclusion of more advanced UI features and simulated responsiveness. None the less, rather than reducing or evening the development cost burden with server side web development, it actually increased it because all of the server side development must be done and then a client side framework must be bolted on top of it. It is quite honestly the worst of both worlds because it spikes the complexity of the solution.

The numbers that we gathered in our research and post mortums of projects supports the conclusion that it is actually more cost effective to build two independent UI's one JavaScript UI and a reduced feature set server side based UI and route client to each according to capabilities.

Further, for many client the monetary outlay of developing the server side UI to support the < 1% client base that could not use a JavaScript UI was more than would ever be recouped for the investment.

In one of the analysis that we did it was actually cheaper to send the clients that did not have access to a supported JavaScript compatible browser a new machine than to spend the development effort to build out an independent system.

In all cases a better business case could be made for spending those development funds on alternative platforms like iPhone / Android / mobile client or IVR systems.

The segment of the market that cannot access JavaScript based applications is a very small segment and it is dwindling every day. For most web applications a business case cannot be made for progressive enhancement to chase this segment; especially when alternative platforms are added to the analysis. In almost all cases the time and money was better spent chasing those non-web segments for growth.

Please note this information is specifically related to web applications (web-based desktop application replacements) and not web sites like a news site. Web Apps are my companies specialty and we don't build web sites so none of this info should be construed as advice for article oriented web sites. Put simply, I do not know that these conclusions would hold true for building something like HN, they are true for building something like Salesforce.com.

blahedo
Yes it's important, no it's not a waste of time. Aside from the people who intentionally turn off JS in their browser, there are people with readers or other interfaces that don't support JS (or, not well), and most bots trying to crawl and find and possibly link to your content are going to behave, at best, unpredictably in the face of a JS-heavy site.
grok2
I think, yes, for content oriented sites (seo benefit, helps to allow people to continue to view content, etc), but if it's an app/utility site, I think there is no point in adding to your workload...
ashchristopher
In this case, it is an app site. I was sorting thinking along the same idea.
kls
I would assume for a content oriented site the most optimal development path would be a CMS as opposed to custom development. Something like Drupal or Wordpress is going to give you a significant time to market advantage over developing a site in either a server side or client side framework.
bmelton
I suppose I'm in the minority here, but at least the way I build applications, I build in the 'vanilla' way first and foremost.

Submissions go to another page, as do clicks and all that jazz. It's quicker for me to get the MVP up and running first, and then later add the JS niceties.

Obviously, there are use cases where this is flipped around -- mapping, for example, and I'm sure many others -- but at least for me, I don't understand why it's even a hardship to make it work for nonJS users, as that's what I always build first.

Workflow aside, you're probably right, at least for end users. Almost every device worth supporting out there is 'modern' enough that they support jQuery, Dojo, et al.

The real trick is of course the other important devices that aren't users. Search engines. Crawlers aren't necessarily capable of following your application flow without graceful degradation, and in this day and age, that likely matters as much or nearly as much as actual users.