niklasramo/palikka

A tiny JavaScript module system for the browser and Node.js

palikka's Issues

palikka.Deferred() does not suppress throws

Palikka currently uses native promise's executor function implementation, which does not suppress throws. However, after thinking this through it makes more sense to make the executor suppress throws similarly to how .then() method behaves. A lot of other promise libraries (Q for example) have also chosen to suppress throws within the executor function.

Case example, this is how executor should handle throws:

new palikka.Deferred(function () {
  throw 'test';
})
.then(null, function (reason) {
  console.log(reason); // "test"
});

Module versioning

Should there be some way to add version number to the module and make it possible to require specific version of a module? This would be especially helpful when a module depends on a specific version of a third party library.

Play nice with Node.js modules.

It might be awesome if Palikka would automatically export and require modules via it's own API when in Node.js environment. Naturally such automation would be optional and configurable via palikka.config. How to implement this kind of automation without confusing the user is going to be hard, but worth an investigation.

Making internal event system as a part of public API

Palikka's built-in event system, which is used to emit and listen module initiation events, is initiated with a reusable event system constructor function which can be used to give basic .on(), .off(), and .emit() methods to any object. In many cases custom modules need some kind of way to communicate with other modules and a private event system is the most logical way handle it. So, it really makes sense to bring this functionality as a part of the public API and document it properly instead of hiding it as a private method. However, this is not what Palikka is designed to do so this needs to be considered carefully.

Promises/A+ compliance test suite

Since palikka is advertised as Promises/A+ compatible we should really add the "official" compliance test suite as part of Palikka's tests. Sure, the compatibility is checked at the moment via custom tests which should be enough, but it can never hurt to have more tests =)

Throwing errors

At the moment Palikka fails silently in many cases where it might probably be a good idea to throw some errors with explanations. However, as that would lead to larger file size the question is that is the library simple enough to ignore error reporting completely?

Module system constructor function

Make module system work as a constructor function like palikka.Deferred() and palikka.Eventizer() instead of being a Palikka method.

Circular dependencies

How should we handle circular dependencies (when two modules require each other). At the moment neither of the modules get loaded, but could there be a better way? Here's how RequireJS does it: http://requirejs.org/docs/api.html#circular.

Perf tests

It would be awesome to have automated performance tests which could be easily compared to the previous iteration of the library (and also to other libraries) so we can see which way we are heading performance wise.

Faster next tick implementation for IE7 - IE10

Although the next tick implementation is working as exepected in IE10 and below, it's still pretty slow since it falls back to setTimeout implementation on those browsers. It would be awesome if something could be done to make the tick faster, but without too much hacking.

The onreadystatechange method seems like a valid candidate. setImmediate would be awesomely fast for IE10+, but it's broken.

setImmediate.js seems like a good reference for fallback methods. There are also some interesting nextTick implementations on jsPerf.

.require() method should receive the dependencies in the callback function's context just like .define() method does

Currently the callback function of .require() method does not receive any special context unlike .define() method. It would be logical for these methods to act identically in all possible areas meaning that one could do the following thing with .require():

palikka.require(['a', 'b', 'c'], function () {
  var a = this.dependencies.a;
  var b = this.dependencies.b;
  var c = this.dependencies.c;
});

Get test suite working in Sauce Labs

I had some problems running Palikka's test suite in Sauce Labs. Currently the tests are run locally on the browsers that are available on the machine (Chrome, Firefox, IE, Phantom). This really needs to be sorted out before v1.0.0 release in order to make sure that the library delivers what it promises.

Move documentation from readme file to github pages

Although I like a lot having all the documentation in the readme file it's not really practical whenever I have to update an older version's documentation. I'll move the current docs permanently to https://niklasramo.github.com/palikka asap.

Allow using a deferred as a module's dependeny

Since modules are already built on deferreds it would be awesome to allow the .define() and .require() methods accept deferreds as dependencies in addition to modules. Not sure yet how useful this feature would be, but since modules are already basically just named deferreds this seems like a natural progression and it's also pretty easily doable.

var windowLoaded = palikka.defer(function (resolve) {
  window.onload = function () {
    resolve(window);
  };
});

palikka
.define('b', {})
.define('a', ['b', windowLoaded], function (b, win) {
  return 'a';
})
.require([windowLoaded, 'a', 'b'], function (win, a, b) {

});

Automatic docs generator

Alrighty, so now we have gh-pages branch officially set up for Palikka's documentation. Currently it needs some manual work to update it, but it would be awesome if we had an automated way to generate/update the documentation of a specific version from a single markdown file.