

Building Backbone.js/Python based tech stack - kosmikko
http://www.mikkolehtinen.com/blog/2012/05/25/rewindy-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! :-)

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

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

~~~
pyre
I've always been under the impression that those "50 years of Java + .Net +
COBOL" adverts are purposely made unattainable because they already have
someone lined up for the job, but they need to 'advertise' the job for legal
reasons.

~~~
heretohelp
Incompetence is a pretty common reason for it. Your case you outline is pretty
rare.

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

~~~
rexreed
Wow - I think this is great!

~~~
jakejake
thanks! any feedback or help is absolutely welcome. this is my first major
github project so i'm still figuring things out (long time svn user, new to
git) but the framework development is very active and in use on production
servers.

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

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

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

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

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

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

------
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/>](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
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.

~~~
nilliams
Awesome, glad to be of help :)

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

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

