By "larger applications", I wasn't talking about jQuery, Node.js or anything built upon them.
I'm talking about real software systems with, at a very minimum, tens of thousands of lines of code. More realistically, we're talking systems with hundreds of thousands, if not several million, lines of code.
C++ can scale up to codebases that large. Java and C# can handle it, as well. Even Python and Ruby can, if care is taken. JavaScript cannot. You'll be hitting numerous maintenance barriers far before then, when you're still well under 10,000 lines of code.
That flexibility is indeed useful for scripts and adding minor interactivity to an otherwise static web page.
However, people are now using JavaScript for development that far exceeds those uses. JavaScript is just not suitable for larger applications.
Once your application starts exceeding a few thousands of lines of code, the problems become very clear. You soon wish you were using a language like C++, Java, C#, Python, or Ruby. Toss in a development team made up of at least several people, if not more, and the pain becomes far greater.
The number of packages involved is a very poor measure of the effort needed to maintain a system.
Apache and more established technologies have had much more testing and are far more mature. Their releases are often much more infrequent, merely because most of the problems have already been worked out. Newer technologies, on the other hand, aren't in such a position.
Although your solution may involve a smaller number of packages, having to perform weekly or even monthly updates due to the immaturity of the software is much riskier and disruptive than having to upgrade Apache and a few of its modules once or twice a year.
I'm not sure why 18pfsmt is overly sensitive. Maybe he subconsciously feels that his new techniques are inferior to proven approaches, and exhibits this through outrage?
Something is wrong with the styling of that page. In Chrome, Firefox and IE the first few paragraphs overlap some of the panels on the right, making it very unreadable.
If you're already running a dozen sites on one server, collectively they're probably not getting very much traffic. You may very well be able to use a large number of processes just fine.
Not all Ubuntu users are using a laptop. It is absurd to penalize desktop users with a UI that just isn't suited to desktop use.
OEMs often don't truly understand the needs and wants of their customers, as well. The recent backlash, even among laptop users, shows this quite well.
The problem isn't Linux. The problem is GNOME, and to a lesser extent, KDE.
GNOME is just not a good desktop environment, yet it has often been pushed as "the" Linux desktop by various distros and vendors. New Linux users end up using GNOME, finding that it's a pretty bad experience, and then they blame Linux and OSS as a whole. Had they used XFCE, for instance, they'd probably think otherwise.
If recent experience is any indicator, it isn't getting any better. People are not happy with Ubuntu's use of Unity, for instance. Anything GTK+-based or GNOME-based ends up being a miserable experience for most people.
Regardless of how much he actually did, this is quite an accomplishment in modern-day America. Even the most basic attempts at some task slightly related to engineering should be lauded. They are very rare these days.
This isn't just "a single person's biased experience". This is an experience that millions of developers and users have experienced time and time and time and time and time and time and time and time again.
ORMs make for a bad developer experience, a bad user experience, and a thus a bad overall experience. For any serious app using an ORM, this will always be the case.
I'm talking about real software systems with, at a very minimum, tens of thousands of lines of code. More realistically, we're talking systems with hundreds of thousands, if not several million, lines of code.
C++ can scale up to codebases that large. Java and C# can handle it, as well. Even Python and Ruby can, if care is taken. JavaScript cannot. You'll be hitting numerous maintenance barriers far before then, when you're still well under 10,000 lines of code.