How to use ES6 modules on the browser?

[tinganho]

Are there any ways to program using ES6 modules and compile everything down to one file? I guess you treat ES6 modules as external modules and therefore not doing any bundling.

I have tried using --out option to compile everything down to one file and using ES6 syntax. But so far, it seems like TypeScript doesn't support it.

I'm just curious how you expect people ot use ES6 import syntax on the browser? I was hoping something like browserify's bundling would happened.

[ahejlsberg]

To use ES6 modules in the browser you currently need to include a module loader such as RequireJS or SystemJS or use a bundling tool such as Browserify.

We're actively discussing implementing a simple bundling feature in the TypeScript compiler itself. Similar to --out it would allow you to bundle the output of a compilation of multiple ES6 modules into a single file with an included micro-loader that resolves references between the modules. The thinking is that you'd be able to designate one of the modules as the external interface and we'd expose only the exports of that module from the compiled bundle (of course that module could use export * to export from several of the other modules). It would be possible to package the compiled bundle as as a CommonJS or AMD module, or as a "self executing" module with no external dependencies.

[tinganho]

@ahejlsberg are there any rough plans on when this will be implemented?

I'm not so fond of the idea of adding a post-build using requirejs or browserify.

[ahejlsberg]

If we decide to do it it would probably be in the 1.6 release.

[EisenbergEffect]

I have a thought related to this. Just throwing this out...

For Aurelia, we are using SystemJS for loading. I'd like to keep that option at the app level, but I'm wondering if we could ship our individual libraries a little differently. Right now, one of the draw backs for module loaders is that resolving dependencies involves lookup in a registry, etc I'm wondering if the micro loading could take a slightly different approach. Could the compiler be configured to instead generate ES5 code that simply uses object references to connect modules to their imports without any sort of registry or lookup mechanism? This could improve performance, particularly around startup time.

For example, each library in Aurelia is composed of a number of modules, but really the library only exports a subset of that as its public interface. Could there be an option to compile each of these libraries to a single file, with all the internal import/export semantics being mapped to object references. Then, could it simply export the the final set of exports for use with a module loader? In other words, statically linked internally, but dynamically linked to consumers.

This is bringing more of the concept of a "library" to TypeScript as something composed of multiple ES6 modules but that is transformed into a single file with an explicit set of public exports.

[csnover]

I would really prefer TS team leave module bundling to the many other projects that already have done it successfully instead of repaving this particular path. AMD is the correct intermediate format for emitting directly to browsers without ES module support, as it was specifically designed for this purpose (modules in ES3/5 browsers).

@EisenbergEffect Web community already went down the module loading micro-performance rabbit hole years and years ago. Go search for some of the research that Dojo and SproutCore teams did, or if you want to experience some extreme code loading pedantry, try reading some of getify’s old blog posts. The right thing to do is to split code and only load what you need at startup, ideally avoiding execution of factory functions until they are required. The AMD format is the result of a lot of research on the best way to do modules in browsers without requiring changes to the language itself and is as ideal as you can get without violating CSP (and probably as ideal as you can get even then with modern JIT). There is no need to expend more energy on this solved problem. (Get off my lawn, etc etc. :))

[EisenbergEffect]

@csnover I've used AMD successfully for a number of years and done very well with that. However, it's important to note that AMD doesn't correctly represent ES6 module semantics. It is possible to write ES6 code that, when transpiled to AMD modules, will result in incorrect dependency resolution. Specifically, I'm referring to how circular references are handled. The only format I know that expresses the exact same semantics as ES6 is the system.register format.

That is a bit beside the point for what I am talking about though. I'm simply throwing out a compilation idea for libraries. Since we distribute our library as a single unit, but it's authored as many ES6 modules, it might be interesting to consider a compilation option which would intelligently combine these into a single module and perhaps use object references rather than a more costly module registry internally. There's nothing stopping the entire thing from being exported as an AMD module though, or any other format.

And I would note, I'm happy for anyone to tell me that is a bad idea. I'm just thinking out loud here...

[cmichaelgraham]

@csnover recently i ran into an issue bundling aurelia amd modules.

the issue was caused by three separate files A, B, and C. A imports a type from B, B imports a type from C, and C imports a type from A.

this scenario is supported just fine by jspm and systemjs ES6 modules.

i'm an old school .NET guy. it seems to me like it should be ok for this type of scenario, particularly within a repo, much like types within an assembly.

my hack solution to the problem was to move the three files into a single file, which worked fine.

it seems to me like this issue proposes to mechanize what i did manually.

does any of that make sense?

[csnover]

@EisenbergEffect It’s a bad idea :) Or, at least, it’s solving a problem that doesn’t exist. Hiding library internals typically causes more problems than it solves; as an end-user of a lib you can operate defensively against other things on the page ruining your dependencies, but as a lib author doing the same thing just causes a little bug in your library to be a big problem for your users since they can’t patch it by just replacing the impact API with a fixed one without copying and modifying the entire thing. I have worked on both jQuery and the Dojo Toolkit so have a lot of experience in the JS lib area to understand this problem. :)

When you use AMD format as an intermediate export format for ES modules circular references still work. You can compile to AMD format with ES modules format in TypeScript today and it works fine, I made sure of that.

[cmichaelgraham]

@csnover maybe i was just doing it wrong somehow. i was using r.js to bundle up the aurelia amd libraries. when the bundle loaded, it received an undefined for the circular case instead of the actual type.

http://requirejs.org/docs/api.html#circular describes that and suggests that you declare require as a dependency and use it to obtain the problem undefined type within the method.

to do that, i'd have to go back to the aurelia source and create a special case.

i'm relatively new to all of this, so i could easily be missing something... :)

[tinganho]

@csnover I'm not sure if it makes sense from a workflow view. Compile TS(ES6 modules) -> JS(AMD modules) and then use requirejs to bundle everything. Of course on dev mode you just add a <script> tag.

One bad thing with requirejs is that for a large project with a lot of modules. In the unbundled mode or dev mode. The requirejs script that is importing and resolving all the dependencies takes maybe over 10s to load all the modules and that being on a local computer not a remote server.

Requirejs also requires people to learn AMD and how to setup a requirejs project. This is a pain point for many devs, especially for non-experienced ones. Just to configure the requirejs config file is pain for many devs.

I guess many think browserify being the solution to these problems.

The right thing to do is to split code and only load what you need at startup, ideally avoiding execution of factory functions until they are required.

I guess with factory functions you mean function(require, exports) { ... module code ... }?
Doesn't a reasonable project runs all the factory functions? Why import/load something you don't need? And if all the factory functions are being run. I don't see any big difference having them run at the beginning(browserify) as opposed to having them run spread out(requirejs).

[csnover]

I'm not sure if it makes sense from a workflow view. Compile TS(ES6 modules) -> JS(AMD modules) and then use requirejs to bundle everything.

Sorry, which part does not make sense?

Of course on dev mode you just add a <script> tag.

If you are setting things up correctly, dev and prod are exactly the same except either require.js or your main module become a built layer in prod.

The requirejs script that is importing and resolving all the dependencies takes maybe over 10s to load all the modules and that being on a local computer not a remote server.

Hm, you might want to check your local server configuration, 10s is a crazy amount of time! Where I work we routinely develop apps with hundreds of modules using AMD and a full reload takes only a few seconds at worst.

(In any case you could always run a server that resolves and bundles your dependencies on-the-fly, like Browserify.)

Requirejs also requires people to learn AMD and how to setup a requirejs project. This is a pain point for many devs, especially for non-experienced ones. Just to configure the requirejs config file is pain for many devs.

I am sure some inexperienced PHP devs would also complain that without register_globals it’s a pain to receive data from incoming requests but that doesn’t mean the simpler solution was not totally wrong :)

I guess I am just a bad person/leader but I don’t have sympathy left in my body for people trying to create apps that think it’s too hard to write <script src="requirejs/require.js" data-main="app/main"></script>, which is all you need to do in most cases. Inexperienced devs can use a boilerplate.

Doesn't a reasonable project runs all the factory functions?

Yes, a reasonable one does, but a project that compiles everything including optional functionality to one file replacing module imports with object references as described herein would not be so reasonable. :)

Why import/load something you don't need?

Exactly! :)

(Also, sorry, this seems very off-topic at this point.)

[tinganho]

Sorry, which part does not make sense?

With JavaScript you write your code and add a <script src=""> to your HTML resource and it runs. I think most people expect the same thing with TS, after the transpiling part of course. With TS and AMD support. You would need add <script src="requirejs/require.js" data-main="app/main"></script> and you would need to setup your app/main in order for it to run your application. This is not trivial?

I guess I am just a bad person/leader but I don’t have sympathy left in my body for people trying to create apps that think it’s too hard to write <script src="requirejs/require.js" data-main="app/main"></script>, which is all you need to do in most cases. Inexperienced devs can use a boilerplate.

And then in app/main you need to write your requirejs configurations and figure out the initial import of your main and also call some functions or methods of the imported modules. And then in production you would need to replace the <script src="requirejs/require.js" data-main="app/main"></script> with the bundle <script src="bundle.js"></script>. Again not so trivial.

Hm, you might want to check your local server configuration, 10s is a crazy amount of time! Where I work we routinely develop apps with hundreds of modules using AMD and a full reload takes only a few seconds at worst.

In my experience a bare minimum setup and a decent amount of modules for a large app like 30 modules. Takes maybe 3-4s. You lose your programming context just waiting for these extra seconds.

Yes, a reasonable one does, but a project that compiles everything including optional functionality to one file replacing module imports with object references as described herein would not be so reasonable. :)

I'm not sure I follow this?

[tinganho]

@csnover I'm just curious how many extra ms do we lose just running a few extra factory functions? Isn't it negligible?