<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 4/22/17 4:52 AM, Joshua Cranmer 🐧
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:5a31e3ae-e621-94df-5253-30d986ac674c@gmail.com">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <p>Now is perhaps as good a time as any other to start thinking
        about technical hurdles to preparing the modules of
        Thunderbird.next (or whatever name people wish to call it). Here
        are some things that we are likely to need to start to come to a
        consensus on before getting any serious headway in coding:</p>
      <h2>JS support and platforms<br>
      </h2>
      <p>Obviously, we need a minimum baseline to support all the
        platforms that we wish to support. </p>
    </blockquote>
    <p>We don't need to use the absolute newest features still
      stabilizing but there's little reason not to assume "latest". Most
      things can be transplined and polyfilled anyway if that turns out
      to be necessary for usage somewhere else.<br>
    </p>
    <blockquote type="cite"
      cite="mid:5a31e3ae-e621-94df-5253-30d986ac674c@gmail.com">
      <p>For a starting point, I think it makes sense to start with
        baseline of ES6, perhaps with async/await support. </p>
    </blockquote>
    <p>Well we definitely want all that. <br>
    </p>
    <blockquote type="cite"
      cite="mid:5a31e3ae-e621-94df-5253-30d986ac674c@gmail.com">
      <h2>Library fragmentation and sharing code</h2>
      <p>I don't know a good pithy name for this, but it's fairly clear
        I expect that everyone thinks we should be dividing the
        implementation into smaller modules/packages/etc. of some size.
        I think it's a good idea to set guidelines for where we expect
        these package boundaries to lie, and particularly on what we
        should do with those kinds of functions that might feel too
        low-level to ask for a dependency but crop up in many packages
        (base64 and email address manipulation come to mind).</p>
    </blockquote>
    <p>Using things from utility helper modules should be ok, but sure,
      it's a weigh off on when to just inline things.<br>
    </p>
     -Magnus<br>
    <p><br>
    </p>
  </body>
</html>