One of the Steroids devs here.<p>Nice job, Marc. Your thoughts on the subject are much appreciated. Thanks for your kind words on the tutorials!<p>As for the pain points you had along the way - we feel you and are working toward improving the development experience. Rest assured that the amount of assorted tricks you need to learn to develop a premium application with Steroids will be going down.<p>The project file structure will be improved to make it easier to tell what parts an app consists of. The focus will be on presenting Angular modules as units of functionality. We find that dealing with preloaded views is cumbersome at the moment, and view handling altogether is ripe for a bit of restructuring.<p>We also believe that there could be more approachable ways for reacting to eg. the application resume event you mentioned, and for communicating between views. An application that consists of several views each running their own JS environment gets surprisingly tricky to get right, and is not a problem you would prefer to be solving when trying to get your app idea off the ground. For instance, you want to have a bit of data that's persisted to localStorage but that gets rendered to multiple views; in this case you'll want to notify the other views in case any changes occur. Currently, implementing this behaviour must be done essentially manually by our users. Steroids Add-ons implements a few measures to improve the situation behind the curtains, but we don't have something to offer everyone at the moment. For this, and for other use cases where you need to deal with asynchronous and non-local data access, we're brewing solutions right now.<p>Thanks for the valuable feedback. _b