Mulberry: A Development Framework for Mobile Apps(rmurphey.com)
rmurphey.com
Mulberry: A Development Framework for Mobile Apps
http://rmurphey.com/blog/2011/09/18/introducing-mulberry/
5 comments
How does this compare to Sencha mobile?
In a nutshell, Mulberry is more opinionated than Sencha -- by being opinionated, it makes it much easier to get an app up and running without worrying about the underlying architecture of the app.
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 :)
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 :)
Excellent write up, thank you.
Here's a video about it http://vimeo.com/29127698
and there's more on http://toura.github.com/mulberry/
Could someone post some demo or example sites built using Mulberry?
There is a screencast demo at http://toura.github.com/mulberry/ -- the code has not yet been released (soon!) so there unfortunately isn't yet any demo code to share, but a demo will be part of the release when that happens.
What is the file size of the JS in the framework, minified, but uncompressed?
There is a total of 387k of JS (minified and excluding phonegap.js), but it's important to remember that all of the JS is shipped as part of the native app, so it all lives on device -- none of the JS is shipped over the wire except when the app is downloaded.
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>
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>
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?