I'm a React developer for front-end stuff and I've recently been given the task of evaluating whether or not Lightning Out (LO) or Lightning Web Components (LWC) can be used in our React web app for communicating with Salesforce.
We have some users who will not be able to log directly into our Salesforce instance, and so the suggestion of using LO or LWC has been made as a possible alternative.
As a non-Salesforce developer, I have a question which I don't seem to be able to answer easily:
Do either of these offerings from Salesforce come with any extra functionality other than the look-and-feel? What I mean is, if I add something from LO or LWC to a React app, do they have inherent capabilities for communicating with Salesforce to fetch/update data or are they just "dumb" widgets that look like Salesforce-native widgets?
Are there any advantages to using LO or LWC over any other UI widget library when it comes to working with Salesforce?
Thanks
First of all, feels like you are using LO and LWC interchangeably, so I wanted to clear that up first:
LWC: Lighting web components are are custom HTML elements built using HTML and modern JavaScript that use core Web Components standards. I recommend checking out their playground if you want to test them first hand.
LO: Allows you to run LWC web components outside of Salesforce servers.
I am facing some of these questions myself, and I had to do a little bit of digging. I will attempt answer based on what I gathered after some research:
Do either of these offerings from Salesforce come with any extra functionality other than the look-and-feel?
The short answer is yes. The true question is whether what's provided is useful in your context or not. For example, they claim that it delivers exceptional performance (although I found solid posts putting that in question), in part thanks to its "Lightning Data Service" (centralized data caching framework which is used to load, save, create and delete a record without any server-side apex code). These are some other things that Salesforce claims are made easier thanks to LWC:
Find solutions in common places on the web.
Find developers with necessary skills and experience.
Use other developers' experiences (even on other platforms).
Develop faster.
Utilize full encapsulation so components are more versatile.
Are there any advantages to using LO or LWC over any other UI widget library when it comes to working with Salesforce?
When it comes to working directly with Salesforce you wouldn't need LO, and yes - there's a very clear advantage to having LWC components as you can easily mount/compose those on any Salesforce page to get desired functionality fairly fast. Particularly beneficial if the System of Record for the data behind the components is Salesforce and you don't currently have a front-end for that data.
I've seen examples for both using React within Lightning, and LWC (with LO) on a standalone SPA. Now to my 2c: both look atrocious from an app architecture standpoint. In addition to that, it's a pretty clear vendor lock-in, so if you don't have the immediate need or mandate to use LWC, just don't use them.
If there are any LWC & React experts out there that care to expand and/or correct any of these, by all means...
So we've recently picked up React in our company as the front-end technology to build our huge business web application. By saying recently, I mean we don't have any previous experience with React (we have a huge background of AngularJS), and by saying huge application, I mean it's really huge and very dynamic with lots and lots of different pieces and functionality.
Because we will have a lot of huge components that all play a very important role and have complex logic inside them, and because we want them to be easily pluggable and reusable, we want them to be as isolated as possible from the outside world and other parts of our application, because otherwise because of their size and complex functionality it would be pretty much impossible to develop and maintain them. That's the reason why we have decided NOT to use Redux, at least in the beginning, while we are developing just the separate components themselves, because it compromises component isolation and makes the whole application data flow logic impossible to understand when there are so many complex components. Although I believe our choice could be wrong, because as I've already mentioned, we have no experience with React.
As I've already mentioned, the application is very dynamic. By that I mean that components are actually rendered by data. We use various configuration provider classes that interacts with our API endpoints to get the pieces of our application's configuration, like configurations of navigation, pages, various forms, lists, etc., and then try to render components that are read from that configuration.
The problem is, after a couple of weeks struggling to get the momentum with React and discover the right patterns and common solutions to our problems, we've been talking in our crew, that maybe React is not the right technology for us, as it's a UI library, not event a framework, and it doesn't help us a lot, but just adds its rendering rules that we have to break at times to achieve the dynamics and component independence we want.
Considering the component isolation and data flow management, I personally have heard that there is a language for front-end development Elm that has pretty robust data flow architecture where each component has its own model that is separate from others, but I don't know whether it's worth a try, as it may fall behind our big requirements pretty soon too.
The reason I'm writing this question here is that I hope to get an insight from people that have a solid background on working with huge front-end applications. I'd like to know whether it's possible to develop such an application with React, whether React is suitable for such complexity and dynamics, whether we really need Redux or something else, what path, practices, ideologies should we follow. If you understood my question correctly, it's more the architecture side that we are struggling with, than the technological. Maybe we are just walking the path that leads to more and more struggle and complexity but not towards production.
There is absolutely no question that React/Redux can (and is widely) used to develop the kind of applications that you describe. Nothing in your description makes what you are building so unique that it excludes React as a platform for building it. We are actively working with a large enterprise customer who is building their entire front end - with 100 + SPA (Single page applications) in React. This is a team of over 100 developers over a 2-3 year project.
The way we structured this has been crucial -
First, you want to choose a UI component library. A few examples below :
MaterialUI - https://github.com/callemall/material-ui
React Strap - https://github.com/reactstrap/reactstrap
React Bootstrap -https://github.com/react-bootstrap/react-bootstrap
Khan Academy React Components https://github.com/Khan/react-components
https://github.com/elementalui/elemental
We basically took one of these and built a component library off of them, because our components are very custom styled.
Second, we created a modular architecture, where each module (SPA) is an npm package with a main container component and redux store.
Finally, we have a central server package, where each of the modules is registered. The server package is responsible for authentication, authorization, logging, routing, etc.
The essence of this answer is not to advise on how to structure a large React application, but to let you know that React can be (and is being) used to develop applications similar to what you are describing.
I'm at the similar situation right now. I have a background in large desktop applications (ERP, LOB - WinForms, WPF) - 1000+ modules, very dynamic (more than 70% of the UI was generated by input data/configuration), adding new functionality was just about extending some configuration (without touching source code).
I'm deeply investigating current web technologies and I'm more and more convinced that React is not a good fit for that. React really shines in small/middle size applications where you (and other team members) develop every page/component 'manually' (not dynamically generated) and you want to have one global state. But it doesn't help you with building large scale application out of the box - it is only UI library (so no support for modules, routing, forms, binding, http requests, static typing (typescript), etc.) and to my surprise, there is no support for style shadowing/encapsulation (you have to integrate, for example, CSS Modules, by your own). And at the end, you have to constantly bother with libraries versioning (to make them always work together is truly time and energy consuming).
I have a great experience with Angular 2/4+ and I think, for now, it is the best technology for that kind of the applications (if you know WPF, it is very similar). It is a full framework, which is prepared to the scaling out of the box. You can split your app into independent modules (specifying which components will be visible to the outside world), every component has public api (statically typed, inputs/outputs) and encapsulated css styles (there is no interference between others).
For the global state (logged in user, global configuration, etc.), you can still use library ngrx/store (which implements Redux pattern and comes with extra nice things, like 'effects' and integrates really well into Angular ecosystem).
I tried to do in Angular really crazy stuff (dynamically generating the whole application from backend configuration) and everything worked perfectly, as expected.
You nailed the issue in your question- react is a view library, not an application framework. The real question is whether React+Redux(or other state management system) is appropriate for a large LOB app.
I will share some insights from our team’s experience in this realm. Large LOB apps have been developed using the MVC/MVP/MVVM design patterns for decades. These are tried and true patterns that ship software. Couple that with dependency injection and you have a modularized, testable, maintainable application. AngularJS (2.0+) is founded on these principles and leverages them deeply. For this reason we use AngularJS for all of our enterprise line of business apps.
React on the other hand is a lightweight, spritely view render that is awesome for smaller applications and client facing pieces (for example taking a dynamic survey or a simple dashboard). We often turn to React and VueJS here because the full AngularJS stack is way overkill and too heavy.
Getting started writing more complex apps in React can really be a struggle, I know exactly how it feels!
As you say, React is a UI lib and not an event framework. That's why you typically need a library to handle events, for example Redux. You clearly state that you decided not to use Redux (you even used capital letters for not :) ). I would take a step back if I were you and reconsider that decision. You say the reason for not using Redux is that your cannot keep your components easily pluggable and reusable when using Redux. I would argue that is not true. Redux is totally decoupled from your React components. Redux only handles receiving events, and managing state. From the React components point of view, it just receives data in props and sends events by calling regular functions. It's possible to still unit-tests, reuse, etc.
I would suggest you take another look at Redux with this in consideration. Happy to help if you have more questions!
React , Redux will make things easier because When it comes to
complex applications you can create Well structured data object. then you can manage the Complete UI through React and its
Materials ... There are some reasons Why this is right choice
State Management ,
Tree Structure data handling,
Reduce the code,
You will be knowing where the changes made (Actions, Reducers)
Your Component will only taking care of UI things
The things that you have to do is Structuring your data
Completely understand your feelings when you start with React and Redux. We were in the same situation when we started with React in our company. At first React has different approach than other frameworks. Yes of course it's not framework, it's just library. You have to start thinking in React way and that is: React components just render state (It's like you render scene on your graphic card at first you have to prepare scene then you are able render), all what component can do is dispatch actions, or better call just action creators.
You need some smart way how to store state in that point I will suggest use Redux.
We also use TypeScript with combination React, Redux. you have to write more code than pure JS but static type control is priceless when you work on large project.
Separating components logic is native approach of react ... you have to separate logic write "Dummy components" and then reuse this with connect. Or passing values as props.
We are using Thunk middleware as action creators it's good because connected component will call just method and logic is in action creators. You have access there to whole state of app then you can fetch something and base on result you can dispatch different actions.
What I like on react/ redux is how to implement async calls etc. First design component to map all states
1) like I have no data
2) data loading
3) loading done
4) loading error
For that you need only one semaphore in you state and a few checks in render method. Then one action creator that will load data and base on progress dispatch action that describing progress.
What is also cool that in react/redux app you have single data flow it's good when new dev jump into project.
For UI we are using Material UI, yes this framework has some problems but nothing what you will not able to deal with.
We are using also Router for navigating in app.
In the beginning I will avoid server side rendering because it will much easier for you start just with client side rendering and with initial state.
When we start for us was useful this template where everything works in one project JavaScriptServices
Then off course great Abramov tutorials.
For design components very useful Storybook
We can write why use or not React for long time ... but What I can say ... for us it was good choice, with some pain in begging but now we have good payback.
We started a large scale business application using Reactjs as frontend technology.
We have over 30 people in the team and we have over 15 modules in our product.
My approach is to the project is developing a common react project that handles only the Authentication, authorization and routing of the application and all other components developed as separate npm react libraries.
To develop the libraries I used https://www.npmjs.com/package/create-react-hook
This library generates the template with an example app which can use to test our library.
Following is the structure of the project
--Library 1 ( Developed using create-react-hook )
--Library 2 ( Developed using create-react-hook )
...
--Library n
--Common Container App (Developed using create react app and have used all above libraries using npm install)
The main advantage of this approach is developers can focus only on their npm packages and they can develop and test relevant component(s) separately.
The deployment also becomes very easy because we can just update npm package of tested version and rebuild the container app and do the deployment without affecting any other part of the application.
We are using this for several months and running the project with a large team without any issue. I think this may be helpful to anyone else too.
So this is just to share my experience working on an enterprise react application that is in production for years in several banks. yes, you heard me right. Now you can imagine how huge the application will be if it's related to fintech (I know it's not always the case). we have huge modules (70+) with a complex logic that pretty much handles a lot of the work that a bank needs. Modules are both isolated and re-useable. I am going to give an example of only one module so you can imagine the size of each module.
Card Production Module
Bulk Card Generation
Bulk Card Export
Bulk Card Request
Card Operations
Card Operations Approvals
Card Printing
New Card Requests
Pin Generation
Pin Printing
This application is a product, not a project and as a product it is configurable. Even the UI is configurable. I have been working on this application as a full-stack developer. Since it's pretty old the state management library that we are using is flux. With state management, the development speed is a little slow but the tradeoffs are better with us not being worried about state management. By far the application has been able to handle huge changes and things which seemed unachievable. Stability has also been a key element throughout this period.
On the back-end, we have Restful services build using Dot Net which supports both MSSQL Server or Oracle depending on the client's needs/feasibility.
After countless react.js projects, I summarized a domain oriented and practical architecture in my blog post.
It is the absolute best practice that I applied many times, enjoy:
http://denislutz.com/domain-architecture-for-react
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Hope that someone can share their experience with some of the latest emerging backbone.js variants out there.
I have some good experience with backbone/underscore/require in several projects and I will like to take the next step towards more advanced solutions for complex application structure.
I know the following frameworks are available:
Marionette
Geppetto (based on Marionette)
Chaplin, Chaplin - chaplin-boilerplate
Vertebrae
LayoutManager
Thorax
Aura
Luca
Singool
backstack
Backbone UI
hulk
BTW - excellent starting point for big scale project
And probably I missed a few.
There is a short introduction about the differences here:
speakerdeck talk link
but it's very general. I was wondering if someone can share their experience with real life applications using these frameworks.
What is the benefit of choosing one over the other? When will marionette be a better solution over chaplin, or why is vetebrae better for certain applications, for example.
Sure, the obvious answer will be "use whats best for your needs", but I lack of the experience with these frameworks to know their strength/purpose/advantages or preferred scenarios.
Thanks!
Edit 1:
found this post:
Backbone.Marionette vs Backbone-Boilerplate
Edit 2:
Answer by Mathias schafer (Chaplin) by mail:
In short, the current structure is close to version 1.0 since it’s already used in production. We’re not planning to add big new feature or breaking API changes until 1.0.
Marionette is for sure the most comprehensive and stable library out there. It addresses several aspects of JS app development with Backbone. For example, it has a strong view layer which Backbone itself leaves completely void. Of course, you will find that some of the aspects won’t meet your demands and you might feel the need to set up a structure around Marionette.
In contrast, Chaplin focusses on a rather small, but very important aspect of Backbone apps, namely the overall app structure and module lifecycle. In this regard Chaplin is very opionated and is more like a framework than a library (like in “your code calls a library, a framework calls your code”). Chaplin provides some central classes which sit above individual application modules and control the overall app state. This gives your app a conventional structure like Ruby on Rails does it for example.
In Chaplin, you declare some routes which map to controllers, and Chaplin starts the controller once the route match. It also takes care of the disposal of old controllers, and the showing and hiding of main views, which a controller is supposed to create. This is the basic idea, but Chaplin takes care of the ugly details to make this run smoothly.
There are two principals which come along with this structure:
- Modularization, decoupling and sandboxing
- Cross-module communication using Publish/Subscribe and Mediator(s)
Of course these patterns are not new in the software development world, and Chaplin is not the only library which applies them to Backbone.js apps.
Chaplin also provides enhancements for the View layer, for example a highly sophisticated CollectionView, but in total not as much as Marionette with its Regions and Layouts. But it’s relatively easy to write such meta classes using the means Chaplin Views provide.
Most of (all of?) the frameworks that you're looking at solve the same problems, but they do it in slightly different ways with slightly different goals.
I think it's fair to say that all of these projects would solve the problems in these categories:
Provide sensible set of defaults
Reduce boilerplate code
Provide application structure on top of the BackboneJS building blocks
Extract patterns that authors use in their apps
Marionette, which I've been building since December of 2011, has a few very distinct goals and ideals in mind, as well:
Composite application architecture
Enterprise messaging pattern influence
Modularization options
Incremental use (no all-or-nothing requirement)
No server lock-in
Make it easy to change those defaults
Code as configuration / over configuration
I'm not saying none of the other frameworks have these same goals. But I think Marionette's uniqueness comes from the combination of these goals.
Composite Application Architecture
I spent more than 5 years working in thick-client, distributed software systems using WinForms and C#. I built apps for desktop, laptop (smart-client), mobile devices and web applications, all sharing a core functional set and working with the same server back-end many times. In this time, I learned the value of modularization and very rapidly moved down a path of composite application design.
The basic idea is to "compose" your application's runtime experience and process out of many smaller, individual pieces that don't necessarily know about each other. They register themselves with the overall composite application system and then they communicate through various means of decoupled messages and calls.
I've written a little bit about this on my blog, introducing Marionette as a composite application architecture for Backbone:
http://lostechies.com/derickbailey/2011/11/17/introduction-to-composite-javascript-apps/
http://lostechies.com/derickbailey/2011/12/12/composite-js-apps-regions-and-region-managers/
Message Queues / Patterns
The same large scale, distributed systems also took advantage of message queuing, enterprise integration patterns (messaging patterns), and service buses to handle the messages. This, more than anything else, had a tremendous influence on my approach to decoupled software development. I began to see single-process, in-memory WinForms applications from this perspective, and soon my server side and web application development took influence from this.
This has directly translated itself in to how I look at Backbone application design. I provide an event aggregator in Marionette, for both the high level Application object, and for each module that you create within the application.
I think about messages that I can send between my modules: command messages, event messages, and more. I also think about the server side communication as messages with these same patterns. Some of the patterns have made their way in to Marionette already, but some haven't yet.
http://lostechies.com/derickbailey/2011/07/19/references-routing-and-the-event-aggregator-coordinating-views-in-backbone-js/
http://lostechies.com/derickbailey/2012/04/03/revisiting-the-backbone-event-aggregator-lessons-learned/
http://lostechies.com/derickbailey/2009/12/23/understanding-the-application-controller-through-object-messaging-patterns/ (WinForms code, but still applicable)
Modularization
Modularization of code is tremendously important. Creating small, well encapsulated packages that have a singular focus with well defined entry and exit points is a must for any system of any significant size and complexity.
Marionette provides modularization directly through it's module definitions. But I also recognize that some people like RequireJS and want to use that. So I provide both a standard build and a RequireJS compatible build.
MyApp = new Backbone.Marionette.Application();
MyApp.module("MyModule", function(MyModule, MyApp, Backbone, Marionette, $, _){
// your module code goes here
});
(No blog post available for this, yet)
Incremental Use
This is one of the core philosophies that I bake in to every part of Marionette that I can: no "all-or-nothing" requirement for use of Marionette.
Backbone itself takes a very incremental and modular approach with all of it's building block objects. You are free to choose which ones you want to use, when. I strongly believe in this principle and strive to make sure Marionette works the same way.
To that end, the majority of the pieces that I have built in to Marionette are built to stand alone, to work with the core pieces of Backbone, and to work together even better.
For example, nearly every Backbone application needs to dynamically show a Backbone view in a particular place on the screen. The apps also need to handle closing old views and cleaning up memory when a new one is put in place. This is where Marionette's Region comes in to play. A region handles the boilerplate code of taking a view, calling render on it, and stuffing the result in to the DOM for you. Then will close that view and clean it up for you, provided your view has a "close" method on it.
MyApp.addRegions({
someRegion: "#some-div"
});
MyApp.someRegion.show(new MyView());
But you're not required to use Marionette's views in order to use a region. The only requirement is that you are extending from Backbone.View at some point in the object's prototype chain. If you choose to provide a close method, a onShow method, or others, Marionette's Region will call it for you at the right time.
http://lostechies.com/derickbailey/2011/12/12/composite-js-apps-regions-and-region-managers/
http://lostechies.com/derickbailey/2011/09/15/zombies-run-managing-page-transitions-in-backbone-apps/
No Server Lock-in
I build Backbone / Marionette apps on top of a wide variety of server technologies:
ASP.NET MVC
Ruby on Rails
Ruby / Sinatra
NodeJS / ExpressJS
PHP / Slim
Java
Erlang
... and more
JavaScript is JavaScript, when it comes to running in a browser. Server side JavaScript is awesome, too, but it has zero effect or influence on how I write my browser based JavaScript.
Because of the diversity in projects that I built and back-end technologies that my clients use, I cannot and will not lock Marionette in to a single server side technology stack for any reason. I won't provide a boilerplate project. I won't provide a ruby gem or an npm package. I want people to understand that Marionette doesn't require a specific back-end server. It's browser based JavaScript, and the back-end doesn't matter.
Of course, I fully support other people providing packages for their language and framework. I list those packages in the Wiki and hope that people continue to build more packages as they see a need. But that is community support, not direct support from Marionette.
https://github.com/derickbailey/backbone.marionette/wiki/Available-packages
Easily Change The Defaults
In my effort to reduce boilerplate code and provide sensible defaults (which is an idea that I directly "borrowed" from Tim Branyen's LayoutManager), I recognize the need for other developers to use slightly different implementations than I do.
I provide rendering based on inline <script> tags for templates, using Underscore.js templating by default. But you can replace this by changing the Renderer and/or TempalteCache objects in Marionette. These two objects provide the core of the rendering capabilities, and there are wiki pages that show how to change this out for specific templating engines and different ways of loading templates.
With v0.9 of Marionette, it gets even easier. For example, if you want to replace the use of inline template script blocks with pre-compiled templates, you only have to replace one method on the Renderer:
Backbone.Marionette.Renderer.render = function(template, data){
return template(data);
};
and now the entire application will use pre-compiled templates that you attach to your view's template attribute.
I even provide a Marionette.Async add-on with v0.9 that allows you to support asynchronously rendering views. I continuously strive to make it as easy as possible to replace the default behaviors in Marionette.
Code As Configuration
I'm a fan of "convention over configuration" in certain contexts. It is a powerful way of getting things done, and Marionette provides a little bit of this - though not too much, honestly. Many other frameworks - especially LayoutManager - provide more convention over configuration than Marionette does.
This is done with purpose and intent.
I've built enough JavaScript plugins, frameworks, add-ons and applications to know the pain of trying to get conventions to work in a meaningful and fast way. It can be done with speed, but usually at the cost of being able to change it.
To that end, I take a "code as configuration" approach to Marionette. I don't provide a lot of "configuration" APIs where you can provide an object literal with static values that change a swath of behaviors. Instead, I document the methods that each object has - both through annotated source code and through the actual API documentation - with the intent of telling you how to change Marionette to work the way you want.
By providing a clean and clear API for the Marionette objects, I create a situation where replacing the behavior of a specific object or Marionette as a whole is relatively simple and very flexible. I sacrifice the "simple" configuration API calls for the flexibility of providing your own code to make things work in the way that you want.
You won't find a "configure" or "options" API in Marionette. But you will find a large number of methods that each serve a very specific purpose, with clean signatures, that make it easy to change how Marionette works.
I'm currently using backbone with the layout manager module and handlebars as templating engine and I found really easy to set up a little application using an already existing Grails backend. Before starting using layout manager I read about Marionette and Chaplin and both seemed to me really powerful but complex. Then I remembered why I originally choosed backbone.js: simplicity. All those frameworks are adding what backbone has left out by design. I'm not saying that a framework is bad, but if I need something more complex I'll try other projects, like ember.js or sproutcore, since they have a unique codebase, written with a goal in the mind of their developers. Here we have frameworks on top of another one. Of course, backbone is a backbone not only for building applications, but also for writing some more powerful library, but the only thing I think is really poor with it is the view layer, since is missing a layout manager and the possibility of nesting views. With layout manager that gap is filled quite well.
So, my answer to your question is: start from using backbone as is, and ask yourself what is missing and what were your expectations about the framework. If you find there are too many things left out by backbone, then go and search for them in the other frameworks and choose the one is nearest your needs. And If you are still not confident in the choice, maybe backbone is not for you and you have to look some other solution (ember.js, sproutcore, ExtJs, JavaScript MVC are all good). If you have experience in writing client apps, you don't really need experience on all the framework out there to choose the right one (for you, of course)
I have studied the various frameworks build with Backbone.js and built the Vertebrae for a project at HauteLook. The project goals included... dynamic script loading, AMD module format, dependency management, build with mostly open source libraries, organize code in packages, optimize and build for one or many single page apps, host on fully cached server, e.g. no server-side scripting using only an API for data, and the funnest for me, use behaviour driven development for the project. There is a description on the project at : http://www.hautelooktech.com/2012/05/24/vertebrae-front-end-framework-built-with-backbone-js-and-requirejs-using-amd/
Our Problem:
Selected libraries (jQuery, Underscore.js, Backbone.js, RequireJS, Mustache) provide module loading, dependency management, application structure (for models, collections, views and routes), asynchronous interactions with API, various utilities and objects to manage asynchronous behaviors, e.g. (Promises) Deferreds, Callbacks. The remaining logic needed to complete the framework includes:
an object (model) to manage state of the single-page application;
a layout manager to present, arrange/transition and clear views, and
controllers which respond to routes, get/set application state, and hand off work to layout manager.
Our Solutions (implemented in Vertebrae):
Application State Manager -
The application manager stores data in memory and also persists data in browser storage to provide a resource for common data/metadata. Also provides data (state) to reconstruct the page views based on previous interactions (e.g. selected tab, applied filters). The application state manager provides a strategy for resources to retrieve state. Meant to act as a state machine.
Layout Manager -
The layout manager has one or many views as well as document (DOM) destinations for each (rendered) view. A page may transition between many views, so the layout manager keeps track of view states, e.g. rendered, not-rendered, displayed, not-displayed. You may use the layout manager to lazy load and render (detached) views that a site visitor is very likely to request, e.g. tab changes on a page. The transition between view states is managed by this object. An entire layout may be cleared so that view objects and their bindings are removed, preparing these objects for garbage collection (preventing memory leaks). The layout manager also communicates view state with controller(s).
Controller -
A controller object is called by a route handler function, and is responsible for getting relevant state (application models) to generate a page (layout), (also responsible for setting state when routes change). The controller passes dependent data (models/collections) and constructed view objects for a requested page to the layout manager. As a side-effect the use of controllers prevents the routes object from becoming bloated and tangled. A route should map to a controller which then kicks off the page view, keeping the route handling functions lean.
The Todos app is hosted both in dev mode and optimized on Heroku...
http://vertebrae-framework.herokuapp.com/
http://vertebrae-optimized.herokuapp.com/
Many of the concepts in the other frameworks are borrowed, e.g. the need to destory views to preview memory leaks as pointed out by Derick Bailey - http://lostechies.com/derickbailey/ ; the Layout Manager by Tim Branyen http://tbranyen.github.com/backbone.layoutmanager/
In summary, Backbone.js is meant to be a tool in your application the Backbone.js library does not provide all the architecture you will need to build an application, but does provide great interactions with an API and solid code structure for... Views (act like controllers too) and your data layer Models and Collections, and finally Routes. We built Vertebrae to meat the goals of our project, and decided to extract the code as a framework for others to use, learn, or whatever.
The answer to your question in my opinion is to learn from all the frameworks and use what you need to meet your goals, if you find that your project goals fit closely with one of the frameworks built with Backbone then great, otherwise built your own framework there are great examples being shared by the community. Or if you find yourself a bit lost in the direction of your application then choose something more opinionated and structured perhaps Ember.js. The great thing is there are a good assortment of choices to help you code using an (MVX) MVC like pattern with JavaScript.
I developed the Luca framework while working at BenchPrep where we used it to develop several large single page apps on top of the backbone.js library.
I had worked with ExtJS for several years prior and have stolen my favorite concepts from that framework such as the component driven architecture where you develop your views as standalone components and then join them together with other components using container views. And since it is heavily based on configuration, developing an app in Luca feels a lot like describing an object with JSON.
One advantage to this approach is the ability to re-use components across several apps or in different places in your app, with with only minor changes using Backbone's extend. It is also very easy to experiment with many different layouts / presentations of components by making only minor tweaks to the JSON configuration.
In addition to a wide range of helper / utility functions, Luca Ships with many higher level Backbone derivatives that you can piece together in any way imagineable to build a complex UI.
Views, Components, Containers
Augmented Model, View, Collection, Router classes
Configuration options that facilitate communication between Models, Collections, Views, the Application and its respective managers.
Containers ( Split / Column Layout, Grid Layout, Tab View, Card / Wizard View )
FormView with all of the standard field components, and helpers for syncing with a Backbone.Model
GridView, for generating scrollable grid elements from a Luca.Collection
CollectionView, for generating views based on a collection
Toolbars / Buttons
Twitter Bootstrap Styles and Markup For Free
Luca plays very well with the Twitter bootstrap framework. Simply by setting Luca.enableBootstrap = true, and including the CSS, your components ( such as the tab views, the toolbars, buttons, forms, fields, grids, etc ) will automatically use Twitter Bootstrap compatible markup and CSS class conventions.
Uses the Grid system for layout, and responds to most of the bootstrap base css classes in an intelligent way
Luca.Viewport and GridLayout components are setup to work with bootstrap's responsive, fluid, or static grid systems.
Aims to provide a one to one match for twitter bootstrap components, to represent them as configurable Backbone Views
The Application Component
Backbone.Model based state machine provides getter / setter methods and attribute change events as a style of application control flow
Integrated Controller component which hides / shows pages of the app in response to Backbone.Router or State Machine events
Integrated Collection Manager which keeps track of the collections you have created, allows you to scope them, group them, assign default parameters to them
A Socket Manager which is an abstraction layer on top of websocket services that makes push as easy as Backbone.Event
A Keyboard Event router which triggers named key events on components which care to respond to such events
Collection and Model Enhancements
Collections are based on backbone-query, which provides a querying interface very similar to mongoDb
enable a local storage Backbone.sync simply by setting collection.localStorage = true
automatic population of collections whose data is bootstrapped on page load
cached methods / computed properties. cache the result of collection methods, and expire the cache in response to change / add / remove events on the collection or its models
computed properties on the models. build attributes based on complex function, and automatically update the computed value in response to changes
Events and Hooks
Luca components are more liberal with the events they emit compared to the stock Backbone components. They will emit events like before:initialize, after:initialize, before:render, after:render, activation, first:activation, deactivation, first:deactivation, and this allows you to more finely tune the behavior of your components. Plus, by defining an event in the #hooks porperty on your view, it will automatically call a similarly named function for you if it exists. This prevents a lot of callback style code which improves readability.
You can also configure the Luca.Events class to publish the events to a global publish / subscribe channel, which makes building a large application easier and aids in inter module communication.
The Ruby Gem
Luca was developed specifically while working against Rails and Sinatra APIs and because of this is currently optimized for a specific stack, but it in no way locks you into a specific server.
Luca comes distributed as part of a Ruby Gem configured to work on the asset pipeline, or as a downloadable JS file.
You are not required to use Rails, or Sinatra. But if you do, I have included a lot of useful things:
Files with the .luca extension get processed as HAML with JST style variable interpolation. ( equivalent to .jst.ejs.haml ) by the asset pipeline
A Test Harness for browser, or headless Jasmine based Unit Tests along with many Backbone and Underscore test helpers.
An API endpoint for the development toolset that ships with Luca ( more on this later )
An API endpoint that allows you to use Redis as a schemaless storage engine for Luca.Collection with minimal configuration
The Development Tools
Luca applications can enable an in browser coffeescript console with Luca specific helpers and commands that aid in monitoring, inspecting, debugging Luca applications and components
With the help of the Rails Gem, and Luca's CodeMirror based component editor, you can edit the source code of the Luca Framework as well the application specific components directly in the browser, using Coffeescript. You will see immediate feedback in response to your edits, with the instances of effected objects being refreshed with the updated prototype, and you can save your changes to disk.
The Component Tester is a live sandbox for playing with the components that make up your application in isolation. It provides you with tools for modifying the component's prototype, setting up its dependencies, and configuring the component. The component will re-render immediately every time you make an edit. You can view and edit the markup that the component generates, as well as the CSS directly in the browser and see your changes immediately. This makes it a very valuable experimentation tool.
The Component Tester will soon integrate with Jasmine so you can view the results of your component unit tests in real time as you edit their code
Luca is a work in progress, but maintains a stable API ( not yet 1.0 ) and has been used in several large production apps. It is definitely a very opinionated framework, but I am working on making it more modular. I am actively working on the documentation and sample components.
I’m a co-author of Chaplin and I’ve written an in-depth comparison between Chaplin.js and Marionette.js:
http://9elements.com/io/index.php/comparison-of-marionette-and-chaplin/
This is not a “shootout” but tries to explain both approaches in a balanced way.