Backbone and Django, finding a better client-side architecture - javascript

I have been working with Django as backend and using jQuery for the front end. Now with web pages been so dynamic javascript has started to get more and more complicated and I feel the need of a better, more organized structure there.
I started reading about Backone and it just feels like a backend approach to frontend (since it's an MVC framework). This would make my code more structured but some functionality seems to be overlapping (i.e. models, urls, ...)
I have also read about using backbone with tastypie and django to implement a RESTful environment here. This is very cool since the app would be ready for phone development too.
now my question is how good or bad this architecture is? what pros and cons it has and if there is a simpler way of achieving a DRY client-side code (maybe following some set of rules/good practices would do)
Any personal experience is more than welcome :)

I was in the same situation a few months as you are right now. Of course the number of tutorials, example projects or documentation is very low and most of them very old BUT one tutorial that I came across fishing night and day for help was this http://joshbohde.com/blog/backbonejs-and-django, was and still is at the moment the only one (that I could find) that was reusing Backbone templates into Django templates with the help of some custom template tags.
My personal experience with Django + Backbone was a good one but only lasted a few months, after that I moved to NodeJS + Backbone. I can only say that even though Django/Python is a fast programming language adding Backbone to it will be even faster (user experience) when you think you will only send (to the REST server and back) small pieces of data and not reloading the entire page on every little detail that has changed.

Related

Which Javascript Framework for a data driven web application?

I've been asked to design a web application which has multiple tiers. It will have a client aspect (rendering information for the user), a server aspect (web api serving data) and a database behind it all.
I'm comfortable choosing the technology stack for the web api and database. It will either be a choice of Microsoft Web Api with SQL backend OR nodeJS with MySQL.
For me the challenge (and the prompt for this post), is choosing the correct frameworks for the client side.
I've used AngularJS quite a few times and its fairly straightforward for me to go down this road again but the project in question will have a lifespan of 5 years and I'm worried that choosing Angular 1.x, having been out since 2009 and due to be replaced by Angular 2.0, which is completely different, is a bad investment.
I will most likely use bootstrap for the base css side.
So out of the plethora of frameworks out there - what would be the strongest for client side data driven web applications?
Some obvious choices being:
Ember
Backbone
React
Knockout
Meteor
Polymer
Ractive
Durandal
Angular 2.0?
To name but a few! Which is best and why? I'm not looking to avail of server side capabilities of the likes of React. Just data (read/write) from the client side.
From your list, I tried quite a few: angular (1), backbone, ractive. I had a look at a few others but didn't investigated them further.
From my experience, Ractive was the winner. I still stick to it and am happy with it.
My first experience was with backbone. It looked pretty simple and what I needed. However, when starting to do non-trivial stuff, I ended up pretty quickly in a dead end. My view and data sometimes went out-of-sync and I didn't know how I could perform some other stuff.
My second experience was Angular. With all the hype, I thought it must be great. But getting into it was hard. It's just ...complex. As soon as I wanted to build a non-trivial directive, I was like "wtf? wtf!". The second show-stopper was the debugging ability. At some point, everything broke and my debug console just threw a strange stack trace, giving me absolutely no clue what might be the problem. ...a long time after I discovered by chance that I had placed a # instead of a # or something like this. Also, one thing I disliked from the start is that it forces you to do everything angular-ly, which doesn't always play well with other libs.
My last experience is Ractive and I write production code with it since a year or so. I'm very happy with it. Sure, it's no silver bullet and has some quirks. But overall, it's a lib where you can quickly get started with, which can do a lot, and that doesn't get in your way. The mainainers are also supprisingly responsive.
...but if you're experienced with angular, perhaps it's better to continue that way.
That's my 2 cents.

JavaScript Web Application

I built a quiz taker app with Ruby on Rails, using the MVC framework. I want to do basically the same thing with pure JavaScript, and add more features with jQuery for mobile devices and special effects, since jQuery is just awesome like that.
I have looked around on sites like TodoMVC for comparisons on frameworks, but I'm foreign to how these frameworks function. Why do they use Collection rather than Controller in their MVC definition? It seems to me that these are just client-side frameworks. Would I use something like Backbone.js for client-side work and Node.js for server-side?
I'm just unsure as to how development with pure JavaScript functions. I need to create a database to store quiz and user information and be able to access that database when viewing most pages, so I feel the MVC framework is the best way to go.
Any suggestions as to where to start?
Wow, that's quite a broad post; let's take things one at a time
Why do they use Collection rather than Controller in their MVC definition?
The exact answer varies by library, but a simplistic answer is that the Controllers in most Javascript apps doesn't really need any framework; they can be raw Javascript and work just fine as they're usually not very complex.
Furthermore, parts what you might consider to be "the Controller" are often provided separately. The primary example of this is Backbone's Router object: it is similar to the implied routing (and routes.rb) in Rails, or the urls.py in Django. Just as those frameworks don't consider routing to be part of "the Controller", Backbone (and similar frameworks) provide routing as a separate piece ... even though it could fall under the C in MVC.
Similarly, much of the DOM manipulation functionality that jQuery provides would normally belong in the Controller of an MVC app, so in a sense jQuery helps you build your controllers; it's just not explicit the way Backbone.Model helps you build your models.
Would I use something like Backbone.js for client-side work and Node.js for server-side?
That's really apples and oranges; to put in server-side terms, Backbone is more like Rails, and Node is more like Ruby (or Mongrel or something). So yeah one's client-side and the other's server-side, but the differences are deeper than that.
Any suggestions as to where to start?
Pick a framework and get your hands dirty! Seriously, you can spend hours reading reviews of the different frameworks, and still be no closer to making a decision at the end than when you started (I speak from experience). But if you just pick one and try it, you'll likely find that it either "gels" with you or doesn't pretty fast.
Personally, I'd recommend starting with Backbone just because A) it's very popular these days, and B) I'm biased: I use it on a daily basis and love it. Also, it probably would fit you well because it was created by the CoffeeScript guy (and CoffeeScript was his attempt to make Javascript more Ruby-like). However, Ember.js is also very popular these days, and Hector mentioned ExpressJS, which I know nothing about but could be cool.
But the point is, pick one, do a hello world, or maybe something a little more complex like an introductory tutorial (Backbone has one around a To Do app). A few hours of coding with it will tell you far more than I (or anyone else on Stack Overflow) ever could about whether it's right for you.
If you are looking for a JavaScript MVC-like framework take a look at Express.js http://expressjs.com
Express.js is more like Sinatra than Rails, but it will give you a good foundation on the server side.
I would definitely look at Google Closure. I have started to use it with LimeJs on a personnal pet project and really got caught with it's compiler and it's modular design.
It's not really MVC, but since JavaScript should be thought more in an asynchronous fashion, I tend to think more of it as event driven than simply a request-pipeline-response way.
So, Closure Library and jQuery / jQuery UI (both on Google API) for the client side and ExpressJs for the server side. Also, take a look at this framework comparison chart, you might find it interesting.

why do we need backbone js or any JS MVC framework?

Why do we need to use a JS MVC framework(backbone) if we are already using a backend MVC framework(e.g Django or ROR). I can't understand the concept of two MVC frameworks and how they fit together. I thought all front-end related files or logic(html, css, js) come under the views component of the back-end framework. Can someone explain this in simpler terms?
Backbone lies in the client [browser], in order to have fast interaction and experience.
This way you can take advantage of real-time communication via websockets, or LocalStorage for example.
Using a client MVC [MVVM better, in Backbone's case] implies that you just supply a RESTful set of resource from the server [which you can reuse in many other context], and not a full HTML generation stack.
Said that, client side MVC is closer to desktop/mobile UI-oriented MVC implementations [see Cocoa / iOS] than to web-oriented MVC [Symfony, Django, RoR...].
It's mostly because of scalability, every MV* frameworks allows You to make modular code. To give users high experience by using websites, JS code and some fireworks are necessary. JavaScript gives also posibility to relieve backend side from unnecessary computations and because of these simple facts and the scale of currently made websites (huge amount of modules on backend and on frontend side), such MV* JavaScripts frameworks are made and becomes more and more popular.
You may want to look at this post Why use MVVM?
I have been using MVVM and have found it very useful for the front end. Rendering is much quicker and smoother and view-model binding is done on the client-side.
It seems like one of the reasons these JavaScript MVC frameworks started popping was in an effort to to bring some structure to client side JavaScript code. JavaScript has been used more and more in web apps in recent years because it enhances the client side experience so much but when you keep adding more and more, it can quickly become a big cobbled mess of spaghetti code. If you've ever inherited a web app that has tons of JavaScript, you know it can take a loooong time to sort through all the callbacks, functions, DOM manipulation, etc. that is going on just to to grasp how to app works and is tied together. It can be really messy. These JavaScript MVC frameworks help organize and bring structure too all this code so it doesn't get out of control.

Decision about web application architecture

I am facing a decision about the web application architecture I am going to work on.
We are a small team and actually I will work on it alone (everybody work on something else).
This application will consist of front-end build on the ExtJS library
and it will use the model "load page, build GUI and never refresh".
On the web "desktop" there will be a lot of data windows, map views (using openlayers + GeoExt) and other stuff.
GUI should be flexible and allow every user to modify (and persist) the layout to fit his/her needs.
It should be possible to divide the application into modules / parts / ... and then let users in specific groups use only the specific modules. In other words, each group of users
can have different GUI available on the web "desktop".
Questions are:
First of all, is this approach good?
There will be a lot of AJAX calls from clients,
may be this could be a problem.
How to handle code complexity on client side?
So far I have decided to use dojo.require / dojo.provide feature and divide the client side code into modules
(for production they will be put together using dojo build system)
I am thinking about to use kind of IoC container on client side, but not sure which one yet.
It is very likely that I will write one for myself, it should not be difficult in dynamic language like JavaScript.
How to handle AJAX calls on server ?
Should I use WCF on server side ? Or just ordinary ashx handler ?
How to handle code complexity on server side ?
I want to use Spring.NET. May be this approach could help with modularity problem.
Data access - here I am pretty sure what to use:
For DAL classes I will use nHibernate. Then I compose them with business classes using Spring.NET.
I would really appreciate some advice about which way to go.
I know about a lot of technologies, but I have used only little part of it.
I don't have time to explore all of them and be fine with the decision.
We do this type of single page interface where I work on a pretty large scale for our clients. (Our site is not an internet site)
This seems to work pretty well for us. The more js you have the more difficult it gets to maintain, so have as many automated js tests as you can and try to break up your js logic in an mvc fashion. 4.0 is supposed to make this much easier.
Ext 4.0 has this built in if you are trying to limit the code you bring down. If you have the same users day after day, then I think it would be best to just bring all the source down (compressed and minified) and cache it.
We've found asmx to work really well. I have nothing against wcf, but last I looked it seemed like more trouble than it was worth. I know they have made many improvements recently. asmx just works though (with a few request header changes and managing the "d." on the client side).
Our Server side data access layer is pretty complex, but the interface for the ajax calls is pretty simple. You have not really given enough info to answer this part. I would start as simple as possible and refactor often.
We are also using nHibernate. Works fine for us. We have built a DDD model around it. It can take a lot of work to get that right though (not sure if we have it right after months of working at it).
If I were you I'd start with just extjs, your web service technology, and nHibernte.
I would recommend ASP.NET MVC 3 with Razor instead of a lot Javascript and calls to Service you can just do ajax calls to an Action in a Controller and that will let you have more maintainable code and use a IoC like Ninject. EF instead of NHibernate.
But it's your decision.
I would look into using a tool like Google Closure Compiler, especially if you're dealing with a very large project. I don't have too much experience with ExtJS, but large projects in JavaScript are hard and something like Closure Compiler tends to make it easier.

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

Categories