Bitburger is the code name for SproutCore 1.0. The purpose of this project is to finish the remaining changes that are necessary to reach a Beta candidate. That means SproutCore must be “feature complete” according to the targets outlined here, and it must generally function on all platforms.

 

If you are interested in testing or hacking Bitburger, this wiki page will introduce the objectives of the project, the current work plan, and finally describes both how to try Bitburger yourself and how to hack/make contributions.

 

Status

The project is currently in beta state.  All major APIs are complete.  Only bug fixes remain.  Bitburger has a full suite of unit tests but they are not verified to run on all platforms yet.  

 

Bugs that need to be fixed will be documented in our Lighthouse bug tracker, tagged as "bitburger" and "beta"

 

Useful Links

• New View API Notes.  Engineering notes for the new view API.  Better documentation will be forthcoming once API settles.
• Upgrading to 1.0 alpha from bitburger or pre-bitburger. A must read if you plan on upgrading your app.

 

Purpose

The purpose of SproutCore is to make it easy for anyone to create a desktop-quality application experience in the web browser without the use of plugins. Currently SproutCore delivers a lot of functionality in a fairly small API, including some unit build tools However, there are some areas in both performance and API ease-of-use that we could still improve.

 

We’d like to hit a baseline with 1.0 that will make it obvious to any casual developer that SproutCore is the best way to build their next rich thick-client web application.

 

Objectives

Specifically, we plan to address the following areas in Bitburger:

 

1. Performance and Memory Consumption with Large Data Sets – In particular the performance of bindings, observers, the data store and views should work well when working with large data sets.
2. Make Timing More Consistent – When a property changes, the way that change propogates through all of the objects in the system via bindings and observers should be consistent and easily predictable. This will eliminate most of the glue and gating code developers write today.
3. Framework Size – Developers should be able to trim the framework down to whatever size they need depending on their project objectives.
4. Normalize and shrink the API – As the current API has developed over 2 years, it has picked up some “legacy” API that is no longer best practice/recommended. The API will be smaller and easier to predict if this legacy API is removed and/or normalized to use current best practices.
5. Become DOM-library Agnostic – Currently we require Prototype. This is bad both from a framework size and from a strategic perspective. SproutCore lives above this layer anyway; we should give developers a choice of library that best suits their needs.
6. Make Views Easier to Build – The current method for working with views (using Ruby view helpers) requires a level of indirection (write this view helper that generates your code…) that is hard for most people to grok let alone debug. Make this easier for developers to work with.

 

Work Plan

Here are the specific changes we are currently planning for bitburger to achieve our above objectives. (click on the link for more in-depth notes). The items with a “Done” or “In-progress” next to them currently have developers actively work on them. The others are still planned. If you would like to get involved, think about picking up in one of these areas.

 

Must Haves

These tasks must be completed before SproutCore 1.0 Beta 1 can be released. These tasks are simple enough that anyone just getting started with SproutCore could do them.

 

• (DONE) Scrub the API - Every class should be reviewed to make sure it follows current SproutCore API Best Practices (see the detail page for this task for best practices).
• (DONE) Improve Unit Testing Framework - Unit tests should be pure JavaScript instead of living inside of an HTML page. It should also integrate Qunit and provide more helper methods for testing SC code to make unit testing easier.
• (DONE) Unit Test The API – All levels of the API are irregularly tested. We need better unit tests that can pass on all platforms.
• (DONE - thx amazingsyco!) SC.Request - Add a simple API for making Ajax requests to replace the Request object formally provided by Prototype. The new request object should use SC property observing to simplify the API. (See detail page for notes)
• (DONE) Speed up SC.Store/Collections – The SC.Store/SC.Collection code is quite old. Build unit tests to test it against large amounts of data and optimize it.
• (Done – thx ttdonovan!) SC.json – Revisit the JSON API to use the updated version of the JSON encoder/decoder from json.org The current version modifies built-in globals such as Object, which means it does not play nicely with all DOM libraries.
• (Done - thx martoche!) SC.time - Currently we enhance the Date object to provide some formatting options. We should replace this with an SC.time that (a) does not enhance the Date object and (b) reuses a single Date object to perform time calculation. This will speed up time comparisons dramatically for apps that rely heavily on dates.
• (Partially Done) Verify IE Compatibility – All unit tests must pass under IE. If a bug is found in IE, we need a unit test to make sure we keep it fix. This is part 1 of IE support goals. See Nice to Haves below…
• (Done) Sc.Routes – The current SC.Routes code consumes too many resources when checking for location changes. Revisit SC.routes to instead simply use setInterval() and only start a run loop when they have a location change to process. Also, consider renaming to SC.routes (lowercase ‘r’) to fit with API best practices. This will also reduce memory consumption considerably.
• (DONE) Use Only SC.Enumerable/SC.Array API – We currently use some of the array enumeration methods provided by Prototype throughout SproutCore. These uses should be replaced with calls to the standard SC.Enumerable/SC.Array APIs or to use more built-in methods such as forEach() or simple loops. This will allow us to reduce dependency on Prototype.
• (Done) CoreQuery – Clone a subset of the DOM-manipulation layer in jQuery for use inside of SproutCore views

 

Must Haves But Harder

These tasks are considered “must haves” for SproutCore 1.0 Final, but they are complex and/or require a great deal of detailed knowledge of SproutCore internals. Some of these may be not be finished before the Beta is released to avoid blocking the project.

 

• (DONE) Improve Build Tools - Several performance gains are planned for the build tools (see detail page for more info).
• (DEFERRED - Post 1.0) CoreQuery Animations – Add jQuery-complatible plugin for CoreQuery that implements simple animations/transitions using CSS Transforms, if available. Optimize for memory use. Animations are highly susceptible to problems with memory object allocation.
• (DONE) Revisit View Layer – Investigate ways to make the view layer faster, possibly by placing some additional constraints on the kind of HTML design you can use with views. (e.g. always require absolute positioning).
• (DONE) Eliminate SC.Application/SC.window – currently events are dispatched to views using a haphazard mixture of SC.Application, SC.window, SC.Responder & SC.InputManager. This can be simplified quite a bit to make the flow simpler and reduce total code.
• (DONE) Revisit Property Observers – Property observing should be optimized to avoid allocating memory, relay only when properties change, and introduce consistent timing rules for triggering observers and bindings.
• (DONE) Event Handling – Implement a low-level library for safely listening for events on DOM elements to replace the one provided by Prototype.

 

Nice To Haves

These tasks would be nice to have in SproutCore 1.0 though we would not block the release of the initial beta if they were not present.

 

• (DONE - Pending Legal Review) Add Store Chaining – Store chaining would allow you to tie together multiple stores, servers, local caches, etc. to manage your data. This will make it vastly easier to work with buffering changes to complex object graphs than the current mechanism provided by controllers. See detail page for more info.
• (DONE) SC.SparseArray – Implement (with unit tests) a simple SparseArray that will implement the SC.Array interface but notify a delegate whenever you try to get an object index that has not yet loaded. This will allow for progressive loading of data. Hook into CollectionView to properly notify sparse array of the range of data the CollectionView will need to display.
• (Partially Complete - Pending Review) SC.Menu – The current menu view requires you to create a individual views for each menu item. Redesign the menu API to instead dynamically build HTML for the menu when it needs to be displayed. This will be much faster and reduce the amount of code required for views. Also, we want to introduce a global menu bar, that can be optionally hidden at the top.
• (DONE - File bugs if any found) Eliminate All Memory Leaks – This is especially a problem on IE. This will be fixed before we go final, but will not block a Beta release.
• (DONE) Make IE Fast – IE7/8 must perform “well enough”, but we would like to make them really fast; and possibly even add IE6 support. These are long term goals, however, so they will not block a 1.0 release.
• (DEFERRED TO POST 1.0) Revisit SC.FormView – FormView’s currently have some old buffering code that is no longer needed because Controllers provide change buffering. FormView should be reduced to just provide an automatic “wrapping” ability for views. Less code = smaller size & faster

 

How to Try Bitburger

To try bitburger, you just need to get a set of the most recent tools on your computer. Assuming you already have the release version of sproutcore installed (“sudo gem install sproutcore” if not), then you can setup using the following commands:

cd [YOUR PREFERRED WORKING DIRECTORY]  
git clone git://github.com/sproutit/sproutcore-buildtools.git buildtools  
git clone git://github.com/sproutit/sproutcore-samples.git samples  
cd buildtools  
git checkout -b bitburger origin/bitburger  
git submodule update --init  
cd ../samples  
git checkout -b bitburger origin/bitburger  
cd frameworks 
rmdir -p sproutcore  
git clone git://github.com/sproutit/sproutcore.git sproutcore  
cd sproutcore  
git checkout -b bitburger origin/bitburger 

 

You now have all of the SproutCore code downloaded and ready for use. To start your sc-server, you need to use the Abbot version of the build tools. Just do the following: 

cd [YOUR PREFERRED WORKING DIRECTORY] 
cd samples ../buildtools/bin/sc-server

 

Now you can load any of the sample apps to try things out.

 

If you would prefer to try bitburger with your own project, then do the same thing as above, but instead of cloning the “sproutcore-samples” project, you can clone your own project. Checkout sproutcore into the frameworks/sproutcore directory of your project and checkout the buildtools as described above.

 

How to Hack Bitburger

Have you found a bug with bitburger? Would you like to help us reach 1.0? Or maybe you have an idea for some extra feature you’d like to add? Sounds like you want to hack some bitburger.

 

The best way to hack bitburger is to work on your own fork at github. Then send us a pull request when you have something interesting to contribute. Just follow these instructions:

 

• Setup your own github account. If you don’t have one already, just visit http://github.com to signup.

• Fork SproutCore Visit the web pages for each of the SproutCore components on the github website and click on the “Fork” button for each. If you don’t see a fork button, make sure you are logged in with your github account. The component pages are: framework, build tools, and samples

• Get Your Own Forks Once this is done, follow the instructions in “Try Bitburger” above to get the SproutCore source, except replace the portion of the URLs that say “git://github.com/sproutit/...” above with “git@github.com:[YOUR ACCOUNT NAME]/...”. For example, if your github account name was “donjuan”, then the you would clone sproutcore using the url:

  git clone git@github.com:donjuan/sproutcore.git sproutcore

Now you are setup to hack SproutCore. If you want to work on a particular feature above, we recommend that you create a topic branch to work on it. For example, if you wanted to help with the requests, here is what you would do: 

cd [YOUR PROJECT LOCATION]/samples/sproutcore  
git checkout -b requests bitburger    
[HACK AWAY]  
git commit -a -m"Describe your changes here"  

 

When you are ready to submit your changes for us to include in SproutCore, you can just push your changes to your local account on github like so: 

git push origin [YOUR-BRANCH-NAME]

 

Then log into github, navigate to your requests branch (click on your SproutCore project then choose your branch from the “all branches”) and click “pull request”. Send the request to the account “sproutit”.

 

Be sure to describe the change you are making in the pull request message so that we can review it.  We’ll do our best to review and apply changes to bitburger as quickly as possible as long as they relate to the objectives and tasks described above.

 

Thanks for contributing!