Skip to content
This repository has been archived by the owner on Jul 13, 2020. It is now read-only.

Depreciation of translate hook #525

Closed
dmail opened this issue Jan 15, 2017 · 6 comments
Closed

Depreciation of translate hook #525

dmail opened this issue Jan 15, 2017 · 6 comments

Comments

@dmail
Copy link

dmail commented Jan 15, 2017

If I am not mistaken, translate hook is, or will be, deprecated according to whatwg/loader#147

My concern is about "fetch and translate hooks can be implemented in user-land via service workers or Realm's evaluation hook."

If I understand correctly, server will return an already transpiled source when a module is fetched by browser. That's fine for the browser but server itself will now have to depend on an other server transpiling source for it, causing two issues :

  • The other server cannot use SystemJS (he is reponsible to transpile)
  • For now, SystemJS does not support http call on node (system-fetch.js#L79)

I don't know what "Realm's evaluation hook" is, would it solve this problem ?

@probins
Copy link
Contributor

probins commented Jan 15, 2017

https://matthewphillips.info/posts/loading-app-with-script-module is an example of using service workers to change the fetch before sending it, and you could do something similar to 'translate' the fetched file. IOW the browser would load a function/module which would translate for example CJS to ES. This is however a temporary requirement (assuming CJS modules will all be converted eventually to ES), and I would question whether it makes sense to do this in the browser. Admittedly, you can cache this function so each browser has a copy, but to my mind, it's better to do the conversion once on the server rather than in every browser. The problem is not so much with your own code, but third-party code you use. Many of these have a UMD wrapper, so what I do is create a new version with an ES or System.register wrapper instead.

Realms were originally planned as part of ES6, but are still under discussion. The current proposal is at https://github.com/FUDCo/proposal-frozen-realms

@dmail
Copy link
Author

dmail commented Jan 15, 2017

Thank your for your help, I'll dive more into the realm proposal.

Concerning service worker I got it but I'm worried about code used by the server, not by the browser. There is no service worker in nodejs. Even if, SystemJS does not support http call on nodejs at the moment.

My use case involves JavaScript transpiled by nodejs and runned by nodejs.

@probins
Copy link
Contributor

probins commented Jan 15, 2017

ah, ok, in that case service worker isn't any use to you. And Realm isn't likely to be implemented in the near future. Have you looked at the 0.20 branch of SystemJS, which uses this revised polyfill which doesn't have a translate hook?

@dmail
Copy link
Author

dmail commented Jan 15, 2017

Good idea, it seems there is still a way to achieve what I want using loader.transpiler according to https://github.com/systemjs/systemjs/blob/0.20/src/instantiate.js#L471.

I hope SystemJS and planned future version maintain a way to set a custom transpiler.

@probins
Copy link
Contributor

probins commented Jan 16, 2017

this is a polyfill, and implements what's in the specs. Node isn't currently planning on implementing the async pipeline, so AIUI there will be no hooks in its native implementation.

@dmail
Copy link
Author

dmail commented Jan 16, 2017

I got the feeling that when native implementation will arrive I'll have to keep the "polyfill" (SystemJS) anyway. I'm refering to System.trace = true which is very usefull but not in the spec.

So as long as SystemJS allow a custom transpiler I'm fine.

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

No branches or pull requests

3 participants