This is the planning document for SproutCore 2.0, the next major version release of SproutCore. This is not a final plan and at any time will contain several ideas that may or may not be a part of SproutCore in the future. In essence, this page is meant to gather ideas and stimulate further discussions elsewhere. So take what you read here with a grain of salt, it's a work-in-progress and doesn't represent the official opinions of the SproutCore project.

The following is just some talking points about SproutCore and version 2.0 without getting into too much detail.

• A chance to speed-up the evolution of SproutCore by removing the backwards compatibility requirement. Since SproutCore 1.6, each new version has strived for 100% backwards compatibility with the previous version as per the versioning rules that state that a minor '1.x' release can introduce new API but not break API. However, this puts a strain on each iteration, because some of the old API was not planned well enough and to properly deprecate it and phase it out is slow. With a major release, we can speed up the evolution by revisiting a lot of API without having to be as concerned about breaking changes.
• A leap forward along the SproutCore 1.x path. SproutCore 2.0 will play to and expand on the current SproutCore's strengths. SproutCore is exceptionally good at building complex software for the web. Part of what makes it so good are: the core runtime technologies, the statechart framework, the data store, the UI library (in particular the containing type views), the build tools, etc. SproutCore 2.0 should strive to make all of these parts better and easier to use. SproutCore 2.0 should also strive to address the remaining pain points in web software development.
• A reasonable migration from SproutCore 1.x. Moving a SproutCore 1.x app to SproutCore 2.0 should be reasonably achievable.
• The framework for creating the fastest software for the web. SproutCore is already exceptionally fast, in particular, version 1.10 could be the fastest version yet. However, fast means a lot of things: fast to launch, fast to load, fast to "run", fast to display a dialogue, fast to scroll through a list, etc. In terms of fast to launch, SproutCore is already about as fast as possible. A very small index.html file with a simple loading message is served at the root of all SproutCore apps, which means the actual initial launch is lightning fast. This is not the load speed. At some point after the initial launch, the actual code finishes loading and then the application starts running. SproutCore 2.0 should strive to improve the launch speed if possible. However, launch speed is a very small fraction of the app experience, probably less than 1%. Fast to run, is more important and if you're doing things right, SproutCore is again already about as fast as possible for a lot of things. SproutCore 2.0's job is then to 1) make it easier and clearer to do things right, 2) make it harder to do things wrong, 3) improve the internal performance wherever possible.
• The best and most complete software development platform for the web. SproutCore 2.0 should still be thought of as a platform: a runtime environment, an application framework, a UI library and build tools. You will not be mixing SproutCore into apps based on other frameworks or libraries. And while you could still mix other libraries into SproutCore yourself, SproutCore should strive to provide everything you need or bridges to the "accepted" libraries for doing things (think jQuery, Raphaël.js, possibly Modernizr).
• The platform providing the fastest way to develop software for the web. This is essentially a repeat of the previous bullet, except placing an emphasis on how the tools and components can be used to speed up development. Web app development is still largely a bare metal type of task. Where SproutCore shines is in doing things like generating image sprites that "just work" on retina displays, on slicing images through code, on making view adjustments and animations dead simple, on getting complex controls in your app for "cheap", etc. SproutCore 2.0 should keep adding to the toolset in order to remove as many of the tedious web app development tasks as possible.
• A re-working of the SproutCore 1.x UI framework for small, medium, large and extra large screens and retina displays. Every view and control in SproutCore 2.0 should be usable regardless of the screen size or pixel density.
• An expansion of the SproutCore 1.x UI framework with several new easy-to-use views and controls. Several new views and controls should be added in SproutCore 2.0.
• A framework with a patterned, memorizable and excessively documented API. The 2.0 API should remove all overloaded arguments and non-SproutCore patterns. This is to make the API more memorizable and discoverable. A new developer should be able to guess at what methods will be supported in code they haven't used yet, simply based on the code they have seen. An experienced developer should not have to revisit methods, because they couldn't remember what the arguments are because they can be overloaded.

• A radical departure from SproutCore 1.x.
• A dumbing down exercise.
  It's easy to look at something large and complex and say "it's too big, nobody needs all this, let's trim it down to the fundamentals". This goes for frameworks and business organizations alike, but so-called "re-orgs" are often huge wastes of time and effort. While a re-org can be useful when the current structure doesn't work, it's no guarantee that the new structure will work any better. And when something is pared down to the base, it just means that every user is required to build their own "house" on top of it, with vastly varying results. Architectural code is exceptionally hard to write and when deadlines are looming, it's almost always going to be wrong. Worse, each custom implementation is wildly different, making it hard to learn the code and to maintain a real application when the original developers move off of the project. We believe that a surprisingly high amount of the necessary architectural code is identical between all apps and so each developer should not be "re-inventing the wheel" each time. SproutCore already works and it works amazingly well when you are able to learn it all. Therefore, while SproutCore is large, we believe that in order to do big things, you need a big platform. Or at least, to do big things quickly, repeatably, without breaking the bank on developers and achieving an excellent result, you need SproutCore.
• A drop-in library for a website.

High level goals for SproutCore 2.0

1. Migrate away from Ruby based tools.
2. Improve SC.Object initialization speed.
3. Make styling and theming easier.
4. Make page configuration easier.
5. Reduce load times.
6. Improve development speed.
7. Add new development features.
8. Improve current views and controls.
9. Add new views and controls.

Concrete plans to achieve the above goals.

1. Migrate away from Ruby based tools.
2. Develop node.js debug and build tools.
3. Improve SC.Object initialization speed.
4. Bring SC.Object optimizations over from Ember.
5. Remove use of arguments allowing for variable length arguments
6. Make styling and theming easier.
7. Remove render delegates. Render delegates are fundamentally flawed, because some views can never truly be separated from their rendered output (i.e. they need to understand the DOM that they are creating, because they rely on certain attributes or elements) and most views don't need a render delegate. Quite possibly the only view that benefited from a render delegate is SC.ButtonView, which is only because the rendered DOM of SC.ButtonView is annoying to style especially when trying to override the default style. That said, it's an awful lot of work to write a proper render/update function, when really all you want is to be able to use a pre-built control and give it your own look. So render delegates == not worth the trouble. Instead see below on improving and adding new views and controls for how to approach this.
8. Make style a programmable property of the view.
   Not sure how this shakes out yet, but the idea is to get away from editing CSS files. I [tmk] believe that CSS editing is one of the most annoying and wasteful processes of developing a large app. It's a constant pain to keep some styles isolated and some styles shared and the back and forth between the code files and the stylesheet files is a headache. We already do layout styling in the code and although it's sometimes a tough pill to swallow, it's actually much faster to add a layout property than it is to come up with a unique class or layerId, open a stylesheet file, find an appropriate place and add a new selector with essentially the exact same values but with more typing.
9. Make style a concatenated property of the view. Along the lines of the above idea of making style a property, views would inherit parent view styles. This would prevent cross view style leakage (ex. styles applied to SC.View > SC.MyView have no way of effecting SC.View > SC.MyOtherView) and would make it easier to override styles (ex. You could set some style attributes to null to remove the defaults from the parent, rather than have to override them with an actual value like you do in CSS). I [tmk] know this sounds crazy. After all, we'd be doing exactly what CSS already does. The difference is, making it programmatic makes it easier to change the style, it should be less typing, it will definitely require less file management time, it may actually be faster (long selector chains are slow to traverse) and we may actually be able to reduce the amount of style repetition.
10. Make page configuration easier.
11. Give several views more useful defaults. For example, SC.SegmentedView itemTitleKey could be 'title' by default instead of null.
12. Add automatic child view layout support. Allows you to have child views laid out according to their width or height or visibility or other and to re-position automatically if a dependent property changes.
13. Make localize a global property shared by all views.
14. Reduce load times.
15. Add ability of build process to automatically blacklist code that is never referenced by the app in any way.
16. Improve development speed.
17. Fix HTML5 manifest generation in new build tools so that developers can very easily turn on offline support.
18. Add new development features.
19. Make HTML5 history paths work with debug server.
20. Add proper validation support.
21. Improve current views and controls.
22. Consolidate shared code between views that support multiple items (SC.RadioView, SC.SegmentedView, SC.Menu, SC.CollectionView, etc.) into mixins. There is a lot of overlap in these views just for manipulating the items/content arrays that they use.
23. Add horizontal support to SC.ListView.
24. Add vertical wrapping support to SC.GridView.
25. Add padding before and padding after to SC.ListView, SC.GridView.
26. Add groupItemHeight to SC.ListView.
27. Add 'first' & 'last' properties/classes to first and last items/groups/items in group to SC.CollectionView
28. Redraw and modernize the default theme, including @2x versions of any images.
29. Make :statechart a required framework so that SC.View, SC.ButtonView and all the others can contain proper internal statecharts.
30. Give SC.ToolbarView more purpose.
31. Rewrite SC.TextFieldView
32. Add new views and controls. Adding lots of these is more palatable if they are either automatically blacklisted out when not used or kept as independent libraries, individually required by the app.
33. SC.AnchorView: For simple links. See https://github.com/sproutcore/sproutcore/issues/982.
34. SC.PageControlView: Like UIPageControl. Shows a series of circles corresponding to views that are swapped in by clicking on one of the small circles.
35. SC.TokensView: A list of tokens, such as keywords or tags.
36. SC.FileView: File upload view.
37. SC.MapView: Google (other?) map view.
38. SC.NavigationView + SC.NavigationController: iOS style integrated navigation view
39. Allow statechart to act as delegates. For example, views could set the application statechart as display delegate, which would in effect consult the current state for display decisions.
40. Move core statechart into core foundation, separated from application statechart specifics.