I am learning ember.js, and I am trying to understand the difference between a view and a component. I see both as a way of making reusable components.
From Ember's website on views:
Views in Ember.js are typically only created for the following reasons:
-When you need sophisticated handling of user events
-When you want to create a re-usable component
From Ember's website on components:
A component is a custom HTML tag whose behavior you implement using JavaScript and whose appearance you describe using Handlebars templates. They allow you to create reusable controls that can simplify your application's templates.
So what is the main difference between a view and a component? And what would be a common example where I would prefer to use a view over a component and vice versa?
Ember.View
An Ember.View is currently limited to the tags that are created for you by the W3C. But if you wanted to define your own application-specific HTML tags and then implement their behavior using JavaScript? You can't do this actually with a Ember.View.
Ember.Component
That's exactly what components let you do. In fact, it's such a good idea that the W3C is currently working on the Custom Elements spec.
Ember's implementation of components tries to be as closely to the Web Components specification as possible. Once Custom Elements are widely available in browsers, you should be able to easily migrate your Ember components to the W3C standard and have them be usable by other frameworks as well that have adopted the new standard.
This is so important to us that we are working closely with the standards bodies to ensure our implementation of components matches the roadmap of the web platform.
Also important to note is that a Ember.Component is actually a Ember.View (a subclass) but that is completely isolated. Property access in its templates go to the view object and actions are targeted also at the view object. There is no access to the surrounding context or outer controller all contextual information is passed in, which is not the case with a Ember.View which indeed has access to it's surrounding controller, for example inside a view you could do something like this.get('controller') which would give you the controller currently associated with the view.
So what is the main difference between a view and a component?
So, the main difference besides that components let you create your own tags and in some point in the future when Custom Elements are available also migrate/use those components in other frameworks that will support custom elements, is indeed that at some point an ember component will make a view somewhat obsolete depending on the specific implementation case.
And what would be a common example where I would prefer to use a view over a component and vice versa?
Following the above this depends clearly on your use cases. But as a rule of thumb, if you need in your view access to it's surrounding controller etc. use a Ember.View, but if you want to isolated the view and pass in only the information that it needs to work making it context-agnostic and much more reusable, use a Ember.Component.
Hope it helps.
Update
With the publication of Road to Ember 2.0 you are now encouraged to use Components instead of Views in most of the cases.
The answer is simple: use components
According to a training video that was recorded on August 2013, Yehuda Kats and Tom Dale (Ember Core Team Members) told the audience to not use views unless you're a framework developer. They've made lots of enhancements to Handlebars and introduced Components, so views are no longer necessary. Views are used internally to power things like {{#if}} and {{outlet}}.
Components also closely mimic the Web Component standard that will be build into the browser, so there are lots of side benefits to becoming comfortable building Ember Components.
Update 2014-11-27
It's even more important now to use components instead of views, as Ember 2.0 will be using Routable Components when a route is entered, instead of a controller/view. In order to future proof your app, it's best to stay away from Views.
Sources:
Road to Ember 2.0: https://github.com/emberjs/rfcs/pull/15
Future-proofing your Ember 1.x code: https://gist.github.com/samselikoff/1d7300ce59d216fdaf97
There is no view, only component (Tom Dale): https://speakerdeck.com/tomdale/ember-2-dot-0-in-practice?slide=27
As it stands now - v2.x being current stable release - views have been completely deprecated. It is said that views are being removed from Ember 2.0 API.
So, using {{view}} keyword in Ember 2.0 will trigger an assertion:
Assertion Failed: Using {{view}} or any path based on it has been removed in Ember 2.0
If you have to use views in Ember 2.0 you can use ember-legacy-views addon, which will be compatible with Ember until version 2.4.
So, to sum up - components are the present (views being removed) and the future - they will also replace controllers. See Routable Components RFC.
Related
The idea of web components is to modularize the web regardless of what framework you use.
The Polymer project promise the possibility to create web components, not to be a framework, so it should be possible to use it with any framework. More than that, I should be able to just download the elements from the element catalog and use it without the polymer library, just with the webcomponents.js.
I recognize that this is an ongoing project and most of browser's vendors are still developing the web components requirements, but what I'm concluding so far is that the Polymer is becoming a new framework as I cannot use their elements without the Polymer library and the use with framework as Angular 2 is not yet working well.
Is that a way to use web components in a real modular way without all the boilerplate that the Polymer suggest?
TL;DR;
Polymer does not break the modularity merely by the fact that it's required to use Web Components built with it. It is just a library, albeit opinionated, used to implement custom elements.
These elements are however still independent modules. All of Polymer stuff should be hidden inside a component and not interfere with the outside.
Long read
The idea of web components is to modularize the web regardless of what framework you use
In a sense, yes. Though Web Components target to modularize the DOM really. For general modularization, there are ES6 modules IMO.
The Polymer project promise the possibility to create web components, not to be a framework, so it should be possible to use it with any framework.
I'm not sure what you expect from Polymer and Web Components in general. The modularity of Web Components come from the fact that when used, they are just an ordinary part of the DOM tree. Any existing library can work with that. Any Web Component is just a HTML element and exposes a uniform interface: attributes and events. What Polymer does is add some niceties on top of that so that you can enjoy data-binding, simpler custom element declarations, simpler events API, styling polyfill, shady DOM and more.
It's a dependency like any other and should not stop you from using Polymer (or Bosonic, or x-tag, or basic-web-components) with any other web framework.
More than that, I should be able to just download the elements from the element catalog and use it without the polymer library, just with the webcomponents.js.
Where did you read that? Also, is it a problem that polymer.html is required for the components to work? You may get the same with other Web Components libraries.
I recognize that this is an ongoing project and most of browser's vendors are still developing the web components requirements.
I believe there is a need of clarification. The vendors implement the Web Components spec and where it isn't ready, webcomponents.js fill in the blanks. Just as I write above however, Polymer is a little bit more, because it gives you more than pure specs.
Is that a way to use web components in a real modular way without all the boilerplate that the Polymer suggest?
Not sure what is the bolierplate that you refer to, but yes, you can write Web Components in plain javascript (or in a minimal dependencies fashion) but you will lose some of the sugar that Web Components give you. It is just like arguing that one shouldn't use jQuery, because all that it does can be done without it.
The question is in regard to AngularJS, BackboneJS, EmberJS and the other frameworks.
I have to translate a project from php to javascript and I have to decide, if I am going to use:
AngularJS
Polymer
A combination of them
I prefer using Polymer, because I like it.
Yet, I am missing (and correct me where I am wrong) the ability to make:
Views and link between them (like in Angualar)
Controllers
I know that the structure is up to me, on how to build my application, but it seems that angularjs has a well predefined structure for building mvc-applications.
Therefore I want to know: Is Polymer a substitute for Angular, if you want to build a well structured web application or is Polymer complementary library to be used along other existing frameworks?
EDIT 21.09.2014
No one really answered the question to my fullest satisfaction, therefore I marked it as not answered yet. Many say it just "DEPENDS". But no one is able to elaborate, on what exactly it depends.
On the complexity of the application? On the needs of the application? For what needs does Polymer fit and for which doesn't it fit? These are the answers I was looking for.
Some say it can be used as a frontend framework. Others say that is just a library and others say "Yes and No". Unfortunately rather confusing answers.
I wish there was an official answer to this, but I let you in on what my feeling is. I believe it is a substitute, but Polymer hasn't yet reached the structure, that other frameworks require to work. Maybe this is intentional, maybe it is just a matter of unreached maturity, because the framework is new.
I hope that the creators will explain, when it is best to use AngularJS and when should someone use Polymer for building large scalable web applications.
EDIT 15.08.2015
Polymer 1.0 is out. And it turns out Polymer is officially NOT a framework and is supposed to work in a complentary way with other frontend frameworks.
https://youtu.be/fD2As5RmM8Q?t=6m42s
IMHO both are two different things and they both are to serve two different purposes. Though they have some common features to offer, data-binding can be one of them.
Polymer
If you truly want to use the Awesome Webcomponents, Polymer is one way to achieve that. There are other options like you can go with your vanilla JS, or use other libraries like X-Tag from Mozilla or Bosonic. These libraries polyfill the webcomponent features which are still in drafted state. So, these libs help us have/provide the same user experience across browsers even where there is no native support for the webcomponents.
Angular
This is a full fledged MVC framework. And people here know what Angular as an MVC framework includes/provides.
That all said to answer your question
Google's Polymer is not exactly a fully functioning Frontend Framework and can be used as a Subsitute OR Complement to other Frontend Frameworks. It can be used as a substitution for the V part in Angular as MVC. Like people use React as V in different frameworks. It is not much a different case for me. Being more specific in case of Angular, Polymer is like directives in Angular 1.x while like components in upcoming Angular 2.x.
References
To be more sure of what I am talking about and for additional sources on how to use the Polymer with Angular2 (Angular2 not released to this date)
you can check this video at "https://youtu.be/7WgEuNZCCHk?t=32m15s" starting from time 32:15 where Rob explains how to use the generic webcomponents/polymer as the components/View in the Angular2.
you can check this project "https://github.com/rkirov/youtube-app" which uses Angular2 and google-youtube web component.
https://github.com/ebidel/polymer-experiments/tree/master/polymer-and-angular/together
From the polymer-starter-kit
Framework-free, or framework-compatible
Build your app out of elements, or wire in an external framework to handle business logic. It's up to you!
So, in my view these two projects are not competing each other.
Webcomponent Specs
The webcomponent specs are here for one's reference
Custom Elements - http://w3c.github.io/webcomponents/spec/custom/
HTML Imports - http://w3c.github.io/webcomponents/spec/imports/
Shadow DOM - http://w3c.github.io/webcomponents/spec/shadow/
I just wish the webcomponents are native to the evergreen browsers ASAP.
From the Polymer Starter Kit:
"Framework-free, or framework-compatible
Build your app out of elements, or wire in an external framework to handle business logic. It's up to you!"
Update:
What was described as Carbon Elements seems to fall under:
Polymer(version 2) App Toolbox
Component-based architecture using Polymer and web components.
Responsive design using the app layout components.
Modular routing using the elements.
Localization with <app-localize-behavior>.
Turnkey support for local storage with app storage elements.
Offline caching as a progressive enhancement, using service workers.
Build tooling to support serving your app multiple ways: unbundled for delivery over HTTP/2 with server push, and bundled for delivery over HTTP/1.
Carbon Elements adding framework features
During The Polymer Summit 2015 Keynote, Google announced a new "Polymer idiomatic and framework oriented" set of elements, tentatively named the Carbon elements.
Some quotes from the longer tjsavage answer regarding Angular 2 vs Polymer Carbon:
"The trick is in thinking about the web platform as an application framework... Polymer the library is to the web components component model as the carbon elements will be to using the web platform itself as an application framework: the opinionated rails to make it easier to understand and achieve."
"Angular 2 will provide one way of structuring your application that uses Angular's view of what makes a good application structure. The carbon elements will provide a different way of structuring your application that more directly uses what the web platform itself provides as its structural underpinning."
Polymer is almost fully functional.
Currently it is missing routing for example but this doesn't mean you can't do this with Polymer.
There is now https://elements.polymer-project.org/elements/app-route
In Dart also dependency injection works fine with Polymer because of the types. If it's possible in Dart, it's possible in JS as well because Dart transpiles to JS. DI in plain JS might be more cumbersome though.
In this package (Dart)
https://github.com/bwu-dart/bwu_polymer_routing
I made the routing and DI packages used by Angular.dart available for Polymer. There are also routing packages for Polymer.js available.
I put together some router demos. The "missing parts" really depend on what type of application you're building.
https://github.com/erikringsmuth/polymer-router-demos
I've used it as both, as an enhancement to an app written in another framework, and as the full framework itself, where it was responsible for every element on the page.
I really like just about everything about Polymer, so I've been very happy using it for the whole app, even built my own router. If you've got an existing app I'd recommend dipping your toe in the water, as Polymer works great composed into other apps to see if it's to your liking.
Let me give this another try:
The key behind web-components (and thus Polymer) is, that they are self-contained. You have a web-component somewhere, you import it, and (if you're lucky) it just works, wherever it comes from. The web-component will NOT interfere other components. So doing things like MVC is not Polymers business (although it provides a data-binding mechanism), as this belongs to the process of tying things together. It is considered to be best practice that these kind of things are solved by creating new elements too, that create and react to events. When it comes to the model you code non-visual web-components, that don't have/need a template. TodoMVC has an (outdated) example for that (https://github.com/tastejs/todomvc/tree/gh-pages/examples/polymer).
So Angular gives you a path to follow on how to do MVVM, whereas it is up to you on how to do the "logic" in your app when using Polymer. IMHO Angular is for more complex and rather enclosed apps, whereas Polymer is for any kind of app, that embraces the web. You even can use Polymer, if you're not writing an app at all ;)
On the Polymer Getting Started page, we see an example of Polymer in action:
<html>
<head>
<!-- 1. Shim missing platform features -->
<script src="polymer-all/platform/platform.js"></script>
<!-- 2. Load a component -->
<link rel="import" href="x-foo.html">
</head>
<body>
<!-- 3. Declare the component by its tag. -->
<x-foo></x-foo>
</body>
</html>
What you will notice is <x-foo></x-foo> being defined by platform.js and x-foo.html.
It seems like this is the equivalent to a directive module in AngularJS:
angular.module('xfoo', [])
.controller('X-Foo', ['$scope',function($scope) {
$scope.text = 'hey hey!';
})
.directive('x-foo', function() {
return {
restrict: 'EA',
replace: true,
controller: 'X-Foo',
templateUrl: '/views/x-foo.html',
link: function(scope, controller) {
}
};
});
What is the difference between the two?
What problems does Polymer solve that AngularJS has not or will not?
Are there plans to tie Polymer in with AngularJS in the future?
You're not the first to ask this question :) Let me clarify a couple of things before getting to your questions.
Polymer's webcomponents.js is a library that contains several polyfills for various W3C APIs that fall under the Web Components umbrella. These are:
Custom Elements
HTML Imports
<template>
Shadow DOM
Pointer Events
others
The left-nav in the documentation (polymer-project.org) has a page for all of these "Platform technologies". Each of those pages also has a pointer to the individual polyfill.
<link rel="import" href="x-foo.html"> is an HTML Import. Imports are a useful tool for including HTML in other HTML. You can include <script>, <link>, markup, or whatever else in an import.
Nothing "links" <x-foo> to x-foo.html. In your example, it's assumed the Custom Element definition of <x-foo> (e.g. <element name="x-foo">) is defined in x-foo.html. When the browser sees that definition, it's registered as a new element.
On to questions!
What is the difference between Angular and Polymer?
We covered some of this in our Q&A video. In general, Polymer is a library that aims to use (and show how to use) Web Components. Its foundation is Custom Elements (e.g. everything you build is a web component) and it evolves as the web evolves. To that end, we only support the latest version of the modern browsers.
I'll use this image to describe Polymer's entire architecture stack:
RED layer: We get tomorrow's web through a set of polyfills. Keep in mind, those libraries go away over time as browsers adopt the new APIs.
YELLOW layer: Sprinkle in some sugar with polymer.js. This layer is our opinion on how to use the spec'd APIs, together. It also adds things like data-binding, syntatic sugar, change watchers, published properties...We think these things are helpful for building web component-based apps.
GREEN: The comprehensive set of UI components (green layer) is still in progress. These will be web components that use all of the red + yellow layers.
Angular directives vs. Custom Elements?
See Alex Russell's answer. Basically, Shadow DOM allows composing bits of HTML but also is a tool for encapsulating that HTML. This is fundamentally a new concept on the web and something other frameworks will leverage.
What problems does Polymer solve that AngularJS has not or will not?
Similarities: declarative templates, data binding.
Differences: Angular has high level APIs for services, filters, animations, etc., supports IE8, and at this point, is a much more robust framework for building production apps. Polymer is just starting out in alpha.
Are there plans to tie Polymer in with AngularJS in the future?
They're separate projects. That said, both the Angular and Ember teams announced they'll eventually move to using the underlying platform APIs in their own frameworks.
^ This is a huge win IMO. In a world where web developers have powerful tools (Shadow DOM, Custom Elements), framework authors also can utilize these primitives to create better frameworks. Most of them currently go through great hoops to "get the job done".
UPDATE:
There's a really great article on this topic: "Here’s the difference between Polymer and Angular"
For your question:
Are there plans to tie Polymer in with AngularJS in the future?
From the official twitter account of AngularJS : "angularjs will use polymer for its widgets. It's win-win"
source : https://twitter.com/angularjs/status/335417160438542337
In this video 2 guys from AngularJS talked about differences and similarities about this two frameworks (AngularJS 1.2 and Beyond).
These links will bring you to the correct Q&A's:
http://www.youtube.com/watch?v=W13qDdJDHp8&feature=share&t=56m34s
http://www.youtube.com/watch?v=W13qDdJDHp8&feature=share&t=59m8s
1 & 2) Polymer components are scoped because of their hidden tree in the shadow dom. That means that their style and behaviour cannot bleed out. Angular is not scoped to that particular directive you create like a polymer web component. An angular directive could possibly conflict with something in your global scope. IMO the benefit you will get from polymer is what I explained.. modular components that have scoped css & JavaScript to that particular component that nothing can touch. Untouchable DOM!
Angular directives can be created so that you can annotate an element with several pieces of functionality. In Polymer web components that is not the case. If you want to combine functionality of components you include two components into another component (or wrap them in another component) or you can extend an existing component. Remember the main difference still is that each component is scoped in polymer web components. You can share css & js files across several components or you can inline them.
3) Yes, Angular plans on incorporating polymer in version 2+ according to Rob Dodson and Eric Bidelman
It's funny how nobody here has mentioned the word scope. I think that is one of the major differences.
There are many differences, but they also have a heck of a lot in common when it comes to creating modular lego like pieces of functionality for an app. I think it's safe to say that Angular would be the application framework and polymer could one day live in the same app along side directives with the major difference being scope but polymer may be a replacement for a lot of your current directives. But I see no reason why Angular could not work as-is and include polymer components as well.
Reading through the answers again while I write this, I noticed that Eric Bidelman(ebidel) did kind of cover that in his answer:
"Shadow DOM allows composing bits of HTML but also is a tool for encapsulating that HTML."
To give credit where credit is due, I got my answers from listening to many interviews with Rob Dodson and Eric Bidelman. But I feel the answer wasn't worded to give this guy's question the understanding that he wanted. With that said, I think I have touched on the answer he is looking for, but in no way do I possess more information about the subject than Rob Dodson and Eric Bidelman
Here are my main sources for the information I have gathered.
JavaScript Jabber - Polymer with Rob Dodson and Eric Bidelman
Shop Talk Show - Web Components With Rob Dodson
Polymer is a Web Components shim
"Web Components" is a new set of standards that is enveloped by HTML 5 designed to provide reusable building blocks for web applications.
Browsers are at various states of implementing the "Web Components" specification, and therefore it's too early to write HTML using Web Components.
But alas! Polymer to the rescue! Polymer is a library that provides an abstraction layer to your HTML code, allowing it to make use of the Web Components API as if it were fully implemented in all browsers. This is called poly-filling, and the Polymer team distributes this library as webcomponents.js. This used to be called platform.js btw.
But Polymer is more than a polyfill library for web components...
Polymer also provides open and reusable Web Component building blocks via Elements
All elements can be customized and extended. These are used as building blocks for anything from social widgets to animation to web API clients.
Polymer is not a web application framework
Polymer is more of a library than a framework.
Polymer does not have support for things like routes, application scope, controllers, etc.
But it does have two-way binding, and using components "feels" just like using Angular directives.
Although there are some overlaps between Polymer and AngularJS, they are not the same. In fact, the AngularJS team has mentioned utilizing Polymer libraries in upcoming releases.
Also note that Polymer is still considered "bleeding edge" while AngularJS is stabilizing.
It will be interesting to watch both of these Google projects evolve!
I think from a practical perspective, in the end the template feature of angular directives, and the web component methodology leveraged by polymer both accomplish the same task. The major differences as I can see it are that polymer leverages web APIs to include bits of HTML, a more syntactically correct, and simplistic way of achieving what Angular does programatically as it renders templates. Polymer is however as has been stated, a small framework for building declarative and interactive templates using components. It is made available for UI design purposes only, and is only supported in the most modern browsers. AngularJS is a complete MVC framework designed to make web applications declarative by use of data bindings, dependencies, and directives. They're two completely different animals. To your question, it seems to me at this point you'll get no major benefit from using polymer over angular, except having dozens of pre built components, however that would still require you to port those over to angular directives. In the future however, as the web APIs become more advanced, web components will completely remove the need to programatically define and build templates as the browser will be able to simply include them in a similar way to how it handles javascript or css files.
The MVVM (model-view, view-model) that Angular offers is not a concern that Polymer aims at solving. The composable & re-usable nature that Angular directives give to you with (a custom tag + associated logic combination) is a more sane comparison when you consider comparing Angular and Polymer. Angular is and will remain a broader purpose-serving framework.
What is the difference between the two?
To a user: Not much. You can build awesome apps with both.
To a developer: They use way different syntax so either solution has a fairly steep learning curve. Angular has been around longer and has a HUGE community so you'd be hard pressed to find problems that haven't been solved.
To an architect: Very different. Angular is an application framework responsible for all aspects of your life. It even has directives vertically integrated in case you want component like features. Polymer on the other hand is more like pay-as-you-go. You want a modal, sure thing, you want an interactive widget, no problem, you want route handling, we can do that to. Polymer is also more portable in that Angular requires an Angular app to reuse directives. The idea with Polymer is be more moduler and will work in other apps, even Angular apps.
What problems does Polymer solve that AngularJS has not or will not?
Polymer is an approach to head towards taking advantage of the new web components standards. If features like custom elements, Shadow DOM, and HTML imports are supported locally, it would be foolish not to take advantage of them. Currently most web component features are not widely supported (current status) so Polymer acts as shim or a bridge. Kinda like a polyfill (in fact it does use polyfills).
Are there plans to tie Polymer in with AngularJS in the future?
We have been using Angular and Polymer together for over a year. Part of the decision to do this was based on promises made directly by the Polymer team to us that interoperability be there. We have given up on that idea. We are now moving towards using only Polymer.
To do it over again we probably would not have made the move to use Polymer at all, instead wait for it to mature. That being said Polymer has it's pros (some quite good) and cons (some of which are quite frustrating) but I think that is a discussion for another thread.
Angularjs directive is an approach for making custom elements. you can define new custom tags with custom attributes. Polymer can also do this but it'll do in an interesting and more simple way.Polymer actually is not a framework it's just a library.but a powerful and amazing library that you can fall in love with it (like me). Polymer let you learn the native web components technology made by w3c, that web browsers eventually implementing it.web component is the future technology, but polymer let you use that technology right now.Google Polymer is a library that provides syntactic sugar and polyfills for building elements and applications with web components.Remember that I said polymer is not a framework and it's a library.But when you're using Polymer, actually your framework is DOM.this post was about angular js ver 1 and polymer and I has been worked with both of them is my projects and I personally prefer polymer over angularjs. But Angular version 2 is completely different in compare of angularjs ver 1.directive in angular 2 has a different meaning.
Angular directives are conceptually similar to Custom Elements but they are implemented without the use of the Web Components APIs. Angular directives are a way to build custom elements, but Polymer and the Web Components specification are the standards-based way to do it.
polymer-element:
<polymer-element name="user-preferences" attributes="email">
<template>
<img src="https://secure.user-preferences.com/path/{{userID}}" />
</template>
<script>
Polymer('user-preferences', {
ready: function() {
this.userID= md5(this.email);
}
});
</script>
</polymer>
Angular directive:
app.directive('user-preferences', ['md5', function() {
return {
restrict: 'E',
link: function(scope, element, attrs) {
scope.userID= md5(attrs.email);
},
template: '<img src="https://secure.user-preferences.com/path/{{userID}}" />'
};
}]);
I'm building a multi-page javascript application. I've read a lot into design patterns, and creating applications using a Core/Facade/Module approach w/ loose coupling (pub/sub scribing to events).
I have a pretty good system worked out that minifies & combines all of my module files & related dependencies into a single external javascript file at deployment. Minimizing extra HTTP requests for my application is a design goal -- therefore I'm not too interested in AMD (asynchronous module definition).
I'm using the guidelines delinitated in Nicholas Zakas's presentation,
Scalable JavaScript Application Architecture
http://www.youtube.com/watch?v=vXjVFPosQHw
&&
Addy Osmani's Patterns For Large-Scale JavaScript Application Architecture
http://addyosmani.com/largescalejavascript/
&&
This premium tutorial, by Andrew Burgess from Nettuts, Writing Modular JavaScript
http://marketplace.tutsplus.com/item/writing-modular-javascript/128103/?ref=addyosmani&ref=addyosmani&clickthrough_id=90060087&redirect_back=true
My question is advice on how to go about managing different pages of this application & their associated modules. I'm also using Backbonejs's Router class w/ ballupton's History.js library to manipulate the HTML5 history/state API and dynamically load pages without a refresh while maintaining backwards compatibility for older browsers that don't support the HTML state API. All of my pages share a common code base (single minified & compressed js file).
Here's an outline of the structure I'm thinking of using in my application:
It's essentially a hybrid approach. The top half consists of a Core/Facade/Module pattern with discrete modules that don't interact directly with each other and publish/subscribe to notifications via the facade.
The bottom half consists of my proposed application structure, which notifies a "main controller" when the state/url changes, the main-controller performs any global operations (such as initializing the header & sidebar-menu of my UI if not already initialized) and the instructs the relevant sub-control to run it's init() method (as well as calling destroy(); on any controller that was previously loaded). Each sub-controller (correlates to ex: home-page, calendar-page, reservations-page, etc.) cherry-picks modules from the pool of available modules and initializes them.
Is this a good approach or am I on a bad track? I can see the modules are still independent of each other which is good for scalability.
I've also considered just treating the Router & Controllers as discrete modules and having them publish/subscribe to the Core, and each controller somehow initializes the necessary modules it needs for it's page.
One thing we did to keep history working smoothly was to first change the URL. On change of the URL an event would get triggered, the router would parse the url then figure out what to do. This event would automatically get triggered on page load as well. If you clicked a link it would simply change the URL, which is fairly simple and completely decouples links/buttons from the application logic. This seemed to work well for our application. We used JQM, but we dropped most of their router since we read most of our instructions from some XML file and didn't have a bunch of HTML pages to load into the main viewport area.
I've often seen backbone apps use the router as the core/mediator. This is a good idea. You can simply listen on change events for the URL and then change the page appropriately. This Mediator should probably be a singleton, although singletons are harder to unit test.
The thing I didn't necessarily agree with Backbone on was its definition of "views". The view sort of seems like an action in a controller (well from some perspectives). We added one more level of separation in our application at that point. Our views made ajax requests to template files which were filled in with some JSON and handlebars.js. I'd say your header/sidebar should just be templates. If you need to refresh them then see how you could do extremely simply otherwise you are looking at creating 4 new modules: collection for a list, model for each item, collection view, and model view. I'd couple templates more tightly with some higher level view until they need to be broken down further (eg. some "Application/Main View").
Having this template layer allows you to make superficial changes without recompiling as well, which is nice. Anytime you can put things into "meta" it is a win (well unless it requires you to read XML (ha)). As a bonus you can then cache the template separately as well (or cache bust it separately for that matter).
Your architecture does seem fine though, and is a valid approach to your problem. One tip I'd give is don't over design up front. Iterating is best. You will need to refactor. It is impossible to foresee what would make your application flow more smoothly 3-6 months in advance.
Update on Dec 18th, 2013
Now a days we are using marionette and more addy osmani tricks. On top of the above items we are using AMD's alternate format:
define(function(require) {
var myTemplate = require('hb!mytemplate.handlebars'),
view = require('myview');
...
});
We are also using the marionette application class in combination with wreqr which provides a request/response layer. This allows us to set application wide objects cleanly. It also allows us to define classes without explicitly stating the class name. This is a pretty good way to sandbox. EG:
this.app.setHandler('CanvasClass', function() {
return RaphaelCanvasView;
});
// elsewhere
this.app.request('CanvasClass').text('123', {x:1, y:2});
This all seems to work out pretty well.
You should also checkout aura js and web components. Our directory structure sort of mimics/anticipates those concepts without investing in them yet.
I think it's a good approach.
I've been developing something similar in 2 huge commercial web-apps (minus backbone, and with a custom history manager) and it works great. I'm also not using AMD and all interactions are handled by pub/sub.
One of my best inspirations (which I'm sure you already know) is: https://github.com/aurajs/aura
I'm searching for a simple architecture for my UI that will have some basic javascript functions in like: select all checkbox's, image crop, some pop-ups and some other plugins.
I found this article: Organizing Your Backbone.js Application With Modules
My application is not a SPA (Single Page Application). I want to know if Backbone.js with jQuery will help me even if my application is not a SPA.
The strength of Backbone is really in its ability to manage many models (even complex ones) and keep the rendered page in sync with their current values. It provides an interface to getter/setter functions so that the changing of a model value (there are many different flavors of "change") will call render on the corresponding view and the page will correctly reflect the underlying models. Furthermore, it provides interfaces to saving, paging, and routing actions on models.
I have used Backbone extensively for both SPA's (where it shines) as well as more traditional, multiple page applications. It has no special support for UI and DOM manipulation, but combined with jQuery/Prototype/Zepto it manages their rendering/manipulation.
Basically, backbone works best to untangle elaborate chains of rendering logic and model updating. If you feel that your application has a lot of view elements that need to stay in sync with models that the client will be updating on the page, Backbone is a wonderful solution. If you just need to select and manipulate DOM elements, it's overkill. jQuery alone can handle that.
Backbone is really not about the things you mentioned, but I wouldn't say it is strictly for single-age apps (SPA) either. I'd say it is for any case where you've got quite complicated pages and it would benefit you to break them up into multiple pieces (for example, several views that all pull data from one model).
However, I would say the strength of Backbone.js is in the SPA realm.
You could probably find some jQuery pieces that answer some of your needs if you're not already using jQuery as part of your app. However, jQuery is all about the parts you mentioned (easy DOM manipulation, popups if you use jQuery UI, etc.) and not about structure or organization.
I believe that the principal idea of backbone, is organize you JS code in complex app using the MVC concept.
This way your app becomes easier to mantain and add new features, It get easy to use frameworks tests like jasmine.
Backbone also make possible (and very good) work based on SPA approach, using ajax request to server. It is completely based on Restful concept, to get a code using backbone, is important to understand what is Restful.
Basically Backbone have a Router (that can work like a controller. but is not a controller).
Model that is where you can manage all the data logic of your application.
Collection that is like a list of models.
View that is where you will react accordingly the model changes.
There are other things, but basically, is this.
But as I said before, you can use it without have a SPA.
The most important thing to have in mind is that the concept of MVC must be followed when using backbone. If you don't do that, it doesn't make sense use backbone.