>> 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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
