3 ms·

WinterCG: Web-Interoperable Runtimes Community Group

63 points by brianzelip 4y ago

brianzelip 4y ago
Listen to context about this (tl;dr, the growing number of deployment targets for modern apps/libs/frameworks) from the recent Syntax podcast. See the 27:01 mark, https://syntax.fm/show/496/supper-club-headless-ecommerce-with-shopify-s-josh-larson https://syntax.fm/show/496/supper-club-headless-ecommerce-wi....
josephg 4y ago
This is really important work to get things like WASM off the ground. Recently I've been working on a rust library I want to be able to run in the browser and from nodejs via wasm. But its way harder than it should be. Wasm-pack has a different target for nodejs and the browser for ridiculous reasons - like 'crypto' and 'WebSocket' being globally available objects in the browser but not in nodejs. And es modules working slightly differently in each environment. Npm is designed assuming packages will be isomorphic. I've ended up with separate -node and -web packages - which makes my code feel non-native. You shouldn't need to care that a JS package uses wasm internally. But these little points of incompatibility really hurt wasm as a target for libraries to use.
- zdragnar 4y ago
  NPM has always been node-first, and relied on tools such as browserify to make some packages more portable - bower was significantly more popular for front end development until it came around. CJS was node's solution to "modules" prior to ES modules, which was not interoperable with requirejs / AMD, the front end solution that came out of Dojo. UMD offered a way to have both, but was far too much boilerplate to support by hand, so it was mostly only adopted by libraries. CJS won out for a very short time, right up until import / export became available via webpack. This short window is pretty much the only time that "isomorphic" really applied to NPM; by the time import / export had gained enough steam (thanks largely to both webpack and typescript for jump starting adoptation), there were enough browser modules that trying to write truly isomorphic code was limited to certain subsets of your application. I imagine running isomorphic code under deno to be quite a bit less painful, as it was built from the ground up to mirror browser environments as closely as possible, but that's not much consolation if you still want to target node.
  - josephg 4y ago
    > This short window is pretty much the only time that "isomorphic" really applied to NPM Huh? Most npm modules still work fine in both browser and native contexts. Bundlers generally support CJS modules, and modern npm modules can use esm just fine too if you set the "type": "module" field in package.json. Even heavily browser based libraries like react usually work fine from nodejs too, to make server side rendering easier. Isomorphic npm modules should still be the default. I'll have to give deno a try. Node has increasingly diverged from the browser, and it causes real headaches.
- TheAceOfHearts 4y ago
  It has always been this way. The only reason many tools and libraries can switch between node and the web transparently is that tons of developers have put in a considerable amount of effort. The problem is that if you're using some node package in the browser that wouldn't typically be there, it'll need to be bundled for inclusion in the browser. Nothing about npm's design implies or particularly facilitates that packages will be isomorphic.
ricklamers 4y ago
This reminds me of the slogan of ISO: Great things happen when the world agrees
encryptluks2 4y ago
Appears to to be created in part by and for for-profit questionable companies. You know why everytime you go on the web your browser sends hundreds of identifiers and your device sensors send data without permission? Because almost all these groups are designed to push forward ideas and goals of for-profit companies that make you the target.
jgrahamc 4y ago
We wrote about this and our support: https://blog.cloudflare.com/introducing-the-wintercg/ https://blog.cloudflare.com/introducing-the-wintercg/

63 points by brianzelip 4y ago

Listen to context about this (tl;dr, the growing number of deployment targets for modern apps/libs/frameworks) from the recent Syntax podcast. See the 27:01 mark, https://syntax.fm/show/496/supper-club-headless-ecommerce-with-shopify-s-josh-larson https://syntax.fm/show/496/supper-club-headless-ecommerce-wi....

josephg 4y ago

This is really important work to get things like WASM off the ground. Recently I've been working on a rust library I want to be able to run in the browser and from nodejs via wasm. But its way harder than it should be. Wasm-pack has a different target for nodejs and the browser for ridiculous reasons - like 'crypto' and 'WebSocket' being globally available objects in the browser but not in nodejs. And es modules working slightly differently in each environment. Npm is designed assuming packages will be isomorphic. I've ended up with separate -node and -web packages - which makes my code feel non-native. You shouldn't need to care that a JS package uses wasm internally. But these little points of incompatibility really hurt wasm as a target for libraries to use.

zdragnar 4y ago
NPM has always been node-first, and relied on tools such as browserify to make some packages more portable - bower was significantly more popular for front end development until it came around. CJS was node's solution to "modules" prior to ES modules, which was not interoperable with requirejs / AMD, the front end solution that came out of Dojo. UMD offered a way to have both, but was far too much boilerplate to support by hand, so it was mostly only adopted by libraries. CJS won out for a very short time, right up until import / export became available via webpack. This short window is pretty much the only time that "isomorphic" really applied to NPM; by the time import / export had gained enough steam (thanks largely to both webpack and typescript for jump starting adoptation), there were enough browser modules that trying to write truly isomorphic code was limited to certain subsets of your application. I imagine running isomorphic code under deno to be quite a bit less painful, as it was built from the ground up to mirror browser environments as closely as possible, but that's not much consolation if you still want to target node.
- josephg 4y ago
  > This short window is pretty much the only time that "isomorphic" really applied to NPM Huh? Most npm modules still work fine in both browser and native contexts. Bundlers generally support CJS modules, and modern npm modules can use esm just fine too if you set the "type": "module" field in package.json. Even heavily browser based libraries like react usually work fine from nodejs too, to make server side rendering easier. Isomorphic npm modules should still be the default. I'll have to give deno a try. Node has increasingly diverged from the browser, and it causes real headaches.
TheAceOfHearts 4y ago
It has always been this way. The only reason many tools and libraries can switch between node and the web transparently is that tons of developers have put in a considerable amount of effort. The problem is that if you're using some node package in the browser that wouldn't typically be there, it'll need to be bundled for inclusion in the browser. Nothing about npm's design implies or particularly facilitates that packages will be isomorphic.

ricklamers 4y ago

This reminds me of the slogan of ISO: Great things happen when the world agrees

encryptluks2 4y ago

Appears to to be created in part by and for for-profit questionable companies. You know why everytime you go on the web your browser sends hundreds of identifiers and your device sensors send data without permission? Because almost all these groups are designed to push forward ideas and goals of for-profit companies that make you the target.

jgrahamc 4y ago

We wrote about this and our support: https://blog.cloudflare.com/introducing-the-wintercg/ https://blog.cloudflare.com/introducing-the-wintercg/