Merry christmas! For me it's Django for around 5 years. I use it for both personal and work projects for all the following reasons (they are well known but repetition is never bad):

* A great (really great) orm

* Best documentation I've ever seen in a project

* Predictable, no magic

* Easy to start but very powerful forms

* Great community, positive attitude, always willing to help

* Batteries included and, for anything missing, lots of add-ons (in the form of apps) for all your needs

* It's in python and supports both 2 and 3

* Good i18n support (english is not my primary language)

* Good templating

* MVT (model view template) architecture works great, especually after you switch to CBVs

* Great support for REST (through django-rest-framework)

* Easy and to-the-point project configuration supporting multiple deploys (development, production etc) and non-commited to vcs settings

I've tried other frameworks in the past but I've always stuck in a missing feature or just wanted to do things in the django way.

I'm pretty sure I'll be minority here, but I don't use any backend framework for page rendering. All my apps are pure SPAs. They render all the screen content themselves on the client and only query servers for data. I prefer this, because I can simply take any app and deploy it to server just by copying its files. I only need to scale API servers and I don't have think about app scaling, because just single instance of nginx with proper caching setup can handle hundred thousands of clients (serving static resources is cheap and fast). Also you can take same app, package it as cordova and deploy to app/play store (although this can be probably achieved with any other frameworks as well). On the frontend I use combo of react, redux, redux-saga ...

Before I've used backbone, but react with redux is night and day difference. Even you're just starting with js, your apps will be less error prone, because of concept unidirectional flow.

Maybe this is no longer special to react/redux, but I'm really not in the age I can switch frameworks everytime some new stack arrive. React serves me well. And then, there is also react-native, which is 90% same as react so you can reuse what you have learned. Other frameworks don't have this close to native counterpart. (not counting cordova, which allows to use any fw, but performance will never be same as react-native).

ASP.NET MVC, because:

- ASP.NET MVC makes it much easier to keep your domain logic decoupled from the framework. This is in contrast to frameworks like Django who expect you to use their ORM, and to derive your model classes from a framework provided base class.

- It's C#. I know it well, it is common in industry, and it is statically typed. For programs of any real complexity, I find statically typed languages to be much more efficient and pleasant to work with.

Eventually I want to move more in the direction of stronger type systems, but it doesn't seem like there are many jobs out there for Haskell programmers who aren't programming demi-gods.

Django, mostly. I like its batteries included approach and its maturity. I've found it's a great tool for many jobs. Every now and then I'll use something smaller, like Flask or Falcon, but as soon as I need an ORM, or auth, I use Django.

I've also used Phoenix a few times now and have been enjoying it. But I know Python much better than I do Elixir, so I skew towards that.

Django, because:

* Very little magic in the core.

* Well architected and loosely coupled (in spite of its sometimes-rep it's not actually monolithic: http://olifante.blogs.com/covil/2010/04/minimal-django.html)

* Largest/most solid ecosystem of 3rd party packages (except possibly rails) that does everything from authentication, CMS, CRM, ecommerce, comments, anti-spam, caching, REST APIs, file uploads, admin, emails, authorization, regular authentication, social media authentication, admin plugins, data import/export plugins, etc. etc. etc. meaning that there's an awful lot of code that you don't have to write.

* An opinionated core which means consistency which means that those 3rd party packages that all use caching, ORM, admin forms, etc. fit together and you don't have stuff like CMS plugins that just decided to use mongo for the hell of it (http://quokkaproject.org/) or 3rd party plugins forced to support 3 or more different storage backends (https://pythonhosted.org/Flask-Security/).

* Python is a terse and readable language with (relatively) strict runtime type checking and a huge ecosystem outside of just web stuff.

On the frontend: React, MobX, TypeScript

TypeScript, because its a fast compiler and has the best typechecker support and typings collection for existing front-end libraries, so there is almost no need to wrap anything.

React, because its conceptually simple, has wide community support and I get TypeScript's type checking inside the TSX templates too, unlike in Vue and most other frameworks.

MobX, because it needs less boilerplate than Redux, plays better with TypeScript than immutable.js, is really easy to make performant (lots of observer components + computed properties) and its intuitive to developers coming from Angular, knockout or Vue.

On the backend: TypeScript, Node, bluebird, node-sql and PostgreSQL

TypeScript, because it makes it easy to write end-to-end-typechecked programs if the backend language is the same as the frontend. The client and server can both claim to implement the same interface, and then its easy to see if any changes violate that contract. Additionally, server-side rendering with React is simpler.

Node, because its reasonably fast without thinking too much about it. The only pitfall are accidentally cpu-bound tasks, but in practice those are a problem rarely and I'm working on a tool to detect and report them: https://github.com/spion/long-task-detector

Another thing missing in node are better streams. A promise-friendly version of pull-stream would fix that.

Bluebird, because its fast and provides a great debugging experience with long stack traces

PostgreSQL, because it can go very far for many things before you need something else.

node-sql, because its an SQL query builder for node which can be made typesafe with TypeScript, and because query builders often beat ORM spaghetti in performance and maintainability in the long run.

I've tried different JavaScript frameworks. I've seen Backbone, Angular, Knockout, Rx.js, React, Redux, MobX, Rails, Asp.net, Meteor and Django, I've tried almost every popular option to compile/transpile into JS - Coffeescript, Typescript, Livescript, Gorillascript, Fay, Haste, Elm, GHCJS and Babel. I've used Grunt, Gulp, Browserify and Webpack. Nothing ever made me so happy and so excited as Clojurescript. Things are so simple, so elegant. Code has never been ever before so easy to reason about. Sharing code between backend and frontend became reality. FFI to existing JavaScript code is so natural. Ring, Compojure and Om.Next, Clojure.spec and generative testing, Figwheel, Devcards, Boot-clj. core.async and pattern matching. My goodness. I just don't understand anymore devs, choosing to struggle with other stacks. Everytime when I try to compare - CLJS feels just a few steps ahead.

I use Django for my projects and I prefer it over Java Frameworks although I am an ex-Java developer. Python/Django feels quicker and lighter than Java/Spring stack which result in productivity boost. I explained in detail why I use Django on my story https://hackernoon.com/why-i-chose-django-over-java-framewor...

Django. I like the "batteries included" aspect. Flask and Sinatra are fun, but I wind up spending more time than I'd like stitching authentication etc together instead of building the project.

If it's my call, Rails since 2005 because it was easier than Java and much quicker to deliver. It still is.

If it's customers call, I used Node (as sw architect), Django, Flask, Web2py. All of them are less opinionated than Rails, which IMHO is bad because any project can be different and it costs time to get on board.

Phoenix, for a lot of the same reasons I used to have for Rails including:

* Fast development cycle

* Conventional

* Great community

* Good ecosystem of libs to take advantage of

* "Magic" (although Phoenix's magic is much different)

And some of it's own like

* Great concurrency (which feels like a free win over Rails)

* Functional programming

* How Ecto, the ORM works

* How simple it is, even with the "magic" included.

* How assets are handled, via a thin layer to Brunch, Webpack, or other JavaScript asset bundler

There's a few more, but I think those are a lot of the major talking points.

Rails - because Ruby is easy to learn, especially for beginners and you get great, custom things done in no time. Also Rails forces you in some patterns that make sense in my opinion. Testing is also fun.

I used Node and Loopback.js for my last project (massive project). It was great in the sense that it helped us avoid writing lots of boilerplate, but the ORM and the "current context" module were a constant source of frustration.

Now I'm working on a project with a smaller scope and I'm simply using express.js and knex.js, no ORM. I love the simplicity and level of control I have. It's liberating not to have to guess what the ORM is doing to my data between my code and the DB layer.

Meteor - It's a fullstack framework that let's you write JavaScript both on the front- and backend. It let's you choose what you want to use for your frontend (e. g. React, Vue, Blaze, Angular...). Best feature: It's realtimeness.

And right now I'm trying Laravel (PHP). It has a great documentation. I like the ORM and that it's easy to use. I want to build an API with it and consume it with a SPA and react.

I don't know how some of you guys have the time to get real experience with dozens of frameworks. I've only really used a few. Out of what I've used, Ruby is my favorite language, and I use Rails for anything with a database, and Sinatra for anything without. Thoughts:

ActiveRecord is the best ORM I've used so far. You don't need a ton of boilerplate or config to get up and running with it. It supports all of the basic stuff, and seems to do it well, and for more complex stuff, it makes it easy to drop down to SQL instead of trying to put a ton of ugly glue on top of doing complex stuff in SQL.

I like the way Rails has commands to output the whole route table, and the whole middleware stack it's using. Along those lines, I like the way the router works, and the way that most of the advanced functionality is neatly tucked into middleware that you can add or remove.

I like the flexibility of being able to plug in a bunch of JS processors, template languages, CSS processors, etc.

I like how much functionality you can add by just throwing a gem in the Gemfile, and the Bundler system does a good job of tracking gem versions to keep all environments consistent.

Competitors I've used:

ASP.NET MVC: Too much functionality is buried in either the IIS server or other libs that you can't debug into easily. I don't like the routing much - there's too many ways to specify routes, all of which seem unclear, and there's no single place to see all of your routes as the framework sees them and where they all route to. Plus the often-incomprehensible method argument matching. MVC tries to be all clever in deserializing arbitrary JSON and XML into .NET objects, which is handy when it works, but good luck debugging what happened when it doesn't work, and good luck if you just want it give you the freakin' request data as a plain old string. I've spent hours smashing my head against trying to get MVC to actually route my requests to the intended controller methods and do something reasonable with the request data. And I still haven't made sense of Entity Framework.

I've also toyed with things in Java, NodeJS/Express, and a few other things, but I don't feel like I've really used them enough to offer an opinion, besides noting that the "common knowledge" of Java being verbose and over-complex, and NodeJS/Express being too bare bones seem accurate.

Spring with Spring Boot in Java. Batteries included and easy to setup and get going. A statically typed language to catch errors at compile time. Easy to deploy by building an uberjar. Great dependency management and builds with Gradle/Maven and built-in support for pretty much any common database and message queue.

For us not-so-smart-people who liked MS Access: PHPRunner.

From a programming standpoint, it's the worst thing in the world: A Windows GUI thing that builds PHP apps and it's closed source.

From a get-stuff-done standpoint: I made a tracking web-app for large expensive tools that knows about Customers, Project Locations, Scheduling, Work Orders and Invoicing - it will grab a customer signature and email them the receipt. I did it in about four hours.

It has hooks in the system for those that actually know what they're doing (not me) to embed PHP code at important points.

I'm operating with Express on one end with React on the other. The big difference with this setup is GraphQL in the middle. It is a huge help to making sense of data flow, what with the strictly typed schema and the built in subscription model. I've also engineered my own event sourcing/CQRS framework with the intention of expanding the app with micro services eventually, but it's just one server node for now.

I recently switched to nodejs from flask and I like it but there are some issues

The pros:

- programming the same language in the frontend and the backend (which becomes a big deal when you do serverside rendering of react components)

- for some reason AWS and Google App Engine have very good nodejs support

- very fast io

- very fast iteration time, faster than python

The cons:

- the lack of quality libraries and standards. With flask there are well known, well tested libraries for every use case. Not so with nodejs.

- javascript, which isn't really a big deal

Django - I am learning and I think it is easier to learn. It is much easier than php.

PHP Symfony for large backend application. I rarely use front-end Pros: - Well structured - Lots of bundles - Large community - Doctrine and Monolog support out of the box Cons: - Steep learning curve in the beginning

None: http://www.catonmat.net/blog/frameworks-dont-make-sense/

I've mainly used Ruby/Rails from ~2008 to ~2015 both for work and side projects/prototypes, then I totally switched to Elixir/Phoenix for almost all my stuff. I still use Ruby/Rails for some works (where/when I can't use Elixir due to some constraint).

I've found that Elixir and Phoenix have an awesome community and a fast-growing ecosystem. The language is very clean and I can solve problems in a cleaner and faster way. It has all the tools I need and runs on a simple but powerful virtual machine with stunning performance and easy deployement. I can use websockets and async jobs without running external processes/daemons and thanks to brunch (or webpack, it depends) I have a powerful toolchain for frontend. Speaking about frontend, I've recently moved from React to VueJS, it's a very decent compromise between React and Angular: simple like React, with features and concepts similar to Angular.

I've been using Tornado for about a year now, and I'm incredibly happy with it. Here is some of the background and reasons for that:

* I had been using Django for some 5-6 years, until I finally realised that I'm not happy with many of its architectural decisions -- global singleton settings, the way views are organized, the way it's organised around the ORM and everything. It provides a lot of tools, but if you don't need some of them them tough luck, you still get to lug them around and it's not helping you find any workarounds.

* I've learned to prefer frameworks that don't get in your way and allow you to choose any individual components for individual needs. I've worked with Flask and Bottle, which are great but sometimes go too far in the opposite direction, focusing so much on simplicity that more complex tasks require jumping through a different set of loops (I'm looking at you, Blueprints).

* Tornado's Web framework is successfully avoiding both types of traps, and it gives you the ability to develop simple apps -- say, a REST API -- quite easily and naturally, at the same time giving you the room to grow your creation naturally as needed. I've briefly tried Falcon, which follows a similar philosophy, and is IMO a great alternative.

* Tornado, however, is not just a Web framework -- it actually provides an amazing set of tools which can be easily in your app or even without any relation to a Web app. And the best part of the toolset is its asynchronous networking capabilities, which provided things like coroutines long before they existed in Python -- and now you can combine the two in a same app.

* Last but not least, Tornado provides an amazing, production-ready, non-blocking HTTP server. Most of the other frameworks make a point of not using their built-in servers in production, instead advising you to plug your app into a WSGI server like uWSGI or gunicorn; you can do that with Tornado too, but if you don't your app can process requests asynchronously, preventing slower requests from blocking faster ones.

Back-end: Node.js + Express + ws + Johnny-Five

Front-end: Bootstrap + (Three.js or Snap.svg) + ws

I create browser-based interactive UIs for controlling Arduino robots. I like to keep the web stack as simple as possible because the tricky/hard parts are in the robotics layer.