The BART train shrieks against the rails. Somber San Franciscans sit in moldy clothe seats, observing each other. Arrive at Twitter headquarters for the June SproutCore Meetup. Young developers patiently line up for pizza and beer.
Dramatis Personae
Application Structure
Colin: The controller layer gets complex fast when you track application state there. DataStore is one of the most powerful parts of SproutCore, but not the easiest API to use. The view layer will be more mobile-oriented than desktop-oriented, especially with regards to templates. We’re not abandoning desktop-style.
Let us talk about statecharts. Server side MVC has no state. Client-side MVC apps will have state, which you must manage. Controllers have two concerns:
- Mediating: handling/manipulating data
- Coordinating: handling events and application state
Statecharts coordinate, executing only applicable logic and managing sequences of events. We can define substates (ready, logged in), which add or remove templates as we enter and leave those states. In this way, we can elegantly add new state while keeping complexity manageable.
Mobile vs Desktop-Style
Colin: We’re abandoning the 1.x view layer for HTML/CSS, which run well on every device. Here is Jack to appease your fears.
Jack: There will still be buttons, radio buttons, and other widgets in SproutCore UI. We have nothing to show you yet, but trust us that CSS will be much better and the widgets are not going away.
Colin: SproutCore can run on mobile browsers, or native web apps. But interface elements won’t match native controls exactly. Some properties of native controls are too difficult to replicate on the web. Cappucino, for example, spends a lot of energy mimicking native controls, but we will ship our own UI.
Our example Todos app is fewer lines of code than Backbone. It will be easier to scale your apps with SproutCore, particularly for weekend warriors adding functionality a bit at a time.
Scaling SproutCore Apps
Peter: For small apps with one or two devs, an agile style is fine. Larger apps are generally written at large companies, with developers specializing in different components. What are the needed roles for SproutCore?
- Technical Lead/Architext
- Knows SproutCore well.
- Creates basic structure: state charts, basic model, high-level view hierarchy
- Point person to management, quality assurance, design and other teams
- Data Modeler
- Integrates with the server and works with server team
- Creates consistent data model and API
- Performance and Dev Tester
- Enforces test writing
- Write and build integration tests
- Keep track of performance benchmarks
- CSS, Spriting, and Visual Stylist
- Global theme and works with designers
- Manage image assets and spriting
- Optimizes CSS of modules
- Individual Module Contributor
- Larger apps must be broken into modules to manage code
- Each contributor works on their own module, with specific engineering problems
Thoughts
Kai: For run-of-mill applications produced by large companies, SproutCore does seem a step up from frameworks past. Right now it’s in a big transition period, so I’ll evaluate it for myself when 2.0 comes out. CSS and state management are both very important to me.
Now would be a great time for a tutorial on state charts in Backbone.js. To me, Backbone provides a more consistent, concise, stable API with which to form the basis of large applications. TileMill is a great open source example with very complex state.
