With that said, I would like to offer some (hopefully constructive) feedback: * The benefit of adding a Rails-like framework to create what is essentially a UI seems a little much. How do you guys feel this adds to the development time/maintenance/etc of a mobile UI? * I understand that you're trying to address the pain-points of working with Phonegap, and the debug feature looks awesome. Can I get this without using all of Mulberry?
Mulberry expects that you're creating a content-centric mobile app, and so it expects you to define your application in terms of nodes that have assets associated with them -- assets like images, videos, audios, feeds, and data. Nodes are the building blocks of a single-page application that Mulberry creates inside a PhoneGap wrapper. Nodes are displayed with templates, and templates consist of components. You can use the components that come built-in with Mulberry and write very little code; however, you can also create your own components to add custom functionality to your app -- this is where Mulberry's true power lies (see the blog post for details).
Speaking more generally, Mulberry is aimed at developers who aren't interested in spending time on the low-level architecture of their application -- things like data stores, views, etc. Instead, Mulberry is aimed at developers who want to create their content, create their assets, create their data, and then write simple JavaScript and CSS that presents that content and data in the ways they need.
Hope this helps :)
We could improve this number, but so far we haven't found that it significantly affects application performance. Mulberry is very conscientious about things that are more likely to affect performance, such as memory leaks as a result of improper component teardown. Apps with incredibly large data sets may experience slowdowns, but there are ways to mitigate that as well. Bottom line: in our year of use of the system, we've been fairly happy with performance, even with 387k of JS>
