search

dherman / defense-of-dot-js

In Defense of .js: A Proposal for Node.js Modules
472 stars 14 forks source link

Counter argument #4

Open prettydiff opened 8 years ago

prettydiff commented 8 years ago

I have been thinking about this subject heavily as I have recently pulled my big personal project out of NPM.

In the current JS module ecosystem there are two primary problems:

  1. module specification
  2. open distribution

    module specification problem

The ES2015 module definition should be considered the ratified standard. This convention is in the specification with intention for adoption all environments where JS executes whether that be browser, Node, or other environments.

Common.js and Require.js are defacto standards that exist and are popularized in the absence of a formal standard. A formal standard is now present, and in coming months will become ubiquitous across the browser landscape. This satisfies both qualities that allowed the defacto approaches to achieve popularity, which suggests defacto approaches will be relegated to a historic status whose support is necessary for backwards compatibility.

The ideal approach for a resolution is to focus development and support upon the new standard and provide an abstraction layer in Node for dealing with synchronous require. An abstraction layer may very well kill the recent performance wins that came with Node v6.0.0, but it is still the most advisable approach for forwards compatibility. At some future time if legacy require should be killed simply remove the abstraction.

The cost benefit of the abstraction layer approach is that all of the risks and costs associated exist primarily in the present and not in the future, unlike a dual support approach. Just get this right the first time and then maintain it only as support for ES2015 module support in Node changes.

open distribution problem

Currently the defacto standard for distribution of JavaScript modules is NPM. The problems are that NPM is not completely open and it is limited to JavaScript. The web is, as a platform, completely open between the IETF and W3C and that platform is not limited to JavaScript.

My solution to this problem is to propose a URI scheme, module which can point to a module repository. Since this approach is based upon URI scheme it would allow universal uniqueness without conflict or assistance. Privacy is free. For private modules move the module repository behind your organization firewall. Since it would be based upon a URI scheme it would also be:

This is the first time I have disclosed the idea. I leave for Warrant Officer Candidate School next week where I will be without phone or internet and was waiting to work on this after graduation.

pitaj commented 8 years ago

Is this really a counter argument? The proposal within this repository is about how to best mark a module or file as standard compliant. Your proposal seems to be much more tangential, defining a package manager of sorts, as opposed to module system behavior.

prettydiff commented 8 years ago

@pitaj The proposal describes a module loading approach which uses a dual-technology mechanism to open access to ES2015 modules without breaking the current technology. Half my post countered this directly. The second half reasoned why modeling NPM for a module approach is less than ideal.

pitaj commented 8 years ago

Your post doesn't define any syntax or give any examples. Excuse my misunderstanding of what exactly you are talking about, but if I am misunderstanding you, it's because of that.

caridy commented 8 years ago

I feel the same, I don't see how is this related to this proposal. Seems way more broader than the simple problem we are trying to solve here, which is: based on what we have today (two parsers), how are we going to detect the right target in the context of node/npm, which is the existing ecosystem.