People who think JavaScript is not a programming language are people who's opinion on JavaScript you should not respect.
JavaScript is a language that has grown organically inspired by semantics of Scheme and syntax of Java. It's original purpose was not general but it has now grown to be so.
JavaScript as a language is suitable to do just about any task if it's fit for it. Take a look at examples like node.js where JavaScript has access to host environment consisting of IO functionality which allows it to be used for generic server side programming
My friend also advocates against using Javascript's OOP functionality, claiming that "you shouldn't be processing data, merely validating." Is Javascript really limited to validating data and making flashy graphics on a web page?
No, JavaScript is a programming language, if you want to represent data structures, algorithms and logic then use the tools the language offers. Specifically 1st class functions and prototypes are powerful tools.
He goes on to claim "you shouldn't be attempting to access databases through javascript" and also says " in general you don't want to be doing your heavy lifting in javascript". I can't say I agree with his opinion, but I'd like to get some more input on this.
Wrong, In the browser we have a database called indexedDB which we access with JavaScript. It's a database baked right into the browser and if you want to use it (and you should) then you use JavaScript.
Also note that both mongodb and couchdb allow you to use javascript to run adhoc queries on the database directly.
As for heavy lifting, he's partly correct. If your doing heavy lifting you should be doing it in C or erlang. Although note that the term "heavy lifting" is vague, for example I wouldn't encode or decode videos in JavaScript, I wouldn't do image processing in JavaScript (use C). I wouldn't no number crunching in JavaScript (use fortran).
Has Javascript evolved from the definition above to something more powerful, has the way we use it changed, or am I just plain wrong
JavaScript was written in a period of 2 weeks just to slap minor scripting functionality into HTML. Since then it has grown severely. Since ES3 (1999) it has been a powerful general purpose programming language.
I'm also somewhat skeptical that every new web app needs to be an SPA but one thing I'm 100% sold on as a generalist with the bulk of his experience on the client side is that a service-oriented architecture that hands off raw data rather than HTML to the client is the way to go whether you're loading prebuilt pages/views from the server and doing a lot of dynamic stuff with data after page load or building almost everything 100% with JavaScript.
The reasons this is preferable to a client-side dev are much the same as the reasons nobody wants HTML in the database. What's the client-side dev supposed to do when they want to resort a table for instance when they've been handed HTML? The performance cost of handling all that on the client is trivial compared to making another server request to do that for you. Also, HTML-building is pretty well-covered in JS-land. Sorting data and building new HTML table rows out of it is pretty trivial work for an experienced client-side dev.
And of what use is the back end architecture to a front end for another device that might need to do something exotic like implement widgets that are 100% canvas or a totally different HTML structure? Why should a client-side dev have to load up visual studio or knock on the back end devs door to make a strictly presentational tweak?
As for your concerns about the loss of strongly typed template validation, trust me when I say that if you're dealing with a competent client-side dev, you will find no .NET framework or visual studio tool that is more coal-to-diamond-to-dust-crushingly anal about well-formed, valid HTML than s/he is.
From the full-stack perspective, I like it because it means I'll never have to fish for business or app logic some yutz decided to drop into the templating layer. Not to mention the per-user load it takes off of your servers while in many cases actually improving load experience for the user in modern browsers with modern computers.
I think it's also easier to reason about the back end architecture when you've fully isolated it from all the presentation stuff. You're no longer grabbing data to mash it into some HTML. You're pulling it together to create an implementation-independent data structure that concerns itself more with general use than what's going to be done with it on the other side. IMO, that tends to lead to more consistency in how things are handled since the data is now an end goal rather than the second to last step of a process and there's fewer opportunities for unrelated concerns to get their wires crossed.
Best Answer
I'm not sure if it's bad or wrong, but it is confusing.
Your PageControl is not a class, it's an instance of an anonymous class. In javascript a class is a function object intended to be used with the new keyword to create instances of that class.
Your code uses the new keyword on an anonymous function.
What you're trying to accomplish, I think, is usually done using the IIFE (Immediately-invoked function expression) pattern.
The key to the IIFE pattern is that you define a function expression that returns an object and then immediately call (execute) that function
(function() {})();
.