> Step 1. Pick a language.

Since the focus seems to be on web backends (given the section following this one), I'd imagine that trying to use C or C++ for such a thing would not be one of the obvious choices.

Also, you've listed Scala twice, I'm pretty sure Xhp and Hack count under PHP, and God help you if you opt to use ColdFusion or ASP.NET (or PHP, for that matter) in anything new.

> Step 2. Pick a framework for the selected language:

Once you've picked a language, you can usually narrow down the selection quite a bit. For some languages it's a bit harder, but for most, the choices are manageable.

C/C++ -> Raphters, CppCMS, WSO2, Wt, ffead-cpp

Go -> Revel, Martini, Gorilla

Java -> Spring, JSF, Struts, GWT, Play, Grails (if we count Groovy as Java), maybe some others that I haven't heard of yet

Ruby -> Rails, Sinatra, Padrino (which is basically Sinatra plus some helpers for databases and views), camping (if anyone actually uses camping in production, please let me know)

Python -> Django, maybe some others (but Django's the only one I hear about regularly)

Dart -> does anyone even use Dart? I'm pretty sure even Google has moved on to Go for backend stuff, and the plan to integrate Dart with Chrome was apparently cancelled.

PHP -> Laravel... I can't think of any others that I've actually seen used. Pretty much every PHP app I've encountered was CGI-based.

Erlang -> YAWS or ChicagoBoss. If you're counting Elixir with Erlang (we might as well), then we can throw in Phoenix and Sugar.

D -> vibe.d is the only one I know of

Javascript -> Node.js, probably.

Perl -> Catalyst, Mojolicious. Or just use (Fast)CGI.

Scala -> Play, Scalatra, Lift, Sweet, Slinky

Clojure -> Compojure, Webjure, Conjure, Moustache

Lisp -> (Common -> Weblocks, possibly Hunchentoot), (Scheme -> SISCWeb (via J2EE)), Racket

ColdFusion -> ColdFusion. I don't know if ColdFusion doesn't instead count under the Java category, though.

ASP.NET -> I dunno, ASP.NET?

Basically, once you have a language picked (based probably on which one looks the best to you), it's pretty straightforward to search the web for "$LANG web frameworks" and find some sort of comparison between them.

> Step 3. Pick a database:

If you're not picking PostgreSQL, then you're wrong, end of story. Maybe CouchDB or Mnesia if you know for sure that you need their replication features and are aware of the tradeoffs of using a non-relational database.

SQLite deserves special mention, because while it's absolutely wonderful for end-user applications, it's not at all ideal for server software except for specific use cases (like using it as an offline data storage format, e.g. for backups or data imports/exports).

MongoDB, Oracle, MS SQL Server, and MySQL also deserve special mention because, if you're using them willingly in a new application (other than to interface with a legacy system that did involve such a regrettable choice), you're probably not right in the head. In particular, there's pretty much zero reason to use MySQL instead of MariaDB (which is also arguably marginal due to its MySQL heritage, but at least it's slightly better), using a commercial database like MSSQL or Oracle is basically begging for vendor-lock-in-related problems, and MongoDB... Jesus fuck-me-in-the-ass-with-a-pogo-stick Christ. Might as well just pipe your data to /dev/null while ranting about how it's "web scale" while we both transform into 3D-animated bipedal animals and I resign from my job as programmer/sysadmin and go shovel pig shit for a living.

> Step 4. Pick a hosting provider: Classic or Cloud and pick from just several hundred providers with different APIs and architectures.

If you're smart, you'd go with Cloud Foundry, since a large number of PaaS vendors support it, so you can pretty much just pick whichever one has the best bang for the buck (might I suggest IBM Bluemix?) and use the `cf` tool to deploy to it.

Additionally, if you're using containers of the Docker variety, the vast majority of PaaS and hosting companies nowadays support them with little to no modifications, so - again - the choice matters very little beyond one's priorities regarding performance, location, and cost.

> Step 5. You're all set! Enjoy your backend. Now it's time to pick a front-end !

Now that is a massive can of worms. So many frontend frameworks. So little time. And pretty much all of them constrained to the quirks and pains of Javascript.

Of course, you could just go with straight HTML and CSS (plus a smattering of JS using JQuery or Mootools), which is what I generally prefer to do in most cases.