It seems like "ability to run JavaScript" is as much a core requirement of a browser as "ability to render HTML" at this point. Are users with JavaScript turned off really worth targeting?
The ability to support your intended audience is still an important factor in building websites.
That said, Sproutcore lets you build rich applications that happen to run inside of a browser. If an app's requirements include "Mac OS X 10.5 or later," then I need to run on it on a Mac. Civilization V requires a discrete graphics card; I won't have much luck running it on a Netbook. And, Sproutcore apps require Javascript.
The rest is up to the implementers of assistive technologies, in my opinion. If you want to be able to build rich, themeable interfaces you will end up having to re-implement "standard" controls like buttons, scrollbars and checkboxes. As far as I know, the ability to actually use native controls is actually being considered for SC 2.0 (read more here: http://groups.google.com/group/sproutcore-dev/browse_thread/...)
Building a different set of JavaScript because it's running over a 3G network seems a weird approach. I would have thought it would be more logical to build a website that works in the context of a Web, rather than an over-simplified view of it.
Isn't this really a problem solved by the HTML5 offline application cache?
At this point, the browser has no choice but to fallback to an HTML only state (or perhaps an HTML+CSS state). The times when this happens is out of our control, and it will never be in our control.
How you do that, is your choice. Other people can continue along the route of "they are not my audience" either until their audience drops to zero, or someone slaps a discrimination lawsuit on them.
Flaky 3G connections are just one example of factors outside a web developer's control. But there are many others.
Consider this: Opera mini is essentially a proxied browser. A server takes a static snapshot of a page and sends it on to Opera mini. No-one in their right mind would need such a locked down browser on their mobile devices. Especially not on an iPhone running Mobile Safari. And yet we have this: http://www.funkyspacemonkey.com/wp-content/uploads/2010/04/O... -- Opera Mini being the top Free App on the Apple iPhone Appstore in _20_ countries simultaneously.
Consider how SproutCore deals with 'offline storage' in a browser that doesn't currently support HTML5's local storage. I'd bet they follow dojo and use a series of fallbacks, and one out of that series is using a 1x1 pixel Flash app that has the ability to write to the local filesystem. Piece of cake, right?
Yet when we have something like this: http://www.adobe.com/support/security/advisories/apsa10-03.h... Big corporate organisations, and potentially big governmental organisations do stupid stuff like this: http://www.webstandards.org/2006/04/03/script-blockers-break... (Their proxies drop JavaScript that does any dealings with Flash).
So with good development best practice, the loading of the one monolithic JavaScript file gets silently aborted, and you get a page of just HTML and CSS.
We do not control the web environment. And that's what makes me weary of conceptions like SproutCore - their inability to adapt to the web environment as it is today.
(Offline application caching is no use when the cache is empty - that's a normal state of affairs when you first enter an application in one specific browser).