Is there any super set or language similar to javascript that provides a more classical c++/java/c#-like OO System. But can be used with HTML-5 and DOM and has a cross-platform implementation?
You could give CoffeeScript a try.
It compiles to JavaScript so it's indeed cross-platform.
As far as scripting is concerned, it is also compatible with using HTML5 tags but it's not really an issue: HTML is the markup language, JavaScript (or CoffeeScript) is the scripting language. So you can still select or edit (HTML5) elements using CoffeeScript; the script will be compiled to JavaScript and it'll still work.
Yes, it's called JavaScript. There are some good articles about OOP around
var Parent = {
method: function () {
...
}
}
var Child = Object.create(Parent, {
childMethod: { value: function () {
...
} }
})
Any attempt to emulate a class system in JavaScript is a waste of time and ends up writing bloated / unreadable / unmaintainable code.
If the above is too ugly, consider using an extend function
In addition to the suggestion to learn CoffeeScript above, you could try out a couple of javascript patterns.
I was recently watching a pluralsight screencast (structuring javascript code) and I was made aware of a couple of javascript patterns but i really like the "Revealing Prototype Pattern".
Very concise and simple, you get some of the benefits of OOP including encapsulation et al.
Pluralsight offers a free 10 days trial period so i guess you can easily get up to speed with it.
There are a few options. The ones that spring to my mind are:
Simple JavaScript Inheritance
YUI extend
Related
For a while now I have been developing javascript applications, usually smaller scripts to accomplish simple tasks but also a fairly large and complex application using Dean Edwards' base2 library for creating pseudo classic OO classes with inheritance,... in javascript.
The base2 library served me pretty well, mainly because it enabled me to follow the classic OO paradigm, which I am quite familiar with. I also know of several other frameworks that can be used to build more robust and mature javascript applications (backbone.js for example). But I always have the feeling that this type of library is a way of 'cheating', to construct a way to write code using principles the language actually isn't suited for.
I have been reading up on different ways to define objects/functions, instantiate them and achieving polymorphism using prototypal inheritance. This is really how the language works at a fundamental level and I feel like I should take advantage of that rather than deciding it is annoying or strange and trying to find a way to do things the way I'm used to (the classical OO way).
So, looking at applications that are not using this type of library, there seem to be so many ways to write your application while for traditional general purpose languages like Java, C++, ... the right way of building your applications seems more clearly defined (it's a lot easier to distinguish good from bad code). If somebody would ask me tomorrow: "start developing projectX for me", I would have no idea how to start defining and structuring my objects in a way I can be sure won't come back to bite me later when it's too late to restructure the whole thing.
What would a professional complex js app skeleton look like, using prototypal inheritance, so without using any type of library for mimicking classic OO, assuming a simple MVC type of app but easily scalable to more complex proportions. How to define my objects? How to keep objects/'classes' grouped together (namespacing)? In other words: how to do it without ending up with a mess nobody understands anymore?
There are two patterns I follow in creating object oriented Javascript 'classes' (thought there are no real classes in JS, we can mimic them). First is more familier OO way and simple to understand.
// in JS, functions can be used as OO classes
var Person = function(name) {
var self = this;
//private methods and attributes
this.getNickname = function(){
return "Yaka";
};
//public methods and attributes (return obj)
return {
getName : function() {
return name + ' ' + self.getNickname();
}
}
};
//static functions attached to 'Person' class
Person.hasBrain = function() {
return true;
}
This model lets you to have private, public and static sections for your classes allowing good encapsulation. But this not the optimal way as every object will carry it's own copy of all instance methods. You can avoid having multiple copies of the instance methods with prototype based programming:
// in JS, functions can be used as OO classes
var Person = function(name) {
this.name = null;
};
// use of prototypes improves performance and memory use
Person.prototype.getName = function() {
return this.name;
}
Person.prototype.setName = function(name) {
this.name = name;
}
This doesn't look very familier for traditional OO programmers, but the optimum way for using javascript resources. It goes well with inheritance too.
var Manager = function() {}
Manager.prototype = new Person();
In practice I use the prototypical approach for base/framework classes that are being used heavily in the application. For classes being used occasionally or for few instances, I use the approach discussed before.
I also recommend you to use an AMD library such as requirejs, and define a single class per physical file. Then use an build optimizer to optimize your files in to a single script.
I copied above 2 approaches from the unit tests in BoilerplateJS reference architecture. Have a look at the code in BoilerplateJS, it will give you more ideas on how to approach complex application development with JS.
Disclaimer: I'm the main author of BoilerplateJS
I have a background in OOP. I started to work a lot with JavaScript. As the project grows it's becoming more difficult to maintain it. In Java I apply OOP principles to keep things under control. What should I do with JavaScript, what should I study that is aimed at keeping a JavaScript application under control?
You can apply OOP principles to Javascript development too. Javascript uses prototypal inheritance, but that is an implementation detail. The concepts are still the same. Most of the concepts with which you are familiar have direct analogues in javascript.
Other tried and true methods apply as well:
1) Stay DRY -- Do not Repeat Yourself. Duplicate code is always evil.
2) Separate concerns -- Use the MVC or MVVM patterns to keep code clean and doing only 1 thing.
3) Test -- When I hear "Difficult to maintain" my brain translates that into lack of tests. You can certainly write unit tests for javascript projects.
4) Code Review -- Code reviews can be a good way of rejecting duplicated code, code that is not crafted properly, not formatted, etc....
This is how you define objects and methods in javascript.
function SomeObj() {
this.someMethod = function() {
alert('boo');
}
}
var o_obj = new SomeObj();
o_obj.someMethod(); //alerts "boo"
Hope it helps.
You can also use prototype to create static functions.
this.prototype.someMethod = function() {
alert('boo');
}
When I was in the same situation I started to look at "how other did". Its ended up with http://dojotoolkit.org/ and http://jquery.com and I was looking how they implement widgets/plugins so other could extend the framework.
Another way of defining simple objects and methods in javascript (without the need for new).
function creaeSomeObj() {
var that = {};
that.someMethod = function() {
alert('boo');
}
return that;
}
var o_obj = createSomeObj();
o_obj.someMethod(); //alerts "boo"
This pattern doesn't support inheritance, but many times it is sufficient.
Why "vs"? JavaScript supports object-oriented programming, but not in the traditional class-based way that you see in e.g. Java.
The way JavaScript's OOP works is usually known as "prototypal inheritance", or more specifically "delegative prototypal inheritance". This can be boiled down to "if you're looking for the property 'foo' in an object, and you can't find it there, then try looking for 'foo' inside the object's prototype instead". That is, the lookup of the property is delegated to the object's prototype (we say that the object inherits the properties from the prototype).
The way prototypal inheritance works has a couple of implications. For instance:
Objects in JavaScript are "dynamic" in the sense that they're just a bunch of name-value pairs. New properties can be added and removed during runtime, so they're much less "static" than objects in the typical class sense.
The way delegative prototypal inheritance works ("if you can't find the prototype here, then look here instead") means it's much simpler than classical OOP. From a purely prototypal point of view, you don't need constructors, for example. "Methods" are just regular functions that happen to be attached to the prototype (which means they are available as properties on all inheriting objects).
There are pro's and con's with both prototypal and classical inheritance, but it's important to remember that they're different.
Now, JavaScript is in some senses inspired by Java and other classical languages, so therefore they decided to make the syntax "class-like" to make it easier for people used to classes to get started. I won't elaborate a lot on this; it's documented to a great extent in other places already.
Some interesting posts:
hughfdjackson's introduction to JavaScript OOP -- short and more to-the-point,
Sorella's longer "Understanding Javascript OOP" -- rather in-depth and very complete resource.
Pluralsight has a course on just this topic: Structuring JavaScript Code that may provide some insight. Two caveats: 1. I haven't sat through the course yet - but content looks great and I've been impressed with other Pluralsight courses I've taken, and 2. it is not free (but may be worth the small $ if it saves you time down the road b/c you have better code structure). No, I don't work for Pluralsight.
In addition to the js frameworks mentioned in this thread, can also look at Knockoutjs - great tutorials here learnknockoutjs.com. Knockout is MVVM focused. Note, there is a good discussion in stackoverflow comparing Backbone to Knockout, and Pluralsight also has a course on using Knockout which I have watched and do recommend.
In JavaScript, Functions are Objects; Mozilla Developer Network, McKoss, SitePoint, and JavaScript Kit explain further.
Example JavaScript Object
function myObj() {
this.myMethod = function() {
alert('hello');
}
}
var demo_obj = new myObj();
demo_obj.myMethod();
Patterns to keep things under control
The patterns listed here are particular to JavaScript.
Use a Script Loader.
Use a JS Framework.
Lint your JavaScript. - Tools are availble to run this on your desktop in Rhino or node.
Minify your JS.
The patterns listed here are typical of OOP Languages, and are not
particular to JavaScript.
DRY - Don't Repeat Yourself.
Observer (Pub/Sub) pattern.
Anti-Patterns to let things out of control
Polluting the namespace
use of eval()
Prototyping against the Object object
Inline Script Tags.
use of document.write
I am not trying to ask another JQuery vs. Prototype vs... topic as I have already read 5+ of those on these forums and have been able to gain a lot of knowledge from them. My question is more directly related to wanting the ability to use inheritance for basic classes and not actually sure what would be a good choice.
To be brief, I have the requirement to be able to control theoretical objects in javascript and manipulate them based on user input then display them.
I have used JQuery and enjoy how easy it is to modify the DOM (which appears to be it's main goal). However from all the readings I have done, it seems that JQuery has no intention of assisting you in dealing with classes, inheritance etc. If I have already chosen JQuery to display and manipulate the data what would be a good choice to assist me with the inheritance issue.
My first thought was Mootools or Prototype, however prototype DOM Extension seems to be a very bad approach and would rather wait for Prototype 2.0 unless this isn't an issue on commonly supported browsers now.
I had also read about Base2, Joose, and JS.Class, but don't know if they will do what I am hoping for either.
Any suggestions based on the above information would be great, again, I am not trying to figure out the pro's and con's of the commonly used JS frameworks.
Why emulate classical inheritance?
What's wrong with functions and .prototype?
var SomeObject = function(data) {
this.data = data;
}
SomeObject.prototype.doStuff = function() {
return this.data;
}
Do it the old fashioned way.
If you want to use anything besides jQuery I would recommend underscore for it's syntactic sugar.
If you must emulate classical OO, I would recommend oorja as it's the lesser of evils.
I have a general question about the design of JavaScript Libraries.
I am trying to consolidate common methods into one js file so they can be reused by different scripts.
I have taken a look at how the JSON library is structured and believe it was a good approach.
JSON for Javascript.
So they start off creating an instance of the class:
if (!this.JSON) {
this.JSON = {};
}
Then they do this:
(function () {
if (typeof JSON.stringify !== 'function') {
JSON.stringify = function (value, replacer, space) {
This is works perfect if you just want to do JSON.[function_name], but what if I want to have a more structured library such that I want: JSON.[subgroup].[function]. How would I structure my JS library in such a way?
Any links to resources are greatly appreciated, thanks.
I would recommend you to follow the Module Pattern in JavaScript instead of following JSON's pattern strictly. Your subgroup is actually referring to sub-modules. Take a look at the following excellent article:
Ben Cherry's JavaScript Module Pattern In-Depth
Other resources you should probably go through:
John Resig's Learning Advanced JavaScript
Seven JavaScript Things I Wish I Knew Much Earlier In My Career
The Seven Deadly Sins Of JavaScript Implementation
There are problems with the module pattern. See http://snook.ca/archives/javascript/no-love-for-module-pattern. I used to use it before but stopped. Now I just tend to keep it simple. If you really want sub-namespacing you can make a simple namespace function for the job.
See
http://blogger.ziesemer.com/2008/05/javascript-namespace-function.html
I'm working on a site and using JQuery for essentially the first time. I've mostly used MooTools for previous projects, and I have a few widget classes I've written using the MooTools Class structure. I'd like to port them over to JQuery, but it looks to me like there is nothing similar to the MooTools functionality when it comes to object classes.
I've searched around a bit, and haven't found much on it. Digg appears to have rolled their own, but I'm not sure if this is something I should be using. Is there a better way? How object-oriented do people normally get with JQuery? What's the usual method of encapsulating a UI widget (or any functional class structure)?
I'll post a fake example of a possible MooTools widget class:
var ZombatWidget = new Class({
Extends: BaseWidget,
widgetPropertyX = 'prop1',
widgetPropertyY = 'prop2',
attach = function(el) {
var f = function() {
//do something widgety
};
el.addEvent('dblclick',f);
el.addClass('widgetized');
}
});
var z = new ZombatWidget();
z.attach($('widgetDiv'));
What I've got is a lot bigger than that, but you get the idea. Do I need to convert this to the prototype method of class/inheritance structuring? How would you write this kind of object class using JQuery?
You might find this approach useful to the task at stake: building an object-oriented jquery plugin.
And this article on Ajaxian "a real OO class system with jquery".
Hm... interesting. We have jQuery which imho is a great tool to interact with the DOM. It's a selection tool where you can write your own code (plugins) to modify selected items. You can interact here with your own (object oriented) code in a plugin to do something really cool.
So why would you need extra OO capabilities in jQuery unless you want to be able to inherit from other jQuery plugins?
Because you might have a plugin that allows you to do the following:
$(".spiffyness").yourSpiffyficationPlugin1();
And, while doing some really cool awesomeness already, you need more spiffyness on top of this.
Therefore you want to inherit from your first plugin which results in:
$(".spiffyness").yourSpiffyficationPlugin2(); //plugin inherited from 1
But... wouldn't you get there too by doing this:
$(".spiffyness").yourSpiffyficationPlugin1().yourSpiffyficationPlugin2();
Where the second plugin just does this tiny (but awesome ;)) thing extra on top of the first one?
In other words: is what you want, worth the effort for the sake of OO purism? Or is the jQuery pipe mechanism good enough and maybe everything you need?
I would say that separation of responsibilities and/or your mootools mindset might be the real issue here. Let jQuery do what it is good at, use it's powerfull pipe mechanism, pipe your own plugins (which may contain tons of fancy OO stuff)... and you can have great results while your code is still clean.
If you do think I am thinking too simple here, a good example of the essence of your point would be welcome! :-)
And to be ahead of that, if you are doing something really advanced and you do not get away with simply doing something on top of something else, you're plugin could also delegate to one of your OO classes. E.g. like:
$.fn.totalAwesomeness = function(options) {
var defaults = {
mode: 1,
title: 'Awesome'
};
var opts = $.extend(defaults, options);
return this.each(function() {
var $this = $(this);
var handler = null;
if(defaults.mode == 1)
handler = new com.myStuff.class1($this);
else if(defaults.mode == 2)
handler = new com.myStuff.class2($this); //class2 inherits from class1
handler.doMagic();
});
};
You can always also use moo4q - http://moo4q.com/ . It adds MooTools class support to jQuery.
I wrote an article some time ago about jQuery object oriented plugins, hope it will be helpful
http://ajax911.com/jquery-object-oriented-plugins/
There are third party javascript class implementations that provide very powerful introspection capabilites. I would like to particularly highlight JS.Class and Joose.
While JS.Class is modeled after Ruby, Joose is modeled after Moose.
I am not a mootools user so I can not comment on their advantages/disadvantages with respect to mootools. But I would summarize their key features.
JS.Class has a strong focus on simulating the Object oriented features of Ruby and does a pretty good job at that. It provides a powerful library modeled after the standard library of Ruby and also comes with a well integrated package management and testing framework.
Joose, while provides no testing framework/package management facilites, excels in terms of
advanced attribute management facilities, filters and better introspection facilities.
Both of them have really good documentation and can be used in browser as well as server.
I've just finished a very first release of my mini project: https://github.com/op1ekun/plOOgins. It's all about writing OOP code to be used as Jquery plugins. It's not rocket science just a little something that we wanted to use at my workplace. Maybe it will help You a bit. Good luck!
Plugins sometimes do the trick.
Of course, you could use just enough of mootools to get it's class/inheritance model. With the implementation of document.id "compatibility mode" in 1.2.3 you can have your cake and eat it too (I think--haven't done it myself.)
The question is... Why are you moving away from MooTools is it fits your needs? Seems to me like MooTools was working fine, and there is nothing jQuery does that MooTools can't do. (The opposite isn't true).
Unfortunately, jQuery is not built to support classical OOP as MooTools is so you will need to write your Classes as jQuery plugins.