Design forces:
- ECMAScript (ES) Module Loader API is coming. The ES module ID syntax are strings that are just treated as string IDs and not paths.
- Existing JS module experience in CommonJS/Node/AMD worlds of using module IDs that are resolved to a URL/path for fetching.
- Better package managers are coming for front end web apps. These package managers install assets by IDs not by paths.
- For front end code,
baseURL + moduleID + '.js'
is likely the default ID-to-URL resolution, but other declarative config could be possible for browser-based ES Module Loaders. Examples of useful declarative config in this area are the problems solved via common AMD loader config
So it will be common in JS code to use string IDs, and not URLs to refer to dependency resources.
With the coming of web components and custom elements, it will be possible for a custom element to depend on other custom e