Would sproutcore still play nice in a development cycle if I only wanted to use it for a nice shopping cart implementation, but use adhoc javascript everywhere else on a website? The last time I looked at it, it seemed to only excel if you needed to implement one giant js application.
I don't really consider the iframe-style as a valid integration point though. You could technically hide anything inside an iframe. The iframe makes it significantly harder to integrate because all your javascript will essentially need to do cross frame communication type crap just to tell the "other guy" what to do. Plus, depending how you stack your iframes, your inner iframes may not be able to do overlays on your parent frame. Iframes in general is just an ugly hack and should be reserved for actual cross-domain type scenarios.
However, I am looking forward to the ad-hoc style integration if that's possible.
iframe would be the lowest-level of integration. A better solution would allowing a SC app to take over a specific element on the page, and we're definitely looking at that solution.
Another perfectly worthy solution might be to theme the SC app so it looks like your main app.
As would I, as "pushing the data onto the client and using it from there" is by far my biggest issue with Silverlight. I was surprised to see a framework that specialized in doing this.
I wouldn't say sproutcore specializes in pushing data to the client, it really is a 'full stack' client side framework. That said, this is one thing that sproutcore does do quite well, the interface for hooking up to JSON datasources is very simple and effective (particularly useful are cascading data sources, which they've recent added and really cleans up the code where there used to be huge if-else if blocks on queries inside your data source file).
There are a lot of things I don't like about it. But in all honesty my dislike might actually be how RIA Services implemented the approach, not the approach itself. I am currently writing a big blog entry going in to details on this. I'll let you know when it's posted.
I just want to say that I'm psyched to be a new member of the SproutCore community. It's a lot stronger than it looked from the outside, and two of the most exciting features in the 1.4 announcement (GreenHouse and SCXIB) are community projects through and through.
I also can't wait to start rolling out the documentation work we've been working on. If there's one thing we need, it's better documentation, and getting some full-time OSS love is really going to make the difference.
Awesome. Sproutcore project has a lot of potential. I was dabbling with Sencha for some mobile client app work, but with the new touch functionality in SproutCore 1.4, it's taken back my interest.
You're right on about the documentation. As of a few months ago, it seemed very daunting to start a new SproutCore project (especially with the update from 0.9 -> 1.0). A solid doc site (like Rails Guides) and maybe a few paid books / screencast series would go a long way. A good example is AppCelerator, which does a really good job with premium training classes and I think it's really helped them get developers onboard.
The work Charles did a while back on SproutCasts was pretty awesome. Would be great to see more of those.
High on my todo list has been to really learn one of SproutCore or Cappuccino and build something cool with it, but I've been torn between which one to start with.
Initially I was leaning toward Cappuccino, but recent announcements (yours, and Motorola buying Cappuccino) have me leaning toward starting with SproutCore now.
Did you consider Cappuccino at all when making you decision? What's your take on the relative strengths and weaknesses of the two platforms and their communities (if you've dabbled enough in Cap to have opinions on this)?
As someone who learned sproutcore last fall, I found the documentation really lacking, and it hasn't gotten much better since then. Mostly I learned by reading the source code, which fortunately is very clear, but that's too much effort for most people to take.
Regardless, I'm very excited for 1.4. There was so little public progress since 1.0.1042 was released that it seemed as if the project had lost momentum. I'm glad to see that's not the case and that Strobe is pushing ahead to improve things.
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-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.
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.
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?
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).
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/...)
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.
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.
"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.
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.
There is a significant difference between refusing to support progressive enhancement and not getting in the web developer's way of this best practice.
30 comments
[ 4.5 ms ] story [ 51.8 ms ] threadhttp://news.ycombinator.com/item?id=1692675
However, I am looking forward to the ad-hoc style integration if that's possible.
Another perfectly worthy solution might be to theme the SC app so it looks like your main app.
I also can't wait to start rolling out the documentation work we've been working on. If there's one thing we need, it's better documentation, and getting some full-time OSS love is really going to make the difference.
You're right on about the documentation. As of a few months ago, it seemed very daunting to start a new SproutCore project (especially with the update from 0.9 -> 1.0). A solid doc site (like Rails Guides) and maybe a few paid books / screencast series would go a long way. A good example is AppCelerator, which does a really good job with premium training classes and I think it's really helped them get developers onboard.
The work Charles did a while back on SproutCasts was pretty awesome. Would be great to see more of those.
Initially I was leaning toward Cappuccino, but recent announcements (yours, and Motorola buying Cappuccino) have me leaning toward starting with SproutCore now.
Did you consider Cappuccino at all when making you decision? What's your take on the relative strengths and weaknesses of the two platforms and their communities (if you've dabbled enough in Cap to have opinions on this)?
Regardless, I'm very excited for 1.4. There was so little public progress since 1.0.1042 was released that it seemed as if the project had lost momentum. I'm glad to see that's not the case and that Strobe is pushing ahead to improve things.
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-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.
The ability to support your intended audience is still an important factor in building websites.
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).
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/...)
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.
That is the dilemma of progressive enhancement. If you choose to do it, you must either limit your enhancements or support two separate interfaces.
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.