Stop pushing the web forward

But, even Firefox has a rather limited UI... Whenever you build anything with a moderately complex UI, it becomes nearly impossible to offer a good cross-platform experience.

I also think that standing on the shoulders of bootstrap and material design (like materializecss) is a better place to start where users will be cross platform than trying to look native everywhere... not to mention that native looks different every other OS release. Hell, look at MS Office from version to version, they break most of their own rules. A relatively clean, usable design is more important than getting everything precisely native looking everywhere.

Just let the browser do what "applications" did in the 90s, while not breaking the stuff that browsers did in the 90s.

After several years of working with VS, Eclipse, and a couple of other developers' IDEs, I can say -with a straight face- that developers' IDEs are slow primarily because they do a lot of work.

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

Here's Firefox, immediately after entering a site name into the URL window.[1] The only visible effects are that the tab name has changed to "Connecting", and the reload arrow has change to an "x". On Firefox Mobile, you don't get either of those, just a one pixel high progress bar at the top of the screen. It's worse on mobile, where things are slower and there are fewer auxiliary GUI items on screen.

At this point, you've only partially left the page. Some clickable items on the page being exited will still work. It's not entirely clear exactly when event processing for the old page stops.

[1] http://s3.postimg.org/53784icoj/afterlink.png