We’re having a SproutCore meetup in Paris on Thursday, August 5th at 8:00 pm. Charles, the creator of SproutCore, will be here, as well as members of the core team. Whether you’re already familiar with the framework of just curious to know more about it, join us for a beer at the Café Léa.

Hope to see you there!

Kiva en Français:

Written in SproutCore.  The source code is available at on GitHub.  We’re going to adopt this project as a demo app.  Thanks to Skylar who has done so much awesome hard work to make this happen!

Every so often a few technology trends converge that yield results much greater than their individual parts.  I think we have reached one of those moments with mobile devices (like the iPad) and HTML5.

In many ways, the iPad is the perfect web device.  It’s a lean-back experience optimized around consuming content. With HTML5 (which mobile Safari does better than just about anything else), the kind of experience you can create on these devices is just really spectacular. You only need to use the NPR demo we wrote earlier this year for a few minutes to realize this is obviously the future of software.

For this reason I decided about a month ago to leave Apple and form a new company centered around helping companies bring great native-style app experiences to mobile device.  The center of this company, of course, is SproutCore.  Monday was my last day at Apple.

This change may seem big to some of you so i want to make a few things really clear up front:

First, SproutCore is now and will always be totally free and open source. I think this business of charging for a commercial license is not an effective way to grow a project. Sure you make a little cash, but at what expense to the community? My goal is to make SproutCore and all of the developer tools that surround it totally free to everyone. All I ask is that you participate in the community somehow to make things a little better for those who come after you.

Second, now that I am no longer held back by big-company legal restrictions, I am going to be much more involved with the platform. Very soon I will post some new example code. Some others are working on new documentation and build tools to ease that pain as well. Starting this fall, my new company will also start to offer online and in person training and mentoring courses to your team get up to speed quickly.  We can also finally get started in that book.

My goal is that by the end of the year, any average developer can pick up SproutCore, build, and deploy a basic app without feeling lost. This is open source and I can’t usually guarantee timelines but at least now we can do what we need to make it happen.

Finally, I want to be totally clear about this: I started working in SproutCore almost 5 years ago because I believe the future of software development lies in native-style apps in the web browser. It is the platform of the future and when that shift change happens, I want to be there with the technology. Now, I believe that time is almost finally upon us.  It’s time to double down, and that is why I am leaving Apple.  

As for my new company, it is called Strobe Inc.   We are currently focused on the digital publishing vertical (and supporting SproutCore as a platform).  You can find a not very interesting landing page, but otherwise I am not ready to share more details just yet.  Rest assured, we will be putting a lot back into SproutCore.

We’ve come a long way.  It’s time to grow up as a platform. I can’t wait till what comes next…

SproutCore Meetup Tonight @ Tropisueño:

Same place as last year.  Great food!

You know how they say that the real world produces the best software. @frozencanuck, a member of the team here at @eloqua, has written an open source Ruby testing framework called Lebowski which leverages Selenium and is specifically designed for Sproutcore and it’s unique needs. Here is a post where he talks about it in detail and you can find the repository for it here. It is still in development, but we are starting to use it in our big SproutCore application.

…This is a guest post by Evin Grano (@etgryphon)

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!

scytacki's capybara-testrunner:

a library which uses capybara to run browser based testing frameworks [CoreTest/SproutCore]

Helping Sprouts Grow Better:

The SproutCore community continues to grow!  Avi has setup a new blog documenting more tips and tricks.  Add it to your RSS reader today!

If you’ve had questions about how to try out greenhouse - now you can watch someone else do it first: Sproutcore Greenhouse Setup (by Jake Mallory)

If  you need to plot charts and graphs, some folks in the community have put together a few frameworks that are just for you.

• Flot Framework - For general graphs checkout the Flot integration by Bo Xiao
• JSXGraph - For plotting and point charts by Stephen Bannasch

Screenshot: JSXGraph demo.

SproutCore Documentation / Todos 06-Building with Grails:

Thanks to Cam MacRae, you can now learn how to write SproutCore apps with Grails as your back end!   Pretty awesome.

Well, we have finally done it. At jsconf2010 on Sunday, Mike Ball and I introduced Greenhouse: a Graphical Interface Builder for building blazing fast native-style applications using SproutCore.

Development on Greenhouse started in earnest only a couple of months ago. Mike and I worked in it in only in our spare time, but we have it far enough along to share with the community as a developer preview in SproutCore’s current master branch.

The truth is, we waited a lot longer than most other projects to start on our interface builder. But we didn’t want to start until we could do it right. We wanted SproutCore to go officially 1.0. We needed the API to become stable because there is nothing worse than jumping the gun and delivering a half-baked designer with an API that changes underneath.

So What, Everyone Has a Interface Builder…

While this may be true, no one has really innovated in this space for 20 years. They all seem to look the same. Here is a small sample of them:

Interface Builder

Atlas

TIBCO Interface

Ext-JS Builder

So these are good, but they all have the same problem.

If we are to build beautiful web applications, we can’t do it with a cluttered workspace. My wife does mosaics and she can’t really be creative unless she has a space to create in…I think it is the same for developers. We need a workspace for creativity, but these interfaces are cluttered with controls and only give you a small window to see your actual content!

So what can we innovate this space? How do we turn these cramped UIs in to a place where we can create some awesome web applications? Here are the steps that we took:

Clean Up the UI

First, we cleaned up the interface. We move the list of components and inspectors to picker panes that can be torn off and docked in the traditional interface builders.

In this way, we maximize the workspace. We move as much as possible out of the way so you can focus on your content. This is also a true WYSIWYG editor.

We have been using this UI for awhile and, I can tell you, people who use it truly love it. This comes from our work with our current company’s product where customers can build emails and landing pages in the browser using a similar interface. We have been building a lot of real world experience in this space.

So we cleaned up the UI, but this isn’t the most important thing we could improve. The biggest improvement is…

Solving the Blue Box Problem

Most production apps are built from custom views developed for the app. The problem is most interface builders can’t show you these custom views so they draw a blue box and leave it to your imagination.

We are all busy people. Most of us don’t have designers that can build custom mockups of views to show us what our UI will look like. Also, these designs change so much that is a major feat to keep up to date if you do have a designer. It is a hugh waste of time. So what you are forced to do is actually not have your custom views styled in your UI builder and it looks like this:

The SproutCore team decided the best way to solve this was to leverage the power of JavaScript. Rather than load a data file, Greenhouse actually loads your entire application in an iframe. Your actual application is loaded in a ‘suspended’ design state so that you can actually see your custom views as you have built them. They will update and look exactly like they would in the code.

This is an amazing time saver for you. It can help you actually build amazing user interfaces. This is what it looks like with a large application with a lot of custom views. It looks exactly like it does in real life as if you were using it!

Oh, and one more thing: Greenhouse’s file format is actually Javascript built off of the 1.0 API. If you have a Sproutcore App that is built with SC.Pages, your pages will automatically load into Greenhouse will little to no effort.

OK, That’s nice, but what is the catch?

Well, most interface builders cost lots of money. Like $100, $200 and even more. Some will even charge you for their beta releases.

We on the SproutCore Team believe that a UI designer is a fundamental tool for any framework that is worth it’s salt. So we have decided to build Greenhouse into SproutCore - entirely free. We want to give this away because its the right thing to do.

Cool! How do I get it?

Well, that’s the easy part. Greenhouse is currently built directly into Sproutcore with some really easy steps to get it:

git clone git://github.com/sproutit/sproutcore-abbot.git abbot

cd abbot

mkdir frameworks

cd frameworks

git clone git://github.com/sproutit/sproutcore.git

cd ../..

And then from your Sproutcore project directory:

/abbot/bin/sc-server

Now all you have to do is open: http://localhost:4020/sproutcore/greenhouse you should get the App Viewer:

Note: If you use a custom build of SproutCore (something in frameworks/sproutcore), you will need to rebase to the Top-Of-Tree (TOT) to make sure you have all the code to run your application in Greenhouse.

We are trying to build the most beautiful and friendly interface builder UI out there. There are still a few bugs and lots of missing features as we have only been working on it for the last two months, but we are really excited about what the future holds for Greenhouse and Sproutcore.

Mike Ball and I are going to use the current version to build a mobile app for our company because we believe the best way to make a product is to use it and find the problems. We are really excited to see the new apps that people will build with this awesome FREE UI designer that offers a uncluttered design space with nary a blue box in sight!!

Update

I also wanted to mention that the beauty of this design was due to the hard work of our awesome designer, Matt Grantham (@MattGrantham). You can see some of his other kick-ass work here.

…This is a guest post by Evin Grano (@etgryphon)

Thought of as a “toy language” for too long, JavaScript is coming into its own. Today JavaScript is used in major duty applications in both the client and server environments.

The problem is, compared to our power-scripting brethren, our tooling support has never caught up.

Running small JavaScripts in the browser is reasonably easy today, but anything beyond that goes downhill fast. A lot of basic things that other scripting environments take for granted simply do not exist for us.

Don’t Get Me Started

Take for example, packages. Both Ruby and Python make it insanely easy to create a library and share it with other people. For most Rubyists or Pythonistas, building a new product or feature usually begins with a search of their package system for a library that gets them close. Once found, one command will install the library to make it ready to use.

JavaScript? No such luck.

First, search Github. If not found there, search Google. Should you find a library, then you need to figure out how to integrate it into your own JS system. Sometimes it is just a script you can drop in. If it is bigger than that, you may need to get a build tool (which is probably written in Ruby or Python anyway) and use that to generate the file.

Once you have the script, of course, tracking updates is just as hard. Usually it involves visiting a website periodically just to look for updates then going through the integration process all over again.

Even just running a JavaScript from the command-line is a total nightmare these days. For most languages, it’s as simple as:

#!/usr/bin/env ruby

And you’re off to the races. The full power of the standard Ruby or Python libraries are at your disposal. If you don’t like those libraries, no problem! A quick search and install from the package manager and you’ll have something new in no time.

Meanwhile in JavaScript land…first you need to pick a JS runtime. Usually you’ll end up repurposing a JavaScript server like narwhal or node.js. Each has a totally different API, by the way.  Whichever runtime you choose will stick you for the life of the project without major transition pains.

What a mess.

Where Giants Fall

Now, to be fair, some really smart folks have been working on some projects that at least partially solve this problem for some time now.

The CommonJS standard has a great module pattern that is a key building block to solving these problems.  It also has a concept of packages that is going in the right direction but each project seems to interpret it so differently we can’t rely on it globally.

There are, in fact, several implementations of CommonJS available, including node.js and Narwhal among many others.  They even have some package managers designed for their respective platforms.

Easily sharing code isn’t a primary purpose of this project, however.  They come with a bunch of added (different) APIs and subtle incompatibilities as well.  When these things break your code, no one is generally in a hurry to fix it.

Which is totally fine, by the way. That’s how open source works. You scratch your personal itch. If someone wants to do something with your project that isn’t part of your personal charter, you don’t do it.

A Call To Arms

The point is that for JavaScript to have a universal set of tools for sharing and executing code, it needs a project dedicated to that purpose. Specifically it needs to have the following goals:

1. Provide a CommonJS runtime environment that works in both the browser and multiple JS “runtimes”.

2. Be as flexible as necessary to help you adapt older JavaScript code to work with CommonJS while maintaining compatibility.

3. Make it insanely easy to create, share, install, update, and fork JavaScript libraries for both the server and the client.

4. Keep the API as focused on sharing code as possible. All other APIs (file io, browsers, etc.) should be exposed as packages that can be dynamically swapped out.

Basically, we want a tool that is focused on making it easy to adapt and share new and existing code to run in browser, server, and from the command line. It should not take a position on other APIs (such as sync vs async). It should be small, focused, and simple as possible.  Ideally it should run on any JavaScript runtime, not just one or the other.

Seed.js

From my perspective, this project does not yet exist.  I think it is important though, so over the last few months I built one. It’s called seed.js.

Seed.js is a flexible package manager for CommonJS modules. (A CommonJS module is a single JavaScript file, a package is a group of one or more related modules that you install together.) It implements three things:

1. A package-aware CommonJS module runtime that works in both the web browser and most “server-side” runtimes (such as node.js or narwhal). This allows you to write your CommonJS modules to a single standard.

2. A command-line tool (called “seed”) that can install, update, remove, and fork packages.

3. A JavaScript-runner that will execute JavaScript using a chosen runtime (e.g. narwhal, node.js), automatically loading seed on top of it.

Virtually every aspect of both the CommonJS runtime (called “tiki”) and the seed command line tool itself is configurable via simple API’s. The idea is to give you lots of ways to enhance the Seed environment itself when adapting existing code so you can make the code run without having to break backwards compatibility.

The point is that seed’s purpose is to be focused and flexible - to adapt to the needs of the community so that we can have one universal packaging system for use across the board.

Current Status

Right now, seed is usable but not finished. We showed seed.js for the first time publicly yesterday at jsconf 2010. It is available now for you to play with at seedjs.org. To get things rolling we have pre-loaded the seed server with a dozen or so packages.

Currently, seed runs on node.js and stores packages on a JavaScript-based server hosted at seedjs.org. When forking packages, seed uses git. But these were just our starting points. All our platform dependencies are kept in a single place so porting from node.js to another runtime should be straightforward. You can target different server backends just by writing a plugin. Ditto for adding support for new SCMs.

As far a projects go - both the Mozilla Bespin team and SproutCore have been using the Seed CommonJS runtime (aka “tiki”) for several months now and we’re really happy with it. In fact, both SproutCore’s ‘runtime’ and ‘datastore’ frameworks have been converted to CommonJS and will soon be available as packages in the seed repository.

…

If you would like JavaScript to become as easy to use as Ruby or Python, please go give seed a try today. Install some packages, write some code. Create a seed of your own and publish it. Then, join the mailing list or join us on the IRC channel at #seed.js on freenode.net and give us your feedback.

Right now seed is new so just about anything can change. The goal is to end up with a universal set of tools that makes JavaScript a better platform to work with - in the browser, in the server, and direct from the command line. If you want this future too, download seed and let me know what you think.

This guest post was contributed by Mike Ball.  Mike presented SproutCore today at jsconf along with Evin Grano.

There are two officially supported platforms for developing apps on touch devices like the iPad: native and HTML5.   A lot of people don’t know this or don’t care because conventional wisdom states that you can’t build a really great HTML5 experience on touch devices.

Guess what?  Conventional wisdom got it wrong.  Ever since the early iPhones Safari has had great touch-specific features and the problem is, as is common in the web, few people know how to use them.

Today all of that changes.  At jsconf this morning Evin and I, representing the SproutCore project, got to show for the first time SproutCore Touch.

SproutCore Touch is the first edition of SproutCore that includes complete support for touch events and hardware acceleration on the iPad and iPhone. 

So in addition to supporting low-level browser features SproutCore also integrates touch into our high-level views.  For example SC.ScrollView supports hardware optimized scrolling which some people said was impossible!  We also have a bad-ass SC.MasterDetailView that automatically reconfigures your UI to show a sidebar in landscape mode and hides it under a picker in portrait mode.

Since all of our views provide touch support automatically, this means that you can actually use SproutCore Touch to build apps that run both on the iPad and desktop computers.  In fact, we’ve found that usually its easier to build our apps for the iPad first and then desktop next - since things usually just work when you transition.

Touch is the most important innovation we’ve seen in computing in 15 years.  It is completely changing the way people interact with their content.  As developers, we have a chance to really up the experience on our own apps thanks to this new technology.  

Now if your app makes more sense on the web than as a native app, you have a viable way to build something using the only other officially supported platform on touch: HTML5.

If you want to try SproutCore Touch yourself check out our slick new documentation app:

http://touch.sproutcore.com/hedwig

It currently runs on both the desktop (well WebKit, Chrome and Firefox - we are still fixing minor bugs on IE) and the iPad.  

If you want to start building SproutCore Touch apps yourself, first go to the SproutCore Home page, install SproutCore, and then switch to the latest master branch.  All the code is available there today.

The developers who worked on this for the last few months are also hanging on the IRC channel at #sproutcore if you need some help.

Finally, I’d like to give a shout out to all of the developers from Apple and around the world who have worked so hard on getting SproutCore Touch ready.  This new technology has truly been a community effort. We were humbled to get to present all of your amazing work today.

So, please check out SproutCore Touch today.  We can’t wait to see the native-like apps that get built with SproutCore touch.

PS. I should add that SproutCore Touch is only possible thanks to the hard work put in by developers over the last few years to give SproutCore 1.0 it’s incredible performance and speed.  Touch devices run fast web browsers on slower hardware.  Without that baseline performance, we never could have built this experience in such a short time.

This guest post was contributed by Mike Ball.  Mike presented SproutCore today at jsconf along with Evin Grano.

There are two officially supported platforms for developing apps on touch devices like the iPad: native and HTML5.   A lot of people don’t know this or don’t care because conventional wisdom states that you can’t build a really great HTML5 experience on touch devices.

Guess what?  Conventional wisdom got it wrong.  Ever since the early iPhones Safari has had great touch-specific features and the problem is, as is common in the web, few people know how to use them.

Today all of that changes.  At jsconf this morning Evin and I, representing the SproutCore project, got to show for the first time SproutCore Touch.

SproutCore Touch is the first edition of SproutCore that includes complete support for touch events and hardware acceleration on the iPad and iPhone.  It will also eventually work with Android, Palm once we have a chance to work with those platform vendors to tie into their custom features as well.

So in addition to supporting low-level browser features SproutCore also integrates touch into our high-level views.  For example SC.ScrollView supports hardware optimized scrolling which some people said was impossible!  We also have a bad-ass SC.MasterDetailView that automatically reconfigures your UI to show a sidebar in landscape mode and hides it under a picker in portrait mode.

Since all of our views provide touch support automatically, this means that you can actually use SproutCore Touch to build apps that run both on the iPad and desktop computers.  In fact, we’ve found that usually its easier to build our apps for the iPad first and then desktop next - since things usually just work when you transition.

Touch is the most important innovation we’ve seen in computing in 15 years.  It is completely changing the way people interact with their content.  As developers, we have a chance to really up the experience on our own apps thanks to this new technology.  

Now if your app makes more sense on the web than as a native app, you have a viable way to build something using the only other officially supported platform on touch: HTML5.

If you want to try SproutCore Touch yourself check out our sick new documentation app:

http://touch.sproutcore.com/hedwig

It currently runs on both the desktop (well WebKit, Chrome and Firebox - we are still fixing minor bugs on IE) and the iPad.  

If you want to start building SproutCore Touch apps yourself, first go to the SproutCore Home page, install SproutCore, and then switch to the latest master branch.  All the code is available there today.

The developers who worked on this for the last few months are also hanging on the IRC channel at #sproutcore if you need some help.

Finally, I’d like to give a shout out to all of the developers from Apple and around the world who have worked so hard on getting SproutCore Touch ready.  This new technology has truly been a community effort. We were humbled to get to present all of your amazing work today.

So, please check out SproutCore Touch today.  We can’t wait to see the native-like apps that get built with SproutCore touch.

PS. I should add that SproutCore Touch is only possible thanks to the hard work put in by developers over the last few years to give SproutCore 1.0 it’s incredible performance and speed.  Touch devices run fast web browsers on slower hardware.  Without that baseline performance, we never could have built this experience in such a short time.

Ajaxian » SproutCore @ JSConf: SeedJS, great features, amazing demos