We Keep Coding

What makes Angular and Backbone different from jQuery?

I have been using JavaScript and jQuery for quite a while now and want to extend my skill set further, during my search I came across two popular names Angular and Backbone and while reading about them I found one line common in both them which somehow also seems to be their USP i.e.
It is designed for developing single-page web applications
This makes my confused.
What is that I cannot do with JS or jQuery and I would require these?
I have created web application on single page, where users can perform CRUD operations on single page through asynchronous calls so why so much importance of for these others libraries?
And as a middle level web developer who has have good hands on JS is it right path to move to these two or here is something else I should look into before these?
Please help?

Structure.
In an ongoing project that started about 4 years ago we built the front end with jQuery. We were able to do just about everything that we needed creating several single page applications that were quite functional.
As the project progressed and the code base grew we started experiencing some major problems with maintainability of the code. We ended up with hundreds or thousands of lines of JavaScript code per page in a tangle that was almost impossible to navigate. This could have been avoided if we were more careful of course but at the time we focused on making sure the back end architecture was robust.
Many years ago the community learned that code needs structure to be maintainable. We developed MVC patterns, multi-tiered applications etc. But JavaScript was never a big player in the field and we largely ignored it.
Over the last 6 months or so we introduced Angular into the project and started sorting out some of the mess in the project. The results are remarkable. Not only is the code simpler and easier to create, the structure makes it easier to implement tests, easier to maintain and generally a huge improvement over what we had before. We still use jQuery but now we have been burnt by the lack of structure and know a thing or two about the architecture of a JavaScript application. Angular and its like provide you with the tools to architect a good application.

When you are creating larger scale web applications it is wise to check out Backbone, Angular or perhaps Meteor. jQuery supports neat tricks, but it does not help you structure your code in a maintainable way. Larger scale web apps build on jQuery need their own vision on how to separate the code into layers with their own responsibility.
The other frameworks give more support.
I would suggest checking out at least one of the libraries. Perhaps you eventually won't use them, but it will benefit how you work in jQuery.

Well Now a days there has been quite a hype about Angular.js and especially SPAs (Single Page Applications). Well to be honest, I had the same question in my mind about a month ago when my team decided to shift from Jquery to Angular.
Whenever it comes to Jquery, one of the first thing that comes in our mind is the DOM manipulation. While using Jquery we always think of manipulating the DOM. Show/hide elements, animating elements, getting data from tags you name it. But Angular offers something more than that. It offers you an architecture, a way to structure your applications at the front end.
So whenever you go for Angular.js, change the way you think about creating web applications (and believe me its worth it). Most of Angular's structure uses the concept of Dependency Injection which is a neat way to maintain your code.
Backbone is only a library whereas Angular.js is a complete framework to create and manage Single Page Applications
Talking about the fact that Angular.js should be used when we are creating large scalable apps, it is true. In my case the team I work with is full of Jquery Ninjas. We have been creating a great app for the last 3 years and believe me it became difficult for us to maintain and debug thousands of lines of Jquery. This is the main reason we have decided to revamp this app into Angular.
Kindly see some of these Helpful links. You will get a better idea.
http://net.tutsplus.com/tutorials/javascript-ajax/3-reasons-to-choose-angularjs-for-your-next-project/
"Thinking in AngularJS" if I have a jQuery background?

How to write a modular JavaScript application?

I am planning to rewrite an existing Silverlight application using HTML, JavaScript and CSS. This will be a rich internet application connecting to a server only for data (JSON based web services) - so there will be no server-side presentation framework such as JSP or ASP.NET. The application consists of about 8 screens, most of them in a tabbed layout. The question is...
What is the best way to write such an application in a modular fashion? I would like to write the individual screens as standalone modules communicating with each other only via events. I would also like to use some sort of an MVC framework to decouple the presentation layer from the model.
Any thoughts on which frameworks I should look at? Have you had a good experience using them? I am starting to look at Backbone.js, JavaScriptMVC and SproutCore. Am I missing anything that is worth considering?
Thanks in advance for your time.
P.S. If you'd like to see the application that I am trying to rewrite, an online demo is available here - it is a realistic trading application built for learning and comparing technologies.

I haven't yet had a chance to try SproutCore, but I hear good things about it and want to look into it at some point. I would recommend trying out at least Backbone and Sproutcore to see which of the two fits your needs and your programming style better.
I do a lot of work with Backbone, and what your suggesting sounds like it would be a very easy fit with backbone. I follow an event-driven architecture with my backbone apps and I find it works very well. it keeps code clean and separated, and allows me to add functionality easily by binding to events that my objects raise.
there are a lot of great tutorials and screencasts for backbone out there, too. here a few of them that should hopefully give you some of the information you need (including my own blog posts):
http://lostechies.com/derickbailey/category/backbone/
http://lostechies.com/derickbailey/2011/07/19/references-routing-and-the-event-aggregator-coordinating-views-in-backbone-js/ (introduce event-driven apps in backbone)
http://joeybeninghove.com/2011/08/16/backbone-screencast-introduction-views/
http://peepcode.com/products/backbone-js ($)
http://tekpub.com/view/mvc3/6 ($ and specific to ASP.NET MVC integration)
again, don't just pick one and never look back. it's worth your time to at least do some simple trial applications in backbone and sproutcore, if not additional frameworks.
hope that helps.

With Sproutcore, you can create so-called frameworks so separate your application. Every SC project has a frameworks directory, you just add a directory for your custom frameworks, and include the frameworks in your buildfile.
It's not a bad idea with SC to at least separate your Model layer into its own framework, for loose coupling and testing purposes (SC is heavily MVC). It might make sense to separate your screens into their own frameworks, depending on how beefy they are. One of the benefits of this approach is you can reuse your frameworks in other projects if needed.
SC also includes a robust Statechart mechanism, so using custom events is quite natural, and because of the statecharts its relatively easy to insure that the events are handled only when the app is in the right state.

Have you tried the Relay framework? Your write your individual screens as standalone modules and use relay's event system to link them together.
http://relay.github.com

ASP.NET MVC3 and right opinionated client side software development model?

I am currently evaluating how to create and maintain MVC3 web applications that have a level of client side richness we've never attempted before. I realize this will require a much more thought out usage of javascript.
This lead to me starting research on Dojo and Closure. Of course the amount of information (especially in context with various versions) is just overwhelming on this.
Does anyone have any good sources of guidance on working with tools such as these in the context of MVC2+ style applications? Such as which mesh well, and which have the highest barriers, personal success or failure stories and so on.

This is interesting, because I think Microsoft is leaning heavily toward wanting MVC users to use jQuery in their projects. jQuery is the only JavaScript framework included by default in the MVC project at creation. They are also actively developing plugins to use in MVC projects. Now I am not saying you should use jQuery for these reasons, but it is hard to ignore how much effort MS is putting towards jQuery and making it a large part of the MVC workflow.

jQuery all the way is the only way. MVC 3 libraries use it behind the scenes anyways now. Whats the issue with simply including the scripts as opposed to relying on the dogo.requires() ?
With jQuery - simple includes on your layout pages are all you need most of the time. There is some faultiness when you want validation to occur on an ajax loaded partial view in which you need to 'tell' jQuery about the new content to validate, but besides that its quite solid.

Just stumbled onto this question: not sure whether you're still interested in it.
There are several internal initiatives inside Dojo to build an MVC module and low-level "binding" functionalities into Dojo, and use automatic binding as the "glue" between the model object and the view (or widgets inside the view).
dojox.mvc is where most of this work is currently residing.
I have a small implementation of automatic binding (similar to WPF so you can actually do MVVM with Dojo) intended as a plumbing layer in Dojo. There is a small proof-of-concept test page here: http://www.mingleplace.com/test/bindingtest.html
So, the short answer is that MVC is actively being developed/pursued in Dojo, and experimental packages are already available. However, as far as when the actual API will be formalized into Dojo, you probably have to wait till 2.0...

What kind of architecture should I learn to make good JavaScript based software?

I know Model-View-Controller well, have known about it for years and used it in terms of server-side development with languages like PHP.
However, I am now working with JavaScript and building a big application with it utilizing SVG, Canvas among other great features modern browsers support. The project is big, so, the architecture behind it must not be fragile.
JavaScript and MVC do not get on like a house on fire, because JavaScript is event-driven by nature. So, are there any architectures or anything else I should definitely learn, understand and implement?
The software will have to deal with data. It already utilizes local storage and web SQL database. I need a Models, right? There is an UI, so I have Views? However, do I have Controllers? What about events? How do I structure everything?
Architecture, architecture, architecture -- that's what I'm interested in. I'm fine with the language of my choice.

First, I'm the author of JavaScriptMVC, so I'm extremely biased in a whole variety of ways. First, there are 6ish things you will ever do in a JS application:
Load Scripts
Respond to user events
Update the DOM
Request data from the server
Convert that data into something useful for JavaScript
Organize your front-end business logic
Your choice of architecture might depend on what tools you want / need.
For general architecture, I do think it's important to separate concerns.
I strongly encourage you to find some way of doing dependency management, and client side templates. They will make your life a lot easier.
JavaScriptMVC uses a tiered MVC approach that's based heavily around custom UI events and OpenAjax events.
I build my low-level widgets with $.Controller in a similar way to how you would build jQuery widgets. The big difference is that the widgets produce a non-ui event that top level controllers can listen to. For example, a tabs widget might produce a "tab.activate" event like:
$('.tab').trigger('tab.activated')
Then, my higher order controller might listen to tab.activated events, and a the model to update the tab content like:
".flickr tab.activated" : function(tabEl, ev){
Flickr.findAll({type : "rainbows"}, function(images){
tabEl.html("//path/to/view", images );
}
}
Flickr.findAll essentially does a query for flickr messages, then calls back with a list of images. Wrapping the service/ajax functionality with models makes them a lot more reusable.
You'll notice that in the callback I update the html of the tab element with the rendered content from a view. This probably isn't the 'best' way of doing it, but I wanted a quick example. Better would be passing the tabs controller the rendered output, for it to do what it will with it. That way if your tab wants to fade in content someday, it will be able to and your master controller won't have to know about the tab's implementation.
The most important thing is to break down your app into the smallest pieces you can. Have them individually testable (and flexible), and combine the little parts into bigger parts as you work your way up to your application.

Take a look at Ext JS. It has a clean architecture that is well-suited towards highly complex javascript applications.
Data handling and server communication is done via stores. Data rendering is done via grids (with in-cell editors), and forms (with a rich set of form controls), which can both talk to the stores. There's also a set of layout classes to abstract away CSS positioning (border layout, box layout, table layout, form layout, ...).
It is however not MVC in the typical sense. The library encourages a programming style that avoids dealing much with HTML and CSS, letting you live (mostly) in pure JavaScript land. You end up thinking in terms of components and data, instead of individual dom elements and style rules. If you don't like that approach, be warned, you won't like this library.

MVC is still the way to go, in my opinion. If you're looking for a good framework to help you achieve that a little less painfully, I would look at JavaScript MVC, it has models, views, controllers, unit testing, jQuery support, etc.

You should learn the Event Based nature of client-side JavaScript and how it blends with MVC based server-side applications.
You should also learn how to properly program inside of the Prototype based inheritance structure of Javascript.
Both of those things will allow you to write you JavaScript so that it meshes with your server-side application framework and is extensible and re-usable.

One thing i have learned over the years of javascript programming is writing UnObtrusive Javascripting which basically means seperating as much as possible structure(HTML) and style(CSS) from Behaviour(JAVASCRIPT).

Althogh not a raw javascript solution, take a look at CoreMVC, the jQuery architechure of MVC.
CorMVC is a jQuery-powered
Model-View-Controller (MVC) framework
that can aide in the development of
single-page, web-based applications.
CorMVC stands for client-only-required
model-view-controller and is designed
to be lowest possible entry point to
learning about single-page application
architecture. It does not presuppose
any server-side technologies, or a web
server of any kind, and requires no
more than a web browser to get up and
running.

If you want a ready-made reference architecture that combines soem industry leading JS libraries with some good JS design patterns for large scale development, have a look at:
http://boilerplatejs.org/
I'm the main author of it and thought of sharing knowledge we gained after developing few large scale javascript products. It addresses following main concerns:
Solution structuring
Creating complex module hierarchy
Self contained UI components
Event based inter module communication
Routing, History, Bookmarking
Unit Testing
Localization
Document Generation

Architecture of a single-page JavaScript web application?

How should a complex single-page JS web application be structured on the client-side? Specifically I'm curious about how to cleanly structure the application in terms of its model objects, UI components, any controllers, and objects handling server persistence.
MVC seemed like a fit at first. But with UI components nested at various depths (each with their own way of acting on/reacting to model data, and each generating events which they themselves may or may not handle directly), it doesn't seem like MVC can be cleanly applied. (But please correct me if that's not the case.)
--
(This question resulted in two suggestions of using ajax, which is obviously needed for anything other than the most trivial one-page app.)

MVC architecture of PureMVC/JS is the most elegant IMO. I learned a lot from it. I also found Scalable JavaScript Application Architecture by Nicholas Zakas helpful in researching client side architecture options.
Two other tips
I've found view, focus, and input management are areas that need special attention in single page web apps
I also found it helpful to abstract away the JS library, leaving door open to change mind on what you use, or mix & match should the need arise.

Nicholas Zakas's presentation as shared by Dean is a very good place to start with. I was also struggling to answer the same question for a while. After doing couple of large scale Javascript products, thought of sharing the learnings as a reference architecture in case someone needs it. Have a look at:
http://boilerplatejs.org/
It addresses common Javascript development concerns such as:
Solution structuring
Creating complex module hierarchy
Self contained UI components
Event based inter module communication
Routing, History, Bookmarking
Unit Testing
Localization
Document Generation
etc.

The way I build apps:
ExtJS framework, single page app, every component defined in a separate JS file, loaded on-demand
Every component contacts its own dedicated web service (sometimes more than one), fetching data into ExtJS stores or special-purpose data structures
The rendering uses standard ExtJS components, so I can bind stores to grids, load forms from records, ...
Just choose a javascript framework, and follow its best practices. My favorites are ExtJS and GWT, but YMMV.
Do NOT roll your own solution for this. The effort required to duplicate what modern javascript frameworks do is too big. It is always faster to adapt something existing than to build it all from scratch.

Question - What makes an application complex ?
Answer - The use of word 'complex' in the question itself. Hence, a common tendency will be to look out for a complex solution right from the beginning.
Question - What does the word complex means ?
Answer - Anything that is unknown or partially understood. Example : The theory of Gravity even today is COMPLEX to me but not to Sir Isaac Newton who discovered it in 1655.
Question - What tools can I use to deal with complexity ?
Answer - Understanding and simplicity.
Question - But I understand my application . Its still complex ?
Answer - Think twice, because understanding and complexity does not co-exist. If you understand a huge huge application, I am sure you will agree that it is nothing but an integration of small and simple units.
Question - Why all of the above philosophical discussion for a question on
Single Page Application (SAP)?
Answer - Because,
-> SPA is not some kind of core technology that is newly invented for which we need to reinvent the wheel for a lot of things that we are doing in application development.
-> Its a concept driven by the need for better performance, availability, scalability and maintainability of web applications.
-> Its a fairly newly identified design pattern, so an understanding of SPA as a design pattern goes long way in making informed decisions about the architecture of a SPA.
-> At the root level no SPA is complex, because after understanding the needs of an application and the SPA pattern, you will realize that you are still creating an application, pretty much the same way you did before with some modifications and re-arrangements in the development approach.
Question - What about the use of Frameworks ?
Answer - Frameworks are boiler plate code / solution for some commonly identified and generic patterns, hence they can take off x% (variable, based on the application) load from application development but then not a lot should be expected out of them specially for heavy and growing applications. Its always a good case to be in complete control of your application structure and flow but most importantly the code for it. There should be no grey or black areas in the application code.
Question - Can you suggest one of the many approaches to SPA architecture ?
Answer - Think of your own framework based on the nature of your application. Categorize application components. Look for an existing framework that is close to your derived framework, if you find it then use it, if you do not find it then I suggest going ahead with your own. Creating framework is quite an effort upfront but produces better results in long run. Some basic components in my SPA framework will be:
Data Source : Models / Collections of Models
Mark Up for presenting data : Templates
Interaction with the application : Events
State capturing and navigation : Routing
Utilities , widgets and plug-ins : libraries
Let me know if this helped in any way and good luck with your SPA architecture !!

The best thing to do is to look at example uses of other frameworks:
TodoMVC showcases many many SPA frameworks.

You can use javascript MVC framework http://javascriptmvc.com/

The web application that I am currently working on uses JQuery and I would not recommend it for any large single page web application. Most frameworks i.e. Dojo, yahoo, google and others use namespaces in their libraries but JQuery does not and this is a significant drawback.
If your web site is intended to be small then JQuery would be ok but if you intended to build a large site then I would recommend looking at all the Javascript frameworks available and deciding which one most meets your needs.
And I would recommend applying the MVC pattern to your javascript/html and probably most of your object model for the javascript could be done as the json that you actually return from the server through ajax and the javascirpt uses the json to render html.
I would recommend reading the book Ajax in action as it covers most of the stuff you will need to know.

I'm using Samm.js in several one page applications with great success

I would go with jQuery MVC

Check out http://bennadel.com/projects/cormvc-jquery-framework.htm Ben is pretty sharp and if you dig around on his blog he has some nice posts about how CorMVC is put together and why.

Alternative: take a look to ItsNat
Think in JavaScript but code the same in Java in server with the same DOM APIs, in server is way easier to manage your application without custom client/bridges because UI and data are together.

Or have a look at https://github.com/flosse/scaleApp

NikaFramework allows you to create single-page application. Also allows you to write HTML, CSS (SASS), JavaScript into separate files and bundle them into only one output file in the end.

I would recommend to explore Yeoman. It allow you to use existing "best practice" for your new project.
For example:
if you decide to use Angular.js, there is a Yeoman generator, that give you a structure for routing, views, services, etc. Also allow you to Test, minify your code, etc.
If you decide to use Backbone, checkout this generator