david kaye dfkaye

Globals are bad

Globals are discouraged as bad practice.

Globals are what we have

Without globals, there is no way to expose your module to other modules, i.e., scripts have to be declared in a specific order so that dependant scripts can use them, and the variables that point to them have to be global.

We see examples of dot.delimited.namespaces all the time - those work in the browser and perform lookups reasonably well. But they are really just big structures whose parts can be clobbered (or mocked - yay).

Constructor Inheritance in JavaScript

First, I like inheritance, but not for everything.

A bad use of inheritance is the canonical rectangle and square example in Java that Rusty Harold examines. However, it is not inheritance per se but the inherited getters and setters that are the real evil. Allen Holub said as much - or pretty close to it.

Another abuse is the construction of subclass hierarchies beyond, say, 3 layers deep. Ideally one would use a base class or interface and subclass that into one-off implementations. An EventTarget, EventSource, EventEmitter or what-have-you serves as a common base for view and model objects in the two-way data-binding version of MVC or MVVM, for example.

Objections based solely on mystical incantations

What is the maximum number of arguments that a constructor should have?

The answer is 3. When the number of args exceeds 3 in a constructor, it's probably time to switch to a configuration object as a single argument. There are two-and-a-half benefits (note specificity):

give your constructor a chance to set defaults if they're missing, verify that specific types are defined or that specific instances of types are defined
OR allows you to assign a single property in the constructor to the config object and defer the integrity checks to other methods, if you wish, so you can add those later to the prototype rather than repeatedly modify the constructor (which can get quite big).
makes mock arguments much easier to maintain in tests where you'll be driving your constructor's integrity checks first, before adding capabilities to the prototype or inheriting from another one.

Some things about using Testling, Tape & Github

I encountered recent difficulties with the testling hook on github, using the tape module for test files.

First off, testling would choke on reading my package.json files, complaining about bad character references (there's a pun that we'll ignore). I found my editor's default encoding with UTF-8 but should have been UTF-8 without BOM - so that's one thing to double-check.

Once I fixed that, tape tests failed every case because the require() call was returning null instead of the subject module's exports. Turns out, my subject file was using an IIFE like this - an artifact of in-browser-console-development:

;(function (exports) {

3rd-party code still needs tests

I'm not the first to say it but it needs re-stating. 3rd-party libraries are no guarantee that your code continues to behave as expected.

If one of the duties of your work is making sure you're not introducing bloat or cruft or inefficiencies or bugs or unexpected behavior, then you're cutting corners if you don't have tests, whether you use 3rd-party code or not.

"Maintaining tests" may seem like an expense to those who don't, can't or won't, but it is naive to claim that writing tests means "it takes longer to develop" or "you'll have to maintain tests along with source."

It might take longer to develop from scratch but it will take less effort to modify or refactor later - when you'll need to maintain pace. Your requirements will change, your code will have to change - why not plan for that up front?

2013-3-30

Some recent activity from active contributors regarding ES6 proposals threaten to undermine its acceptance from the community at large.

ES6 proposals include the fat arrow, destructured assignment, splat args, let/block scope, class syntax, class-based inheritance, setters/getters with export, the module loader syntax, weak maps, weak events, @symbols, and so forth.

That is a lot for a community user of the language to comprehend. It is a lot for a single iteration of any project.

The sheer amount of change is at root of the confusion apparent even among the es-discuss mailing list ~ [see this conversation for an example] (https://twitter.com/kangax/status/315863525899780096 ""that was removed from the spec", "I thought it was back in", "it's on the table", "'on the table' does not mean 'in the spec'"").

"JavaScript doesn't need more features; it just needs a couple of small things fixed" - Ryan Dahl

The CommonJS and AMD module syntaxes are unfriendly to each other, requiring boilerplate everywhere, which UMD tries to solve with more boilerplate.

The ES6 module syntax adds new keywords in strict mode, that then depend on a sharply modified cross-origin requests shims, and internal module management. An ES6 Module Transpiler aims to solve the not-yet-supporting environments problem with a source transformation step.

We don't need more syntax like imports x from 'x.js'. We don't need a module keyword that will break QUnit module() or Node.js modules.

	/**
	* file: Constructor.js - provides construction prototype and parent inheritance to JavaScript
	* author: @dfkaye - david.kaye
	* date: 2012-10-30
	*
	* To-DO
	* - commonjs module support for global scope and exports
	* - better 'actual' support for extending natives (like Array) - could be bikeshedding, though...
	*
	* 11/20/12

	/**
	* file: css-api.js - provides stylesheet requestCss api to JavaScript -
	* author: @dfkaye - david.kaye
	* date: 2013-2-12
	* fixed whitespace: 2020-07-28
	*
	* Prior Art:
	* - http://www.phpied.com/when-is-a-stylesheet-really-loaded/
	* - http://www.zachleat.com/web/load-css-dynamically/
	*

	/**
	* UPDATE 2013-02-27 ~ This is now in repo at https://github.com/dfkaye/simple-path-normalize
	*
	* file: simple-path-normalize.js - simple path normalizing JavaScript function -
	* author: @dfkaye - david.kaye
	* date: 2013-2-22
	*
	*/
	;(function (exports) {