Okito.net

The Mobile Web

Fred has wrote about prospects for the Mobile Web which sparked a lot of discussion. John Lilly responded here as well.

We web people always come up with complex reasons for the web’s failure on mobile - technology (“if only we had a camera!”), openness of the ecosystem, or number of developers for example. All of these are head fakes. A sort of ‘if we build it they will come’ attitude that tech people are prone to when they need to justify tech they have fallen in love with. [1]

The real reason is much simpler but harder to accept: consumers just don’t want it.

The average session length on a phone is 4 minutes. In such a short session, the time it takes to navigate to a web app and wait for it to load can use up 25-50% of your session time. Whereas a well built native app can be found and launched in a few seconds.

Native apps are simply more convenient than web apps; they fit better with how people actually use their phones.[2]  There are other benefits as well - many of which could be easily fixed, such as memory management or device access - but the high order bit is speed.

Ultimately all great technology innovations are driven by consumer demand for convenience. If you have consumer demand, technology, developers, all the other things we worry about will follow suit.

Does this mean the web can never win? Hardly! But this framing gives us a much better way to think about when and how the web might win once again.

If native apps are more convenient than the web today, in what ways are they not convenient? One obvious issue is the time it takes to find install the app before you can use it. This is particularly painful for transactional-based activities such as shopping, news, or buying services.

This is an area where the web - at least in theory - should be able to win because apps don’t need to be installed first.

However, it can’t be through a web browser. The cost of navigating to these services is simply too high.

This is why I am interested in services like Google Now - which offer a form of passive discovery that have the potential to eliminate the navigational cost of the web. It’s not a complete solution, but a step in the right direction.

It’s easy to imagine a world in the future where task-oriented applications can be consumed on demand instead of installed first - perhaps downloaded in the background before you actually need them by a discovery service that pays close attention to your current context and predicts your future needs.

This is the way the web will eventually win - not as the web as we know it today - but in the form of a new product that is more convenient than native apps today for certain activities.

Initially the apps will probably suck compared to their native counterparts. And maybe only a few people will know how to build them. The service may be open or not. It doesn’t matter to consumers - as long as it’s the fastest, most convenient way to get things done on their phone - they will demand it. The rest will follow.

FOOTNOTES

1. I am guilty of this too. See my previous startup [Strobe] and many years of efforts to build native-style apps in the browser.

2. Incidentally, this also explains why the web is more useful on tablets.  Tablet sessions are twice as long and more more discovery oriented. For this type of usage, the web is more competitive.

On SproutCore 2.0

As you might have heard, Apple released the icloud.com service to developers yesterday.  Some people violated their NDA if you are interested.

First of all, a big “congratulations!” is due to the people that worked on this project.  It’s truly fantastic.  I am proud to have worked with you in the past.  (And prouder still that I get to work with some you at Strobe!)

Secondly, this seems like a good time to explain a bit more about what’s happening with SproutCore and our move from the 1.6 branch to 2.0.  There has been some confusion in the community about what the new 2.0 release means and why we are making such radical changes to the old code.

I think iCloud demonstrates perfectly why 2.0 needs to exist.

Some Background

SproutCore has always been about creating “native” style web applications in the web browser.  Thanks to apps like Twitter and Gmail, and iCloud, the trend towards these types of apps seems pretty obvious today.  Five years ago - when I wrote the first version - it wasn’t so clear.

Lucky for me, though, a major company was willing to pay me and a small team to spend our full time just thinking about how you could push browsers to their limits in creating large scale, fluid, native-style web applications.  You can find most of the tech we built to make that possible in SproutCore 1.6 today.  As you can see, in the hands of someone who understands the entire system, you can do truly amazing things with it.  

Over the years, some very smart and brave pioneers have been willing to dig in and learn the code necessary to master SproutCore.  Those people have been able to do great things with it; many even contributed back awesome new improvements of their own.  

I am very grateful for this group of people.  But, what about everyone else?  It shouldn’t take a few days of training and lots of stamina to make something amazing with SproutCore.  That is where 2.0 comes in.

If SproutCore 1.0 was about figuring out how to get the most out of browsers so a select few could build amazing native-style apps, SproutCore 2.0 is about bringing that power to everyone else.

SproutCore 2.0 is a completely refactored edition of SproutCore.  While the old version was made up of four frameworks and tightly coupled build tools, 2.0 is made up of nearly a dozen libraries and an independent tool chain.  The result is a system that is much easier to document, easier to learn, and easier for community members to get involved with it.

Let me give you a couple of examples:

Whitelisting vs String Loading

SproutCore 1.6 is a huge framework.  I think it can top out around 1MB when you include everything.  To make matters worse, although the framework is made up of four sub-frameworks, poor management overtime has meant that they all share dependencies making it impossible to turn most of them off.

The way you solve this in 1.6 is with a poorly documented feature called “whitelisting”.  (There is also a “blacklisting” option, equally poorly documented.)  These two features allow you to selectivly omit or include specific JS files from SproutCore during your build.  This makes your build much smaller but essentially requires you to understand all the dependencies to make it work.

SproutCore 2.0 is much simpler.  For one thing, there are now nearly a dozen frameworks (and growing) with carefully managed dependencies, making it much easier for you opt into only the parts you care about.  More importantly, the new build tools use a new ‘string loading’ technique which alleviates most of the pain around loading a lot of JavaScript - especially on mobile - making this issue far less important to begin with.

More importantly, the process of managing these dependencies is a part of the `bpm` - the package manager - which is currently being finished but will include full man pages explaining the process.  String loading is a bit more esoteric, but it is also completely automatic so most developers will get the benefit of this feature without even having to know it exists.

RunLoops vs Invisible RunLoops

Another very important feature of SproutCore is the RunLoop.  RunLoops allow SproutCore applications to defer expensive operations to the end of a cycle.  For example, most rendering in SproutCore views is deferred in this mannor, meaning that expensive DOM operations only happen once - dramatically improving performance on large applications.

The problem is that RunLoop’s are a classic ‘leaky’ abstraction.  It’s very frustrating to write code and then have it seemingly execute out of order.  As a result, almost everyon SproutCore 1.x developer has to learn in-depth at some point about RunLoops and how they work.  1.x code is frequently peppered with calls to `invokeLater()` and `setTimeout()` to try to set these timing issues right.  (Though almost always this actually makes things worse.)

In SproutCore 2.0 RunLoops still exist, but they are far more invisible.  We spent a huge amount of time rewriting the View layer to carefully manage which parts of your code we will defer in order to minimize any surprises when writing code.

Personally, I still think most SproutCore developers will need to learn what a RunLoop is at some point in time, but for the early people trying SproutCore 2.0 it is far less of an issue.  You definitely don’t see invokeLater() or setTimeout() peppered about like before, which is a huge improvement.

Ad Infinitum

There are many more examples.  But perhaps the most important point about this is that SproutCore 2.0 is essentially an effort to take the great technology we assembled in SproutCore 1.6 and go through it piece by piece - carefully testing and documenting each component, working through rough patches that seem to trip up or confuse people, until we feel confident that most people will be able to get it.

And this is where we get to the part that confuses most people.  This task is like organizing a messy house; you can’t do it all at once.  The only way to give each thing the attention it deserves is to go room by room, working on each section until you feel it is done well it enough to move on.

During this process, some features you can find in SproutCore 1.6 today will be missing.  Eventually, most of them (a few things in 1.6 are truly bad ideas) will come back.  Until then, our recommendation is simple:

1. If you want the full power of everything in SproutCore today and you cannot wait and you are willing to dig into the code, use SproutCore 1.6.  A lot of people still are.  Strobe’s forthcoming app even uses 1.6.
2. If you are building a simpler app or a “hybrid” native-web style app along the lines of Twitter, SproutCore 2.0 - when it goes final - is for you.  It’s leaner, easier to learn, faster out of the box, but also missing the rich desktop controls of 1.6.

And what if you want the desktop controls in 1.6 but the ease of use of 2.0?  

Wait. Or better yet: contribute!

SproutCore 2.0 is far easier for people to learn and use.  And now all of the core functionality is basically done.  Views work, bindings work, the datastore works.  Mostly what we need now are the rich desktop-like controls - an effort we plan to capture in the sproutcore-ui and related packages.

Thanks to our more flexible design in SC 2.0 it’s way easier to get involved now too.  These are separate packages, meaning you don’t have to get anyone’s permission to start writing your own and sharing them with others.  

So hopefully this helps to clear some things up.  SproutCore, I believe, is still the best framework out their for building fluid native-style web apps.  With the transition from 1.6 to 2.0, we’re opening it up to the public too.  

We are making it far easier to anyone to learn how to use it and contribute themselves.

If you want to check out the new SproutCore 2.0 the best place to learn more about it today at at the Github page.  We are building out an updated website and docs for SproutCore and the build tools we are using (called bpm) for the final release - so stay tuned for more information there.

In the meantime, if you have thoughts on this transition, I would love to hear from you. Drop a comment here or follow me on twitter @okito.

SproutCore/WWDC Meetup 2010

The SproutCore Team is getting together tomorrow night in San Francisco for dinner and drinks following the last WWDC session.  This is really informal meeting this year, but if you want to see the core team and chat, signup here:

SproutCore Meetup Eventbrite

We will confirm a location tonight based on the number of RSVPs at 6pm Pacific Today.  Hope to see you there!