Apparently you really have to learn those, plus, flask, backbone, coffescript, require.js, jquery, bootstrap, handlebars.js, stylus, mocha, zombie, etc., etc. Simple! :-)
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.
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.
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 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 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.
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 wonder if partials count? I don't know that all of the moustache derivatives have them anyway.
But for larger apps Handlebars.js is great because it supports pre-compilation which helps boost performance.
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.
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.
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.
https://github.com/j2labs/todos is an example.
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.
One thing is for sure, though, the bar has been raised.
> I'd prefer to use Python rather than having to
I haven't actually played with it much, so this is not an endorsement.
and https://github.com/amccloud/backbone-bindings (my library)
How does require.js make coffeescript debugging easier?
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!
I guess my main point was that from my personal experience, writing less code and writing clean code leads to less bugs.
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.
Good roundup list.