Building Backbone.js/Python based tech stack

[krupan]

Heh, I used to think web development was hard because you had to learn sql, python, html, css, and javascript.

Apparently you really have to learn those, plus, flask, backbone, coffescript, require.js, jquery, bootstrap, handlebars.js, stylus, mocha, zombie, etc., etc. Simple! :-)

[danneu]

I think you'll be hard pressed to find a peripheral tool that you can't confidently be productive in after a few hours to a few days.

The list of buzzwords isn't so much evidence that you need to be proficient in a lot of random tools as it's evidence that you should feel unattached and comfortable learning new tools if you want to participate in the web space.

[sdfjkl]

And then people complain when they can't seem to hire anyone that knows their tech stack of the minute.

[almost]

Libraries are good, so instead of having to learn to implement all those things (or learn how the last guy implemented them) you can just learn the library :)

[peacemaker]

My thoughts exactly! How many tools and tech does one website need?! :)

[chime]

If you are using backbone and don't need a complex templating engine, just use _.template. It comes free with underscore, which is a requirement for backbone.

[jakejake]

I wrote a code generator that generates a Backbone.js app based on a MySQL schema. It uses PHP, but mainly all the PHP does is provide the REST API for backbone. I'd like to think I've done a decent job with the organization of the client code.

I went with a pretty bare-bones setup using Underscore templates (since they come for free with Backbone) and using the built-in features without additional extensions (like model binding). But I was able to get some fun stuff in there like collection pagination. If anybody would care to take a look and give me some feedback there's a live demo so you don't have to install anything. It's at http://phreeze.com/

[skylan_q]

As someone who is learning to use backbone and underscore templates, I'll second this. But I've got to say that Handlebars looks like another decent option.

[salmanapk]

I agree.

But for larger apps Handlebars.js is great because it supports pre-compilation which helps boost performance.

[tbatterii]

Weird. our tech stack for our app (proprietary software) is totally different. It's good to have so many great options. :)

We use pyramid on appengine for a json rpc layer. And ember.js/handlebars/jquery and foundation css on the front end.

the pyramid piece has hung around the longest, but previous versions of our application ran on web2py + yui then a gwt app talking to the pyramid piece. Briefly we tried django in hopes of replacing web2py but in the end, pyramid does a lovely job with request routing. And our app depends heavily on it's acl features.

I'm not so much involved in the front end piece but, I feel like we've finally landed in a nice place with ember.js, as the app is growing features rapidly more rapidly now. Looking forward to digging in as soon as the backend tasks calm down a bit.

[beagle3]

Could you elaborate on why you wanted to replace web2py, and what django/pyramid do better than web2py for your use case?

[nicksergeant]

Could you explain a bit about your decision to use Flask + extensions rather than just Django? It seems like you started with Flask and added a bunch of extensions to provide most of the things that Django provides out of the box...

[landtuna]

I'm not the author, but I just picked a Flask / Backbone stack over Django (after initially starting with Django) because so much of Django didn't seem to fit. Django wanted me to make a server side template based CMS. All I wanted was something where I could make a server that talked mostly JSON to clients. (My web application controls and displays results from using some custom hardware and will serve at most tens of users.)

[koblas]

While I can't speak for the authors, I personally have been building out some sample apps with Tornado + Backbone. Since as it's working out Tornado provides a very scalable data layer with a minimum of fuss.

[kosmikko]

What is good in Django is mainly it's ORM, which we don't need. Its templating system sucks, and also its memory usage and performance otherwise.

[j2labs]

Brubeck can generate a full REST API capable of supporting Backbone.js apps by just writing the data model. Similar to Tastypie, but on Brubeck.

https://github.com/j2labs/todos is an example.

[karolist]

This amount of separate software projects from different people to learn, to track and maintain just for a single website? Has the world gone mad? I remember the times when we didn't had to duct type 20 buzzword of the month libraries to build something useful, :(

[GeneralMaximus]

You don't have to.

These are the only pieces you need (besides CSS, HTML and JS) to get a large frontend heavy web application off the ground:

1. A web framework. OP used Flask, which is a microframework. Not a good choice for a large project. To gain feature parity with full-featured frameworks, you end up having to use tens of third-party extensions of questionable quality. As I mentioned in another comment, Pyramid would've been a better choice.

2. A frontend framework. I haven't personally tried all of them, but Ember.js looks like a good choice to me.

3. A database. Forget about fancypants NoSQL databases. Just use MySQL, PostgreSQL, MSSQL or whatever RDBMS you find convenient. Relational databases were built for a reason, and people recommending MongoDB or whatever are doing it because either (a) they want to be hip; or (b) they have a vested interested in the success of the NoSQL movement; or (c) they slept through their CS classes and have no idea that NoSQL databases are rehashed versions of thirty year old technologies which were thrown out the window because they were so terrible at maintaining data integrity.

That's pretty much all you need. SASS, RequireJS, CoffeeScript, Handlebars etc. are completely optional and just there to make your life easier.

To be honest, the only frontend-heavy apps I know of that are complex enough to warrant the use of seven billion hipster libraries are Google's apps. If you're not writing GMail or Google Docs, don't get sucked into library-itis. The time you waste learning ten libraries (five of which won't be around two years from now) is better spent improving your app. You'll end up with 200 extra lines of code, but at least your codebase won't be 98% third-party code.

[jakejake]

It definitely can be overwhelming the number of libraries and choices out there. It doesn't mean you have to use all of them, though, each component serves a function that you may or may not need.

One thing is for sure, though, the bar has been raised.

[eragnew]

You have no idea how much I appreciate this post. I've been researching Python web development for a few weeks now and have been forced to evaluate all the different options on my own without really knowing what I'm looking for. (Since I'm starting from scratch, I'd prefer to use Python rather than having to internalize Javascript syntax just to be able to start the project). Have to agree, Django is way too cumbersome for what I need. But I had to figure that out on my own. Having it laid out clearly like this is really helpful, and now I can pick and choose the parts that will work for me. Thanks for sharing this. I'll plan on sharing the love as soon as I get my stack figured out :)

[Estragon]

  > I'd prefer to use Python rather than having to   
  > internalize Javascript syntax

You might want to check out <http://pyjs.org/>. It translates python code into javascript for execution client-side.

I haven't actually played with it much, so this is not an endorsement.

[amccloud]

backbone.modelbinding is abandoned. Alternatives:

https://github.com/theironcook/Backbone.ModelBinder

and https://github.com/amccloud/backbone-bindings (my library)

[kosmikko]

Yeah thanks, I forgot to add a note on this.

[wensheng]

I'm using Tornado instead of Flask. When I was evaluating Flask vs. Tornado, I found Tornado to be much faster than Flask. More importantly, Tornado is much more straightforward. I actually prefer putting all URL in one place (tornado) instead of using those @route decorators(flask,bottle). On Flask, if you want to write anything more complex than HelloWorld or ToDo, you use something called blueprint, which is not easy (at least for me) to understand.

[hogu]

"With CoffeeScript, writing JavaScript becomes fun again. Code is cleaner and more verbose, leading to faster development and less bugs. Sure there’s opinions against it, but seems that many have changed their opinion? Just saying that you should try it. I’m not going back to vanilla JS. Debugging is not an issue when you use require.js. And plz don’t make those uncomprehensible magic one-liners."

How does require.js make coffeescript debugging easier?

[nilliams]

I'm with you on this one, that doesn't seem like the most well-considered paragraph. As well as the point you picked up on there's also: 'Code is cleaner and more verbose' - less verbose surely. 'Faster development and less bugs' - huge sweeping generalisation that I'm not sure can be backed-up.

That said I'm a CoffeeScript fan, but I'd like to see people being realistic about its benefits, not just making really vague claims. Also it's okay just to say things like 'Coding in CoffeeScript is fun', I would have just left it there. :)

Edit: I also really like the article overall, thanks for posting and sorry for the initially negative tone of my comment. I especially like the perspective on the backend - agreed!

[kosmikko]

What I meant that you can keep the files small thus it's easy to find the correct line of error.

[mau]

How do you pre-render the pages for the client? Do you just send a static HTML and let the js populate the page or there is a better way from python to not duplicate the template processor?

[akoumjian]

Django+tastypie works with backbone.js with very little configuration.

[bm1362]

Exactly what I used on my first non-trivial web app.

I had Django + Tastypie serving a REST API and Backbone.js on the front-end. Bootstrap for styling. Apache/mySQL. It turned out to be a success but when I look at the codebase it is a nightmare. I ended up writing a mobile app version which was nice since I was able to just plug it in to the REST api.

But, at the end, I was annoyed with Django and Tastypie- something just didn't sit right. Implementing things like sessions, which in PHP are obvious but verbose, relied too much on Django's hidden magic that I felt I was hacking a solution rather than architecting one.

[amccloud]

Yup! and i've packaged those little configurations into a plugin. https://github.com/amccloud/backbone-tastypie

[ericingram]

Seems like it might be tough to maintain an app with so many external dependencies

[jayliew]

Curious, have you given dotcloud a try?

Good roundup list.