1. You recently moved over to work on SproutCore. What is SproutCore?
SproutCore is a framework for developing fast native style applications. It was developed by Charles Jolley five years ago to work on a personal project, but it really gained its power as part of Apple. Charles started working for Apple about three years ago and Apple used this framework to build MobileMe and they really put a huge amount of R&D effort into making SproutCore a really amazing framework for building applications that feel native, but are in the web. Obviously, when you are working for a company like Apple, especially Apple, a lot of things like SproutCore while they may still get releases open source, they don’t build up a strong community.
I think SproutCore had some community, but since Charles left Apple, we’ve definitely been growing the community at a better rate. SproutCore is becoming sort of a more traditional open source project where not every piece of code that’s written has to go through a cumbersome legal and marketing process to vet the code and make sure it’s OK to be released. I think given the constraints of something like Apple, Charles did a pretty amazing job in getting things continually released. If I was there I probably would have given up, frankly, but there is this amazing low level framework for building fast native applications that just need some polish.
So, part of the reason why I moved over to work on SproutCore is that I think I’m pretty good at developer usability and in my view, SproutCore is pretty amazing in terms of what it can do, just go look at MobileMe to see what it can do. A lot of work has gone into mobile and touch and all this stuff, but the getting started on-ramp experience that Rails is famous for, just isn’t there in SproutCore. I’m going to be spending a lot of my time making that on-ramp better but with the acknowledgment that a lot of what’s already there is pretty amazing.
2. How does SproutCore address some of the current challenges of mobile development?
Probably, if you’ve done any mobile development, what you’ll note is that while the browser is very powerful and has a lot of features, a lot of those features are available in very raw form and it’s very hard to avoid tripping over landmines in terms of performance. Doing one little thing wrong, can suddenly make your app extremely slow. What SproutCore does to make this better is it is very aggressive about controlling what goes on a page, when, how. It takes some features from the Cocoa ideology in terms of this concept called the RunLoop, in terms of making things happen, sort of in batches as opposed to as you go.
What SproutCore really does is it takes the real world experience of Apple and in building MobileMe and iWork.com and brings that to you as a developer. So it gives you a better wrapper for a lot of the features like touch events, like hardware acceleration and actually hardware acceleration is really the difference between a mobile application’s animations feeling almost disgusting and feeling almost desktop-like. What Apple and now, I think, Android have done is they’ve exposed hardware acceleration to you through the web API and so it’s very possible to build things that look smooth, that feel good, that feel like they would on a desktop on a mobile device.
But if you don’t use those features the application feels bad and what SproutCore has done is do all the research that you would have to do to make this stuff feel good. Actually I’m happy to say I just released today a post on the SproutCore blog. We’re going to be taking a lot of this stuff and re-releasing them for people who are not necessarily ready to take the leap and do this full SproutCore. Things like our core object system, our bindings, our data store and maybe even our animations so that you can use this in a regular jQuery app and then when you’re ready to go default way, you can use SproutCore.
But I would say that to get the benefit of something that feels fast, that feels native, you need to give up control of your application to something that is going to be smart about what it does. Just because there are too many landmines in the possibility of one errant command to the browser causing severe havoc is much higher in mobile than it is on desktop. It’s even there on desktop, but it’s worse in the mobile device and it’s worse as you build more complex things. It’s actually pretty easy if you build a simple thing to do the right thing, you can test, you can get aggressive.
But when you build something that’s like an iPad with a lot of UI with a lot going on with animations it starts to get really easy to make mistakes. One good example is hardware acceleration - it’s great, you should turn it on, you should use hardware acceleration. But in some cases too much hardware acceleration could become a problem; the GPU could be not good enough at pushing pixels. So, if you do hardware acceleration on everything that becomes a problem. SproutCore has this feature called "wants accelerated layer" where you could say "This little area here try to be hardware accelerated if you can."
We do the work of figuring out if it’s the right thing to do to give it hardware acceleration or not, depending on what else is going on on the page. First of all I think it’s pretty cool that this API like essentially scrollability without having to do anything will work with acceleration and without acceleration, but second of all, it just goes to show that whether or not you can do something that seems obvious, actually turns out to be a little tricky sometimes. That’s why it’s called "wants accelerated layer" instead of "has accelerated layer." You are leaving it up to the SproutCore engine to figure it out and that turns out to be very important.
It sort of goes against the way a lot of people think about applications, which is they are directly touching the DOM all the time, but not doing that, giving up that control really makes your applications perform better and feel better. It’s something that I think people will have to get used to, but it’s something that it’s worth it.
3. What is planned for SproutCore 1.5 and when is it expected to arrive?
I’ll tackle the expected arrival: probably not this year, probably sooner after. A lot of the work to go onto 1.5 is already done. Probably the most important things in 1.5 are the mobile things - better support for touch events, performance improvements on touch events, better support for hardware acceleration. There is a new theme called Ace2, which is shipping with SproutCore 1.5 which includes better mobile experience, things like bigger buttons for mobile. Strobe, which is the company I work for that does a lot of the SproutCore work has been doing a lot of work on mobile devices and the lessons learned from that are getting into 1.5.
I would say 1.5 is the mobile release. What’s really cool about SproutCore is that a lot of the core ideas of SproutCore make sense in the mobile context, so for instance, having fixed position top and bottom because of the way we already do that in desktop, it was easy to work on mobile. Then, once we got scrolling in, you can tell a view "This view is scrollable" and then it will use either hardware acceleration if possible or not if it’s not possible or work on the desktop. Even though SproutCore today doesn’t have the mobile theme and the mobile widget set which something like Sencha might have, SproutCore has a lot of the lessons from years and years of building desktop-like applications already built in.
That’s really making the difference for us in our projects. We’ve been doing a lot of work on high profile mobile applications and we’re able to do a lot because of the fact that SproutCore already has a lot of this stuff built in. What I’m looking forward to is being able to work on that "Hello, world" experience so that people come in for the first time and they ramp up well and people who just want to build a quickie website, they just need some native widgets, make that work. That’s what SproutCore’s missing today.
I think if you look at all the frameworks, SproutCore is by far ahead in terms of performance, in terms of what we do for you to abstract you from the browser’s problems. But it’s missing a lot of the widgets and a lot of the polish that you would expect from the top levels. I don’t mean "polish" in terms of how it works internally, I mean developer usability.
One really good thing about doing that is that we can be, like I said, a lot more aggressive about tamping down something that might be really good if you don’t have a lot going on. You might reduce hardware acceleration, or you might reduce the frame rate or something, once you start getting a lot more going on. The extent to which we do that is different in different areas, but it gives us the ability to notice that something is going on and make a change to the runtime that gets everybody better performance without making everybody have to change their application. I think that’s probably the most powerful thing about SproutCore is that you’re sort of describing how your application should work in GUI terms and we’re doing the underlying work to make it work.
Actually the browser is not very slow, but there are things about the browser that are slow and there are things about the browser that you might want to do in some situations and not in other situations. A really good example of this is that IE performs much better when you insert innerhtml strings, other browsers perform better when you do direct DOM manipulation. We actually choose the technique that’s appropriate for the browser. You might not always be able to insert strings depending on what else you might have done, so you might not want to do it if you’ve made only a small change like changing a class, you might not want to insert strings.
This is not something that you as a user should have to care a lot about. This is something that the runtime should care about. Basically, it isn’t even so much that you don’t know about the DOM, if you build custom views, you do some amount of interaction with the DOM. You can reuse your skills working with the DOM, but it means that for things that are native the way views work, the way scrollable views work. We have a thing called the card view, we have pop-up layers, all this stuff are features that already have built in the best practices and we can upgrade the way those things work based on the more we learn without having to make you upgrade your application.
I think that over time has become a very important thing about SproutCore. It’s something that other frameworks for this sort of thing have in varying degrees. So, what you should look for, if you are interested in this stuff is if the way it works is that you have to supply an HTML template and it injects that HTML template directly to page, that essentially means that there is not much that they can do to optimize that. There are some frameworks that are aggressive about HTML templates and some that are less aggressive. You might think that "I would rather write HTML. It seems easier."
But writing HTML bottom line means that that’s the max we can do is we can insert that HTML directly in where a level of abstraction up from that means that we can be smarter about how we’re achieving the thing that we’re abstracting. I can totally get that that’s annoying if you are building a custom view and you go like "I just want to put this in page." We’re working on ways to make that feel better. If you are just doing something that’s HTML template-y that could be easy, that can never be how SproutCore built-ins work, because the SproutCore built-ins are things like SE.view.
It’s a low-level construct and the way that works has to be as optimized as possible. It’s used in a lot of places and we need to be aggressive about learning a lot from the browser and using features when they’re available.
People probably know that there is this thing called PhoneGap and other similar techniques that let you take HTML 5 apps and put them into a wrapper that you can sell in the app store. Here is my pitch for why you should build native applications with HTML 5 technology, especially if you are interested in sharing. A lot of people are building applications, this is especially important for content distributors like magazines and newspapers, but also true about blogs and all these type of things where you create an application and you would like to let people share. If you are building a native app you are probably taking advantage of the native experience.
So you might do something like have a panoramic photo and if you build the native app using all this stuff and then you want to let people share, they’ll click on "share" and you’ll go look on the web app and the web app will be crappy, you’ll see the non-panoramic photo. And that isn’t what you intended to share, you intended to share the panoramic photo. What you can do is you can say "I’ll just rebuild the panoramic photo functionality in the web." Once you’ve done that you may as well build a native application using web technologies. One really powerful reason to build your application using web technologies is that you can more easily share the things that are in the native application with the world.
That’s something you want to be able to do: you want to be able to say "I’d like to share this on Twitter. I want to share this on Facebook." That’s extremely common request for us. We’re in the publishing industry so maybe our sample is skewed, but it’s definitely common for people to want to have a Facebook or Twitter button and it’s good if you can show the same thing that they are looking at. They are sharing a thing; it’s the same thing they are looking at. Just in general, I think one thing that you notice about native applications is that while you could theoretically get really aggressive with native applications, you can get native applications probably to perform better if you work really hard at it than the best web application.
You have to know what you’re doing to make that work and I think the difference is that the way that JavaScript works, the way SproutCore works is that maybe the best SproutCore application isn’t as high performance as the best native application, but the average SproutCore application is much better than the average native application. In almost all cases that matters more. If you look at scrolling on the SproutCore application, it will almost always be better than native scrolling. Somebody did an NPR demo a little while ago that sort of replicates the NPR iPad application in SproutCore and the scrolling is smoother by just saying "This thing is scrolled" because doing scrolling you could maybe do a better job in native, but you have to know what you are doing.
There isn’t a "Here, just scrolling." There isn’t built-in support. Maybe there is, Apple gets better, they provide more technologies for common techniques over time, but part of SproutCore is like a convention over a configuration approach, where a lot of common cases will just work, they’ll just be fast. I’ve definitely noticed that scrolling in a lot of native applications is slow because the way that you have to make them fast is something that you have to learn about. What I would say is that in a lot of cases where you want to build a native application using SproutCore is going to be great.
The learning curve is definitely bigger than it should be, but it’s not as big as you might think. I think it’s probably not any worse than Cocoa, maybe better than Cocoa, so learning about it, putting another tool in your tool belt, knowing that if it comes time to build a native application then you want to make heavy use of sharing. If you want to put this mobile application on the web for some reason, you want to put it on an Android device instead of just an Apple device, these things will work, that’s important. I would also say about Android and Apple and webOS devices, one thing that I’ve noticed a lot of people do wrong when they build mobile toolkits is they don’t really take advantage of the things that are special at each device.
For instance, the Android has a hardware back button, yet you see everybody who builds toolkits that are supposed to work cross device, they all sort of do iPhone style back button on the top left of the application. Android users are not used to that, they are used to pressing the back button and so while I don’t think you need to be exactly 100 percent the same as the native, I think that you need to approximate the look and feel of the device. Another example would be notification is different. Apple’s notifications look different from Android’s notifications look different from webOS notifications. You want to have it so that the notifications feel more like native.
You can get away with not doing this, you can get away with having something that’s all the same everywhere, but then it becomes very obvious that you are in the web, it becomes very obvious that you’re using lower quality applications - the thing that Apple complains about that you did the lowest common denominator. This is going to be one of the things that we’re going to be focusing a lot of attention on as we start to build out. The quick and dirty native mobile experience is thinking about how it’s going to work on different devices, so the back button is a no-brainer for me. On Android you don’t have a back button to respond to the back button press. We’re going to be doing a lot of work to make that make sense, again, probably not copying Android’s look and feel exactly.
One problem with doing that is just that something is not exactly right it becomes very obvious. If you have a button that feels kind of like Android, people don’t expect it to behave exactly the same. If you have a button that looks exactly like Android and behaves 1 percent differently it’s very glaring. So you don’t want to go all the way, but on the other hand you don’t want to go to the lowest common denominator. This is something we’re thinking a lot about as we move forward in SproutCore. I think probably what you’ll notice about the SproutCore in the years ahead (hopefully we’ll make it that long) is that we have a level of attention to detail that a lot of people lack.
So, while today a lot of things are very raw, a lot of the reason for that is that our attention to detail is very high and we don’t want to ship something just for shipping it. We talk about this a lot, we could spend two months now and ship something that looks like Sencha. And we don’t want to do that. We want to ship something that maybe we build up slowly but as we build up everything that we deliver is very high quality, very much attention to details thinking through the implications for mobile devices. We’ll always be performant and we’ll always feel right on the device in question. I think that’s how we’re thinking about the problem.
It will definitely make it so that for the short term and even medium term we will appear to be less out-of-the-box ready than other people, but I think our scalability in terms of once you have an application you can build something real of it, will always be better. Or for the moment, we are better and I think we’ll continue to be better.