Building Backbone.js/Python based tech stack(mikkolehtinen.com)
mikkolehtinen.com
Building Backbone.js/Python based tech stack
http://www.mikkolehtinen.com/blog/2012/05/25/rewindy-tech-stack/
15 comments
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.
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.
And then people complain when they can't seem to hire anyone that knows their tech stack of the minute.
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.
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.
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.
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.
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.
Incompetence is a pretty common reason for it. Your case you outline is pretty rare.
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 :)
My thoughts exactly! How many tools and tech does one website need?! :)
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.
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/
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/
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.
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.
I love it! I Was looking at doing something similar with Scala.
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.
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 :)
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 :)
I tend to prefer mustache, because I can use the same template code server-side and client side trivially. It's nice for cases where you are pre-filling stuff, or where you want to render for no-script situations.
It might be better to say that it's free of control flow structures[0]. This is my preferred approach but it can definitely take some adaptation if you're used to doing a lot more in your views.
[0] I wonder if partials count? I don't know that all of the moustache derivatives have them anyway.
[0] I wonder if partials count? I don't know that all of the moustache derivatives have them anyway.
While I do love and use Handlebars for our Backbone app, if you find yourself using a lot of such each block helpers... you may want to create a new Backbone view to handle that
Does anyone use Dust? http://akdubya.github.com/dustjs/
Some discussion http://news.ycombinator.com/item?id=3349845
I agree.
But for larger apps Handlebars.js is great because it supports pre-compilation which helps boost performance.
But for larger apps Handlebars.js is great because it supports pre-compilation which helps boost performance.
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.
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.
Could you elaborate on why you wanted to replace web2py, and what django/pyramid do better than web2py for your use case?
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.
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.
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...
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.)
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.
Are you implying that you can't use Postgres for web-scale services?
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.
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.
IMHO - Sessions don't make sense at scale. When you have sessions you usually cache objects in sessions, which means you need complicated update mechanisms. Better to store the objects in Redis and just have a single update...
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.
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.
And if you really need a good ORM at some point, you can just us SQLAlchemy which is a lot nicer anyway.
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.
https://github.com/j2labs/todos is an example.
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, :(
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.
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.
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.
One thing is for sure, though, the bar has been raised.
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 :)
> I'd prefer to use Python rather than having to
> internalize Javascript syntax
I haven't actually played with it much, so this is not an endorsement.
backbone.modelbinding is abandoned. Alternatives:
https://github.com/theironcook/Backbone.ModelBinder
and https://github.com/amccloud/backbone-bindings (my library)
https://github.com/theironcook/Backbone.ModelBinder
and https://github.com/amccloud/backbone-bindings (my library)
Yeah thanks,
I forgot to add a note on this.
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.
"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?
How does require.js make coffeescript debugging easier?
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!
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!
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?
Django+tastypie works with backbone.js with very little configuration.
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.
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.
Yup! and i've packaged those little configurations into a plugin. https://github.com/amccloud/backbone-tastypie
Seems like it might be tough to maintain an app with so many external dependencies
Curious, have you given dotcloud a try?
Good roundup list.
Good roundup list.
Apparently you really have to learn those, plus, flask, backbone, coffescript, require.js, jquery, bootstrap, handlebars.js, stylus, mocha, zombie, etc., etc. Simple! :-)