Unless your web application happens to actually be a series of <form>s, your JavaScript probably starts to become your content. To use an example from today, how would one go about building this without JavaScript? Without losing the heart of it in the translation to static HTML?
exactly! why should we have that visualization be backed by a html table within the page? Especially when you probably have that data backed by an API anyway that could probably server up json, xml or whatever else.
Why? Because not everybody is a human with 20/20 vision sitting in front of a monitor.
Before I go off on to much of a rant, I do want to clarify - having the javascript be the content is fine for a special 'once off' page like the one in the grandparent post. In this case its probably replacing a flash animation. Its also fine for applications where you have a tight handle on the people and devices which will use it.
However as a general practice its a bad idea. A few very important cases that this breaks:
* The googlebot and archive.org
* Vision impaired users
* Services such as readability and instapaper
All of these could be better served by having a symantec table of data, which is then then enhanced and presented in a different manner by javascript.
I can't believe you're being downvoted, this is exactly why progressive enhancement can't be abandoned. As someone with poor vision, I've found most of the crap HN thinks is 'cute' to be completely unusable. The modern web is a huge pain to use, it was actually /better/ in 2005 than it is now, from a usability perspective. This is very scary, considering the renewed emphasis on good UI/UX.
The saving grace is that the 2012 internet has excellent mobile sites (they suck on mobile with user-scalable=0 or maximum-scale=1, but on a desktop browser things flow excellently).
Sadly you're sane understanding doesn't jive with the HN echo chamber, but you're spot-on. The web is more than just tech demos.
Good points but I don't think witholding progress to support these services is a good idea.
The solution is to come up with best-practices and tools that allow both interactive and static versions to exist in tandem, with minimal overhead.
Catering to lowest common denominator means technology, for all humans, lags behind. This is a massive issue. Either the tools for consuming static content (e.g. google bot) need to evolve to embrace the modern internet, OR we need to produce simple tools for dynamic sites that transparently serve the static content for services that require it.
That said, there's a lot of simple elegance in a straight html page.
You’re talking about “content” sites rather than interactive applications.
It doesn’t make any sense to present a chat client or a multiplayer game or a data driven map or a vector drawing program as a set of hyperlinked pages. Googlebot, archive.org, instapaper, etc. wouldn’t really get much useful from such applications anyway.
Unless your web application happens to actually be a series of <form>s, your JavaScript probably starts to become your content. To use an example from today, how would one go about building this without JavaScript? Without losing the heart of it in the translation to static HTML?
http://www.nytimes.com/interactive/2012/02/13/us/politics/20...