Building Backbone.js/Python based tech stack

http://www.mikkolehtinen.com/blog/2012/05/25/rewindy-tech-stack/

by kosmikko • 14 years ago

114 61 14 years ago

mikkolehtinen.com

amccloud2• 14 years ago

backbone.modelbinding is abandoned. Alternatives:

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

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

kosmikko5• 14 years ago

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

jayliew• 14 years ago

Curious, have you given dotcloud a try?

Good roundup list.

chime• 14 years ago

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.

skylan_q• 14 years ago

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.

nilliams3• 14 years ago

I'd go so far as to say 'just use Handlebars', as at some point you will need an 'each' construct which underscore templates don't provide. They're okay for minimal templates that are akin to string interpolation, but as soon as you 'get serious' you end up writing things like <% _.each(things, function(thing){ %> which is just horrible.

Mustache-based templates (mustache, handlebars, hogan.js), though they are a bitch in their schooling you on being 'logicless' really are in my experience, very practical.

And please no-one downvote me by nitpicking that templates can never be truly logicless, I know that :)

smagch• 14 years ago

Does anyone use Dust? http://akdubya.github.com/dustjs/

salmanapk• 14 years ago

I agree.

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

csytan• 14 years ago

Neat. I didn't know that.

Just to clarify, Handlebars supports server side pre-compilation so that slower clients such as mobile devices can get a bit of a speed boost in the loading process.

tsiki• 14 years ago

Underscore also supports pre-compilation with _.template().

jakejake3• 14 years ago

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/

rexreed• 14 years ago

Wow - I think this is great!

ebiester• 14 years ago

I love it! I Was looking at doing something similar with Scala.

uniclaude• 14 years ago

Great!

I made something similar three years ago, but I admit that even if it was good enough for my freelance jobs, it was nowhere as polished as yours. I really like it. Thanks for sharing.

krupan• 14 years ago

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! :-)

sdfjkl• 14 years ago

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

heretohelp2• 14 years ago

Our company hires people who are simply interesting, intelligent, and willing to learn.

We seriously consider non-coders for positions that will be primarily coding if they have a strong background in some interesting field (like statistics).

Not all companies are just vomiting lists of reqs into the void while sitting on their hands for the perfect candidate to roll in.

kosmikko5• 14 years ago

We don't hire people based on our tech stack, or at least knowing every part of is not a prerequisite. I know that great engineers can learn any stack quickly. If you have experience in writing similar (in this case frontend heavy JS) apps with any stack you can potentially work for us.

Anyways, the stack is part of your app. You can either write it yourself or build on existing components. Sure you can build your stack on top of more traditional technology, and likely there will be more potential candidates but finding good developers will be just as hard.

almost• 14 years ago

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• 14 years ago

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

danneu• 14 years ago

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.

akoumjian• 14 years ago

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

bm1362• 14 years ago

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.

amccloud2• 14 years ago

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

nicksergeant• 14 years ago

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...

landtuna3• 14 years ago

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.)

landtuna3• 14 years ago

Also, because I don't need teh web scalez, I'm using Postgres. For fear of making things completely undevelopable for hires outside Silicon Valley and NYC, I passed on stuff like Coffeescript and SASS.

kosmikko5• 14 years ago

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.

sophacles2• 14 years ago

And if you really need a good ORM at some point, you can just us SQLAlchemy which is a lot nicer anyway.

GeneralMaximus2• 14 years ago

Did you consider Pyramid? It's insanely flexible, has amazing documentation, doesn't make any assumptions about the kind of applications you want to build with it and has a "pay only for what you need" philosophy. I'm currently using Django for my projects because it's a good fit for them (CRUD apps that generate static pages; zero frontend wizardry), but if I were to write a frontend-heavy webapp that talked to a server using a JSON API, Pyramid would be my first choice.

koblas2• 14 years ago

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.

saintfiends• 14 years ago

As someone who literally started using tornado a few days back, I can completely agree about the minimum fuss part. Though documentation is a little sparse atm, it has a fairly small code base. I was a little surprised it didn't come with a sessions module.

hogu• 14 years ago

"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?

kosmikko5• 14 years ago

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

leeoniya• 14 years ago

then you meant less verbose

nilliams3• 14 years ago

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!

kosmikko5• 14 years ago

Thanks for feedback! Yeah, that paragraph was a bit unclear, I edited it slightly.

I guess my main point was that from my personal experience, writing less code and writing clean code leads to less bugs.

eragnew• 14 years ago

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• 14 years ago

  > 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.

j2labs• 14 years ago

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• 14 years ago

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, :(

jakejake3• 14 years ago

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.

GeneralMaximus2• 14 years ago

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.

ericingram• 14 years ago

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

tbatterii2• 14 years ago

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• 14 years ago

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

tbatterii2• 14 years ago

Sure,

it ends up for our application there are a lot of rule based permissions(not every application needs this). and pyramids traversal/acl mechanism works great for this in keeping the rules for permissions separate from your view code. Without it, I would guess that 90% of every view would be asserting permissions under different conditions(repeated and prone to error), but instead with traversal we have a good separation of concerns in this area.

The reason I suggested that we move away from web2py at the time was because we were set on using appengine, and it was very aggravating for me(the only employed dev at the time) to try to do things the "appengine way" through an abstraction layer I didnt understand and it never seemed to be caught up with appengines monthly sdk releases.

We tried the django non-rel and again, you read the appengine docs(which are mostly awesome btw), they say "do it like this" and then you are diving into source code trying to figure out how to trick the abstraction layer into doing what appengines docs would suggest. I also found it annoying that so many supposedly reusable pieces I ended up having to fork and hack in order to get them to do what I wanted. So no value there either.

In the end, to me, the abstraction had no value. And we decided to accept appengine as our platform and use it as it was intended rather than use some layer that promises that if by remote chance we might want to switch to something else, we could(in theory).

Hopefully whoever reads this can understand, I am judging these frameworks based on the criteria of the application I was hired to build. I'm not saying they have no value, they just didn't have any value for us, and when you are trying to get a company off the ground and funded, you don't have the luxury of time or patience. Decisions had to be made quickly, and 24 months later, I'm pretty happy with those decisions. My decisions aren't necessarily the right ones for anyone else.

wensheng• 14 years ago

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.

mau• 14 years ago

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?

Building Backbone.js/Python based tech stack

Related Stories