Things are taking off for folks interested in starting local user groups! 2009 saw the resurgence of the San Francisco group, and thus far, just in January, groups have been announced in both New York and Chicago, with dates on the way. If you’re interested in starting a group in your area, we’d love to help you get off your feet! Send us an email and we’ll get in touch :)

The next edition of the San Francisco User Group will be all about the docs—we’ll be gathering, hackathon style, to work on general documentation and the new SproutCore Guides. There’s been a major recent interest in getting our documentation resources up to snuff to keep up with the growing number of new developers looking to dive in, and this is the perfect way to keep the momentum going.

There’ll be a small, but not too small group gathering on-site in San Francisco, and a number of folks joining us via the web. We’ll start with some intros, talk about how to divvy up the work, and then pair off. SproutCore Core Team members Yehuda Katz and Peter Wagenet will be on-site and online leading the festivities and answering questions.

If you’d like to join us, on or off site, be sure to RSVP. To attend in person (there *will* be pizza and drinks, courtesy of the folks at Strobe), hit the main Meetup page. To join us remotely (and there are, alas, only a small number of spots, to be sure we can work with everyone in attendance), there’s a separate Meetup invite for you.

I (Charles) will be speaking at the Facebook HTML5 tech talk next week on SproutCore.  If you’re in the area and curious to learn what it’s all about, come check us out!

Great series of articles on using SproutCore’s built-in unit testing library for BDD.

First San Francisco meetup in a long time. Yehuda talks about project amber. Sorry about the audio this was recorded with an iPhone. Next time we’ll have a more professional recording.

Yehuda’s slides are now available as well. Enjoy!

SproutCore: Amber <object height="355" id="__sse5953832" width="425"> <param name="movie" value="http://static.slidesharecdn.com/swf/ssplayer2.swf?doc=amber-101128152244-phpapp01&amp;stripped_title=sproutcore-amber&amp;userName=wycats"/><param name="allowFullScreen" value="true"/><param name="allowScriptAccess" value="always"/><embed allowfullscreen="true" allowscriptaccess="always" height="355" name="__sse5953832" src="http://static.slidesharecdn.com/swf/ssplayer2.swf?doc=amber-101128152244-phpapp01&amp;stripped_title=sproutcore-amber&amp;userName=wycats" type="application/x-shockwave-flash" width="425"></embed></object> View more presentations from Yehuda Katz.

We, on the SproutCore Team, would like to introduce the community to our newest Core Team member: Michael Cohen! Michael has been a very enthusiastic member of the SproutCore Community and has release some amazing code for SproutCore. He is the main author and designer of the Lebowski Framework. Lebowski was developed to use-case test large SproutCore applications namely Eloqua10. He has worked extensively with Core Team members: Mike Ball (@onkis) and Evin Grano (@etgryphon), on the statechart implementation for SproutCore (formerly called Ki).

Michael has also been a incredible community member and helping people understand how to learn SproutCore with his blog: Keeping Sanity One Smelting Accident at a Time. He is currently employed at Eloqua as a Senior Developer along with other core team members: Evin Grano and Mike Ball. We expect great things from this gentleman from the north. You can follow him on Twitter @frozencanuck and on Github: FrozenCanuck

SproutCore 1.4.4 is now out! This is mostly a bug fix release, though there are a few things worth noting.

First off, anyone on the bleeding edge of Chrome may have noticed some odd behavior on Chrome 9. This is a bug in Chrome 9, but we’ve added in a workaround so you don’t have to wait on them to fix it.

We’ve also added support for enabling Chrome Frame in your app, just set :chrome_frame => true in your Buildfile config and then we’ll automatically add the appropriate meta flag to your index.html.

SC.copy also now has support for deep copy. This means that all children of the item that you’re copying will also be copied. To use this, do SC.copy(obj, YES).

Also, we’ve added a property called SC.buildMode that will return a value of ‘debug’ when you’re running from sc-server.

And finally we’ve added support for custom MIME types in sc-server. Set :mime_types => { '.suffix' => 'mime/type' } in your Buildfile config to get sc-server to use the appropriate MIME type. Remember, this will only help you in development, you’ll need to configure your deployment server separately.

As always just run gem install sproutcore to get the latest goodness, and feel free to comment here or reach out elsewhere if you’ve got questions.

You’ve all been asking for it, and it’s time to deliver! It’s been a nice long while since our last few meetups (embarrassingly long, even—don’t look it up…), so you definitely want to join us for this one, as we get things kicked off again.

We’ll be meeting on Tuesday, November 23rd, 6:30 p.m. in downtown San Francisco (SOMA, to be specific) for our first proper SF Meetup. Get to know SproutCore creator (and the evening’s MC) Charles Jolley, along with members of the SproutCore Core Team—Evin Grano, Yehuda Katz, Peter Wagenet and more—as they walk us through some of the latest and greatest developments in SproutCore. We’d also love to hear about how you’ve been using SproutCore, so come prepared for lightning talks!

Our friends at Strobe will be sponsoring with pizza and drinks, and Engine Yard will be hosting. The space is great, but is limited, so be sure to RSVP via Meetup. See you there!

FrozenCanuck introduces Lebowski for the SproutCore framework.  If you aren’t using automated testing to verify your app, you should be.  If you claimed you couldn’t do it because you didn’t have any tools…well now you don’t have any excuses.  Get to it!

There have been enormous leaps in browser technology and computers that have made rich internet apps and cloud applications no longer a figment of someone’s utopian dream, but a reality that can be acted on today. I want to take you on a journey how my company, Eloqua, did just that, take an utopian dream of the best web application and made it a reality, with SproutCore.

How do you decide what technology to use?

Well, the journey started about a couple of years ago, even before I came to Eloqua. Eloqua was the market leader and really the inventor of the marketing automation space. This space is where the marketing teams and the sales team work to get the right information to the right people at the right time. In order to grow your business, timing is crucial. Eloqua had built an application from the ground up over the last 10 years. It had all the successes and failures that come with inventing a space. Now that they succeeded in inventing the space, it was time to start the revolution all over again. Eloqua now needed to change the game because the space was starting to get crowded and we all know that unless you are innovating and catching the next wave, soon the market leader can become yesterday’s technology footnote in Wikipedia. This is when Mike Ball and I came onto the project and it was called Eloqua 10…

We were looking for the next greatest thing in web technology and we started to see this resurgence in an age old idea: returning to fat clients with business logic and thin servers, but all with a new significant twist. These apps were done with more native code for the browser like JavaScript and plugins and made the web more like native desktop applications. So which technologies are we to use to to do this? How do you make a great user experience across the web? Well, first you need to see if people have done it before. So we started to look around the internet for web applications that do what we wanted to do. We found a couple of examples of really cool applications that are pushing the envelope of what is possible. Applications like:

• 280 Slides from the guys at 280 North
• Photoshop Express Editor
• Squarespace
• Mobile Me

So these applications represent technologies like the following: Cappuccino, Flash/Flex, SproutCore, jQuery, ExtJS and others. But, what if you want to make a more sophisticated application than these? What if you want to push the envelope further? You have to choose the right technology and make it do a little more than what you have seen before. That is how you become a thought leader and that is how you innovate and stay on top of your game as a technology company. So how do these technologies stack up?

We worked and studied every one. We made sample applications with each when available and through this trial effort and working with people we came out with a clear winner…

…SproutCore

SproutCore was a new technology, but was moving in the right direction and at the right time. We had a list of features that were required by the framework that we were to use:

• Required! Must have a quick load time.
  • Answer: Only SproutCore has bundling to get load times down.
  • Answer: SproutCore makes is easy to do things like deferred evaluation.
• Required! We had a legacy system so we needed a good solution for gathering data from an established system.
  • Answer: Only SproutCore had a fully unified data store architecture.
  • Answer: SproutCore was backend-agnostic so we were able to connect seamlessly with a legacy backend and develop in parallel.

• Required! We had a need for fast and snappy application for getting large amounts of data.

  • Answer: Only SproutCore has things like SparseArrays to speed up data delivery

• Required! We were going to try some new and innovative things that we haven’t seen before so we needed a platform that could easily adapt.

  • Answer: SproutCore has a great extensible architecture and since it is only JavaScript we can do what we needed to do when we needed to do it

Clearly, Only SproutCore provided the basis for innovation that we were looking for. We looked at the principles that it was based on, inspiration from Cocoa, but not limited to that framework. SproutCore used the limitations of the web in resources and used to its advantage to make an awesome desktop-like experience. And better yet it was free and open! We, as an engineering team, decided that we were going to be an open company with our technology. We needed to find a project that supported those ideals. We also needed a project that was backed by at least one respected company, was stable, and looked like it had the brightest future. Again, the only clear winner was SproutCore.

Now that we have chosen to use SproutCore we needed to see how far we could push it. So we wanted to innovate and release it to the SproutCore Community. Here is a small list of features that came directly out of our work with Eloqua that we have open sourced:

• SCUI: One of the first official third party libraries that provides the following features:
  • LinkIt: directed and non-directed graphing library that came from our work in Campaign Canvas work flow in Eloqua 10
  • Dashboards: a OSX/Windows 7 dashboard like framework
  • Foundations: Lots of the missing UI elements that we wanted to release like Calendars, Datepickers, mixins and other views that are helpful
• SCUDS: Local data storage with cascading data sources
• Lebowski: Our testing framework for Sproutcore-specific applications
• Greenhouse: the free SproutCore IDE that comes directly from our with with our work in the Email and Landing Page Editor. Only possible with the power of SproutCore’s design framework
• Sai: The VML/SVG vector graphing library
• Ki: Statecharts for the Faint of Heart for building really world class level applications
• Tasks: This is the project management tool that we use internally to deliver our project on time

So we have accomplished something remarkable in Eloqua10. If you would like to see and here more about this application you can check it out at:

• Eloqua 10
• The Day “Or” Died: Eloqua10 Launch

So the question still is: How do you really build large impressive web applications? You choose SproutCore. The market has just taken notice. In fact, tech analyst commented that this could be one of the greatest reinventions of a SaaS company in history. We could have only done this with SproutCore and the great community behind it. I am proud to call myself a Core Team member and I am really proud of all the work that my team at Eloqua has done.

They always say, “Fortune favors the bold” and when choosing technology for a large project like ours you have to find a technology that is shooting for a spot in the future. We are looking to keep pushing Eloqua and SproutCore to new and greater heights.

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

SproutCore 1.4.3, a bug fix release, is out now! Just gem install sproutcore to get the update. For more information see the Changelog.

For the first several years of SproutCore’s life, we shipped a fast, minimal jQuery clone that powered our view layer. As of SproutCore 1.4, we integrated jQuery proper into SproutCore’s view layer. I thought it might be worth taking a few minutes to explain why we made this change and what it means for our project.

Why?

In the past, we tried to stay relatively DOM library agnostic.  You could use Prototype, jQuery, MooTools, or whatever else you wanted.  SproutCore would do its best not to depend on any of these so you didn’t have to pay the cost of loading a library you didn’t own.

Since we made that decision, things have changed somewhat on the web.  jQuery adoption, in particular, has skyrocketed.  Not that these other libraries aren’t used, but today it’s common to find most sites using jQuery alongside them for one or two things.

In short, we believe jQuery has become a nearly standard library of the web. In many ways, it is no longer just about one project but really belongs to the web as a whole.

Because of its degree of use on the web, it is by far the best way to work with the APIs exposed by the web browser. And while it was once somewhat sluggish compared with hand-rolled code, jQuery is now usually *faster* than the code you wrote yourself. The jQuery team has spent years building features with and an expert-level understanding of the browser environment and API.

Here’s one example: did you know that when you use `$(“

”)`, jQuery caches a document fragment that it reuses every time you use the same String value? (Did you know there was such a thing as a document fragment?). To avoid memory bloat, jQuery applies heuristics to the String based on real-world usage. The widespread use of jQuery and the team’s focus on real use cases has afforded the library a careful balance between all of the factors that go into using the browser efficiently.

Having spent almost half a decade pushing the limits of the browser, we’re familiar with a lot of these tradeoffs. In many cases, jQuery 1.4.3 will be faster and more efficient than our code. In some cases, because of the ways that SproutCore has been used, our techniques are more efficient. Starting with SproutCore 1.4, we’re going to be contributing time and resources to jQuery, which is crucial to our own success.

SproutCore for the Rest of Us

While we are integrating jQuery further into SproutCore, we thought we might take this opportunity to make SproutCore more accessible to regular jQuery developers as well.

SproutCore has always been built as a modular framework. We’ve always wanted people to be able to use SproutCore’s runtime library and data store as standalone JavaScript libraries. Unfortunately, we didn’t put in the effort to ship them as separate libraries. 

In the weeks ahead, I’ll put in the bit of work necessary to make them releasable as standalone libraries. While I’m at it, I’ll reduce duplication with jQuery’s own utilities, which should make the SproutCore Runtime and SproutCore DataStore libraries fit in nicely in the jQuery ecosystem.

The goal is to make it easy to use the parts of the SproutCore libraries that you want without having to jump head-first into the full SproutCore experience. SproutCore’s binding system, batched DOM changes, and data store are battle-tested libraries that can significantly improve the structure of your applications.

I also plan to create jQuery plugins for these components so that you can use the SproutCore binding system as a normal jQuery method. The SproutCore team has spent some time on extending jQuery to allow DOM manipulations to be batched up and persisted all at once, and I’m working with John to make it easier for us to release a well-behaved jQuery plugin that won’t break as new versions of jQuery are released.

If you’re interested, it will probably work something like:

  var $ = batchedjQuery;
  $("#item")
    .addClass("active")
    .addClass("selected")
    .css("color", "blue")
    .flush();

This becomes increasingly useful when paired with the SproutCore run loop, which allows you to make these changes in various functions, and trigger the batch manipulation at an appropriate time. This technique is baked into the way SproutCore works, and it’s partially responsible for the performance of large SproutCore applications like MobileMe. Why shouldn’t you be able to get the same benefits in traditional jQuery applications?

And when you’re ready to jump in and do a fast, native-style application, the full SproutCore framework will be ready for you.

This won’t change the direction of the SproutCore framework itself or its API. It will simply make SproutCore’s tools more accessible to a wider audience of jQuery developers who are not yet ready to jump on the SproutCore train.

Closing

Like I said, jQuery belongs to the web. Contributing to the health and success of the jQuery library helps all web developers by giving us a shared place to work on innovative ways to use the tools that the web browsers give us. As browsers continue to improve those tools, the web community increasingly needs a place to share the work to make new features accessible, and there’s no better place than jQuery.

Post by Yehuda Katz

The Selenium Meetup group is hosting Michael Cohen, creator of the excellent Lebowski Testing tools, to discuss how you can use Selenium and Lebowski to automate testing of your SproutCore app.  

The event is in San Francisco on Oct 21, so if you are in the area be sure to come by. 

At long last, SproutCore finally has its own twitter account!  Follow us at @sproutcore for frequent updates.  Also, if you are a SproutCore developer, let us know and we’ll add you to the @sproutcore/developers list so others can find you too.

SproutCore has now been updated to 1.4.2! This is a minor patch release with a handful of bug fixes to both the framework and to abbot.

In Abbot, we fixed a regression that caused sc_require to fail with uppercase filenames. We also fixed an issue that caused sc_static to load files that only partially matched the requested filename.

Additionally, we made a couple fixes to SC.DateTime and fixed Tab key behavior for SC.SelectFieldView.

To get these updates, just run gem install sproutcore.

Late last night we merged the quilmes branch back into master. The merge includes all changes from quilmes, along with the fixes from master. This means that we now only have two major branches: master, new home of the quilmes code, heading towards 1.5 and 1-4-stable for the 1.4 code.

1-4-stable is a bug fix only branch. Any new features should go into master. If you do have a bug fix for 1-4-stable, please check to see if it also applies to master and vice-versa.

Also, a reminder for those of you who missed it. The git repo has now moved to the sproutcore acccount at github.com/sproutcore. If you have not done so, please update the remote on any cloned repos you have as follows:

git remote rm origin
git remote add origin git://github.com/sproutcore/sproutcore.git

If you have SproutCore as a submodule, open your .gitmodules file and update the references there as well.

Hot on the heels of the 1.4 release, we’ve now released 1.4.1. This is a very minor bug fix release with one fix each to Abbot (the build tools) and the Framework. In Abbot, we fixed an issue with string escaping in a call to the YUI Compressor in sc-build. In the Framework, we changed SC.Request’s X-SproutCore-Version header to report 1.4 instead of 1.0.

To get the update, just run gem install sproutcore.

Those of you who have been following SproutCore may have noticed the appearance of a series of Release Candidate gems for version 1.4. Today, we’d like to offically announce the release of version 1.4! Why the jump from 1.0? We’re going on a year since the first release of 1.0 and almost exactly eight months since 1.0.1046 and a whole lot has happened since then. This release has over 1000 new commits and around 20 new contributors.

Thankfully, you won’t have to deal with long release cycles in the future. SproutCore 1.5 is already coming along nicely. We hope to release it before the end of the year. We’ll continue to maintain SproutCore 1.4 as we move forward with bugfixes. If you’re interested, you can follow that work on the 1-4-stable branch on Github. Apple has done quite a bit of work that they plan to contribute back to the project soon. After that, we will merge the work that we’ve done so far on SproutCore 1.5 (code name Quilmes) with the parallel work we’ve done on SproutCore 1.4.

From here on out, we’ll be releasing pre-release gems regularly as well as patch releases for bug fixes. You can get the most recent SproutCore pre-release by running gem install sproutcore --pre and the most recent stable release by running gem install sproutcore. No more eight month waits!

Along with the release of 1.4 we’re also moving the SproutCore repos over to github.com/sproutcore. To update your current repositories:

git remote rm origin
git remote add origin git://github.com/sproutcore/sproutcore.git

We’re also starting to make plans for SproutCore 2.0 which will bring some awesome new improvements. As we design and develop 2.0, we’ll keep you up-to-date with the changes we are planning and give you previews of the new features. One of the most exciting changes in the releases ahead is the ability to package up and share SproutCore components (even with dependencies!) as easily as the best facilities in other languages. Stay tuned for more details!

Along with these new releases also come some major SproutCore personnel changes. As you may have heard, Charles Jolley has left Apple and started a new company around SproutCore called Strobe Inc. Long time SproutCore contributors Peter Wagenet and Colin Campbell have both joined Charles at Strobe. As you may have already heard, Yehuda Katz and Carl Lerche of Rails 3 fame have also come on board as Strobe employees and will be major contributors going forward!

What’s New

By now you’re probably wondering, “Well, what is new in 1.4?” As I said earlier we had over 1,000 commits so this is just a brief overview.

Touch Support

We now have extensive support for touch events. All SproutCore controls now support touch events natively. This means that with minimal effort, you can get your SproutCore apps running on the iPhone, iPad, and other mobile devices! More touch controls are coming in 1.5 but the foundation is here now. For more info read the original blog post.

Faster Build Tools

One of the first contributions by Yehuda has been to speed up Abbot. Importantly, reloading your application after making a change will take one or two seconds, rather than the 10 to 20 seconds it took in SproutCore 1.0. That makes a huge difference to your ability to make small changes and see them reflected immediately in the browser.

There are a few changes you should be aware of:

• The SproutCore 1.4 build tools expect your files to be saved in UTF-8. This is almost always true, but you may have some files saved in a different encoding. The build tools will give you an exception if this happens, and you will need to resave the files in UTF-8. If you use Textmate, you can use the Save As dialog to change the encoding.
• You may be used to using the build tools directly from Github. In the future, you’ll want to use the prerelease gems (using gem install sproutcore —pre), and only use the tools from Github if you are actively hacking on the tools themselves.
• If you want to use a different version of SproutCore than those that ship with the build tools, copy or symlink it to the frameworks directory in your app.

Bug Fixes and Stabilizations

Many of the commits in 1.4 also dealt with bug fixes and stabilization improvements. SproutCore should overall provide a better, more solid experience. We’ve also put in some additional browser compatibility improvements so you should have a better cross-browser experience as well.

Universal Error Handling

Previously when fatal errors occured, your app would just stop working, often without warning. We’ve now introduced a new error handler called SC.ExceptionHandler. The default error handler is very basic so you may want to provide your own version. Just overwrite SC.ExceptionHandler with an object that has a function called handleException. This function will be called with the exception as the single argument. Alternatively, you can overwrite only the handleException function as such:

SC.ExceptionHandler.handleException = function(exception) {
  // default
  if (this.isShowingErrorDialog) return;
  this._displayErrorDialog(exception);

  // you can use any error handling code here
}

Animation Support

Though this feature was actually present in 1.0.1046, it was never officially announced and has largely flown under the radar. SC.Animatable supports both traditional timer-based animations and hardware accelerated animations using the same API. This means that you can build animated SproutCore applications that look gorgeous on iPhones and modern browsers with hardware acceleration support. For more information see the README. Oh yeah, we’ll also be bringing even more animation support in 1.5.

Experimental Features

In addition to these production ready features we also have some new experimental features as well thanks to the great work of the SproutCore community.

Greenhouse

A full-fledged interface builder for SproutCore written in SproutCore! While not quite ready for production use, we’re continuing to work on this and are working hard to bring you a way to build your web apps in a web browser. We think this is the future of SproutCore view development, so keep an eye out for a lot more in the coming months. Find out more in the announcement blog post.

TableView

A long asked for feature, a preliminary version of SC.TableView is now in 1.4. While it has some issues, it does work and if you’re feeling adventurous you may want to try using it in your apps. If you make improvements please contribute them back to SproutCore. Other people like you might even pick up the ball and run with it. See the blog post.

CollectionView Fast Path

Make your CollectionViews much faster—and make them scroll with much better performance on tocuh devices—with SC.CollectionViewFastPath. This is somewhat experimental and is not yet thoroughly documented, but should be mostly ready for production use. Consider it beta level.

Community Contributions

Not only has interesting stuff being going on in core, but a lot of interesting community projects have been going on as well.

SCXIB

In addition to Greenhouse there is now an alternative way to develop your app interface. SCXIB will load your XCode Interface Builder .xib files and turn them into SC views on the fly while you edit the interface in Interface Builder and reload your app. It even supports custom SproutCore classes! So you now have three options: Greenhouse, SCXIB, or the way you’ve already been doing it.
Github

SproutCore UDS

A universal data source for SproutCore that includes support for backends like Rails and CouchDB. Also supports common public APIs like Twitter, with planned support for Amazon, Facebook and Github. And if that wasn’t enough, it also supports local storage! Expect to see a lot more work on drop-in, flexible data stores for SproutCore 1.5 and 2.0. Github

Sai

A SproutCore vector graphics library that supports all major browsers.
Github

Ki

Statecharts for SproutCore. That pretty much says it all :)
Github

Get Involved

Code Contributions and Bug Fixes

As always, SproutCore relies on your contributions. If you find a bug or want a new feature, consider helping us out with it.

All you have to do is fork the repo on Github and send us a pull request. We really love Github’s new pull request feature, and it lets us process your patches quickly and efficiently. Just please do us a favor and send a separate pull request for each major issue that you’re addressing. Learn more about the new pull requests in the announcement blog post

If you run into an issue but can’t figure out how to fix it, please submit a ticket at either http://github.com/sproutcore/sproutcore/issues for the framework or at http://github.com/sproutcore/abbot/issues for the build tools. We’re keeping a close eye on the issues and closed quite a few during the release candidate.

Documentation

SproutCore’s Achilles’ heel has always been its documentation. No longer! We’ve started a major push to improve the documentation, and have been doing some interesting experiments with documentation (you might have noticed that the Touch documentation is in a beautiful new documentation engine codenamed Hedwig). If you’re interested in being a part of this let us know and get in on the discussion in sproutcore-dev@googlegroups.com.

Appendix

New Committers since 1.0.1046

• Alex Johnson
• Andrew Dupont
• Brian Moore
• Brian Noguchi
• Bruz Marzolf
• Eric Kidd
• Joshua Holt
• Julian Viereck
• Luke Burton
• Matthew Grantham
• Matthias Loitsch
• Michal Kurgan
• Mitchell Rivera
• Nathan Baxter
• Patrick Walton
• Richard Klancer
• Robert Buchholz
• Ryan Nielsen
• Yehuda Katz

(Some may be missing from this list. Sorry!)

1.4 ChangeLog

Check out the massive (and incomplete) list.

Post by Peter Wagenet with help from Yehuda Katz and Devin Torres

Want to follow or discuss developments on the internals of SproutCore?  Now there is a mailing list just for you!  

The JSConf presentation that started it all.  Now available on blip.tv!  JSConf 2010 

We’re having a SproutCore meetup in Paris on Tuesday, August 3th at 8:00 pm (EDIT: we originally planned to do it on the 5th but we had to reschedule). 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!

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…

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!

There’s always been a little confusion over what exactly you’re downloading when you get Sproutcore.

Sproutcore Abbot

Abbot is the name for the new-ish build tools that compile Sproutcore 1.0 projects. It includes all of our favourites, like sc-gen, sc-server, and sc-build. When you do

gem install sproutcore

what you’re actually downloading is the Abbot build tools.

Then How Do I Get Sproutcore?

The Sproutcore Javascript framework is included with the Abbot build tools. This is why when sc-init’ing a project, you don’t need to do anything as far as downloading the JS framework to access the Sproutcore code.

How Do I Stay Up To Date With The Framework?

Using the most recent revisions to the JS framework that is on Github is really simple. As I mentioned in the last post, you cd into your project directory and run

mkdir -p frameworks && cd frameworks
git clone git://github.com/sproutit/sproutcore.git

This will get you the most recent master branch in a “frameworks” directory. The Abbot build tools are smart enough to use this copy of the JS framework, rather than the one it downloaded in the gem install process.

It’s worth mentioning now that we’ve made a lot of progress towards Sproutcore 1.1, and the code lives in the Quilmes branch. If you’d like to use that latest awesome sauce, you can create a git tracking branch like so

cd your_project/frameworks/sproutcore
git fetch
git checkout -b quilmes origin/quilmes

Staying Updated with Abbot

Abbot doesn’t move nearly as fast as the JS framework (at least, not anymore) but there are still occasional fixes that get implemented that are nice to have around, instead of waiting for new gem releases. If you’re in your project directory, cd out and checkout abbot by doing:

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

This will create a folder “abbot” in the same directory housing your project. Then when you want to run sc-server, say, from inside of your project directory, you just run

../abbot/bin/sc-server

And voila, you’re using the most recent revisions to Abbot.

Hopefully this alleviates some confusion over what exactly Abbot is and how it is different from Sproutcore the JS framework.

Including external code in your project is very important in saving time and headaches with Sproutcore. In this post, I’ll quickly go over how to add Sproutcore UI to a project.

sc-init MyProject && cd my_project

Now that you’ve got a generated Sproutcore, we’re going to create the frameworks folder.

mkdir frameworks && cd frameworks

Now we’re in the frameworks directory. The Abbot build tools are cool enough to know that anything in here should be included in the build process (once we add the framework to the Buildfile). First things first, let’s download the Sproutcore UI package using git:

git clone git://github.com/etgryphon/sproutcore-ui.git scui

This will create an scui folder inside of your frameworks folder that contains that latest code. Now, open Buildfile in the project’s root directory, and you’ll see

config :all, :required => :sproutcore

I like to keep my requirements explicit (ie, don’t use :all). Instead, add this line after what’s there:

config :my_project, :required => [:sproutcore, :scui]

You should now be able to use the Sproutcore UI code inside of your app.

Bonus

For those of you that don’t know this, you can actually add Sproutcore to your frameworks directory, and it will override the one that came with Abbot. This is especially handy if you want to follow the master or quilmes branches at the Sproutcore git repository, instead of using the already stale 1.0 release.

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

Sliders: Themed.

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

Pointer buttons, too!

Capsule buttons!

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.

File this under “Amazingly Easy” when using a new modification to Chance.

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