For a very long time, javascript has remained the same. Browser venders have given us new things to access from using javascript. But the language it’s self has remained pretty much the same since it’s conception in 1995. As of this month however, things have changed. Firefox 4 will soon be released and with it the first browser supporting a strict mode for javascript.
OOP in Javascript, the right way
In the past months I’ve covered a lot of topics involving the basics of javascript, several design patterns, and the power of RequireJS as a tool for better JS applications. Now it’s time to put the pieces together and let’s see what we can do with it all.
Posted in Javascript
Tagged CommonJS, design patterns, frameworks, Javascript, RequireJS
Leave a comment
HTML Form styling with Formall – part 2
As an accessibility researcher, this subject is pretty close to my heart. When I designed Formall, the first priority was given to make sure that the HTML which would create good looking forms would also create accessible and user friendly forms. Things like where to put errors and how to indicate required fields don’t go wrong that often, but they can be done much better then you see in practice.
HTML Form styling with Formall – part 1
One of the most painful jobs of front end development, I always found to be styling forms across different browsers. The CSS rules on how forms should be styled leave much to the imagination of browser vendors. So I’ve attempted to put together a style sheet that can take some of the work out of our hands. It is literally saving me hours of work every form I have to create.
Javascript modules
The module pattern has taken the javascript world by storm. Almost every library out there uses it these days. It has become the corner stone of server side javascript. There has even been talk of including it in a future version of the ECMAscript specifications. So what’s all the fuss about?
Variable visibility in javascript
Every function has it’s own scope. A place where we can declare variables that are only available within the function it’s self. We’ve already seen how this can create private variables in a constructor. But there is much more to be said about variable visibility.
Constructors vs factories
Often in Javascript, you only want one instance of an object. In classical OOP this is done with a singleton design pattern. In javascript we simply use the object literal (i.e. { property: ‘value’}). But when we need a multitude of similar objects, javascript gives us two ways to do it. With a factory function, or a constructor. But which one should you use?
Inheritance using the Caller extension pattern
The caller extension pattern is a design pattern I’ve discovered, which let’s you create constructors that can inherit from any other constructor. To do this we get to use some javascript magic: the call and apply methods. So let’s see some code!
A critical look at javascript’s prototype
Javascript’s prototype is often compared to the inheritance model used by classical OOP languages. In these languages a sub class inherits properties and methods from a super class. In the sub class you can then add and override methods and properties of the super class. Allowing you to create objects with either the generic features of the super class, or the specialized features of the sub class. There is a big difference when using prototype to inherit from an object rather then class.
The basics of javascript prototype
In the next couple of articles I’ll introduce a number of design patterns that I feel have the potential to be the staple food of any javascript application. But to really understand these, we need to first understand some of the basics. First up, javascript’s answer to inheritance, prototype. Unlike classical OOP languages, Javascript doesn’t use classes to create objects from. Instead it lets you manipulate objects directly. Instead of inheriting from a class the way you would in classical OOP, in javascript your objects can inherit from other objects using prototype