

Mulberry: A Development Framework for Mobile Apps - nprincigalli
http://rmurphey.com/blog/2011/09/18/introducing-mulberry/

======
prpatel
I like the concept and the 'innovation' of the Mulberry team. Using Rails-like
commands for creating a JS based mobile project is just a small innovation
IMO, but the implementation (based on the video) seems well done. I love teams
that are able to take an idea, no matter how small or large, and follow-
through with it in a complete manner. I love that devs are creating cool new
frameworks for the web/mobile space, it is certainly exciting.

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?

------
DenisM
How does this compare to Sencha mobile?

~~~
rmurphey3
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 :)

~~~
DenisM
Excellent write up, thank you.

------
nprincigalli
Here's a video about it <http://vimeo.com/29127698> and there's more on
<http://toura.github.com/mulberry/>

------
va_coder
Could someone post some demo or example sites built using Mulberry?

~~~
rmurphey3
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.

------
dreamdu5t
What is the file size of the JS in the framework, minified, but uncompressed?

~~~
rmurphey3
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>

