The goal keeps moving though. If I need to process TypeScript files into JS to load them in the browser, why stop at modules and not just go ahead and link and tree shake and all that too?
Maybe things will settle down and browsers will actually run the code that web developers are writing, but the way things are going I don’t see that ever happening. Likely we’ll end up coding in any language and downloading WASM.
people do have other expectations like typescript. but whether we can meet the expectation of "this code should be a module that i can use or you can use or they can use" is much closer to the obvious "what-it-says-on-the-tin" definition of modules. and currently, without a lot of rewriting the module & it's dependencies, that goal is effectively impossible.
i'm not worried about fancy or more. i'm worried about the base case. and right now the base case is a no-go. it doesn't work. es6-modules have not brought modular modules to the web. it has failed to do it's most important goal.
can people with no tools, with no type-script, are they capable of using modules? if they require a bunch of tools to do so, i feel like the answer is that the web does not have modules. systems like import-maps begin to give consumers of libraries ways to assemble dependencies in a way that they can take off the shelf modules & plug them together on the web. until we see something like this, some way of sharing modules, the web platform does may have the language feature, but it has none of the benefits of modules that software-developers require to build systems atop even-mildly complex module graphs.
> can people with no tools, with no type-script, are they capable of using modules?
With a "modern framework"? Probably not. At least not with current documentation.
With everyone's classic "framework" Vanilla JS? Yes, absolutely. There's nothing stopping anyone. It's rather easy, and I've done it for small projects at this point.
There's one subtle change to the SCRIPT tag (type="module"), and new syntax to learn (if you haven't already learned it from Typescript or Babel), but that's it.
Sharing modules "just works" if you use what has always worked in SCRIPT tags: URLs. You don't need "import-maps" if you have URLs you trust (and "cool URLs don't change"), and Deno is exploring that as well as the way forward for "server side" applications as well that you can build complex dependency graphs solely on top of URLs.
Sure, "modern frameworks" are built on top of a house of cards of CommonJS (and sometimes still ancient AMD/UMD/weirder) dependencies, Node-style "bare" imports (imports by package name only, imports without file extensions, etc), npm package.json configuration and file meta (contributing to Node-style bare import complexity), and other issues. It would be a amazing if we could just rip the legacy code band-aid off and presto every "modern framework" would be ES2015 module native and just an `import framework from 'https://myawesome.framework.example/myawesome.js'` away. Deno has even pointed out that we can automate more of that (than we currently do) and move the "bunch of tools" to the the servers that serve the URLs, there could be a service out there for `import { React, Vue, etc } from 'https://oldworldnodetomodernmodules.example/modern-framework...'` doing all the hard "tool" work and bringing "people with no tools" to the same table, if that were something we cared about doing. (Just as web hosts like unpkg have helped a lot of SCRIPT tag only people able to use npm dependencies for years now.) (ETA: But again, that's useful for old code with legacy dependencies; new code could be entirely written with URLs as the "package manager" no sweat. URLs are just as capable of most of the complexity we put up with from npm.)
1) Module support in browsers. (Now ~92% per caniuse.)
2) Optional: Wide support for HTTP/2 in browsers. (Now ~95% per caniuse.)
3) Optional: Wide support for HTTP/2 in servers. I don't have good statistics on this one, but things feel "close" to ready.
(2) and (3) are desirous for performance, and we've known that all along as modules balloon the number of HTTP requests.
Maybe you also want to count super option (4) "smart HTTP ES module push preloading", but that seems unnecessary gilding to me.
> If I need to process TypeScript files into JS to load them in the browser, why stop at modules and not just go ahead and link and tree shake and all that too?
If you are outputting modules you shouldn't have to "link"; admittedly performance is still a concern, but that's what HTTP/2 (and/or HTTP/3) are supposed to help with.
If you are outputting modules rather than "linking"/"packing" you shouldn't have much to tree-shake and the browser will naturally tree shake in terms of simply not requesting modules outside of the execution path.
Just because you have a build step doesn't mean you have to "build all the things", and it shouldn't be a surprise and should be obvious that a type-checking-and-stripping only run of Typescript is faster than a Typescript+Webpack+Rollup+Terser or whatever stack.
> Maybe things will settle down and browsers will actually run the code that web developers are writing, but the way things are going I don’t see that ever happening.
That's an orthogonal issue, though. Does it matter that the browser is running code "exactly as authored"? Even then, Typescript outputting ES2015+ modules is more often than not just stripping types. The distance between ES2015+ and Typescript today is often minuscule. Typescript has been pretty focused on sticking to TC39 Stage 3 so even features that aren't currently supported by browsers are most often tomorrow's features (not "next decade's features").
Plus, Typescript even gives you the option today of moving all your type checks to JSDoc comments and running as a type-checker only and you can feed the JS directly to browser as is, if that really is a concern that you think the browser should be using the same files that you are writing. (But again, does that really matter? And also, that isn't stopping you from using ES2015+ modules today. It doesn't matter if you are using a Typescript build step or not.)
this deserves a good write up, because it's complicated.
it's not that hard to write a es6-module. it's pretty easy, and you can ask for it, and it'll work, behave like a ecmascript module in an ok way.
but. but if that module has other modules that it wants to pull in, the author of that module has to hardcode a bunch of assumptions about how & where that module that it depends on is. the module, in short, is not modular, because there's no way for users of that module to help it find the modules it depends on.
the best example of a work-around for this absolutely tragically-impotent pretty-much-useless es6-module system is dynamic rewrite engines like unpkg.com javascript cdn, which, on their home page mentions the ?module query parameter you can ask for. this will dynamically resolve & re-write all the dependencies of a module, to point to other unpkg.com modules. let me re-iterate: it has to re-write each module you ask for in a way where all of that module's depenencies are now also resolved unpkg modules, who themselves will also be rewritten such that their dependencies are also solved, & so on & so on, until the whole tree of modules is all rewritten to use unpkg modules. each module has to be rewritten such that there's now some kind of way to import dependencies. es6-modules provides no means to do that. each module has to resolve it's dependencies fully, ahead of time. so modules here are not actually modular: each host is left to copy, resolve, & modify the original module & make it their copy of the module, resolving dependencies however the consumer can figure out.
this is completely hosed & absolutely unbearable. modules are not modular. es6-modules are ok syntax, are ok language, but they are categorically useless on the web. it's truly tragic; es6-modules stopped while being only 33% of the way done. for what it's worth, import-maps is the only work anyone has suggested to resume progress & let modules work in any kind of inter-operable manner, & i have heard no good protest against it: i sincerely wish it would advance much much faster & be released so we can stop being stuck with terrible, unusable, non-modular modules on the web.
https://caniuse.com/es6-module