Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add documentation for which features do not require traceur-runtime #1007

Open
matthewrobb opened this issue May 11, 2014 · 11 comments
Open

Comments

@matthewrobb
Copy link

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

@matthewrobb
Copy link
Author

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
Copy link
Collaborator

arv commented May 12, 2014

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
Copy link
Author

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...

arv added a commit to arv/traceur-compiler that referenced this issue May 12, 2014
The intent is to make the runtime library more modular.

See google#1007
@matthewrobb
Copy link
Author

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
Copy link
Collaborator

arv commented May 14, 2014

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
Copy link
Contributor

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 [email protected]:

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
.

arv added a commit to arv/traceur-compiler that referenced this issue May 14, 2014
arv added a commit to arv/traceur-compiler that referenced this issue May 14, 2014
@matthewrobb
Copy link
Author

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.

arv added a commit to arv/traceur-compiler that referenced this issue May 14, 2014
arv added a commit to arv/traceur-compiler that referenced this issue May 14, 2014
arv added a commit to arv/traceur-compiler that referenced this issue May 14, 2014
@sheerun
Copy link

sheerun commented Oct 25, 2014

+1 Also an option that enables all features that don't require runtime would be cool.

@sheerun
Copy link

sheerun commented Oct 25, 2014

Also +1 for standard traceour runtime in bower, component and npm registry. I woudn't like to host runtime precompiled with my library. I guess it should be a dependency.

@jokeyrhyme
Copy link

By definition, the compiler knows which ES6 features are being used by the subject code. As such, would it make sense to have the compiler produce the minimal runtime that matches the required features? Optionally either keep it as a separate build artefact or automatically prepend it to the app bundle?

@johnjbarton
Copy link
Contributor

Yes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants