supporting ES upgrading with a programming pattern repo?

Claus Reinke claus.reinke at talk21.com
Fri Nov 11 04:24:46 PST 2011


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/
 


More information about the es-discuss mailing list