Famous JavaScript framework steps back to move forward

25.06.2015
In releasing an open source alpha version of the Famous Framework this week, Famous aims to revamp the division of technical responsibilities and improve on the MVC (model view controller).

Builders of the Famous framework learned a lot from the early release of the framework in April 2014 as well as in developing the Famous Mixed Mode Engine, said Zack Brown, an engineer at Famous, in a blog post. "One lesson was that with a mission as ambitious as ours -- to empower everyone to create beautiful experiences for any device -- creating one library that tries to be 'everything' isn't a tractable approach. In other words, the first version of our render engine was focused on too many goals: capabilities, performance, usability, extensibility, and approachability, to name a few."

Thus, Famous decided to divide responsibilities, with the Engine layer focused on capabilities and performance, and the framework leveraging the engine but centered on re-usability, consistency, and integration with other technologies, Brown said.

The framework is intended for building compose-able, reusable, and interchangeable UI widgets and applications, balancing declarative with imperative and functional with stateful programming, the technology's GitHub page notes. It's built on top of Famous Engine, for rendering JavaScript. Previously known as Famo.us, the technology has had held the promise of enabling complex 3D UIs via JavaScript and Web development.

To improve on MVC, the framework implements an architectural pattern called BEST (Behavior Event State Tree). "BEST is a new architectural pattern for building reusable, interchangeable components that behave predictably both in isolation and at scale," Brown said. "In fact, you can think of BEST as an event-driven variant of MVC that breaks out the output/input responsibilities of the controller into separate concerns: Behaviors and Events."

While MVC has been used for decades, it has many pain points, including code bloat, with code winding up in the controller even though it does not belong there, according to Brown. The controller often bears the brunt of complexity -- synchronizing and managing versions of state and their interdependencies, plus shuttling states off to the Model and the View, Brown explained.

(www.infoworld.com)

Paul Krill

Zur Startseite