To keep this thread from getting off-track: I am talking about
patterns as a common ground between ES.next spec writers
and JS.current coders. Focusing on patterns now would help
to get JS coders involved in checking current proposals for
consistency/edge cases, instead of leaving that burden to
the spec editor alone.
Let me give an example of what I have in mind. I'll pick ES.next
modules because they are complex, new, and are documented in
a fairly accessible form already.
Joe Programmer has been using module loaders, following
certain code patterns, such as:
- just load a named module and use its exports, synchronously
- just load a named module and use its exports, asynchronously
- try loading common libs from CDN, fall back to local copies
- conditionally load polyfills for older browsers, selectively load
different code for mobile browsers
- load asynchronous file API, loop over exports to convert from
file operations from callback parameters to promises
- re-export (parts of) existing modules as a single module
(loop and filter, mix and match)
- ..
Joe Programmer likes to be ahead of the curve, so he wants to
know what ES.next modules mean for his coding habits. He finds
the ecmascript wiki, and the harmony namespace (isn't it time to
separate harmony from ES.next, btw?), and goes looking for
modules.
For most ES.next proposals, the first thing he sees is the spec-ese
(Joe prefers to learn JS, translated from ES in blogs, rather than
study the raw source), but he is lucky: the modules proposal
actually has examples and rationales! They don't seem to
address all his use cases, and he is beginning to suspect that he
will either have to keep his old module loader around, or use
ES.next module loaders and reified module objects, instead of
the nice and simple ES.next modules.
Joe is slightly confused by all this talk about compilation and
early errors: JS is a just-in-time language, so compilation happens
behind the scenes, right? And how can he catch those early errors,
to keep his clients from being exposed to "compilation errors"?
Is there a way to depend on the latest version of a module, but
fall back to a known-good version if the latest fails to compile?
Joe wonders whether he should join es-discuss, but he doesn't
read or speak spec-ese and ES.next is in the process of writing
out the spec. And finding answers to his specific questions in
the archives, with their torrents of back-and-forth snippets and
alternative design options, turns out to be difficult.
Meanwhile Steven Spec has been answering similar questions
by Jim Programmer, Jack Coder, and Doris Developer, and is
beginning to wonder whether there is an easier way to find
old answers and communicate about the new design and its
possible issues. And Ed Editor is having nightmares about
missing obscure feature interactions while turning proposals
into a coherent spec.
If Ed, Steven, Joe, Jim, Jack, and Doris could communicate via
a repository of code patterns, they might understand each other
well enough to talk to each other. Before the spec gets frozen.
And if failed design speculations get cleaned from the pattern
repository, we'd end up accumulating useful patterns for the
blog writers, when ES.next reaches stability and everyone has
to look into upgrading.
Claus
http://clausreinke.github.com
http://clausreinke.github.com/js-tools/
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
