Raynos

"private" state in JavaScript means using local state in a constructor function and returning methods which are in scope of that local data. This pattern is not compatible with prototypes.

An example:

People still seem to use string concatenation for building DOM nodes. We see code like

A recent article on Extending Natives prompts me to clarify the arguments for and against extending natives.

Let's look at three specific situations in which you may or may not extend natives or host objects

Should be really simple right? Surely if I google for it, I will find instructions!

No. Not at all. You get a lot of noise about how to do this using magic blog platform X or how to add a shiny img button to wordpress.

node.js does

I quite often see questions raised at node.js or express.js asking how you should structure your application. They ask do we need a large MVC framework? Do we need a library or tool to handle code structure for me?

I often say no. I just tell them to write modular JavaScript and it just works. This is actually a very difficult thing to do.

Sorella's article on Sugary JavaScript OO prompted me to talk about the sugar pd provides to make prototypical OO easier!

EcmaScript 5 has given us Object.create as the first step towards doing prototypical OO that feels natural. However it's not enough.

I left a comment on axel's post about JANOS, that made some nice points that are worth expanding on

People seem to have accepted that inline JavaScript in HTML is bad and that inline CSS in HTML is bad. It breaks separations of concerns.

However people seem to be forgetting it works both ways. Separations of concerns also means no inline HTML in your JavaScript. I.e. no HTML string literals in your JavaScript.

In reply to Wilcox's research paper there seems to be a major confusion about what it means to be non blocking and why node is non blocking.

Now let's start with why node is in a single process and why its non-blocking.

DOM-shim v0.1 is out. This alpha version includes the basic shims.

This version should only be used by people who really want a normalized DOM as there are still plenty of unhandled edge-cases that I just don't know about.

DOM4 has a CustomEvent interface that's rather easy to use. You can just create custom event objects and dispatch them on any EventTarget.

Now, browser support for DOM4 is flaky but thankfully the DOM-shim fixes that! Of course the DOM-shim gives you the real DOM API to work with rather then some library or abstraction.

These days dom libraries do two tasks. They normalize the dom across browsers and they provide a dom abstraction.

Now why does every library re invent dom normalization? It simply doesnt exist.

So I keep picking up this attitude of "Woh what are you doing, does it work on IE6?" and I'm shocked how the web community has this attitude of "support all platforms over a range of 10 years".

You go tell that to the desktop or games communities and they will laugh, find me a modern game today that will install on a 10 year old machine (which has had no updates). No walk into any one of those communities and start demanding it works on a 10 year old system, no-one will take you seriously and for good reasons. It's simply ridiculous.

Kangax has a great article about Extending the DOM and how it's wrong

However I would like to introduce the DOM-shim and tell you why extending the DOM is not always evil.

part 2

Today we will cover Object instantiation and Object initilization. This is an important topic with respect to working with protototypes.

In the node.js community we have toolkits and frameworks.

Toolkits give you set a tools to build an application and frameworks implement architecture decisions for you and give you a high level API to build an application.

Part 1

Today we'll talk about "prototypes as classes" and how those ideas have been incorporated into pd 0.2

For some reason people don't understand prototypical OO and start emulating classes in JavaScript.

So we'll walk through doing OO JavaScript in ES5 using pd.

vows-fluent is a small sugar library I've written building on top of vows. It gives you a more intuitive chaining API compared to vows regular declarative API.

This tutorial will cover what vows is, how to use vows-fluent and how to write tests with them. We'll write the unit tests for after as an example project.

I've had to answer flow control issues repeatedly. Both in my own code-base and as answers to StackOverflow questions. All these problems can be handled with one of two methods. One issue is dealing with nested asynchronous tasks and the answer to this is to use middleware. The other issue is aggregating many asynchronous tasks into one end point and the answer is this is to use function execution delay.

I've build a tiny utility function called after to handle aggregating of asynchronous tasks. I'll walk you through how to use it in this post. I will get around to building a generic middleware component that can be used to chain asynchronous tasks together effectively, it will be inspired by connect.

I've been building my own blog from scratch with node.js and express. Progress has come along nicely and it's stable enough to persist content on.

To celebrate the opening of my blog, I'll write a series of tutorials on how to write to make your own blog using node. This tutorial series will be aimed at people who have some exposure to node and already know JavaScript.