4 ms·

I wonder if there are any examples of SproutCore being used in a decently progressively enhancing way. The last time I looked through, JavaScript disabled/unava

I wonder if there are any examples of SproutCore being used in a decently progressively enhancing way. The last time I looked through, JavaScript disabled/unavailable view was an empty div. Might be strange to pick up the lack of attention on progressive enhancement from a JavaScript library developer group, but take a look at what davglass is doing with YUI and node.js in terms of progressive enhancement (for example http://ajaxian.com/archives/progressive-enhancement-using-nothing-but-javascript http://ajaxian.com/archives/progressive-enhancement-using-no... ). The ability to run the same javascript on the client and the server introduces a powerful new way to do progressive enhancement, this opens up possibilities of taking a very rich interactive application that works decently enough on a constrained platform/network (very much directly aimed at the Sprout Core "we do web applications not websites so we don't have to bother about non-javascript" philosophy at their original launch) The ability to build upon what's already there is important. So a solid approach to progressive enhancment is necessary for any JavaScript library that wants to be anywhere near web developer mainstream.

glhaynes 16y ago
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?
- Isofarro 16y ago
  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.
  - catch23 16y ago
    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.
    - Isofarro 16y ago
      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.
      - frekw 16y ago
        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?
        Isofarro 16y ago
        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/Opera_Mini_App_Store_chart_big.jpg 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.html 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-breaking-apps/ 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).
  - aaronbrethorst 16y ago
    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.
    - Isofarro 16y ago
      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)?
      - frekw 16y ago
        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/thread/6dea15afe9b64e15 http://groups.google.com/group/sproutcore-dev/browse_thread/...)
mhd 16y ago
I've yet to see a site that depends on JavaScript heavily and degrades well. I think in this case you're much better of making secondary interface in pure HTML, cf. GMail. You could also make some small JQuery (etc.) enhancements to this bare-metal platform. Having something that degrades from full whizbang to dumb terminal is really hard, kinda like getting a desktop application that is fully cross-platform. Sometimes it's better to just use a common backend for separate interfaces.
chc 16y ago
Dav's experiment is interesting, but I don't see how these static pages come anywhere near touching "we do web applications not websites so we don't have to bother about non-javascript". A rich interface simply will not work with its interactivity taken away. Even something as simple as a selection rect fails under such a system. It would require a separate interface, and now we're back to where SproutCore gets us. That is the dilemma of progressive enhancement. If you choose to do it, you must either limit your enhancements or support two separate interfaces.
- Isofarro 16y ago
  "It would require a separate interface, and now we're back to where SproutCore gets us." That's precisely the downside a JavaScript library or application development platform should be seeking to avoid: forcing developers to write two versions of their service - one with SproutCore and one without. In a startup world, I'm surprised that someone on a tight budget can afford this approach and still have a viable minimum product at the end of it.
  - chc 16y ago
    But there is no library or application development platform that avoids the dilemma. It's a very hard problem. It seems unfair to fault SproutCore for not solving a problem that nobody else has made any real headway on.
    - Isofarro 16y ago
      There is a significant difference between refusing to support progressive enhancement and not getting in the web developer's way of this best practice.

glhaynes 16y ago

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?

Isofarro 16y ago
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.
- catch23 16y ago
  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.
  - Isofarro 16y ago
    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.
    - frekw 16y ago
      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?
      - Isofarro 16y ago
        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/Opera_Mini_App_Store_chart_big.jpg 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.html 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-breaking-apps/ 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).
- aaronbrethorst 16y ago
  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.
  - Isofarro 16y ago
    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)?
    - frekw 16y ago
      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/thread/6dea15afe9b64e15 http://groups.google.com/group/sproutcore-dev/browse_thread/...)

mhd 16y ago

I've yet to see a site that depends on JavaScript heavily and degrades well. I think in this case you're much better of making secondary interface in pure HTML, cf. GMail. You could also make some small JQuery (etc.) enhancements to this bare-metal platform. Having something that degrades from full whizbang to dumb terminal is really hard, kinda like getting a desktop application that is fully cross-platform. Sometimes it's better to just use a common backend for separate interfaces.

chc 16y ago

Dav's experiment is interesting, but I don't see how these static pages come anywhere near touching "we do web applications not websites so we don't have to bother about non-javascript". A rich interface simply will not work with its interactivity taken away. Even something as simple as a selection rect fails under such a system. It would require a separate interface, and now we're back to where SproutCore gets us. That is the dilemma of progressive enhancement. If you choose to do it, you must either limit your enhancements or support two separate interfaces.

Isofarro 16y ago
"It would require a separate interface, and now we're back to where SproutCore gets us." That's precisely the downside a JavaScript library or application development platform should be seeking to avoid: forcing developers to write two versions of their service - one with SproutCore and one without. In a startup world, I'm surprised that someone on a tight budget can afford this approach and still have a viable minimum product at the end of it.
- chc 16y ago
  But there is no library or application development platform that avoids the dilemma. It's a very hard problem. It seems unfair to fault SproutCore for not solving a problem that nobody else has made any real headway on.
  - Isofarro 16y ago
    There is a significant difference between refusing to support progressive enhancement and not getting in the web developer's way of this best practice.