Some notes after a few eventful weeks in JS land. Two key things have happened:
1) StackBlitz released two key projects:
a. Web Containers
b. Turbo - an in-browser npm client with amazing performance and app size benefits thanks to aggressive tree-shaking features.
This is astonishing work and immediately useful ( on stackblitz, in chrome… ). Running a node equivalent in service workers is already bad-ass, but the accomplishment of Turbo in reducing dependency library sizes is incredible and promises to shake up the npm client scene if it’s all true.
2) NodeJS 16 is shipping with Webcrypto bundled by default.
( bonus round )
3) Deno has shipped version 1.10
Continues to impress people with its approach to dependencies as uris. Deno is also an attempt to provide a fuller stdlib in the runtime than Node was and has broadly copied web apis, so the compatibility jank developers experience between node and the web is greatly reduced.
The technical benefit to Fission of these advances is obvious - ( assuming these things are successful or not technically fatally flawed somehow ) - we will eventually be able to run wasm, decent crypto and many ( but not all ) node applications in browsers both mobile and desktop as well as on servers and FaaS platforms as long as the platform we’re running on is modern, aka current browsers or NodeJS 16+.
The benefits to the developer ecosystem are also huge: Developers will care even less where their JS/TS/$whatever runs, and our heuristics of determining where compute happens can be simpler and more flexible, and mainly worry about things like “if I run this will it kill the battery of this device” instead of more complex questions like “is this compatible in the current runtime environment” or “I am in a remote part of Bali, where is the nearest compute I can find that will run this application at all”.
So this is great - we’re officially living in the future - what does this mean for the WebNative SDK?
It means we should be compatible in these places - compatible, reliable, almost transparent. We’ll have to do more work and more evergreen-oriented compat-checking tests to ensure we always just work, but the result of doing this difficult work is that developers building on the WNSDK can safely import us and use our apis and not worry about us.
Caveats
StackBlitz’ webcontainer && nodejs implementation, as impressive as it is, has some limitations that mean that many node applications will not work as-is:
Modules support is just a matter of time, and the issue of native binaries and npm postinstall scripts are things that can be either resolved or mitigated for most use cases ( eg just use wasm blobs for that instead of doing builds… ).
The issue of supporting other languages is likely just work for those interested, especially with projects like Deno which have arguably better dependency import properties wrt specifically the challenges of running in a browser ( or more specifically, a service worker! )
The webcontainer-core README however has this to say about networking support:
HTTP Networking
- We’re limited by the browser’s ability to make network requests, so connecting to processes like MongoDB, Redis, PostgreSQL, etc. are not currently possible. This may change as Chromium plans to ship Native Sockets in the future. For now, we’re limited to HTTP connections, but we’re able to support other protocols that run on HTTP such as WebSockets. HTTP requests to external services must be allowed with CORS or a CORS proxy.
This is a little terrifying, not the least of which because so much of what node.js scripts do is tcp networking. Sure, the bulk of this is likely over http / https, but I wonder about edge cases like websockets, let alone the availability of Chrome’s Native Sockets concept in shipping browsers on devices.
The future for Native Sockets looks just as grim as anything else new on the web: Chrome & Edge will likely adopt and ship, iOS will be mysterious about it for months, years, perhaps decades, and Firefox / Gecko is increasingly irrelevant in terms of total market share. Safari will likely be the main drag here in terms of delivering actual experiences to devices. Grim, hacky workarounds that abuse http will proliferate and cause compat problems. Everyone will run into TLS cert issues.
The pragmatic / webby approach of course will be to jam everything into websockets or other http protocols.