Fabric.js: Use ES6 (transpile w. Babel)

[kangax]

Pros:

• More concise and easier to follow code
• This will have to be done at some point anyway

Cons:

• Additional build step
• Some people don't know ES6 (yet)

[kangax]

/cc @Kienz @asturur

[kangax]

Examples of how we could use ES6:

Old:

var atan2 = Math.atan2,
      abs = Math.abs,
...
x = pointer.x,
y = pointer.y,

New (destructuring):

var { atan2, abs } = Math;
...
{ x, y } = pointer;

Old:

initialize: function(el, options) {
  options || (options = { });

New (default parameters):

initialize: function(el, options = { }) {

Old:

return { x: x, y: y };

New (shorthand properties in object literals):

return { x, y };

Old:

{
  ...
  _setActiveGroup: function(group) { ... }
  discardActiveObject: function() { ...}
}

New (shorthand methods):

{
  ...
 _setActiveGroup() { ... }
 discardActiveObject() { ... } 
}

[kangax]

Old:

Object.prototype.toString.call(object[prop]) === '[object Array]'

New:

Array.isArray(object[prop])

[kangax]

Old:

gradients.coords = {
  x1: options.x1,
  y1: options.y1,
  x2: options.x2,
  y2: options.y2
};

New (using ES7 object rest/spread):

gradient.coords = { ...options };

[kangax]

Old:

'<radialGradient ',
  commonAttributes,
  ' cx="', coords.x2,
  '" cy="', coords.y2,
  '" r="', coords.r2,
  '" fx="', coords.x1,
  '" fy="', coords.y1,
'">\n'

New (template literals):

let str = `<radialGradient 
  ${commonAttributes} 
  cx="${coords.x2}" 
  cy="${coords.y2}" 
  r="${coords.r2}" 
  fx="${coords.x1}" 
  fy="${coords.y1}">\n
`;

[asturur]

i just learned standard javascript T.T

[kangax]

It really makes for a cleaner and more concise code. Once you'll get a hang of it, you'll never go back :)

[kangax]

I'm not saying we should transition right away. It's a lot of work but we can possibly start doing it gradually sometime in the future.

[raganwald]

If you really want to get funky:

Old:

{
  ...
  _setActiveGroup: function(group) { ... }
  foo: function() { 
    this._setActiveGroup();
    // ...
  }
}

New (symbols for private method names):

const setActiveGroup = Symbol(‘setActiveGroup’);
{
  ...
  [setActiveGroup]: function setActiveGroup () { ... }
  foo: function() { 
    this[setActiveGroup]();
    // ...
  }
}

Now the setActiveGroup method is quasi-private: It is not enumerable, nor is it included in the value of methods like Object.getOwnPropertyNames. It can only be accessed by code that knows the symbol bound to setActiveGroup.

(There is an explicit reflection backdoor around this, but still.)

[kangax]

Good point, @raganwald! And yep :)

Also no need for function ... there _although_ I see that function name inference doesn't seem to go as far as checking symbol identifier in a computed property of class method? (no time to check spec at the moment)

[kangax]

const _getActiveGroup = Symbol('getActiveGroup');

class Canvas {
  [_getActiveGroup]() {
    // ...
  }
  getActiveGroup() {
    this[_getActiveGroup]();
  }
}

[raganwald]

Absolutely!

Although, this would probably not be the first thing I tackled in a rewrite. It adds a little complexity now in exchange for quasi-safety later. My first choices would be the things where ECMAScript 2015 does away with ES-5’s accidental complexity.

[kangax]

My first choices would be the things where ECMAScript 2015 does away with ES-5’s accidental complexity.

..which are what, in your opinion?

[asturur]

a feel of deep unsuitableness is all around me

:)

[inssein]

I'm all for this, especially if we use Classes. Not a big fan of the way we do classes in this library.

[Bnaya]

Another ES6 pros would be, that projects that uses ES6 can use the source code as is with out build and to import just needed classes.

[kangax]

Yep, better module architecture! Good point.

Sent from my iPhone

On 21 Nov 2015, at 01:26, Bnaya Peretz [email protected] wrote:

Another ES6 pros would be, that projects that uses ES6 can use the source code as is with out build and to import just needed classes.

—
Reply to this email directly or view it on GitHub.

[jedateach]

A basic first step is to configure a babel transpilation build. Feed it all your current ES5, and then just gradually migrate pieces to ES6.

[jedateach]

@kangax - do you have any thoughts on how to roll this out?

The source could be transpiled, and then the existing build scripts could pick up files from a folder different to 'src'.

I'm also wondering if you've thought of using a build tool (eg, grunt, gulp, broccoli)?
Or...what plans are there to tidy up the build scripts - if any? I think they could _at least_ be more modular.

[kangax]

Yep, I would want all those things. I don't have time for Fabric anymore so hopefully someone can help.

[jedateach]

Ok - I'm interested in helping, but I just wanted to find out if I'd be going against any plans.

I've been using broccoli heavily in my main job. It is really fast because it caches heavily all the intermediate build steps, and therefore only needs to update a small part of the final build each time you make changes. It has built in watching.

I might have a play to see if I can get a build running through broccoli (and babel along the way), or perhaps just babel with the existing build.

[asturur]

i m cometely ok switching to es6.
i m spending lot of time on coding fabricjs, sadly i m not expert of build tools and i would like something i m also comfortable with.

i m mot really a fan of writing code and running the transpiled version but i see this is the trend now.

[jedateach]

I agree it seems strange that javascript (an interpreted language) would depend on a build step, but transpiling allows us to write in modern javascript, and have the code work on older browsers.

Perhaps it is worth defining what the build system should do first?

eg:

• Optional uglification / minification / concatenation
• ES6 transpilation
• Module selection options
• source map generation
• package as globals or AMD
• more?

Build tool selection could have its own criteria also:

• Popular + documented enough for contributors to contribute
• @asturur is comfortable with
• more?

Can I suggest a new "update build system" issue get created?
...I'm pretty sure everyone now agrees ES6 is a good way forward regarding this issue.

[jedateach]

@asturur - what's your typical workflow when developing fabric.js?

[asturur]

the only available workflow is:
branch
modify submodule
npm run build ( wait for minification )
npm run test
ok push.

i agree that having a listener tool that rebuild the package at every save is better.

if the concatenation is optional is even better, a main jsfile is just importing / requiring all the stuff and we do not have to concatenate to use or test the library.

if you are available for a chat we can discuss it a bit

[jedateach]

Here's a commit containing some modularisation of build.js:
https://github.com/jedateach/fabric.js/commit/444ef1d7bbac100296cd1caae32f3a0e409219d3
...with the main goal being to be able to use the file list in a different build system

[jedateach]

I'm splitting up the build into a build/ folder, and so far about 5 files. I'll push another commit to my branch soon.

By splitting the existing build into pieces, then I'll be in a position to plug some of those pieces into a new build tool. Particularly the ordered files list, and the cli arguments.

I'm looking for a build tool with these characteristics:

• reasonably popular / likely to stick around for a while
• supports ES6
• incremental builds = fast

I'm really aiming to get a build system that can give us ~1 second builds. I know broccoli can do this, but it doesn't have a large ecosystem. I've already tried using gulp, but it gets the same build time as current build. Grunt will be the same or worse.

I'm thinking at this stage that webpack could be a good candiate. My only concern is whether it can support the existing "globals concatenated files" kind of approach we currently have.

Once I've got a build working with a new build tool, the next step would be to look at switching the existing module system with ES6 modules.

Am I on the right track with this? Any concerns?

[kangax]

Sounds good to me, thanks for doing this.

[garprogram]

Hi, this is a great idea, I was thinking about it.
Is there any branch of development for this feature ?.
I would be happy to contribute.

[asturur]

i would like to not kill the current web based builder in this process.

[garprogram]

It's a hard job to rewrite all the code to es6 and change the whole repository so nothing breaks, the builder is just a small but important step. I agree

[asturur]

Rewriting the code is out of scope now, enabling a structure that allow us to start writing es6 and transpiling is the key point.

[garprogram]

Ok, when I have free time I'll read some things, I think I've seen a transpiler tool on the ecmascript website, closure compiler also does transpile to es3 / es5.

[garprogram]

Maybe https://babeljs.io/ can help.

[Bnaya]

I would advocate writing new ES6 code with flow annotations or even in typescript :)

[asturur]

untill fabricjs is one man band, me for now, i skip this part.
i have to deal issues about rendering and api normalization that are far more important.

from a dev point of view the fact that the cose is es6 or es5 change little. the fact that you can easily understand and change it is far more important.

for now better syntax is lesser than actually good code flow.

that is my opinion at least

[Bnaya]

I totally understand you

[cyberhck]

if anyone's willing to give change a try, could try writing it in TypeScript, type checking would help to a great extent, and it'd automatically create d.ts files, (and make documentation very easy because you won't write jsdoc)

I could initialize a sample file and try getting a decent build system.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.