One of the questions that’s come up several times in talking to other developers about Mulberry is this: How is Mulberry any different from all of the other mobile app development frameworks that are out there?

At Toura, we’ve been developing and using the technology behind Mulberry for more than a year, creating apps for clients that range from museums to major media companies. Because our core business is centered on the rapid creation of content-rich apps, we focused our development efforts on reuse from the start. That focus led us to an opinionated framework, one that makes some assumptions about the kinds of applications developers will build with it and about how those applications will be built.

Being opinionated results in a framework that dramatically reduces the effort that’s required to develop an app, and subsequent similar apps are easier still, because it’s vastly more likely that functionality developed for one app can be reused down the road.

While many JavaScript developers have come to think of DOM nodes as their building blocks, in Mulberry, the fundamental building block of an app is a component. The functionality of an app is described by how components, arranged on a page, display the app’s content and interact with each other.

Mulberry comes with lots of components and page layouts that use those components — making it easy to create content-rich applications that incorporate images, videos, map locations, and more — and it also provides simple APIs for creating custom components and adding them to the underlying framework. Custom and built-in components can be arranged into pages, and those pages can be enabled with pre-defined or custom interactions between components. Components neatly encapsulate their DOM structure, behavior, and state, and expose predictable interfaces that make them easy to integrate into applications. Mulberry apps aren’t about wiring up buttons and lists and grids — they’re about defining the interactions between far richer components, and then customizing the presentation layer to create a unique experience.

For Toura, all of this means that creating a particular kind of app has become a reliably repeatable process; more importantly, adding custom functionality to individual apps is also a reliably repeatable process whose results can be readily reused across multiple applications and platforms. Units of functionality — a Twitter feed component, say, or a component that displays a location’s name, address, phone number, web site, and map — take the place of DOM nodes as the building blocks for applications, and they can be mixed and matched and connected in any combination that makes sense.

We’ve placed a lot of value on being able to define new functionality, creating APIs like mulberry.component and mulberry.capability that let us set up new components and interactions without impacting existing functionality. We’ve also been diligent about keeping our presentation layer very loosely coupled with the behavior and data layers. All of this means that we can dramatically alter the “look and feel” of an app while leaving the underlying functionality largely intact, and create new experiences with shockingly little code.

Mulberry embraces a view of how we should be building apps that moves away from some of the DOM-centric habits that JavaScript developers have learned over the last few years — habits that have presented challenges as those same developers transition from building websites to building full-fledged apps. By rethinking the nature of apps to emphasize patterns that facilitate smart reuse, Mulberry makes app development and customization a simple, repeatable, and scalable endeavor.