These extensions have two components: a controller and a view (though the view is optional!). This springs from my initial assumption of how a reasonable client-side code structure might look, and my experience writing MVC code on the server.
In practice, this has not quite sufficient. Currently, most of the extensions that represent screens juggle what we would probably call a "document" inside of the controller, with the view containing some logic and containing the functions that update the DOM when the document's state changes, with the controller doing everything else.
Moving forward, I foresee there being some sort of document object that receives new data from user scans or user interaction in the view, handles communicating the data back and forth with the server, and gives the view hookups that fire whenever there is updated data to be changed in the display.
Right now, all that stuff has been going in the controllers. In the future, I see the controllers evolving to become simply the part of the extension that is exposed to other extensions. At the moment they are that, but also all the document-juggling,
But enough of my blathering, let's blither over some examples.
Launching the app
It used to be slightly more complicated, but now it's not. In body onload or $(document).ready() or whatever, just call the catHerder function, passing an array containing strings of extension names.
catHerder([ 'DeviceRegistration', 'Login', 'MainMenu', 'InventoryCount' ])
Extensions will be loaded and initialized in the order that they are found in the array. Once all extensions are initialized, the first one in the array will be shown.
Making a new extension
To make a new extension, you just need a function named whatever you want the extension's name to be - that's your controller. If the extension has a view, create a second function with the same name as the controller, but with "View" at the end of the name.
Extensions are event emitters (via smokesignals) -