Over the same period of time I have experimented with a good chunk of the new/popular/interesting toolkits, languages, and whatever - in search of the best tools to use in my craft. There are too many good but not overwhelming choices. Python or Ruby or Java or Perl or Smalltalk or Lisp or … at the end of the day I do not find any of the many choices especially compelling compared to the others. What is needed is some criteria filtering down the alternatives. The list boils down to some clear choices:
- On the server-side C++ is going to be around forever for whenever brute force processing is needed (not for many/most web applications).
- On the server-side Java is going to be around forever, has a huge collection of libraries covering almost everything needed by a web application, and can be quite efficient with all the work on the JVM.
- Between the browser and server shipping HTML and JSON seems generally to make the most sense. Yes, I am mostly ignoring XML for in the client and on the wire.
What is missing is something a bit looser on the server. For many tasks getting lots of function written is more important than high levels of efficiency. This is where Lisp, Smalltalk, Perl, Python, Ruby, PHP, and shell-scripting came in. Which do you pick and why? They all have merits, but none seem like a clear winner.
- Generating and consuming JSON data gets just a bit easier.
The other piece of the puzzle is integration into IIS (for the Windows folk) and Apache (for the Unix folk). Personally I like the notion that the application/interpreter runs in a seperate process, lashed to the web server with something like FastCGI (or similar). There is an existing FastCGI extension for IIS, but new IIS versions tend to break extensions in interesting (not) ways. The news of late is that Microsoft is offering a FastCGI extension. This is very good news for folks deploying applications on Windows, as we hopefully should see fewer problems with new IIS revisions.