We Keep Coding

class use in a prototypal inheritance-based language

The following answer to this question does a great job explaining the differences between classical inheritance and prototypal inheritance. this was of interest to me to understand because I started working in Java, but moved over to Javascript.
In his answer, he states for prototypal inheritance that, "All of the business about classes goes away. If you want an object, you just write an object."
Yet there is so much documentation and questions on how to "write classes" in Javascript.
Why is there push to make the language something it is not. I'm looking for concrete examples of cases where using classes in JS applications are more sensible in this prototypal language and the benefits of awkwardly fitting a square peg into a round hole. As Aravind put it, why are people learning Javascript by comparing it to others, and not as it was intended... and why is this practice seemingly encouraged?
Bottomline question: Why are classes being introduced in ECMAScript 6?

The masses like classes.
There's nothing "more" or "less" natural about prototypal inheritance, this is entirely subjective. JS is its own language, just like Smalltalk and Self had different ideas about what it meant to be an object.
ES6 classes are syntactic sugar. They normalize/clean up how inheritance/etc are to be used in JS.
Similar to CoffeeScript, they attempt to standardize how OOP is done in JS, and make it more familiar to people that aren't used to prototypal inheritance.

Why are people learning Javascript by comparing it to others, and not
as it was intended?
This gets into cognitive and learning theory, but the short version is that humans like things that are familiar, and one of the ways we learn is by relating new ideas to knowledge we already have.
Why are classes being introduced in ECMAScript 6?
Classes were almost introduced in ECMAScript 4, actually. I think there are good arguments for OOP being a useful pattern for writing complex software, and class based inheritance is more familiar to many programmers than is prototype based inheritance. I think an equally valid question might be "why does JavaScript still implement prototype based inheritance when most people who learn it will be more comfortable with class based inheritance?"
If you're curious what classes in JavaSCript might look like, take a look at ActionScript 3, which is based on that draft of EMCAScript 4 with class based inheritance.
Of course, just because ECMAScript adds class support does not mean that JavaScript will, or at least that it will any time soon.

I found this article by Zakas explaining it clearly, that it's just syntactic sugar, and at the end of the day Javascript will work the same way.
Don't worry about having to learn classes or having to shift your programming styles, nothing changes. :)

Why are classes being introduced in ES6? Sugar, of the syntactic variety.

Classes are very good for people who come to JavaScript from object-oriented languages (like Java).
This is the experience I've made several times already. I had a number of J2EE web projects with good Java dev teams, who had some JavaScript knowledge, but not much. Almost the first thing I did was to explain prototypes, prototypal inheritance and how one can implement the OOP paradigm using prototypes - basically the pseudoclassical inheritance. (Now I routinely do a "JavaScript for Java Developers" workshop almost in every project of that kind.)
With that approach I mostly saw good code coming out. Most Java developers tend to stick to the pseudoclassical pattern and are quite happy with it. This is most probably not what JS ninjas out there would write, but, frankly, I don't care. The code is easy to understand and to maintain, people had a good learning curve and were productive very fast.

Prototype languages, like JavaScript, are really great for small scale, short term projects that don't require a lot of testing or maintenance. Their simple and flexible functionality really shines in this realm.
Class based languages on the other hand tend to be a little more rigid and require more setup, which isn't as great at the little stuff but the extra structure is helpful to keep the larger, long term projects scalable and manageable.
When JavaScript first started, its primary function was to manipulate static DOM elements, which is a great application for a prototype language. Fast, flexible and simple -- no fuss. Now, however, the role that JavaScript fills is much more complex and is more and more an application than a simple script. Adding classes to a prototype language does sound a little funny, but the added structure classes provide, along with their widespread familiarity could very easily help teams of developers handle the complexity of modern JavaScript applications.

Learning JavaScript... Should I skip straight to the good stuff (the frameworks)?

I learnt HTML/CSS a good few years back, then PHP a little later. I've recently become interesting in web development again, just started playing with frameworks like Django and RoR. I'm curious as to how much time/effort I should spend learning straight JS before looking at frameworks. I've been reading through a let of articles called Mastering AJAX by Brett McLaughlin which seems quite good, but I'm seeing a lot of stuff (such as cross browser compatibility - even for things like XMLHttpRequest) coming up which look like they would be non-issues if using a framework.
So, should I keep reading through these articles and try to build stuff using basic JS, or should I just start looking into jQuery and the like?
Also, I've been watching a few videos regarding GWT from Google I/O. I've been learning Java over the last year, built a few medium sized apps in it. I'm wondering if GWT is something that's worth going straight to, along with gQuery?

Starting with the basics of JavaScript is a good idea, IMHO.
Read JavaScript: The Good Parts, by Douglas Crockford. Very, very good book.
You should also check out Douglas Crockford's web site.
I also had to come back here and mention this in an update:
Douglas Crockford presented an illuminating talk about JavaScript - past, present, future - at the Microsoft MIX10 conference earlier this year. You'll find the full video for Crockford's talk at Microsoft MIX10 - The Tale of JavaScript. I Mean ECMAScript.

No.
Just as when you are learning to program you are taught first C/Pascal then Java/C++ and finally Python/Ruby/Smalltalk/Lisp, and when learning any language you start with simple language constructs, you should first learn ECMAScript, then learn DOM and finally frameworks.
Why? Because you'll have a deeper understanding of the language, and will be able to debug things that might seem odd unless you've got that learning experience.
If you are a seasoned developer, you can speed up each phase, but don't skip them, or you will have problems due to not fully understanding the small oddities.
Javascript is an interesting and fun language, but can act rather odd at times (Date has bitten me a couple of times in the ass).
Use frameworks to avoid repetitive tasks and to simplify your code, but not as a starting point. Simplicity is a final goal, not the starting point, and frameworks are for that, simplicity, not for learning a language. Frameworks are intended for simplifying things for experienced developers.
Learning the differences between browsers (DOM implementations) will allow you to debug your framework. That is priceless.
I've been learning Java over the last
year...
Javascript is not Java. Never was never will.
Even if you can compile to Javascript from Java, it's still a framework, don't jump into it unless you already know what you are doing.

I think "both." Mix it up. Play around with a framework. You'll get stuck when you try to do something real, so you'll pick up some JavaScript to figure it out.
A lot of the good jQuery books teach you JavaScript along the way.

This is one of the best videos for beginner javascript developers that understand how to program in other languages:
It's a talk the John Resig did last year at Northeastern, most of it is devoted to talking about core javascript, then the last quarter of the talk jumps into jQuery:
http://video.google.com/videoplay?docid=-7485992465859932389&ei=jhZUSu73OpfSrQLgyYV3&q=john+resig&hl=en
It's actually a really interesting tech talk and presentation since he does live examples and Resig is pretty good at presenting.
Like others in this question, I also highly recommend reading Javascript: The Good Parts for a better understanding.

Yes, jumping straight to framework-based programming instead of DOM is a good idea.
I started doing JS before any major frameworks like jQuery came along, and was reluctant to switch at first, but when I first started using jQuery, it felt so good to be able to write selectors and stuff and not have to worry about cross-browser compatibility.
However, there are some areas of JS where frameworks wouldn't be available. One of them is in userscripting, where you have to make your script work on a site you don't control. Another such one is the use of JavaScript in applications such as XUL.
Overall, I suggest you start with some trivial JS applications, then switch to jQuery instead of going on to the complex topic of DOM.

What makes you think that the frameworks are the good stuff and the JavaScript is not?
If you ask me, I will say that JavaScript is a real fun language and you should learn it first. JavaScript has received bad rap because it was mainly used for browser scripting and those browsers were buggy making people think that JavaScript sucks.
Crockford says that JavaScript is the world's most misunderstood language.
If your prior experience is with PHP (or any non functional language for that matter), the concept of 'first class functions' will really give you an 'aha' moment. 'Closure' will be another tool which will simplify your code and will make you wonder why all languages don't have it. Prototype inheritance will show you that there are alternatives to OOP. I would definitely suggest that you learn JavaScript first before you jump to any frameworks. I must add that you will also have to learn the concepts (first class functions/closure/prototype inheritance), to use any JS framework efficiently as all frameworks exploit the features of JavaScript.
To learn JavaScript, get Crockford's 'JavaScript, The Good Parts' book and try to learn the language using a standards compliant browser (say Firefox [with FireBug], Safari, Chrome) without focusing on DOM manipulation. This presentation by Simon Wilson is also good.
Once you have a good feel for the language, move on to the next step i.e. manipulating the DOM. I would personally suggest that you try to do some DOM manipulation using bare bone JavaScript to get better understanding of the DOM and the pain points involved. [E.g., when I attach a method to onClick of event, 'this' doesn't refer to what I think it refers to?]
After you have suffered a little bit of pain by doing DOM manipulation by hand, move on to a JavaScript framework which removes all the pain and makes JavaScript fun again. Personally, I would highly recommend jQuery over other frameworks.
And if you have any questions while on your JavaScript journey, you can always ask them on SO! :) Good luck.

I wouldn't touch any framework in any language until I have good basic understanding of underlying technology. Worth type of coder is one that uses tool without a knowledge.
JavaScript has somewhat sad history but in its latest incarnation it's surprisingly powerful and even fascinating language. I say - learn it well, then use whatever framework suits your current needs

It depends on where you want to invest your time. Ideally, we're all expert in assembly language, but that's not realistic or practical. We have to pick our battles. Then generally we attack each other for picking the wrong battle, which we call "cargo cult coding."
Personally, out of all the things I could spend a lot of time banging my head against, the intricacies of cross-platform JavaScript seemed less interesting and rewarding than other choices, so I decided to jump straight to jQuery. I'm happy with how it worked out.

I had the same background as you. After 6 months of MooTools I found out that mootools was indirectly teaching me "vanilla" javascript.
I've heard people say that mootools feels more like plain ol' javascript than jquery (after all, jquery's tagline is "jQuery is designed to change the way that you write JavaScript.").
I'd recommend starting with a framework. Plenty of the best javascript developers use frameworks. Once you're comfortable there you'll likely be able to pick up the others frameworks and plain ol' javascript quite readily.

Which JavaScript OOP design pattern will most take advantage of (new) ECMAScript 5 features?

ECMAScript 5 is in final draft now, and includes new features relating to objects and prototypes. While hunting around SO and Google for OOP design patterns, I found that there were quite a few different ways of "doing OOP" (however you might define OOP, from trying to emulate classical OOP to simply trying to cut down namespace pollution) in JavaScript.
Which design pattern is the most forward-looking vis-à-vis the direction ECMAScript 5 is taking the JavaScript world? What are its key advantages? Which of those weren't possible or as nice to implement before?

I don't think ECMAScript 5 changes the landscape for OOP in JavaScript. Classical OOP will still be a bolt-on for people who want to use it.
The real story, in my opinion, is that when ECMAScript 4 was scrapped, JavaScript and ActionScript diverged, and JavaScript will NOT be adding classes the way ActionScript did.
I suspect that the libraries that support OOP (MooTools, Prototype, etc.) will mostly stick to what they are doing, but maybe they can use some new ECMAScript 5 features in their implementations to solidify things.
And we'll probably keep seeing interesting approaches like Joose and Class.js.
Remember this is going to take awhile. We still have a double-digit chunk of people using IE6. So the first useful places to use ECMAScript 5 will probably be on mobile phones, Adobe AIR, and JavaScript servers, where the browser is (mostly or strictly) known.
John Resig posted an article on ECMAScript 5's object changes here.

I think the standardization of Object.create will allow more people to use the underlying prototype-based OO without shame. Trying to hide the "new Foo" pseudo-classical syntax behind a wrapper makes the code confusing.

Server side Javascript best practices?

We have a CMS built on Java and it has Mozilla Rhino for the server side JS. At the moment the JS code base is small but growing. Before it is too late and code has become a horrible mess I want to introduce some best practices and coding style.
Obviously the name space control is pretty important. But how about other best practices - especially for Java programmers?

Here's some tips from the front lines:
Like Java, use docblocks in Doxygen/JsDoc style for functions
Unit test. Personally like JsTestDriver, as it can be executed automatically from CI server too.
Use JSLint. It will nitpick about bad code
Consider using Google Closure Compiler. It will nitpick about code like JSLint, but it can be helpful for spotting poor doc blocks etc.
Make sure everyone on your team understands how closures work. Otherwise it'll lead to headaches
As you mention, namespaces are important especially if you want your code to work nice with other JS libraries (var myns = myns || {};)
Personally I find using a library which provides OOP helpers like classes etc. helpful. You could use prototypal inheritance but it's often a bit trickier that way.

As Douglas Crockford likes to say, JavaScript is the worlds most misunderstood programming language. Though many people don't know it, there is a right way to code in JavaScript. I have no doubt that if you let Java developers start coding before understanding how to write good JavaScript you will run into serious trouble.
The first thing to do would be to make sure everyone has read Mozilla's excellent article, A re-introduction to JavaScript (https://developer.mozilla.org/en-US/docs/Web/JavaScript/A_re-introduction_to_JavaScript). One of the biggest problems with JavaScript is that there are many ways to do most common tasks, and this article should get people on the same page. Another essential reference is Douglas Crockford's work, including JavaScript: The Good Parts.
One other thing that gets a lot of Java/C++ programmers is that JavaScript uses function scope NOT block scope. This can cause some very tricky problems. There's a great article about this issue at A List Apart called Binding in JavaScript.
To summarize the major issues talked about in the above resources, the most crucial differences to learn are
how to write object oriented code using prototypal inheritance (vs.class based inheritance)
how to use closures and lambdas
how to utilize the power of dynamic objects
how to write function-scoped code

Since you have a JS engine in Java, make it a habit to write unit tests for your JS code. Select a coding style and apply it vigorously. If possible, use tools to check that the code submits to the coding style.

Javascript as a functional language

I am looking get to grips with functional programming concepts.
I've used Javascript for many years for client side scripting in web applications and apart from using prototypes it was all simple DOM manipulation, input validation etc.
Of late, I have often read that Javascript is one of the languages that supports functional programming.
With my familiarity and experience with Javascript, my preference is to use it to learn functional programming. I expect I would be able to concentrate more on the main functional concepts and not get bogged down or distracted by a completely new syntax.
So in summary, is Javascript a good choice to learn functional programming concepts? What capabilities in Javascript are relevant/support functional programming?

JavaScript supports first class functions. See Use functional programming techniques to write elegant JavaScript.

Higher Order Javascript is a great way to get familiar with the functional aspects of javascript. It's also a relatively short read in case you want to get your feet wet without diving into a larger book.

I would say that although you can quickly grasp some functional programming concepts with JavaScript, using JavaScript consistently like a functional programming language is not a common practice. At least not obviously common. Most people don't post tutorials that pinpoint how to do functional programming with JavaScript -- the one marxidad pointed out is actually a pretty decent example, but you won't find a lot of that. The functional aspects are not often apparent, just like when people use closures in JavaScript, but are unaware that they are doing it.
The idea that you would pass two functions through as arguments to a third function, and then have the return value be some execution related to the first two functions is an advanced technique that almost always appears only in the core of full-blown libraries like jQuery. Self executing anonymous functions and the like have gained ground, but are still not used consistently. The majority of tutorials often focus instead on JavaScript's OO capabilities, like how to create properties and methods, scope, access control and also how to use the prototype property of constructors. Honestly, if functional programming is what you want, then I would choose a language known strictly for this capability.

I don't remember who said it, but javascript has been called "Scheme with Algol syntax". So for learning Scheme/Lisp, Javascript isn't a bad start. Note though that functional languages like Lisp are quite different from pure functional languages, such as Haskell.
Apart from "first-class functions" (Meaning that functions are values, that can be assigned to variables), lexical scope is also an inherent part of what makes a functional language.
Higher Order Javascript and The Little Javascripter has been mentioned already. They are both excellent texts. In addition, Higher Order Programming in Javascript may be an easier start.

Although javascript supports FP to some degree, it does not directly encourage it. That's why projects like Oliver Steele's Functional exist, to fill in the gaps. So I wouldn't recommend it for learning FP. Check out F# instead.

I would recommend reading The Little Schemer, which is a fairly slim book about recursion and is a good introduction to the functional style. Whilst it's focused on Scheme it can easily be applied to JavaScript, see http://javascript.crockford.com/little.html. I found it really helpful in my javascript development, although it gets quite tricky towards the end.

Javascript is a multi-paradigm language. If your goal is to learn functional language concepts, try starting with a pure functional language like OCaml or Haskell.

Also, Eloquent JavaScript: Functional Programming chapter.