The SproutCore blog will soon live at http://blog.sproutcore.com.  Your feed reader should redirect automatically, but update your bookmarks too!  We’ll be retiring this blog in a few weeks when we launch the new site.

Go to http://blog.sproutcore.com »

This great set of slides from Google covers in some detail the features coming in EcmaScript 5.  ES5 offers the possibility of bringing the best out of JavaScripts, cleaning up some of the rough patches and making it generally far more useful for general purpose programming.

Best of all, ES5 is written in such a way that it can largely be decomposed back into traditional JavaScript for browsers that ship today.

For the last few months, we have been laying the ground work for adopting ES5 as the new standard for SproutCore code.  Most of the SC1.0 API has been vetted for compatibility.  The build tools have also been prepped to one day add an ES5 -> JavaScript1.5/ES3 compiler which would allow you to write in ES5 code and generate JavaScript that runs on all modern browsers, including the older ones.

There has been a lot of debate over the last year over whether or not developers should write directly in JavaScript or should they write in a “serious” language such as Java, Objective-C/J, Python, etc and then convert to JavaScript.  The argument goes that these languages allow the compiler to generate better code while working around the deficiencies of traditional JavaScript.

The drawback, however, is that other languages have different strengths than JavaScript due to their differing underlying implementations.  Algorithms that are fast and efficient in these platforms will not always translate back to JavaScript.

Any developer who has worked on a large scale project in GWT, for example, can tell you it doesn’t take long before you have to drop down to debugging the unreadable JavaScript emitted by GWT to find out why some algorithm doesn’t work the same way in hosted mode as it does after a build.

We think an ES5 to JavaScript 1.5 compiler has the potential to offer the best of both worlds.  ES5 covers most of the potholes in JavaScript that trip up developers of large projects, so you get all the benefits you might get from Java or some other language.  At the same time, ES5 is fundamentally JavaScript.  When you design algorithms that work well in ES5, they will also work well in older engines.  Debug-oriented “compiled” code can look similar to the code you wrote so debugging in the browser won’t be a big pain.

A compiler can easily clean up the few syntactical differences that exist between the two.

We won’t be adding this compiler for a while.  We totally focused on finishing SproutCore 1.0 right now.  Overall, however, I’m really happy to see the ES5 spec converge into something we can really work with.  ES4 was fatally flawed but the committee seems to have gone in a more pragmatic direction this time which is great news for the web.

We’ve all been so busy writing code that no one has had time to post on the blog much, but I wanted to give you a quick update on SproutCore 1.0’s progress.

A few weeks ago we quietly made the SproutCore 1.0 alpha public on our github repository. The response from those few brave souls who’ve been willing to test it has been very positive. Most of the new features are there and major rework is complete. There are lots of bugs, as you might expect from an alpha release. We also have a few classes (in particular SC.CollectionView) that aren’t yet hardened enough for everyday use.

Right now we’re slaving away at getting the final bits of this code solid enough to help get everyone else involved. This is taking up almost all of the core team’s bandwidth since we want to finish the work in the next few weeks.

Once this work is done, SproutCore 1.0 should be ready for all of you to start to get your hands dirty with it. We’ll have a couple of tutorials ready for you to go through to help you learn the new API as well as some outlines for docs on the new Wiki site. Our goal will be to help you get started writing apps and get some of you deep enough into the code so you can help fix bugs, contribute to docs, etc.

I am really excited about the 1.0 version of SproutCore. The purpose of this project is to build the best standards-based rich internet application platform that we can. With 1.0 we’re really setup to achieve that.

I’ll have a lot more to say when I’m done writing code, but in the mean time feel free to browse the alpha code on github as well as the samples-todos and samples-hello-world for a sense of what is next to come.

If you’re going to JSConf 2009 this weekend in Washington DC, be sure to check out Mike Subelsky’s talk on SproutCore, Saturday 3:40-4:30.

Rumors of a new $200 Web-Top called the CrunchPad.  Is it for real?  Who knows but if it comes with a fast browser like WebKit, it could be a real laptop replacement for many.  This is why cloud-based rich applications based on JavaScript frameworks like SproutCore will dominate future platforms.

Did Arrington actually pull off the CrunchPad WiFi tablet? - Narcissistic Infarction

Introduction to PaperCube from Peter Bergström on Vimeo.

A few months ago I linked to Peter Bergstrom’s PaperCube project.  It’s a great data visualization tool and written in SproutCore.  The final version is up now so you can check it out!

PaperCube - Peter Bergström.

SproutCore 1.0 is a huge milestone.  It’s the point where you tell developers your code is good enough for them to base their business on it.  You only get to do it once, so its worthwhile to take the time to get things right.  Sometimes that means doing more surgery than you would like.  In the end, though, it is worth the effort to have something you can really love to use.

I’m happy to report that except for the store layer, last Friday we hit our SproutCore 1.0 alpha milestone.  This means that we consider the API largely feature complete and ready for the most adventurous of developers to start building upon it.  We will make all of these changes public as soon as our postback request clears.

What Changed?

Almost everything.  New build tools.  New view layer.  New model layer.   Here are some of the highlights:

• The view layer now supports a “deferred” rendering model that allows you to mark a view as dirty and then have it update the DOM one time at the end of the run loop.  This means that as changes propagate through your application, you will avoid expensive UI updates in the mean time.
• View’s also get a new rendering layer that allow you to push HTML strings into an array which is then joined together and set via innerHTML one time at the end of the runloop.  The most expensive part of working with a web browser is touching the DOM and in many cases this will reduce the number of DOM actions down to one.
• The Store will soon sport “materialized” records.  This means that instead of creating SC.Record instances whenever you load JSON into the store, we just keep track of the JSON and then create SC.Record objects only when you ask for them.  This can dramatically reduce the time it takes to load in large numbers of objects.
• We can also now chain multiple stores together allowing you to clone a store, make changes to a bunch of records and then commit those changes in one go back to the parent store.  This will replace the current change buffering included in the Controller objects today because it will allow you to modify an entire object graph rather than one at a time.
• Of course, the bindings and observers were rewritten some time ago to be more memory efficient and to reduce the amount of echo in applications.  The “cacheable()” feature is one of the most populate changes here.  This added qualifier on a computed property automatically caches results, eliminating a lot of the glue code you used to need to write to cache property values.
• The new build tools now support breaking your frameworks or apps into smaller sub-frameworks and apps.  The SproutCore framework in particular is now broken into six different subparts which you can pick and choose as needed.  The build tools will automatically determine the optimal packing order for that frameworks to produce the smallest number of files.
• And of course, we’ve added hundreds of unit tests with over 3,000 assertions for both the framework and build tools.  This has already paid big dividends in making SproutCore much faster and more reliable on IE 8.

What’s Next?

Over the next month, we’ll be writing documentation on the SproutCore wiki and creating examples that demonstrate most important portions of the framework.  Along the way I expect us to find a lot of rough patches in the API that we will need to smooth out.  Our focus for this next phase will be to smooth out API problems over fixing bugs.

Once we are satisfied with the API we’ll focus on fixing bugs until we reach a high enough code quality to go final.  During this beta testing phase we expect you to be able to work against the new APIs since they will be fairly fixed.

1.0 has turned out to be a much larger project than we initially planned.  But I’m really glad we did it.  It is the best work we’ve ever done.

Chris Anderson gave the final keynote at SXSW today.  He says that since the marginal cost of most web services is approaching zero, you might as well make your service free.  After all, if you don’t do it, someone else will.

His analysis is critically flawed.  Don’t listen to him.

The fact is there are many industries that have a marginal production cost approaching zero.  Yet they still manage to charge for their products.   Take the desktop software industry for example.  The marginal cost for printing a CD or issuing a new download is actually as low or lower than the cost of many hosted web services.  Yet Adobe, Microsoft and many others charge hundreds or thousands of dollars for their software.  How to they do it?

Two words: marginal utility.

Anderson, who called himself an economist during the keynote, thinks that eventually the price of most services will fall to their marginal cost.  Sometimes this is true, but its not because people buy things based on cost.  They don’t.  They buy based on the additional marginal utility they will gain.

Therein lies the reason why most online services have to be free.  The added utility they deliver over the what consumers already have is so small that its not worth paying for.

Take for example Twitter.  Twitter is fun and useful, but if it disappeared tomorrow, most people would still be able to talk to their friends without much disruption.  The marginal utility for most people is near zero.  Hence, no revenue.

Alternatively, consider Salesforce.  Another online service, also focused on communication.  But this time the nearest alternatives to Salesforce either lack major features or cost thousands of dollars more in time and setup costs.  High marginal utility means high prices.  Today SalesForce has over a billion a year in revenue.

Some free businesses, like Facebook, can become large enough that their audience membership offers high marginal utility to advertisers versus other venues.  This allows them to charge a high CPM and earn revenues that way.  But again, the value here is based on utility, not cost.

Low marginal cost does impact web software in one critical way.  Because the marginal cost of a service is near zero, it means that many sites can go on for years without offering any useful utility before they will be forced out of business.

Ironically, because the cost of operating the business is so low, it can lure entrepreneurs into thinking this is a good use of their time.  It probably isn’t.  A low-utility website may not have a high monetary cost but it does have a real opportunity cost.

To be fair, building high-utility software on the web has historically been very difficult.  There is only so much you can do with a styled web page and a little JavaScript.

Thankfully, new high-powered browsers are changing all of this.  And frameworks like SproutCore bring the development costs for creating high utility services on the web down to the level average development teams can afford.

This is where I think the really revolutionary power of SproutCore and related technologies will come into play.  When you can create software in the web browser that can rival the richness, complexity, and high utility, of desktop software, you can generate some big returns.

If this makes sense to you I hope you’ll participate in helping us make SproutCore everything it needs to be.  It carries the promise of not just making web services that are not just fancier, but more useful and profitable as well.

One of the reasons we rewrote the build tools for SproutCore 1.0 was to make it easier to support building for multiple platforms.  SproutCore is now made up of six different smaller frameworks that you can mix and match as needed.

Today at SXSW I had a few hours to kill so I took some time to work on one of the new platforms we want to support.  Introducing SproutCore Mobile:

SproutCore Mobile shares the same Runtime, Foundation, and Datastore frameworks as its desktop cousin but it will come with a completely different view layer - custom built for the phone.

Even more important - the example includes an HTML5 ApplicationCache manifest file, which will be automatically generated by the build tools.  This means when you load the app on the iPhone, the phone will save a cached copy of your app and reuse it on future runs.  No more 25K limit to keep cached files.

Best of all, you can “install” SproutCore apps directly on your phone just by clicking the + icon in Mobile Safari.  The phone will add an icon for the app to your dashboard and download and cache all the files.  Launching is really fast.

For enterprise applications that don’t go onto the iTunes store, this is a great way to distribute your software without going through the hassle of the manual installer.  If you want to go through the store, you can always take your SC app and package it using PhoneGap instead.

Currently SproutCore Mobile only contains the button view you see above.  It’s likely that it will only ship with that view when SproutCore 1.0 is released.  However, all the other technologies needed to build mobile apps will now be in place.  All we need to do is add the views.

This year a bunch of the core SproutCore team members will be visiting SXSW and we brought Bitburger (aka SproutCore 1.0) with us.  If you’re working on SproutCore, interested in SproutCore, or want to see a demo of some of the stuff we’re working on, feel free to get in touch!

If you just want to show up at a party, the fine folks at OtherInbox are hosting a Ruby on Rails/SproutCore part on Monday night.  We’ll also have a smaller “birds of a feather” lunch on Sunday around noon someplace nearby the convention.  This will be a great time to just meet up with other SproutCore folks including the core team and talk some tech.  I’ll post most details here and on my twitter feed (@okito) when I have them.

If you’d like to meetup some other time, find us on IRC at #sproutcore, or send a twitter to @okito or simple email me at charles [at] sproutit.com and we’ll get in touch.

Now I have a plane to catch to Austin.  See you there!