Browser APIs and their weird dissimilitudes

gistfile1.js

// WEB WORKERS

var worker = new Worker('task.js');
worker.onmessage = function (e) {
};
// where's addEventListener? A Worker shoud be an EventEmitter
worker.addEventListener('message', function (e) {
});
// And you know, on() as an alias of addEventListener makes a lot of sense too

// WEBGL
// In WebGL, you need to insert a shader in a script tag. Ok, makes sense, it even uses a type different to "text/javascript".
var vSource = document.getElementById("vertex").firstChild.nodeValue;

// Then you need to create a shader object by calling createShader
var vShader = gl.createShader(gl.VERTEX_SHADER);
// Now wait, I have an instance and I need to set the source afterwards?
// Worse, it's an instance but I have to set the source from a method of the context?
gl.shaderSource(vShader, vSource);
// How it should be:
var vShader = gl.createShader(gl.VERTEX_SHADER, vSource);
// Of course, a shader without a source? Maybe I'm missing something and it makes sense, but it still can be an optional parameter
// At any rate, if I was going to set the source of a shader, I'd expect it to do it from the shader itself:
shader.source = vSource; //do'h

// Next we need to compile the shader.
gl.compileShader(vs);
// Wait, something we learned is that compiling is expensive and by the way this is written, it is a synchronous call
// It should be async! For many reasons, like avoiding using try...catch, but also to avoid locking the UI thread compiling shaders
// Then again, it's the shader that's compiling. Have it say that!
shader.compile(function (err) {
  if (!err) {
    // NodeJS de facto standard. Work here
  }
});

var program = gl.createProgram();
gl.attachShader(program, vShader);

// Again, why aren't we doing actual OOP? Shouldn't it just be...?
var program = gl.createProgram();
program.attachShader(vShader);

// Wait that reminds me of something... Ah yes
sibling.parentNode.insertBefore(node, sibling);
// How it should've been:
node.insertBefore(sibling);
// Makes sense, right?


// I don't expect method chaining from a browser API, but I do expect it to be similar to other APIs
// mostly the DOM, but preferrably the good parts of the DOM.

// So browser developers, please, we know how to use EventEmitters and callbacks.
// Let the APIs help us write good programs, not get in the way