Add documentation for which features do not require traceur-runtime

[matthewrobb]

Also potentially add a compile option to enable ONLY those features that do NOT require the traceur-runtime.

[matthewrobb]

Alternatively make it so traceur-runtime can be custom built to only include specific features? Not sure how possible this is but it would be nice.

[arv]

Both are useful. I have been wanting to split up the runtime file so that custom runtime files can be made easier.

Here is a first draft audit of the features and their dependency on a runtime:

Default options

Requires runtime

• arrayComprehension - Symbol.iterator
• classes - $traceurRuntime.createClass
• destructuring - $traceurRuntime.assertObject
• forOf - Symbol.iterator
• generatorComprehension - $traceurRuntime.initGeneratorFunction & $traceurRuntime.createGeneratorInstance
• generators - $traceurRuntime.initGeneratorFunction & $traceurRuntime.createGeneratorInstance
• modules - $traceurRuntime and a lot more from src/runtime to support dynamic module loaders. --modules=amd and --modules=commonjs needs no Traceur runtime.
• spread - $traceurRuntime.spread
• polyfills - Array, Promise, String, Map, Set, Symbol

No runtime

• arrowFunctions
• computedPropertyNames
• defaultParameters
• numericLiterals
• propertyMethods
• propertyNameShorthand
• restParameters
• templateLiterals

Experimental Options

Requires runtime

• asyncFunctions - $traceurRuntime.asyncWrap
• symbols - runtime.js overrides a bunch
• typeAssertions - $traceurRuntime.types

No runtime

• blockBinding
• types
• annotations

[matthewrobb]

Destructuring, modules, and spread all seem like they could reasonably be compiled out dependency free. I'm not familiar with the traceur code for these features but my goal is to be able to run modules through traceur with --modules=instantiate and be able to load them with SystemJS or es6-module-loader and no runtime...

[matthewrobb]

Im playing around with adding options.standalone. Right now it works similarly to experimental except that it sets all options that are NOT flagged stand alone to off.

What I am thinking is that there may be a more intuitive way to go about all this. It seems like the real desire would be to select the modules for a custom runtime build and automatically get the features that either don't need any runtime help or that depend on an included runtime but nothing else.

Also it would be great if the runtime got built out to amd/commonjs/instantiate modules as well, leaving it up to the user to determine the bundling strategy etc.

[arv]

Also it would be great if the runtime got built out to amd/commonjs/instantiate modules as well, leaving it up to the user to determine the bundling strategy etc.

We toyed around with that idea before and I think it would be great. I think there might be some bootstrapping issues though.

[johnjbarton]

I guess you are thinking about loading runtime dependencies via module
loading? I think our build scheme is a bit easier now or at least I
understand it. If you want to pursue this don't hesitate to ask about it.

On Wed, May 14, 2014 at 8:29 AM, Erik Arvidsson notifications@github.comwrote:

Also it would be great if the runtime got built out to
amd/commonjs/instantiate modules as well, leaving it up to the user to
determine the bundling strategy etc.

We toyed around with that idea before and I think it would be great. I
think there might be some bootstrapping issues though.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1007#issuecomment-43095789
.

[matthewrobb]

Great to see the runtime splitting up. Thanks guys!

I was looking at the runtime dependency for destructuring and it seems like something that could probably be inlined without adding a ton of bloat. Is that something that has been discussed before? Once you decouple destructuring from needing the runtime then traceur becomes a lot more attractive as a general transcompiler with a set of optional features that DO require runtime support.

I think if things looked more like the above then it would be much easier to get broader buy-in to using traceur in production scenarios.