Rewrite in ES6

[bennlich]

In preparation for modularization and the future

[backspaces]

Right on!

For me, modules first. I think I've proved CS/AS can successfully backtick import/export. I know it would seem weird, but if we do this, and simply use a System polyfill, we wouldn't need traceur runtime.

There are subtleties.

• Which es6 features? Use traceur features even when there are Native implementations. I've build a dynamic options setter for traceur so we can defer to native when possible.
• Performance. It seems that the initial native versions of "let" are still slower considerably than var. Are there other performance traps?
• Module use style. I've figured out how to make the ABM global as currently used. But better yet, I think I've figured out how to use the dynamic loading stunt, so models not using Links, for example, would not even import that code. It would be a pretty big mind-set change. All still within CS.

[jamiebuilds]

Hey @backspaces and @bennlich, you might want to check out 6to5. It compiles to very plain ES5 code similar to how coffeescript does. We have a great gulp plugin since you're already using it. I'm a contributor for 6to5 so feel free to ping me if you need help, or you can ask one of us on gitter.

[miketheprogrammer]

@backspaces, speed of es6 methods will depend on the browser and it's optimization compiler. Most es6 functionality like generators will send you right to deoptimization he'll in chromes v8." On Dec 7, 2014 4:11 AM, "James Kyle" [email protected] wrote:

Hey @backspaces https://github.com/backspaces and @bennlich https://github.com/bennlich, you might want to check out 6to5 http://6to5.github.io/. It compiles to very plain ES5 code similar to how coffeescript does. We have a great gulp plugin https://github.com/sindresorhus/gulp-6to5 since you're already using it. I'm a contributor for 6to5 so feel free to ping me if you need help, or you can ask one of us on gitter https://gitter.im/6to5/6to5.

— Reply to this email directly or view it on GitHub https://github.com/backspaces/agentscript/issues/58#issuecomment-65931319 .

[backspaces]

Yes, I have to agree that 6to5 seriously caught my attention and is very readable. It is not as performant as either the coffeescript or traceur transpilers, the author and I discussed this a bit. But you have a great point .. start with the 6to5 translation and go from there!

One idea we've worked with is traceur with dynamic options: testing for browser implementation of es6 features and if there, just use them, don't transpile, use the browser's. I don't know how easy this is with 6to5 but can ask the author or just look at the repo.

-- Owen

On Sun, Dec 7, 2014 at 5:35 AM, Michael Hernandez [email protected] wrote:

@backspaces, speed of es6 methods will depend on the browser and it's optimization compiler. Most es6 functionality like generators will send you right to deoptimization he'll in chromes v8." On Dec 7, 2014 4:11 AM, "James Kyle" [email protected] wrote:

Hey @backspaces https://github.com/backspaces and @bennlich https://github.com/bennlich, you might want to check out 6to5 http://6to5.github.io/. It compiles to very plain ES5 code similar to how coffeescript does. We have a great gulp plugin https://github.com/sindresorhus/gulp-6to5 since you're already using it. I'm a contributor for 6to5 so feel free to ping me if you need help, or you can ask one of us on gitter https://gitter.im/6to5/6to5.

— Reply to this email directly or view it on GitHub < https://github.com/backspaces/agentscript/issues/58#issuecomment-65931319>

.

— Reply to this email directly or view it on GitHub https://github.com/backspaces/agentscript/issues/58#issuecomment-65935953 .

[jamiebuilds]

Every transform in 6to5 can easily be turned on and off, and all of the polyfills will default to using the native implementation if it exists.

Traceur is very fast and if that's most important thing to you then its a good choice, but I've found that depending on the Traceur runtime for library code tends to scare off users.

[backspaces]

Stumbled across this on migrating from CS to ES6: https://www.airpair.com/coffeescript/posts/migrating-coffeescript-to-es6-javascript Bottom line: not as easy as it might seem.

The post has interesting insights, also the AirPair company seems nifty. I wonder if they are working on automatic conversion from CS to ES6.

Now if 6to5 had help there it would be world changing!

[sebmck]

@backspaces Some parts of that article are outright wrong. Such as coffeescript -> being equivalent to ES6 =>. The performance of 6to5 is definently concerning and i'm hoping to make it much better for the 2.0.0 release, you can track that at 6to5/6to5#261.

[backspaces]

Thanks Sebastian, both for the comment and 6to5 in general. I've definitely been impressed with the approach, and I think performance can be managed. I hope you continue to support array comprehensions, I use them everywhere!

On Wed, Dec 10, 2014 at 1:47 AM, Sebastian McKenzie < [email protected]> wrote:

@backspaces https://github.com/backspaces Some parts of that article are outright wrong. Such as coffeescript -> being equivalent to ES6 =>. The performance of 6to5 is definently concerning and i'm hoping to make it much better, you can track that at 6to5/6to5#261 https://github.com/6to5/6to5/issues/261.

— Reply to this email directly or view it on GitHub https://github.com/backspaces/agentscript/issues/58#issuecomment-66420334 .

[backspaces]

Starting to look at the issues for es6 conversion. BTW: decaffeinate is interesting.

One rather large issue is strict mode. Axel Rauschmayer sez:

Implicit strict mode:  The bodies of modules and classes are implicitly in 
strict mode in ECMAScript 6 – there is no need for the 'use strict' marker. 
Given that virtually all of our code will live in modules in the future, 
ECMAScript 6 effectively upgrades the whole language to strict mode.

Another is our use of class variables. Axel sez:

Inside the body of a class definition: A class body can only contain methods, 
but not data properties. Prototypes having data properties is generally considered 
an anti-pattern, so this just enforces a best practice.)

These could be problematic, for example our use of cloning classes (see Util) is not strict mode. There may be a workaround (use of "new Function) but then the only place we use this is for the three classes (Patch, Agent, Link) which we make very light weight via defaults ("class properties", also illegal in es6), and soon the new color model that gets rid of expensive arrays, and allows color sharing via color maps.

Basically, because AgentSets are the only creators of these three classes' instances, and we want them to be very efficient, I think we should migrate away from classes for them, towards a Prototypal, light-weight "flyweight" pattern, with a default layer/support. It also allows us to get closer to a shared Redfish "layers architecture".