Hacker News new | past | comments | ask | show | jobs | submit login

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?



There are other causes of JavaScript not being run in a browser than a visitor turning JavaScript off. A mobile phone running off a flaky 3G network is still a common issue outside of Silicon Valley.

The ability to support your intended audience is still an important factor in building websites.


From reading complaints about AT&T and the iPhone from people in/near San Francisco, I'd say a mobile phone running off a flaky 3G network is a common issue inside of Silicon Valley.

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.


Okay, lets try a question closer to Sproutcore's "build rich applications that happen to run inside of a browser" approach: Can we see some decent examples of Sproutcore applications that interact well with assistive technologies (specifically screen readers)?


Well, it utilizes WAI-ARIA for most (if not all) controls which is really all it can do.

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/...)


Yes, but if you're targeting mobile devices, you can load them a different set of javascript that would be lighter load on the network. I think it's kind of pointless to use something like Unobtrusive Javascript support because if you're one of those users with javascript disabled, we probably wouldn't want you as our target audience anyway.


Mobile devices here are devices that can connect to the Web over 3G. That's not just mobile phones, but smartphones, tablets (like the iPad), netbooks, and laptops. Heck, I know people who connect to the internet over 3G from a desktop.

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.


I don't understand your 3G argument. I use 3G to connect to the Internet from my desktop for various reasons, and I've used plenty of SC apps via that connection.

Isn't this really a problem solved by the HTML5 offline application cache?


Patchy 3G coverage in areas is just one example of where a browser that's fully capable of running the latest JavaScript whizzbangs, yet still finds itself in a situation where it doesn't have any JavaScript to run.

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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: