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.
I was never able to personally judge that statement. My experiences show that the flexibility of JavaScript only improved maintainability of the software written in it.
http://npmjs.org/ is a list of solid software (also large software) written in JavaScript.
So I don't think your statement, about maintainability being connected with how flexible a language is, can be proven to be true.
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.
Why do you think JavaScript cannot handle it? If you reach the million lines of code you probably have a really modular application, otherwise it's unmaintainable in any language. Being modular it can be sub-divided in many small layers which are the size of a jQuery library.
I think your experience with JavaScript comes from reading code made by bad developers. If your software is written by good people it will be maintainable even in JavaScript.
I've worked on some larger applications in javascript (though nothing incredibly large), and I can tell you if I had the choice of using any language that offered static and strong typing I'd take it in a heart beat. A small change in one place often means an error in some part of your code you didn't even think would be affected. I've loaded 65k LOC JS files in firebug and webkit's debugger chasing some error down that was happening in some piece of code that I've never seen before. All because that's how far my screw up managed to travel when there is no type checking or strong typing. In that particular case I had set a string value to something that was supposed to have been an array. Something like that would never have happen in, lets say C#, but "crap"[0] or "crap".indexOf("c") or ["c", "r"].indexOf("c") are all valid JS.
Dynamically typed languages offer a lot of benefits and a lot of burdens. Only you can judge whether you're willing to take those risks. Personally I am more comfortable with dynamically typed languages as they feel more natural and less programmatic, but this is just personal taste.
Nothing of this is related to the free-formness of JavaScript. Python and Ruby are also dynamically typed.
I have no experience with ruby, but python's advantage is in strong typing. Try and add an int and a string and you'll get a type error, JavaScript on the other hand will do it though. While maybe allowing you to write more expressive code, it does mean that errors become harder to locate, and when dealing with larger applications, I prefer being able to locate errors quickly.
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 happen to find this post very helpful as a student of the craft, and your comments seem to be defensive of a traditional approach because you don't care to examine the reasons for the choices you've made. The pros and cons of either choice would be more helpful than demonstrating animosity toward an approach you've chosen to dismiss.
It's great that you have a setup you know and are comfortable with, but for those of us that would like to explore all options these posts are very helpful. It sucks you have to dismiss this as a ploy to be "hip".
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.
That is probably true CPU wise, I am just worried about memory. If each process is 50 MB and you have 12 servers and 9 processes per, that is over 5 GB. If my machine only has 4 GB of RAM some of those processes must be in the swap file.
you can do pretty well with 1-2 processes per site; if you don't have the traffic to warrant it, there's no reason to run more. gunicorn can also use an async worker type (gevent) which can help keep the number of needed processes down.
django also has a sites package, so you can run multiple sites per django instance. it's less encapsulated but if you run a high number of websites with a low amount of traffic each it makes a lot of sense.
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.
I personally think the whole "Linux Desktop" issue is a bit of a red herring. GNU/Linux (and, I assume, other libre Unixes) is the only widely-available OS I know of where it is even possible to use a graphical environment without the "desktop" metaphor, which I see as a huge step forward.
To me, the "desktop" is all about entrenching the various kinds of boring, repetitive work that computers are supposed to relieve. This insidious metaphor is implicit in everything about how desktop environments are used and developed: the way users are encouraged to scatter icons across their screen for fast access to files, instead of encouraging organization and fast access via searching; the presumed importance of "office" software that most users could replace with a typewriter and a calculator; the focus on making the environment "intuitive" from the first moment one uses it, at the expense of training the user to eventually learn to use their computer more effectively and efficiently.
I would much prefer to see the free software community put its efforts into building graphical environments that eschew the desktop metaphor, and instead focus on making it easy for the user to off-load work to the machine. Part of that task is making it easy for the user to discover what the components of the environment are, how they work, and how to recombine them in novel ways.
A good test for this, I think, is how well a graphical environment supports a task like data entry, because it's the kind of thing that just about every computer is going to have to do at some point, and it is often a mind-numbing task. It's often mind-numbing not because the task is boring, but because most "desktop" environments provide no way to offload the cognitive advances you can make while doing it. After a few records, you know you have to check that field C looks a certain way relative to fields A and B, or that it's faster to enter field E before fields D and B, etc.; but the software you're using provides no way to encode this information, so you have to remember this boring algorithm and execute it repeatedly yourself, instead of letting the computer handle the algorithm while you focus on edge cases.
The challenge is to build an environment that a user can offload the algorithmic aspects of their work onto, without requiring the user to be a full-on programmer, at least not at first.
Free software has already taken some significant steps in this direction. Tiling window managers, the OLPC's Sugar interface, and even to some extent programs like Emacs are examples. We're ahead of the game when it comes to building a new metaphor for working with a computer. We just need to recognize it.
I briefly played with Unity as included with Ubuntu 11.04 and felt that it was interesting, but unfinished. I find Gnome 2 very usable now, though it had rough edges for years. Unity is less usable due to its rough edges.
Distributions intended to bring new users to Linux might do well to focus more on testing than new features. I've been using Linux on various laptops for almost 10 years now and I don't want to deal with instability and broken things on my production machine. New users looking for an alternative to Windows will likely find the grass is not greener on the other side. I'm not talking about ugly UI or inconsistency. I'm talking about the fact that my Thinkpad won't suspend, that my sound sometimes stops working, that my notification icons for Skype and a couple other apps were 1px for over a month while the bug was well-known.
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.
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.
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.