Translate hook

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Translate hook

jbondc@openmv.com

I’ve been reading recently the module discussions and one particular concept troubled me.

 

I don’t understand the motivation behind an on-the-fly ‘translate’ loader hook that would compile CoffeeScript into JavaScript.

Would every browser have to include a CoffeeScript compiler? Which version?

 

If just seems like the only result would be more ‘web fragmentation’ by having browsers with different EcmaScript implementations and different compilers/translators of many different  languages? How is that going to work out?

 

While I understand the benefits in theory, in practice I get the overwhelming impression that an on-the-fly 'translate' concept is a great way to break the web, not make it any better.

 

Am I missing something, what problem does it solve?

 

Jon


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Translate hook

Tab Atkins Jr.
On Tue, Jun 18, 2013 at 9:02 AM, [hidden email] <[hidden email]> wrote:

> I’ve been reading recently the module discussions and one particular concept
> troubled me.
>
> I don’t understand the motivation behind an on-the-fly ‘translate’ loader
> hook that would compile CoffeeScript into JavaScript.
>
> Would every browser have to include a CoffeeScript compiler? Which version?
>
> If just seems like the only result would be more ‘web fragmentation’ by
> having browsers with different EcmaScript implementations and different
> compilers/translators of many different  languages? How is that going to
> work out?
>
> While I understand the benefits in theory, in practice I get the
> overwhelming impression that an on-the-fly 'translate' concept is a great
> way to break the web, not make it any better.
>
> Am I missing something, what problem does it solve?

Without reading the module spec to make sure of this, I'm nearly
certain that the 'translate' hook is for authors to supply *their own*
translation script.  There won't be any built-in ones.

~TJ
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Translate hook

Sam Tobin-Hochstadt
In reply to this post by jbondc@openmv.com
This is a misunderstanding of the `translate` hook in particular, and
the concept of hooks in the loader in general.  The loader hooks are
there for programmers to configure and change the default behavior of
the browser.  For example, you could modify the standard loader, or
create a new loader, so that it understood CoffeeScript.  However,
this doesn't mean that browsers will ship loaders that do this
(although of course they could). The default behavior of the
`translate` hook for the System loader is to return its input
unchanged.

Sam



On Tue, Jun 18, 2013 at 12:02 PM, [hidden email] <[hidden email]> wrote:

> I’ve been reading recently the module discussions and one particular concept
> troubled me.
>
>
>
> I don’t understand the motivation behind an on-the-fly ‘translate’ loader
> hook that would compile CoffeeScript into JavaScript.
>
> Would every browser have to include a CoffeeScript compiler? Which version?
>
>
>
> If just seems like the only result would be more ‘web fragmentation’ by
> having browsers with different EcmaScript implementations and different
> compilers/translators of many different  languages? How is that going to
> work out?
>
>
>
> While I understand the benefits in theory, in practice I get the
> overwhelming impression that an on-the-fly 'translate' concept is a great
> way to break the web, not make it any better.
>
>
>
> Am I missing something, what problem does it solve?
>
>
>
> Jon
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Translate hook

Jonathan Bond-Caron
>> The loader hooks are fantastic. In the case of translate(), consider:
>>
>> module Button from "classes/ui/Button.js"
>> module Button from "classes/ui/Button.dart"
>> module Button from "classes/ui/Button.ts"
>> module Button from "classes/ui/Button.coffee"
>> module Button from "classes/ui/Button.zip"
>> module Button from "classes/ui/Button.mypackage"
>>
>> In the last two, you can extract non-javascript content (css, html) and place it somewhere else for loading processing.
>>
>> It's nice to have options but would all those and more be valid by overriding Loader.translate()? IMHO, web fragmentation.

> I'm not sure what the problem here is supposed to be.  You'll have to have libraries for doing any of these things, which will modify `Loader.translate`.  Right now, I can fetch code in any
> language from any source, process it, and eval it.  People write script tags for coffeescript or python or lua using JS translators. Is this leading to web fragmentation?

If translate() is intended as a hook for transpilation, it will lead to fragmentation.
I don't have crystal ball but I am concerned about 'transpilation' as a feature in the loader api.

I should probably add:
module Crypto from "classes/crypto/Crypto.asm.js" (compiled from c++)

"Our goal is to make the open web a compelling virtual machine, a target for compiling other languages and platforms."
http://ejohn.org/blog/asmjs-javascript-compile-target/

Maybe I'm misinterpreting something, but the translate() hook just seems like a mechanism to compile just about anything that maps to javascript or LLVM bytecode.
http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html

Is there some consensus that the web "needs typed language foo"?

Don't get me wrong, asm.js is really clever from a technical standpoint.
I'm finding it difficult to not be worried about the non-technical implications.

>> The second concern is re-writing code:
>> import m from "https://cdn.company.com/module.js"
>>
>> Can I transform the source and turn private closures into public functions? Why bother with export?

> Yes, you can transform anything you want, once you have the source.
> You can already do this with XHR, or with an inline script tag, or ...

Sure but that's a bit of a stretch, XMLHttpRequest was initially designed to load XML and inline script tags are quite inconvenient for large amounts of code.
By design in this case, source code transformation is encouraged either by programmers or by the browser.

> The reason to bother with export is that it works with the system.
> Sure, you can implement a whole new language, but that has exactly the costs of implementing a whole new language.  The loader hooks make that possible, but it isn't reasonable to do > it unless you're serving some actual use case.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Translate hook

Brendan Eich-3
Jonathan Bond-Caron wrote:
> If translate() is intended as a hook for transpilation, it will lead to fragmentation.

This does not make sense, because no would-be-fragmenter (browser brand
X) gains share by shipping pre-packaged translators -- they'd be
implemented in JS and managed on github, so anything built-in would just
drift out of date quickly, besides not being attractive to developers
who cannot count on it exception in brand X.

Downloaded translators are a different story, but those play on a level
field and all ES6 browsers can support them equally well. They stay
fresh via HTTP caching or better. They're no different than jQuery.

Of course, many sites will precompile to avoid any client-side perf hit
and CPU heat. That's the biggest counter-argument to translate as a
much-used-by-deployments tool. But it still makes sense for prototyping
and experimentation. It is not inherently fragmenting.

Rubbing the general "compile to JS means many languages" worry bead is
pointless. That genie won't go back in its bottle. We're better off with
JS also being evolved to serve its hand-coding user base at the same pace.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Translate hook

Brendan Eich-3
Brendan Eich wrote:
> out of date quickly, besides not being attractive to developers who
> cannot count on it exception in brand X.

"except in brand X", of course.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss