Translate hook
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.
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.
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." 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. 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 "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.
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.
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.
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