-
Just use JSR[0] and only deal with npm when a project forces you to do things backwards. Since JSR packages are available on npm, there's nothing lost.
[0]https://jsr.io/
-
InfluxDB
Purpose built for real-time analytics at any scale. InfluxDB Platform is powered by columnar analytics, optimized for cost-efficient storage, and built with open data standards.
-
IMO the game changer in your scenario is when type annotations are added as a standard JS feature:
https://github.com/tc39/proposal-type-annotations
At that point you'd be able to run your TS code directly without any transpiration necessary. I'd love to remove all the build process junk from my projects and have them run quicker.
-
Nest
A progressive Node.js framework for building efficient, scalable, and enterprise-grade server-side applications with TypeScript/JavaScript 🚀
And then here is one of the biggest backend JS frameworks (NestJS) clinging to CJS/holding off on migrating to ES modules. https://github.com/nestjs/nest/issues/13319
-
Before Node had any/experimental module support (April 2019, https://nodejs.medium.com/announcing-a-new-experimental-modu...), I'd been using std-things/esm loader for Node.js, which seemed to have no problem allowing CJS and ESM to interop, require and import each other. In my experience it worked flawlessly. https://github.com/standard-things/esm
It's wild to think about: esm has taken nearly a decade to be feasible for folks to use, without heavy encumbrance; it was the key feature of es-2015/es6!
It took many more years for import-maps to become a thing, such that we could start using modules in a modular fashion; we've had to use bundlers/codemods to re-resplve dependencies, unless you've been going to go Deno's original path of just hitting absolute urls wherever they be. There's still no standing proposal for how we get import-maps on service-workers & shared workers; modules still are not a ubiquitous feature of the core web & JavaScript ecosystems. 9 years latter.
-
Fwiw the github page for that proposal isn't linking to what seems to be the most recent discussion *. I thought type-annotations-as-comments was a no-brainer, but it seems messy. The Sept discussion shows that it is complicated by the current variety of annotation schemes (TypeScript is not the only one), and the parsing subtleties, which gave rise to unresolved questions about what is the basic motivation. bummer.
* https://github.com/tc39/notes/blob/main/meetings/2023-09/sep...
-
Barely a third of "high-impact" packages on npm are ESM. And that's with a generous definition of what an ESM package is. [1]
[1]: https://github.com/wooorm/npm-esm-vs-cjs
-
Go has the benefit of not having to reach a distributed consensus amongst a handful of individual browser vendors. Try compiling a large Go project with tinygo to get a glimpse of that experience [1]. If the browser vendors had been able to ship ES4 or ES5 with module support between 1999 and 2009, Node probably would have implemented it and there would be no dichotomy between CJS and ESM.
[1] https://github.com/evanw/esbuild/issues/1111
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
Bundler developer here: some bundlers (like Parcel) use esm imports within their generated runtime output to facilitate loading dynamic bundles.
It's a bit simpler (and I'd assume faster) than the traditional approach of dynamically creating a script tag at runtime.
Additional features like access to import.meta lets you get the path to the current script which also helps bundlers with resolving the paths to dynamic imports without requiring the developer to specify the base path explicitly.
There are problems though, for example you cannot retry an import() if the internet drops. The failed import is cached so the browser will fail the import again on retry, even if the connection is restored https://github.com/fatso83/retry-dynamic-import
-
On the flip side we have other amazing devs who are also active with cutting edge libraries and simply do the small amount of extra work to make their modules available in both ESM and CommonJS to this day:
https://github.com/WebReflection/uhtml
