develwoutacause’s avatardevelwoutacause’s Twitter Archive—№ 1,284

  1. My understanding of the #JavaScript type syntax proposal is that the goal is to remove the #TypeScript compiler from the critical path of the edit/refresh workflow. But what if... browsers stripped types via an unofficial, non-spec, dev-only feature?🤔💭 devblogs.microsoft.com/typescript/a-proposal-for-type-syntax-in-javascript/
    On twitter.com Twitter logo develwoutacause’s avatar ♻️ 1 Retweets Mood 0
    1. …in reply to @develwoutacause
      Imagine setting Content-Type: application/typescript and the browser parsed the content as TS and removed all types (without actually checking them just like the current proposal). Devs would enable this feature via a flag in DevTools, just so TS doesn't leak into prod.
      Permalink On twitter.com Twitter logo develwoutacause’s avatar Mood +3 🙂
      1. …in reply to @develwoutacause
        This sounds crazy, but I can't think of a compelling reason why this is worse than the actual proposal. Browsers compete in developer tooling already and saying "Build with me because you can skip your compile step" is a great selling point for developers! 👨‍💻
        Permalink On twitter.com Twitter logo develwoutacause’s avatar Mood -2 🙁
        1. …in reply to @develwoutacause
          @Microsoft even owns @MSEdgeDev, they could prototype this feature right now and see if it is indeed a compelling feature to attract developers. The browser we develop directly on is going to have the least compatibility issues, so this is a win for Edge users too! 🌐
          Permalink On twitter.com Twitter logo develwoutacause’s avatar Mood +8 🙂
          1. …in reply to @develwoutacause
            This approach doesn't require standardizing wide swaths of TS syntax and doesn't require favoring TS at all! A browser could ship the same feature for #Flow, #Dart, #Elm, #CoffeeScript, or whatever the latest trend is. 📈
            Permalink On twitter.com Twitter logo develwoutacause’s avatar Mood +2 🙂
            1. …in reply to @develwoutacause
              TypeScript itself also doesn't get put in the awkward position where future features need to be compatible with JS type syntax, *and* they don't need to try and update old features to be compatible. 😎
              Permalink On twitter.com Twitter logo develwoutacause’s avatar Mood 0
              1. …in reply to @develwoutacause
                Main downside I can think of is that TS syntax is not stable and changes between versions. IMHO, this is a minor issue because breaking syntax/grammar changes are rare and browsers could support specific versions defined in the HTTP response. It doesn't need back-compat forever.
                Permalink On twitter.com Twitter logo develwoutacause’s avatar Mood -2 🙁
                1. …in reply to @develwoutacause
                  Also, as a non-spec DX feature, not every browser will be expected to support it, so your preferred browser might not. That kind of sucks, but is also the nature of competition. If it's a compelling and useful feature, lobby your favorite browser to adopt it! 👉📈
                  Permalink On twitter.com Twitter logo develwoutacause’s avatar Mood +4 🙂
                  1. …in reply to @develwoutacause
                    I'm struggling to think of a good reason why a proper spec for JS type syntax would be better than browsers implementing real TS syntax as a dev-only feature. What do you think? Anything I might be missing? Super interested to hear your thoughts. 🤔💭
                    Permalink On twitter.com Twitter logo develwoutacause’s avatar Mood +6 🙂