40 ms·
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
by 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.