[HN Gopher] The Web-Interoperable Runtimes Community Group
       ___________________________________________________________________
        
       The Web-Interoperable Runtimes Community Group
        
       Author : jgrahamc
       Score  : 60 points
       Date   : 2022-05-09 13:06 UTC (9 hours ago)
        
 (HTM) web link (deno.com)
 (TXT) w3m dump (deno.com)
        
       | AaronO wrote:
       | Aaron from Deno here. I'm glad to see this come to light and very
       | much looking forward to developing and strengthening foundational
       | Web APIs underpinning modern JS runtimes such as Deno &
       | Cloudflare Workers.
       | 
       | Happy to answer any questions you may have !
        
       | jitl wrote:
       | Cloudflare's post on the same community group:
       | https://blog.cloudflare.com/introducing-the-wintercg/
       | 
       | @jgrahamc would you consider merging/rebasing Workers on Deno or
       | another runtime once these APIs converge?
        
         | jgrahamc wrote:
         | I think that's really a question for kentonv. But I think it's
         | hard to imagine us doing that. We are pretty heavily invested
         | in our runtime and know how to make it work in our very large
         | environment. And I think having multiple, open source run times
         | is ultimately good for everyone.
        
           | kentonv wrote:
           | Right. The APIs are actually the place where the different
           | runtimes are most similar to start with -- most of the APIs
           | implemented by Workers were standards taken from browsers in
           | the first place. The Workers Runtime is hugely different from
           | other runtimes under the hood, and has been intentionally
           | designed that way to meet the needs of our product and
           | network. We couldn't plausibly switch to another runtime.
        
           | jitl wrote:
           | Gotcha, reasons make sense and thanks for the reply!
        
       | pimterry wrote:
       | This looks really cool! Very excited to get closer to universal
       | JS for some of these APIs.
       | 
       | What's your plan for handling this in cases where there's
       | existing divergence? Is there general enthusiasm for breaking
       | changes in server-side frameworks to fix that and create
       | consistency? It is much easier to do on the server than in the
       | browser, but still painful...
        
         | lucacasonato wrote:
         | I think you need to categorize divergence into two parts:
         | 
         | a) Divergence in implementation on the same API surface (e.g
         | setTimeout in Node) b) Divergence in API surface for a similar
         | implementation (e.g WHATWG streams vs Node streams)
         | 
         | The former is obviously much harder to change than the latter,
         | as the latter can be resolved by adding additional API surface.
         | I assume you are talking about the former.
         | 
         | This sort of divergence where implementation differs, but API
         | surface is the same is luckily pretty rare. The most prolific
         | example is setTimeout in Node. It's unclear how exactly the
         | Node project intends to deal with situations like these. It's
         | possible that this is something which can just never be solved
         | in Node, and it just sticks around as a "wart" forever. The
         | solution to compatible APIs for cases like this would likely
         | need to be a new API then. For async timers this could be a
         | promise based API like `Promise.delay()`.
         | 
         | There is unfortunately no "one size fits all" solution for
         | these problems though, which is why this CG exists. We're going
         | to try to categorize and come up with solutions to these
         | problems.
        
       ___________________________________________________________________
       (page generated 2022-05-09 23:02 UTC)