Besides the ability to run Streamie against your own github repository without running your own backend server, there are several other design decisions in the code that are supposed to make the source as approachable as possible.
I'm joining Google next month, so the obvious choice for a client framework would have been to use closure. I decided to go with jQuery instead because everybody already knows that one already.
When you want to start digging into Streamie, start by reading app.js. In this file you see two big static arrays:
streamPlugins: This is a list of "plugins" which are run on every single tweet and which can transform the tweet in any way. Currently all stream plugins are defined in streamplugins.js. If you want to extend Streamie's tweet view, like e.g. translating all tweets, this is where you want to add your own plugin.
initPlugins: This is a list of plugins which are run as soon as the connection to the backend system has been established and Streamie is basically "running".
The REST API
Twitter exposes an extensive REST API to interact with it's service. Using these APIs requires doing oAuth. Doing anything with oAuth sucks. The good thing is that Streamie provides a proxy for the REST API that does all the oAuth stuff for you. This means you can use the API just as it is documented. E.G. this is how you favorite something in Streamie. Because the main channel from Twitter to Streamie is the user stream API, you don't really have to worry about rate limits.
Tweets, Direct Messages, Retweets
Coming from the Twitter API Tweets, Direct Messages, Retweets look quite different. Streamie normalizes them to be all specialized Tweets. This makes working with them quite easy. Streamie is using the "Stream" metaphor extensively. That is why your direct messages appear in the main stream. The buttons in the navigation only activate CSS classes which filter out certain tweets.
Start up time
Streamie's startup time can be quite long (as in a couple seconds). This is mostly due to the time it takes to load initial data from twitter. (See here if you are curious how that works). In development you can append ?cache to the URL and these API calls will use sessionStorage caching which makes loading almost instant.
Overall Streamie's software design is quite simplistic. Right now it feels like there might be a need to abstract some stuff a little more. There will likely be classes for "status inputs", custom events and maybe even tweets :)
Do you have questions or suggestions about how Streamie works or is supposed to work?