Move from CoffeeScript to ES6

ah slight snag, turns out that apply is also throwing the error Class constructors cannot be invoked without 'new' in current chome canary.

Caitlin quotes in the esdicuss topic:

People are experimenting with polyfilled class implementations, which don’t all correctly throw when called as a function (no new). Eventually, they’re likely to be disappointed that this isn’t legal, and might have to undergo some serious pains to fix their applications.

But yeah we should be ok because when it’s ES6 proper we shouldn’t be affected because we will no longer be using a polyfill. Nor are we calling call\apply on classes directly.

So io.js fixes the corruption issues with writing heap snapshots, yay!

I’ve pushed up https://github.com/bevry/taskgroup/commit/017d457f7a182bbbe4ca8f0f4a1cdbd1bf0ed2a2 which contains an interesting results. itemsCompleted is our memory enemy. We need to get rid of that by default.

Yeah that will be great. itemsCompleted keeps a reference to all tasks until a gc occurs so i’m in favour of this.

So io.js fixes the corruption issues with writing heap snapshots, yay!

Was this in regards to something I said or did you see something via iojs? they’ve not updated my issue with any findings yet…

@balupton my replies never get grouped to what im repling to, is there something I’m doing wrong?

https://github.com/iojs/io.js/issues/1058

Different than your issue.

Does this mean DocPad will also move from recommending Eco to a JavaScript-based templating language? If so, have you decided on which one yet?

+1 Ideally we could also support React usage.

Ideal stack:

  • React, Consolidate.js
  • ES6
  • CSS Modules, SASS, LESS
  • Browserify

Ideally it would be React or Consolidate which exposes a ton of templating languages.

Hey @cameronjroe, I haven’t tried it yet myself but there is a docpad-plugin-react.

I’ve been using docpad-plugin-babel and docpad-plugin-browserifydocs together in my workflow to use ES6 in my DocPad projects and it’s been working great so far.

Regarding moving away from eco. Perhaps we will move to a JavaScript equivalant of eco. Moving to React requires the entire ecosystem and architecture to change, being the way react snowballs to affect everything.

Just like to mention that Taskgroup has now been converted from CoffeeScript to JavaScript. The performance benefits of the conversion, including the benefits of being able to profile and debug the actual source code, have been fantastic.