Looking back instead of looking forward?

[robbie-mac]

Let me preface this with, I have never written a spec before in my life, and I have a tenuous grasp, at best, of this one. I'm trying hard to understand, but I'm confused as hell.

I have been watching the discussions of the loader, and the implications on node and the browser, and I would like to know why is the answer to so many questions about the loader, and by extension import and export, a reference to what is currently used and not to what could be? Why is facilitating Common JS and AMD JS such a priority? Why is it even being talked about? Same as browserify and jspm, and webpack and all the other package managers? They are what is, not what could be.

The fact that import and export are new language level instructions, they don't preclude continuing to use of all the libraries and processes and pre-processors, that we have been using. ES2015 modules are a shiny new way, the future way. Free from the need to be backwards compatible, because there hasn't been a previous implementation to break.

There seems to be a lot of answers like "system does it like this" or that library does that. Let me be clear I have nothing against System JS, its a fine library, I just don't think the spec should be written according to a library that is attempting to be a universal loader for Common JS and AMD JS and ES2015. If it is you just end up with a wrapper around Common JS and AMD JS and we call it ES2015 loader. That process will limit the thinking. At the end of this process we should have 3 independent module loading processes, that libraries can then implement in a universal loader. Or projects can choose 1, and not get the weight of the other two.

Lastly, with the major differences in environments (node and the browsers) why is the loader spec not just defining interfaces that the environments can implement a basic loader, or the end application developer can tailor to their own application needs? Why is it defining the entire pipeline implementation?

[caridy]

@robbie-mac if module a requires b and c, and b and c have to be ES standard modules, otherwise a can't be written as ES standard module, then a will likely be written in other format. We have the biggest ecosystem of JS code in npm, we have to support interoperability, otherwise no one will be able to adopt ES standard modules.

As for the second question, this spec is defining precisely that, a foundation for browser and node to build on top of. But if you have specific questions about it, just ask, and I will try my best to explain.

[matthewp]

Let me be clear I have nothing against System JS, its a fine library, I just don't think the spec should be written according to a library that is attempting to be a universal loader for Common JS and AMD JS and ES2015.

Why do you think that the spec is being written according to SystemJS?

Why is it defining the entire pipeline implementation?

Can't speak for the spec authors (i'm not one) but portability suffers if each environment implements loaders differently.

[robbie-mac]

Thanks for the quick reply guys, and sorry I have not gotten back to this as fast. I have a new baby in the house and he definitely demands some attention. @matthewp I haven't really zoned in on anything specific in the spec, but comments like the one referenced below (Sorry to pick on you @guybedford) are what I mean by looking back instead of looking forward.

133

his sort of thing can be done through a custom format loading with the loader hooks. In SystemJS the above method is provided via SystemJS.config({ meta: { 'app/*.json': { format: 'json' } } }).

It just seems to me that a clean slate approach will yield the best results for es2015, and then let loader libraries figure out how to tie them all together.

@caridy I guess the specific question would be this. If an application chooses to have a dependency that is commonjs or asmjs (however they get it, npm, or github or whatever) It should be their responsibility to asses the implications. Shouldn't it? When you think about the chaining of modules, if you have a dependency on a module that is on npm, won't all of its dependencies be the old dependence model? I may be getting just the tip of the iceberg but it seems the technical argument is that you have to transition seamlessly from new dep model, to the old model and maybe back again? I may be short sighted but I don't see this as an issue for this spec. Maybe for a library trying to tie them all together but even then, once you transition from the new model to the old, whats the chances of going back? If the module is old, then its dependencies would be as well. I think this spec should concentrate on the new model and only the new model. Thinking optimistically, wont this spur library authors to update to the new dep model?

As for portability, again, that can be an issue for libraries. Even then, if the interfaces are the same, the only difference will be speed. We already see that issue raising its head and being defeated. Look at native promises vs a library like bluebird.

If the interfaces are clear, and a reference implementation shown, that includes methods for replacing the reference implementation easily, without monkey patching, then as everybody learns more and the community at large updates the vast back library to es2015 (I am thinking optimistically here) then the spec wouldn't contain the cruft of commonjs and asmjs.

I guess what I am trying to say is we already have libraries like SystemJS, that claim to do it all (and in fact do to a certain extent) leave the awesome developers to do that (props to @guybedford ) and let this spec define a new method, unencumbered with the artifacts of old.

[b-strauss]

There are many things you can't do with ES2015 modules, or any other mainstream module system (Java, C#, etc.): module configuration, abstracting over modules, reentrancy, side-by-side deployment, etc.. All these things are really great if you have them, the problem is the Common/AMD ecosystem is huge. Introducing a new module system that is fundamentally semantically different from Common/AMD and is foreign to 99.9% of all programmers would be a huge mistake, even though it would technically be a better solution.

Languages that use these advanced features (e.g. newspeak) will remain a niche product for the foreseeable future. It should be the job of such research projects and/or academia to drive the field forward in this regard, not the job of a system that is as widespread as javascript and needs to work now.

[caridy]

@robbie-mac I'm getting mix feeling about your comments. We have designed the loader with EWM in mind, we will make sure that it is flexible enough for libraries and frameworks to seat on top of, just like my dear friend @guybedford (which is a big contributor of this spec) as done it. I wonder what make you think that this spec is doing things that libraries should be able to do? Every abstract operation in this spec is calling into implementation details that are not exposed to JS code. The hole point of exposing those low level primitives that enable others to do whatever they think is best. We are not saying that you, as a developer, are obligated to use existing modules, we are saying that if you want/need to provide interoperability with existing modules, you should be able to do it via the APIs that we are exposing in loader, and that's what reflective module records can do for you. I guess, if you has any concrete example of your concern, let us know, and we can try to explain in details. For now, I will close this issue since I don't see any action item, but we can continue the discussion here :)

[robbie-mac]

Introducing a new module system that is fundamentally semantically different from Common/AMD and is foreign to 99.9% of all programmers would be a huge mistake, even though it would technically be a better solution.

If there is a better solution, why not use it? Fundamentally, it was decided that commonjs and AMD was not getting the job done, that IMHO is why language level modules were/are neccesary. So why is the opportunity not bieng taken (or is it) to push the language and ecosystem forward? Its not going to break the current ecosystem, that can still be used just as it has been.

@caridy It wasnt my intention to step on peoples toes or to seem like I was insulting or calling out individuals like Guy. It was simply an example of what gave me the impressiin I had. That said, Its ok to have mixed feelings about my comments, in fact I think thats a good thing. Not because I want to alienate you (which I don't) it shows you are passionate about the product yiu have invested so much time in, and Im the new kid in the sandbox that is picking apart your sandcastle.

I know Im coming late to the party, and I also know that I dont have the chops to do a lot of this myself. I just think that there is this shiny new thing that is going to end up bieng a repackaging of the old stuff we already have. I realize that I may be way off base here, and wrong on so many levels. Thats why I asked the question. I want to learn and understand

[robbie-mac]

To take a step back, and revisit the thread I referenced. I now realize I totally misunderstood the answer. The answer is really saying that loader is bieng implemented in the way I hoped it would be, but the example used systemjs as a solution already leveraging it. Sorry guys, I completely misunderstood that one

[caridy]

🍻