I've worked with angular which uses DOM-Based templating and also in Ember which uses String-Based templating. But I never worked on backbone. Can anyone tell me which templating method it uses?
Backbone doesn't force you to use any particular templating engine, you can use what you want to render templates.
Render the UI as you see fit. Backbone is agnostic as to whether you
use Underscore templates, Mustache.js, direct DOM manipulation,
server-side rendered snippets of HTML, or jQuery UI in your render
function. Sometimes you'll create a view for each model ... sometimes
you'll have a view that renders thousands of models at once, in a
tight loop. Both can be appropriate in the same app, depending on the
quantity of data involved, and the complexity of the UI.
(src: http://backbonejs.org/#FAQ-tim-toady)
Backbone is agnostic with respect to your preferred method of HTML
templating. Your render function could even munge together an HTML
string, or use document.createElement to generate a DOM tree. However,
we suggest choosing a nice JavaScript templating library. Mustache.js,
Haml-js, and Eco are all fine alternatives. Because Underscore.js is
already on the page, _.template is available, and is an excellent
choice if you prefer simple interpolated-JavaScript style templates.
(src: http://backbonejs.org/#View-render)
(rtfm!)
Backbone.js is a MV* framework that works with any template system. Typically you will use the Underscore library for creating templates for simple applications. The Underscore library is a dependency of Backbone so its always available to your Backbone.js app.
A NEW ALTERNATIVE to Underscore.js has just been released called "Lo-Dash" its sole purpose is to completely replace Underscore.js all together. It also has a template system that you can use in your Backbone.js apps. Simply drop in Lo-Dash, remove underscore and it works seamlessly. When Lo-dash is tested with Backbone.js all the unit tests pass which means that it is a perfect Underscore.js replacement. The Lo-Dash API was also written with performance in mind so it replaces slower clunky JS patterns with better high perf patterns like "for loops" etc... Also it provides like 30 additional features that isn't available with underscore. Check it out for yourself: http://lodash.com/
After you have checked out Lo-Dash and still need more than i would check out some of the other template systems out there like: Handlebars.js, Mustache.js, Jade, Haml-js, etc...
Related
I'm a little confused about mvc frameworks for the web...take angular for example. Are the "views" in angular the (tweaked out) html and CSS and the "models" just javascript/json-like objects that contain data like regular Ajax data? It seems to me that this is how it is (maybe not in full detail, but roughly it seems like this is it). Does angular even use CSS? And I don't really understand the controller.
I know javascript to a degree where I am not a total beginner but these frameworks make no sense to me, it's like everyone is speaking Greek or something when I look up tutorials. It would help to know I'm sort of on the right track or whether my thinking is wrong, in a ballpark sense.
Help is highly appreciated. Thank you.
It sounds like you're on the right track. In Angular specifically, yes, the views are written declaratively in HTML and special tags and attributes called directives. Models can be anything; often you'll see examples in Angular that use plain JavaScript objects as the models, but in a more complex app you might have special objects that have methods specific to the application. Controllers are just there to tie the two together—they take the models and make them available to the view via the scope, and events (like ng-click) call methods on the controllers which make changes to the models.
AngularJS implements Model-View-Controller paradigm by connecting your HTML (views) to your JavaScript objects (models) via two-way data binding.
It extends HTML by providing directives that add functionality to your markup and allow you to create powerful dynamic templates. You can also create your own directives, crafting reusable components that fill your needs and abstracting away all the DOM manipulation logic. Like most JavaScript MVC frameworks, it lets you work with any server-side technology as long as it can serve your app through a RESTful web API.
You can find more info here:
http://www.angularjstutorial.com/
http://stephanebegaudeau.tumblr.com/post/48776908163/everything-you-need-to-understand-to-start-with
http://mrbool.com/mvc-in-angularjs/28962
Is there any library that provides just Model, View and Collection base classes, similar to Backbone's, but without all the router/history/sync stuff?
You may want to take a look at Exoskeleton by Paul Miller.
Exoskeleton is a faster and leaner Backbone that supports custom builds. Please note that it does not support IE below version 9. If you need to support older browsers, you might want to stick to backbone.
You can just ignore the Router and use the rest of the framework, or if you want to reduce the code footprint to absolute minimum it is not difficult to remove the Router from the code.
Another alternative is Bamboo which is a model layer solution similar to Backbone.Model. You can use it with any view/template library eg. Reactive or Ractive
We're about to start a project using mentioned libraries. We have already used jQM in another project, but coupled with Backbone. Now we're thinking about using AngularJS with jQM. Do you think it's a good idea? And if not, why?
To elaborate, the question is whether it is advisable/recommended/easy/beneficial to use these libraries together, or maybe there is something that should prevent us from using them both in one project. We don't want to spend half of project's time on making them work together just on principle.
AngularJS and JQM do different things. AngularJS is MVC + Lot More. JQM on the other hand is for direct UI manipulation (lower level than Angular). The good news is AngularJS is flexible and will let you work with any other Javascript framework including JQM. The recommended way of using them together is use the adapter as mentioned above or create your own reusable directives that will add "JQM nature" to your views. For e.g. you can create a directive that will convert a standard UL to a fancier JQM list. The good thing about doing this in directives and not within your view is that your UI code is separated in separate modules and not intermingled with business logic.
I am considering using AngularJS instead of Handlebars with MeteorJS. I am more familiar with AngularJS, but it doesn't work well out-of-the-box with Meteor. Handlebars is default templating engine used in MeteorJS.
I would like to know the trade-off between the two, e.g., whether AngularJS provides more flexible front-end coding than Handlebars.
My question is: when pairing with Meteor, what AngularJS can do that Handlebars can not in terms of front-end programming?
(Note that people love AngularJS in part b/c of its two-way binding and data model, but Meteor-Handlebars do these very well too).
Update: Please do not vote to close this question if you think it is a duplicate of another question in SO that compares Angular and Handlebars. Meteor added significant power to Handlebars due to its "database on client" approach.
Angular and Meteor can be combined, and it's a pretty neat combo. Angular's templating system and its two-way bindings (DOM to JS model) can even be made to go the whole way and be kept in sync with a Meteor collection. Such a pairing of Angular and Meteor means you get instantaneous DOM to database syncing, which is very cool. Angular can't do that by itself, nor can Meteor (without writing more or less tedious event handlers) and even less Handlebars.
The angular-meteor Meteor package is pretty much ngMeteor's successor (it builds on ngMeteor code) and integrates Meteor collections with Angular models, the two templating systems, Meteor Session variables etc.
TL;DR: Meteor works best with packages (think jQuery, bootstrap, d3, underscore, stylus, less) since they enhance a framework. Those same packages would enhance Angular too (well, kind of). Angular is an end-to-end framework, so trying to integrate it on top of another end-to-end framework like Meteor is a recipe for headaches.
Handlebars has very similar expressions and bindings that you're probably familiar with in Angular. But while the templating engine is similar, it's the rest of the frameworks that differ greatly.
Angular leans heavily on its internal directives (ng-repeat, ng-form, ng-bind, etc.) to easily tie in javascript (i.e. power) to your markup. There's a lot of magic behind the scenes.
Meteor leans heavily on the pub/sub model and connecting to your true data stores. Their secret sauce comes from easily adding but abstracting packages (handlebars is one of their default packages, but some others are bootstrap, accounts-ui, d3, etc.).
Meteor follows very different ideologies and has different opinions on framework design than Angular does. In my opinion, Meteor's are superior though the project is still in its relative infancy. You'll find that Meteor is really, really good at prototyping quickly, especially if you need to tie in user support and want to use Twitter/Facebook/Google.
You'd be better off choosing one or the other, but if you're not strong on the server side, you could write a pretty slick Meteor app to just act as your API server.
If you want to use angularjs with meteor you can just install a package that does that. Then you can use both meteor and angular.
Meteor is realy nice for getting your data from server to client, angular is very nice in getting that data displayed (and stable).
mrt add angular-stack
or
mrt add ngMeteor
Generally speaking, AngularJS has passed the version 1.0 milestone and is considered ready for production use while meteor is still alpha software. Consequently, Angular is more polished, has directives, modules and rich third-party libraries like AngularUI.
But if you feel like experimenting with a bleeding-edge framework, don't think you'll have to do super-fancy templating-stuff but need a database built in, go with Meteor!
I think you might find this answer helpful.
Also I think it might be a duplicated question.
I just started to learn AngularJS and struggle with some concepts of AngularJS. It would be great if somebody could explain me some points...
I understand that ng-click is technically not the same as onclick (see here), but both are placed in the markup. I thought that would be a "bad practice"? Why is this one of the core concepts of AngularJS, if most people say this is "bad"? I thought it would be better to select the DOM element from JavaScript and not to place logic in the markup.
If ng-click is the right way to react to click events in AngularJS what should I do with other DOM events? I see that there are several other directives like ng-mouseover, but not all DOM events have a AngularJS equivalent. How would I handle a 'drop' event in AngularJS (hence in the AngularJS way - not the normal way)? To be clear: I want to drag a file into my webapp.
Thank you very much,
Pipo
Why is this one of the core concepts of AngularJS, if most people say this is "bad"?
Well, people who really like Unobtrusive JavaScript might say it is bad. Angularians (and those with a flex background) see value in the more declarative approach.
"Angular is built around the belief that declarative code is better than imperative when it comes to building UIs and wiring software components together... By declaratively describing how the UI should change as your application state changes, you are freed from low level DOM manipulation tasks. -- Overview doc
See also Don't the data attribute options used in Bootstrap, Angular.js, and Ember.js conflict with Unobtrusive Javascript principles?
what should I do with other DOM events?
Write your own directives to listen for them (or find one that someone else has already written). Angular gives you the power to extend what the browser can do -- by writing your own directives.
Update: in the comments below, Tim Stewart mentions AngularUI's ui-event, which lets you bind a callback to any event not natively supported by Angular.
By nature, Angular requires elements in the markup in order to function properly. Further, those elements must be "compiled" each time they change, for the most part. So, it's already somewhat "obtrusive" irrespective of the JavaScript. You can't simply replace the markup, and have everything auto-bound for you like you can with something like jQuery.
Strictly speaking, unobtrusive JavaScript:
1. separates structure and behavior, in order to make your code cleaner and script maintenance easier
2. preempts browser incompatibilities
3. works with a clean, semantic HTML layer
(Wikipedia)
That's not Angular, for sure. In order to achieve the two-way binding on everything, they chose to make custom binding points in the DOM, as opposed to using a class name or ID the way that jQuery would do. (A somewhat non-standard approach, but it obviously works.)
But the real way to think of it is this: Basically each controlled section of your markup is not really straight HTML anymore anyway. It's really more of a template now, and as such requires interaction with the engine that is preparing it for rendering. As such, the traditional rules of unobtrusiveness don't really apply... (FWIW, I'm a huge fan/user of the jQuery.on() function to bind elements to events automatically when the element is added to the page. Very clean and flexible, IMHO, and I do wish there was a similar mechanism in Angular. I like adding a class to items in multiple locations on the page that invoke the same event handler automatically. Having a single place to go change code is a good thing. but I digress...)
For me, the bigger issue is that of progressive design. Does the web page work without JavaScript enabled at all? Does anyone really care about that? Hmmm...