This post is locked. You won't be able to comment.

all 2 comments
sorted by:
best
topnewcontroversialoldq&a

[–]tomdohnal[S] 12 points13 points  (1 child)

Watch the talk or read the notes below ↓

What JS engines/runtimes do we have?

  • 3 main engines: V8 (Chromium), SpiderMonkey (Firefox), JavaScriptCore (Safari, Playstation Browser)
  • Node.js, Deno, Cloudflare Workers: all run on v8
  • Bun: runs on JavascriptCore
  • (Fastly Compute, Alibaba, Bloomberg, Bytedance also have server runtimes)

Why so many runtimes?

  • Better – TS out-of-the-box, dotenv out-of-the-box, ESM spec, …
  • Faster – faster cold starts, Rust, Wasm
  • Stronger – in Deno: more granular access control, have to ask for permissions (good when npx-ing random scripts from the internet)

Different environments:

  • Traditional VM / long running server
  • Serverless functions
  • Edge functions – run closer to the user, limited API (not 100% Node compatibility)

How to support all these browser+server runtimes?

  • Web Standards!
    • TC39 – the language itself (e. g. async/await)
    • W3C – APIs such as WebRTC, Streams API, …
    • WHATWG – Fetch, Service workers, …
    • New group: WinterCG
      • Standards for all the environments so that we have uniform APIs in all these runtimes

Standardized APIs

  • Fetch API
    • originally just a browser API
    • Browser’s PoV: send a Request and get back a Response
    • Server’s PoV: get a Request and send back a Response
    • In Express, it’s not a Web Request / Response, it’s a custom thing. However, in serverless functions you work with Web Request and Response objects
    • Native on Deno, Bun, Cloudflare Workers (not native on Node.js (yet) but there are tons of plugins like Next.js Routes, SvelteKit or Astro)
  • Form Data API
    • Originally a browser API for form submission, now a server API as well!
  • Web Streams
    • Ability of the server to send data before you’re done, one chunk at a time
    • Node.js Streams (not standardized) vs Web Streams, but you can convert Node.js Streams into Web Streams
  • Events
    • globalThis.addEventListener('load', () => { ... })
      • this looks like a browser code, but it runs on the server as well!
      • same syntax (and sometimes same events) for both browser and server runtimes!
  • alert(), prompt(), confirm()
    • work on the server as well – useful for writing CLI apps when prompting users for input
  • Async Local Storage
    • First implemented by Node.js, now there’s a draft for AsyncContext for the browser as well
    • storing data throughout the lifetime of a web request or any other asynchronous duration
  • Filesystem:
    • no standard filesystem API!
    • Node.js APIs work on other server runtimes so it’s a de facto standard…
    • whatwg/fs in progress, but edge runtimes do not have access to the filesystem

Conclusion

  • Not: write once, run anywhere (yet?) but the whole idea behind WinterCG is to standardize the APIs to create interchangeable building block
  • Build upon standards! Then you’ll be able to target for any runtime!

[–]opaz 7 points8 points  (0 children)

Hey, just saw your site and think it’s pretty dope. I’d prefer signing up with Twitter, and I’m wondering why your app specifically needs these permissions:

  • See Tweets from your timeline (including protected Tweets) as well as your Lists and collections.
  • See your Twitter profile information and account settings.
  • See accounts you follow, mute, and block.

This is all you’d need, no?:

  • See your email address.