7 ms·

CommonJS is hurting JavaScript

147 points by srwhittaker 3y ago

geenat 3y ago
The problem with Javascript modules = Everyone will be forced to run a full web server to do anything (to handle CORS restrictions). We all lose the ability to simply have a local index.html file, and have it Just Work (TM): <script src="script.js"></script> This ability is amazing for demos, fast iteration, onboarding new devs and developing without a ton of layers of js ecosystem machinery. Deno doesn't care about retaining this level of developer experience because Deno is marketing its own runtime / build step / ecosystem.
- postalrat 3y ago
  Is CommonJS even a thing for javascript running in web browsers? Moving from CommonJS to modules shouldn't affect any running in a browser.
  - recursive 3y ago
    Sure it is. I've used it via require.js. There were other ways too.
    - postalrat 3y ago
      Using require.js is your choice. CommonJS often isn't a choice.
- lucacasonato 3y ago
  If you are same origin, you do not require CORS to use type=module. Also type=module works on HTML pages served from file:// (file:///.../index.html).
  - caditinpiscinam 3y ago
    I just tried this and got "Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at file:///home/**.js. (Reason: CORS request not http)" in firefox
  - recursive 3y ago
    It is not possible to do same origin from a file system. Everything served from a file system is considered to be different origins. This drives me bonkers.
    - cxr 3y ago
      Because browser makers only have respect for the bourgeoisie and clear contempt for the proletariat.
- tredre3 3y ago
  > <script src="/js/anything.js" ></script> Shouldn't that be a relative path for it to actually work as you intend?
  - tracker1 3y ago
    It just needs to be browser resolvable, assuming this element is meant to run in a browser. So absolute paths do work. For libraries, you may want to use import maps or absolute urls (similar to Deno). There's also esm.sh and jspm.org for modules that are able to be relatively easily converted. I think it may be necessary/prudent to get some level of JSX support into browsers, much like the ts as comments efforts. Not sure how that will/would land. I was a pretty big fan of E4X, and had a prototype similar to React about a decade before it. In the end, who knows.
deleted 3y ago
[deleted]
tracker1 3y ago
Didn't see mention of Browserify and other bundlers after it that made CommonJS the defacto standard for client/browser libraries as well. I think the biggest miss was not making mixed mode (default) for Node do it the way webpack/babel, etc did it by default in terms of interop. I get they wanted to make it more implicit to call cjs from esm, in the end it just inhibits conversion of existing libraries as dependencies are now a bigger hurdle. Frankly, I like the Deno way of things better. I find it annoying, to say the least that the TypeScript team won't consider allowing you to import with a .ts(x) extension, and convert to .js(x) as part of the build process... no, you must omit the extension. I've been using the import/export syntax since well before it was standardized via babeljs, these days I kind of want to remove webpack/babel from my pipelines altogether and mostly just rely on esbuild. I've also been using/following rome.tools development, having switched over several projects from eslint already, and will probably start with their bundler when it's ready. I think there's a way to go with tree shaking and static analysis in that direction to reduce load. I also would not mind seeing the efforts to treat TS extensions as comments in the JS engines in that it would be easier to serve up straight TS/JS without bundling/minifying. I'm not sure we'll ever see a return to that in practical terms. In the end, it's evolving. I'd also like to see Cloudflare, Deno and others come together on a more common server interface so that you can target multiple clouds with a single codebase. I don't know how well that would ever work out at this point though. There's aspects that I definitely like to all of them.
- lucacasonato 3y ago
  Check out https://wintercg.org https://wintercg.org
- rektide 3y ago
  > I think the biggest miss was not making mixed mode (default) for Node do it the way webpack/babel, etc did it by default in terms of interop. I get they wanted to make it more implicit to call cjs from esm, in the end it just inhibits conversion of existing libraries as dependencies are now a bigger hurdle. Huge huge agreement. I forget the specifics but there was some super tiny corner case around maybe default exports that could potentially create ambiguity & that spawned a multi-year bellyaching around doing anything at all for interop. What Node got was incredibly hard fought for against much resistance to interop. But the final compromises made everything so much more painful for everyone. So many esm projects but oh look a .eslintrc.cjs, how unsurprising & sad. It's extra maddening because node had a wonderful just works (except that tiny tiny tiny corner case) interop via @standard-things/esm, which seamlessly let the two worlds interop. It'd been around for years before node started shipping support, and it was no ceremony just works bidirectional interoperability, and it took basically no effort or thought from the developers point of view to use. It sucked seeing us walk back from great, mired by frivolous over concern for a obscure corner-case. https://github.com/standard-things/esm https://github.com/standard-things/esm
taink 3y ago
I wouldn't go as far as saying CommonJS is hurting JavaScript, but it's current status in the node ecosystem is definitely painful. I mean the default remains CommonJS, so using esmodules is awkward on 'native' node, but if you use the most popular bundling systems, the default becomes esmodules. I won't pretend I know which is better between the two, but the decision should be made to either make it optional or deprecate it if esmodules is really the Best Module System™. The current in-between is far from ideal, that's for sure.
- deleted 3y ago
  [deleted]
revskill 3y ago
Wait, is ESModule something like async function esmodule(commonjsModule) { return new Promise((res, rej) => res(require(commonjsModule))) } ?
nailer 3y ago
Yep. I've started removing CommonJS support from my modules. I'm tired of wrangling JS development tools. ESM is the present, let's use it.
- deleted 3y ago
  [deleted]
rglover 3y ago
Shrug I think there should be more praise on these guys for what they accomplished given the state of JavaScript when they started. They saw a problem and came up with a solution. Was it perfect? No, but it's not this abominable creation. Much like John Resig's work on jQuery nudged JavaScript forward, so did the work on CommonJS/Node.
- deleted 3y ago
  [deleted]
  - deleted 3y ago
    [deleted]
- fndex 3y ago
  Quoting from the article: "In 2009, CommonJS was exactly what JavaScript needed. The group took a tough problem and forced through a solution that continues to be used millions of times a day. But with ESM as the standard and the focus shifting towards cloud primitives — the edge, browsers, and serverless compute — and CommonJS simply doesn’t cut it. ESM is a better solution for developers, as they can write browser-compliant code — and for users who get a better end experience."
  - rglover 3y ago
    This is what confused me in there (in the sense that the author seems to "get it" as to why CommonJS is still around). All of this ESM stuff has only (relatively) recently started to take shape. To say CommonJS is "hurting" JavaScript though seems overly-reactive. Technological evolution takes time and deep consideration to not create future messes. It's not the most comfortable but we're in the "messy middle" of moving from one to the other.
- montroser 3y ago
  Agreed -- the article actually acknowledges this point, but the clickbait title is not very generous. CJS was doing just fine in Node.js for nearly a decade before ESM came along and made everything more difficult by shoving browser constraints into a server-side runtime. ESM may be the right direction for the whole ecosystem in the long run, but it's a little backwards to say the perfectly good incumbent system is "hurting" the language because everyone who invested in it doesn't want to go through the pain of migrating to a new fashionable system that is worse in many ways.
caditinpiscinam 3y ago
I hope that more modules transitioning to ESM will eliminate the practice of exporting a single function with other functions attached as properties. Drives my crazy
davedx 3y ago
Clickbait headline
johnea 3y ago
> CommonJS is hurting JavaScript That's just not good enough, it needs to strangle, crush and bury javascript...
wwwigham 3y ago
I think this is funny, since esm being "native" on browsers doesn't really matter until you can convince devs they don't actually need to use a bundler. So long as you're using a bundler, the browser's runtime doesn't really matter - you're using the runtime the bundler presents and emulates on the browser. Native ESM has proven to be quite painful in ecosystems that _don't_ rely on the presence of a bundler to patch over problems, precisely because of the issues of interoping with, I don't know, _literally any existing code_. I can't think of a concrete benefit to a developer that ESM brings (just pain, but maybe I'm biased by what I'm exposed to). Probably why it's so slow to be adopted.
- deleted 3y ago
  [deleted]
- tracker1 3y ago
  I think it's still largely prudent to use bundler tools. I think the biggest issue with not going to ESM syntax comes down to static analysis and tree shaking. It's so much better with proper ESM, and will reduce overhead for the browsers. The bundlers definitely paper over various issues. Being able to import non-js resources like styles, json and other references is useful, to say the least. I don't think this will ever be really practical for direct browser use short of some generational compute and network improvements. That said, we aren't that far off. Many site are spewing several MB of JS on load, and it's relatively well performing even on modest phones these days. At least relative to 90's dialup where the rule on loads was measured close to 15s. Things are absolutely snappy (mostly). I think the biggest hurdle today is shear entropy. React+MUI+Redux is imo pretty great, and getting to something similar in pure JS would take a lot of effort. Not insurmountable, but significant. There's still a new framework of the month nearly every month in the JS space. Getting movement is hard. It'll take time and persistence.
- WorldMaker 3y ago
  I've seen some great development environments where all of development/debugging is unbundled ESM directly in the browser. It's going to take a lot of momentum shift to swing the "bundler pendulum" back away from "always" to "as needed" (or even, shockingly, "never"), but I think it is going to happen. HTTP/2+ really does make "never" a bigger possibility than ever before, especially in cases like MPAs (and SSR SPAs that don't mind slower hydration outside certain fast paths). Also, even some cases with bundlers, some of the modern bundlers (esbuild and swc) are still directly bundling to ESM now as the target. Lazy-loading boundaries and common/shared-code boundaries are just ESM imports and there's no "runtime emulation" there, just native browser loading at that point. They are just taking "small" ESM modules and making bigger ones.
deleted 3y ago
[deleted]
reactus 3y ago
Would anyone be interested in an article about the crusade to move JS to ESM? I've been considering writing one, here's a preview: Sindresorus wrote a gist "Pure ESM modules"[0] and converted all his modules to Pure ESM, breaking anyone who attempted to `require` the latest versions of his code; he later locked the thread to prevent people from complaining. node-fetch released a pure ESM version a year ago that is ~10x less popular than the CommonJS version[1]. The results of these changes broke a lot of code and resulted in many hours of developers figuring out how make their projects compatible with Pure ESM modules (or decide to ignore them and use old CommonJS versions)--not to mention the tons of pointless drama on GitHub issues. Meanwhile, TC-39 member Matteo Collima advocated a moderate approach dependent on where your module will be run [2]. So the crusade is led not by the Church, but by a handful of zealots dedicated to establishing ESM supremacy for unclear reasons (note how Sindresorus' gist lacks any justifications and how weak TFA's justifications are). It's kind of like the Python 2 to 3 move except with even less rationale and not driven by the core devs. 0 - https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3... 1 - https://www.npmjs.com/package/node-fetch?activeTab=versions https://www.npmjs.com/package/node-fetch?activeTab=versions 2 - https://github.com/nodejs/node/issues/33954#issuecomment-924824456 https://github.com/nodejs/node/issues/33954#issuecomment-924...
- rektide 3y ago
  ESM was a part of es2015. It's been 8 years that we've had to tangle with both cjs & esm. It's been absolutely awful for everyone. This crusade is nowhere near zealous nor righteous enough against the infidels & non-believers. But it also hasn't been effective enough at supporting/supplying the crusade either. Matteo's statement was that Node hasn't stabilized their loader support so tools have a harm time migrating to esm. Imo it's a pity ecmascript never stabilized a module registry, that esm 1.0 shipped & most people thought it would happen; it's long felt like a bait & switch. But it wasn't a feature browsers needed or really wanted so that unfulfillment was unsurprising. Anyhow, IMO Matteo is making a technical point that it's still hard to finish the move, which is a different spin IMO than a "advocated a moderate approach". Given the hurt we legitimately experience, I really wish Node and/or WinterCG or someone would prioritize figuring out & implementing whatever needs to go into a module registry/loader. And then beg the big tool chains that need this stuff to expedite their migrations, pretty pretty please.
attractivechaos 3y ago
I dislike CommonJS for a different reason: questionable "fs" module. This module mixes file I/O with file system accesses, which is confusing. More importantly, it does not provide line reading in a synchronous way. I sometimes work with multiple files simultaneously and need to control which file to read. It is awkward to do that with async APIs. Influenced by CommonJS, dart is similar. This ruins large text file processing. Most other languages can read a file line by line in a synchronous way.
notnullorvoid 3y ago
I agree that CJS needs to go, and the sooner the better. However it's slightly irritating hearing this presented on the Deno blog. Deno is no better when it comes to causing issues for library authors who want to provide cross runtime compatible ESM modules. They bundle their own fork of TS which lags behind TS stable, no support for important things like `typeVersions`, no way to test your library with newer (or older) TS versions. You're better off authoring ESM libraries for Node then telling Deno users to use `npm:` imports.
wdb 3y ago
The ESM-only packages like node-fetch are such a pain to work with in Node in a CommonJs project. I think this forced ESM is causing a lot vulnerabilities in code base due to the pain converting projects to ESM is. I am busy enough to try to get tests pass for some new version of a package that got ESM-only. Wished they would publish cjs and esm for packages that target Node. Fine you go ESM-only for browser only packages.
rickstanley 3y ago
Today I came across a dilemma. I wanted to somehow stub or fake Azure's Service Bus. There's no official way to do it. So, I came up with an idea to overwrite its implementation with my own, by mapping @azure/service-bus to my own class in tsconfig.json, no luck, because the framework that I use is using Webpack under the hood, so I would need to create a plugin, rule, whatever, to make it work, but I didn't want to write a specific configuration just for Webpack. Instead, I had another idea: to import @azure/service-bus dynamically, using ES dynamic `import`, in place of static imports. But, since I'm using Node.JS, I have to set the package.json type to module, so I can use top-level `await`, with dynamic `import` to import, with the help of a ternary, the correct implementation on the fly. I had a extremely bad experience trying to convert a CommonJS project to use ES Modules before. So I did not go through with the plan. Finally, after spending some time trying to not use CommonJS I gave up, and in place of dynamic import I used the "good" ol' `require()`, ending up with something like this: const { ServiceBus } = (isDev ? require('./my-service-bus') : require('@azure/service-bus')) as import('@azure/service-bus'); . And that was that. Project maintainers have to make ES Modules practical before it's pretty.
andrew_ 3y ago
The problem was never CommonJS. The problem was never ESM. The problem has always been, and continues to be, stubborn backward compatibility. Node is making the same mistake that Microsoft made with Windows, that Apple did not make with OSX - rather than letting go of a system that's been outgrown and forcing the userbase to grow, they cling to the old way and the old API, allowing it to ferment. This is the fault of the team working on Node and leadership making poor choices, including TC39.
pjmlp 3y ago
My workaround is to use Typescript.
_nalply 3y ago
There's an explosion of module types. Node has cjs and esm, Browser has legacy (create sub-objects in the global or window object) and esm. I tried to write a polyglot, but was not successful. https://stackoverflow.com/questions/48396968/72314371 https://stackoverflow.com/questions/48396968/72314371 proposes a clever polyglot exploiting that await is parsed differently at the top level when in esm or not. However this doesn't help, because import and export keywords always fail hard (not catchable by try-catch) and eval (yuck!) doesn't help because inside eval your are legacy. So you have to bundle if you want to provide for everybody... (shrugs)
nicolae_g_iotu 3y ago
My opinion is that a moderate approach is required, maybe a new solution needs to be discovered. I think ESM modules are most of the times desirable by developers of small to mid size packages. These developers want to have their packages used both on server and in browser. On the other side heavy duty packages which are able to generate production loads (see Fastify) should use CommonJS. In my opinion production loads should not have importable elements, stay private and rather just run and get the job done. At the same time it is really not that important for such loads to have good loading times for the micro packages used. This is debatable, but yet another aspect to consider: server side production loads must use CommonJS.
nicolae_g_iotu 3y ago
I just realized that programmers of production loads can quickly switch to ESM. Just perform a global replace of 'require' using 'import'. What's actually preventing this from happening is the fact that not all official packages are ESM ready. So the solution might be actually very easy. Set a deadline for the implementation of ESM and send frequent notifications to developers. After the deadline all those running production loads will have to switch to ESM syntax when updating. This seems facile and organized.
progx 3y ago
It hurts, it is an aboslut pain in the a... It is really time that this old tech dies and everybody converts their projects to ESM.
tamilvendhank 3y ago
Trying to reuse same code as it is written on both server and client is a bad idea. As a language, JavaScript may support loading from file system or web. But, one of its use cases must not be code reuse on both client and server. If I am to write a project in this way, how would it look like? Assume, I write some server code in a server project that I want to use in client as well. How would I access that code from client? I need to make it accessible over internet. But, that is in a project that has other code as well, some of I do not want to be accessed over internet. What do I do? I will write rules in my web server to only allow access to specific files. Here and beyond, this process becomes complex and will get only worse.
mikece 3y ago
[flagged]
- deleted 3y ago
  [deleted]
- deleted 3y ago
  [deleted]
- phailhaus 3y ago
  Microsoft made TypeScript instead, which has taken over the industry.
  - irrational 3y ago
    Which has taken over some parts of the industry. I work for a Fortune 100 company and Typescript isn't used widely at my company.
  - wheelerof4te 3y ago
    Not really an alternative to JavaScript, just an add-on.
- shadowgovt 3y ago
  Probably, but that didn't happen and here we are. JavaScript and the DOM are the language and API to manipulate page content, be it directly or as a compilation target. (Me, I use them as a compilation target, so arguments like the ones in this article are about as interesting to me as arguments about whether the security rings in the next iteration of CPUs are appropriate for modeling proper access constraints).
- blowski 3y ago
  > Heck, if MSFT had made VBScript available without license in browsers other than IE I think JavaScript would be an obscure footnote in history. And we’d be moaning about how bad VBScript is, and how we wish another language had won.
- politician 3y ago
no_wizard 3y ago
Does anyone have a detailed understanding of why CommonJS (and its async incarnation, AMD) were not adopted by browsers? I do much like the `import` syntax personally and its a little cleaner to read, but CommonJS and AMD were the undisputed winners of the module format until ES Modules were born. Not that I have a problem with ES Modules, I don't, however I am interested in what was so insufficient about the preceding formats that we couldn't have standardized on them EDIT: I know about the deal with CommonJS being synchronous. That isn't per se an issue I don't think, esp. because AMD built on top of CommonJS primitives, and with minimal refactoring CommonJS code could be used in the browser when defined this way if asynchronicity is a must. Generally, what I "imagine" browsers doing with CommonJS is making the `require` calls async in the background (IE non visible to developers) so they can resolve the modules then parse the code. This isn't terribly different from how import statements work today. I'm wondering why we didn't undertake the work to just improve the existing format, more or less. EDIT 2: I'm interested from a historical perspective. I think ESM is the right choice and 100% the future.
- bastawhiz 3y ago
  > and its async incarnation, AMD A bare-bones implementation of AMD could be put together with less than a kilobyte of JavaScript (this is what we used at Mozilla for a minute circa 2012). Meanwhile, the ECMAScript folks were working on ES6, which was going to have a module system. Why would the browser build in support for a highly-opinionated system that you could implement yourself so trivially, all while a TC39-blessed standard was in the works? > what I "imagine" browsers doing with CommonJS is making the `require` calls async in the background (IE non visible to developers) so they can resolve the modules then parse the code That's not possible. You need to run the code to know what's being required: if I call `require('./' + getModuleName())`, you don't know what's being required until `getModuleName()` is evaluated. So you actually need to start running the JS. You need to pause execution of the code calling `require()` (a la `alert()`), and then you can download and parse the required module. When the file is downloaded, you can parse and execute the imported module. Each file would need to be downloaded/parsed/executed _synchronously_ in the order that each `require()` happens in: it's only async in so far as the JS pauses execution and picks up later. > This isn't terribly different from how import statements work today. Not so. You can find and resolve `import` statements (note: not `import()` calls, though these return Promises) without executing a JS file. You can parse the imports out of a file in one pass and fetch/parse/repeat for each import in the dependency tree before anything starts executing. Since "native" imports are static and declarative, you can resolve all of them without ever executing any code. And any dynamic imports return promises that the programmer needs to explicitly handle the behavior of at runtime. > just improve the existing format 1. You'd have to kill dynamic imports (passing anything other than a string literal to `require()`, which would be impossible to do without breaking compatibility and couldn't be polyfilled. 2. AMD allowed a callback syntax for `require()` (it came out years before promises), which is cumbersome. Adding promises later would be challenging and leave technical debt.
striking 3y ago
That's all well and good, but what about those of us that already have a mountain of Jest tests with mocks that aren't supported in ESM mode? https://github.com/jestjs/jest/issues/9430 https://github.com/jestjs/jest/issues/9430 I've definitely worked around my fair share of CommonJS issues but until ESM "just works" I'm slightly pained by how aggressive the tone of this article is.
- olias 3y ago
  Use vitest.
  - striking 3y ago
    We're trying, we've had compatibility issues with node-canvas and our older version of graphql-js
- qbasic_forever 3y ago
  I did not perceive an aggressive tone from the article, I think you are projecting your annoyance with the Jest project and your architecture choices.
  - striking 3y ago
    I can't tell you your perception is wrong, but I generally don't unload ornate rhetoric like "insidious saboteur" or verbs that relate to strong imagery like "rip out", "bury" when writing about code unless I intend for my tone to be aggressive. My code works fine and the article isn't doing itself any favors by mocking me (heh) for thinking so.
- briantakita 3y ago
  Unfortunately, migrations are necessary when major releases occur. At some point, the argument to cling onto old tech which holds back the entire ecosystem needs to be deprioritized. Years have passed already so it should not be a surprise when the ecosystem moves on. Re mocks, an ecosystem should not be held back solely due to an arcane edge case. The apps that use test doubles can be rearchitected to support test doubles to the programmers' satisfaction. Most people do not use test doubles & the benefits of ESM & not having to deal with CJS outweigh the downsides of losing some convenience in mocking modules. This is something that will not be popular with clingers to CJS, but it is something that will benefit the wider ecosystem. The vocal minority which is holding back the ecosystem should start making plans to migrate because it is in the process of happening right now... So I think the general resentment is having to do extra work to support CJS which is not standard across all JS platforms...and some legacy libraries are still written in CJS requiring an interop. So it would be great to not have to do this extra work to support the legacy CJS on Node.js when every other JS platform is using ESM. In this case, one person's convenience comes at a cost to everyone else & at some point, that one person is going to have to suck it up & do the work to support his use case...just as everyone else had to do the work to support the legacy CJS for years now.
hyperhello 3y ago
I hate hearing this pirate corporation language about JavaScript. We know you want it to be C++. The rest of us need it to be BASIC.
- wheelerof4te 3y ago
  C++ is overrated. Use the crab language, instead. /s
jhp123 3y ago
the benefits of esm are not compelling enough to rewrite everything. Browser-native module loading is a niche use case which can never be as performant as bundling (even if per-request overhead is minimized in http2, a chain of dependencies will lead to excess round trips).
- cxr 3y ago
  > the benefits of esm are not compelling enough to rewrite everything. Your "everything" somehow doesn't account for stuff that wasn't written in NodeJS's standards-incompatible way to begin with.
- lelanthran 3y ago
  > the benefits of esm are not compelling enough to rewrite everything. It's rare that standards don't beat out non-standards in adoption. ESM is the standard; there is only one way this ends,and it's not in favour of CJS.
- klodolph 3y ago
  Bundling works better with ES6 modules. Compare the experience of using, say, browserify to rollup/esbuild. Plus, with ES6 modules, you can do bundling for your release builds, and do your development work directly with the original source files.
ineedausername 3y ago
I also want to hurt Javascript.
deleted 3y ago
[deleted]
wandering23 3y ago
[dead]
TeffenEllis 3y ago
I’ve managed several open source projects through their transition from CommonJS to ES modules and the least interesting part was the server-side of the equation. More often, the most exciting, and most excruciating aspect is wrangling TypeScript to emit browser friendly module paths. Anything short of relative paths everywhere won’t cut it, and TypeScript really doesn’t like to emit file extensions when TSX is involved. There’s also some unsolved mysteries surrounding the path resolution defined by a package.json file, but at least there’s now a proper way to have a package use project root relative imports. Things usually go well until you get back to the browser, which now needs an Import Map to bridge the two worlds. I still haven’t figured out how to wean off NPM either since all the magic compiling CDNs use its namespace to create browser friendly bundles…sort of where we started from. There’s a few foot guns on bundles now too, like deduping React so hooks work, along with some surprises about modules being stateful. And while Deno is pushing the dream forward, I can’t help but feel they compromised the vision too far for Node compatibility. At this rate, I could see Node v30 being a merge of the two projects. I’m honestly happy it’s all coming along. It seems like this is JavaScript’s Python 3 moment, where everyone has to rewrite code to slightly new paradigm for the next generation of apps to fully appreciate. I’m most thankful for async imports operating like ordinary Promises!
- mathiasrw 3y ago
  Im about to make the transition for alasql. Any chance you can share a link to a repo you feel did this well?
yafbum 3y ago
> I really think that the needs of server side code are different enough than the needs of client side code that we’re better off drawing from Python and Ruby than from Dojo and jQuery. This sentence sounds ok until Python and Ruby are held as the apparent gold standard of server development. That's not really the case, I think?
- AmpsterMan 3y ago
  I think the historical context is necessary. At the time, Rails was a thing and python was taking server space from Java, PHP, etc. They weren't looking to those languages as standards, but rather as languages that were likely to have similar problems.
- ilyt 3y ago
  Compared to JS it's hard to throw a rock and not hit something better than it... But I can confirm deploying Python or Ruby apps is generally bigger PITA.
- bdcravens 3y ago
  Thinking back to when CommonJS was implemented, absolutely. I don't think you'd want to call Spring or ASP the gold standards.
  - meepmorp 3y ago
    You know, now that I think about it, ASP might actually be the first example of a server side JS programming environment, kinda sorta. Nobody really did it, but you could use JScript instead of VBScript.
    - tracker1 3y ago
      There was the Netscape JS stuff, but I don't think it was nearly as popular as Classic ASP by 2000. I wrote a lot of ASP in JScript, was able to reuse validation libraries, etc for common inputs/forms which was nice at the time. I think the difficult points, were COM iterators were kind of alien feeling in JScript, and developing COM controls at the time were awkward and a real pain to debug/diagnose even in VS at the time. Not to mention, very little in the space of Classic ASP was open-source, free or even anything not insanely expensive from what I recall at the time. What was in the box was pretty much just JS and VBS, and most of what you could piece together was sluggish as all hell. Cool, you can use the spell checker from MS-Word... damn, three users tried to use it at the same time on the server. etc. I have some fond and nightmare memories from those days. I think in terms of before jQuery (though scriptaculous, prototype and others were cool), after jQuery and after Browserify and 6to5/Babel. The ESM transition is much, much slower going.
andrewmcwatters 3y ago
No, ESM spec writers are hurting productive developers. I literally never think about require or import, because they're not problems I have. But now, I get to fight importing dependencies with cancerous ESM design and think about language basics, while spec writers revert us all to CS 101 students trying to figure out how to do elementary things. Which isn't going to change any of my mature code, either, I'm going to wrap the entire script in: (async () => { })(); and then: const { default: foo } = await import('bar'); So, has anything meaningful changed? No. I don't need to tree shake on the server, and if you're tree shaking on the client-side, you've already screwed up, and you're too inexperienced to realize it.

147 points by srwhittaker 3y ago

The problem with Javascript modules = Everyone will be forced to run a full web server to do anything (to handle CORS restrictions). We all lose the ability to simply have a local index.html file, and have it Just Work (TM): <script src="script.js"></script> This ability is amazing for demos, fast iteration, onboarding new devs and developing without a ton of layers of js ecosystem machinery. Deno doesn't care about retaining this level of developer experience because Deno is marketing its own runtime / build step / ecosystem.

postalrat 3y ago
Is CommonJS even a thing for javascript running in web browsers? Moving from CommonJS to modules shouldn't affect any running in a browser.
- recursive 3y ago
  Sure it is. I've used it via require.js. There were other ways too.
  - postalrat 3y ago
    Using require.js is your choice. CommonJS often isn't a choice.
lucacasonato 3y ago
If you are same origin, you do not require CORS to use type=module. Also type=module works on HTML pages served from file:// (file:///.../index.html).
- caditinpiscinam 3y ago
  I just tried this and got "Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at file:///home/**.js. (Reason: CORS request not http)" in firefox
- recursive 3y ago
  It is not possible to do same origin from a file system. Everything served from a file system is considered to be different origins. This drives me bonkers.
  - cxr 3y ago
    Because browser makers only have respect for the bourgeoisie and clear contempt for the proletariat.
tredre3 3y ago
> <script src="/js/anything.js" ></script> Shouldn't that be a relative path for it to actually work as you intend?
- tracker1 3y ago
  It just needs to be browser resolvable, assuming this element is meant to run in a browser. So absolute paths do work. For libraries, you may want to use import maps or absolute urls (similar to Deno). There's also esm.sh and jspm.org for modules that are able to be relatively easily converted. I think it may be necessary/prudent to get some level of JSX support into browsers, much like the ts as comments efforts. Not sure how that will/would land. I was a pretty big fan of E4X, and had a prototype similar to React about a decade before it. In the end, who knows.

deleted 3y ago

[deleted]

tracker1 3y ago

Didn't see mention of Browserify and other bundlers after it that made CommonJS the defacto standard for client/browser libraries as well. I think the biggest miss was not making mixed mode (default) for Node do it the way webpack/babel, etc did it by default in terms of interop. I get they wanted to make it more implicit to call cjs from esm, in the end it just inhibits conversion of existing libraries as dependencies are now a bigger hurdle. Frankly, I like the Deno way of things better. I find it annoying, to say the least that the TypeScript team won't consider allowing you to import with a .ts(x) extension, and convert to .js(x) as part of the build process... no, you must omit the extension. I've been using the import/export syntax since well before it was standardized via babeljs, these days I kind of want to remove webpack/babel from my pipelines altogether and mostly just rely on esbuild. I've also been using/following rome.tools development, having switched over several projects from eslint already, and will probably start with their bundler when it's ready. I think there's a way to go with tree shaking and static analysis in that direction to reduce load. I also would not mind seeing the efforts to treat TS extensions as comments in the JS engines in that it would be easier to serve up straight TS/JS without bundling/minifying. I'm not sure we'll ever see a return to that in practical terms. In the end, it's evolving. I'd also like to see Cloudflare, Deno and others come together on a more common server interface so that you can target multiple clouds with a single codebase. I don't know how well that would ever work out at this point though. There's aspects that I definitely like to all of them.

lucacasonato 3y ago
Check out https://wintercg.org https://wintercg.org
rektide 3y ago
> I think the biggest miss was not making mixed mode (default) for Node do it the way webpack/babel, etc did it by default in terms of interop. I get they wanted to make it more implicit to call cjs from esm, in the end it just inhibits conversion of existing libraries as dependencies are now a bigger hurdle. Huge huge agreement. I forget the specifics but there was some super tiny corner case around maybe default exports that could potentially create ambiguity & that spawned a multi-year bellyaching around doing anything at all for interop. What Node got was incredibly hard fought for against much resistance to interop. But the final compromises made everything so much more painful for everyone. So many esm projects but oh look a .eslintrc.cjs, how unsurprising & sad. It's extra maddening because node had a wonderful just works (except that tiny tiny tiny corner case) interop via @standard-things/esm, which seamlessly let the two worlds interop. It'd been around for years before node started shipping support, and it was no ceremony just works bidirectional interoperability, and it took basically no effort or thought from the developers point of view to use. It sucked seeing us walk back from great, mired by frivolous over concern for a obscure corner-case. https://github.com/standard-things/esm https://github.com/standard-things/esm

taink 3y ago

I wouldn't go as far as saying CommonJS is hurting JavaScript, but it's current status in the node ecosystem is definitely painful. I mean the default remains CommonJS, so using esmodules is awkward on 'native' node, but if you use the most popular bundling systems, the default becomes esmodules. I won't pretend I know which is better between the two, but the decision should be made to either make it optional or deprecate it if esmodules is really the Best Module System™. The current in-between is far from ideal, that's for sure.

deleted 3y ago
[deleted]

revskill 3y ago

Wait, is ESModule something like async function esmodule(commonjsModule) { return new Promise((res, rej) => res(require(commonjsModule))) } ?

nailer 3y ago

Yep. I've started removing CommonJS support from my modules. I'm tired of wrangling JS development tools. ESM is the present, let's use it.

deleted 3y ago
[deleted]

rglover 3y ago

Shrug I think there should be more praise on these guys for what they accomplished given the state of JavaScript when they started. They saw a problem and came up with a solution. Was it perfect? No, but it's not this abominable creation. Much like John Resig's work on jQuery nudged JavaScript forward, so did the work on CommonJS/Node.

deleted 3y ago
[deleted]
- deleted 3y ago
  [deleted]
fndex 3y ago
Quoting from the article: "In 2009, CommonJS was exactly what JavaScript needed. The group took a tough problem and forced through a solution that continues to be used millions of times a day. But with ESM as the standard and the focus shifting towards cloud primitives — the edge, browsers, and serverless compute — and CommonJS simply doesn’t cut it. ESM is a better solution for developers, as they can write browser-compliant code — and for users who get a better end experience."
- rglover 3y ago
  This is what confused me in there (in the sense that the author seems to "get it" as to why CommonJS is still around). All of this ESM stuff has only (relatively) recently started to take shape. To say CommonJS is "hurting" JavaScript though seems overly-reactive. Technological evolution takes time and deep consideration to not create future messes. It's not the most comfortable but we're in the "messy middle" of moving from one to the other.
montroser 3y ago
Agreed -- the article actually acknowledges this point, but the clickbait title is not very generous. CJS was doing just fine in Node.js for nearly a decade before ESM came along and made everything more difficult by shoving browser constraints into a server-side runtime. ESM may be the right direction for the whole ecosystem in the long run, but it's a little backwards to say the perfectly good incumbent system is "hurting" the language because everyone who invested in it doesn't want to go through the pain of migrating to a new fashionable system that is worse in many ways.

caditinpiscinam 3y ago

I hope that more modules transitioning to ESM will eliminate the practice of exporting a single function with other functions attached as properties. Drives my crazy

davedx 3y ago

Clickbait headline

johnea 3y ago

> CommonJS is hurting JavaScript That's just not good enough, it needs to strangle, crush and bury javascript...

wwwigham 3y ago

I think this is funny, since esm being "native" on browsers doesn't really matter until you can convince devs they don't actually need to use a bundler. So long as you're using a bundler, the browser's runtime doesn't really matter - you're using the runtime the bundler presents and emulates on the browser. Native ESM has proven to be quite painful in ecosystems that _don't_ rely on the presence of a bundler to patch over problems, precisely because of the issues of interoping with, I don't know, _literally any existing code_. I can't think of a concrete benefit to a developer that ESM brings (just pain, but maybe I'm biased by what I'm exposed to). Probably why it's so slow to be adopted.

deleted 3y ago
[deleted]
tracker1 3y ago
I think it's still largely prudent to use bundler tools. I think the biggest issue with not going to ESM syntax comes down to static analysis and tree shaking. It's so much better with proper ESM, and will reduce overhead for the browsers. The bundlers definitely paper over various issues. Being able to import non-js resources like styles, json and other references is useful, to say the least. I don't think this will ever be really practical for direct browser use short of some generational compute and network improvements. That said, we aren't that far off. Many site are spewing several MB of JS on load, and it's relatively well performing even on modest phones these days. At least relative to 90's dialup where the rule on loads was measured close to 15s. Things are absolutely snappy (mostly). I think the biggest hurdle today is shear entropy. React+MUI+Redux is imo pretty great, and getting to something similar in pure JS would take a lot of effort. Not insurmountable, but significant. There's still a new framework of the month nearly every month in the JS space. Getting movement is hard. It'll take time and persistence.
WorldMaker 3y ago
I've seen some great development environments where all of development/debugging is unbundled ESM directly in the browser. It's going to take a lot of momentum shift to swing the "bundler pendulum" back away from "always" to "as needed" (or even, shockingly, "never"), but I think it is going to happen. HTTP/2+ really does make "never" a bigger possibility than ever before, especially in cases like MPAs (and SSR SPAs that don't mind slower hydration outside certain fast paths). Also, even some cases with bundlers, some of the modern bundlers (esbuild and swc) are still directly bundling to ESM now as the target. Lazy-loading boundaries and common/shared-code boundaries are just ESM imports and there's no "runtime emulation" there, just native browser loading at that point. They are just taking "small" ESM modules and making bigger ones.

deleted 3y ago

[deleted]

reactus 3y ago

Would anyone be interested in an article about the crusade to move JS to ESM? I've been considering writing one, here's a preview: Sindresorus wrote a gist "Pure ESM modules"[0] and converted all his modules to Pure ESM, breaking anyone who attempted to `require` the latest versions of his code; he later locked the thread to prevent people from complaining. node-fetch released a pure ESM version a year ago that is ~10x less popular than the CommonJS version[1]. The results of these changes broke a lot of code and resulted in many hours of developers figuring out how make their projects compatible with Pure ESM modules (or decide to ignore them and use old CommonJS versions)--not to mention the tons of pointless drama on GitHub issues. Meanwhile, TC-39 member Matteo Collima advocated a moderate approach dependent on where your module will be run [2]. So the crusade is led not by the Church, but by a handful of zealots dedicated to establishing ESM supremacy for unclear reasons (note how Sindresorus' gist lacks any justifications and how weak TFA's justifications are). It's kind of like the Python 2 to 3 move except with even less rationale and not driven by the core devs. 0 - https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3... 1 - https://www.npmjs.com/package/node-fetch?activeTab=versions https://www.npmjs.com/package/node-fetch?activeTab=versions 2 - https://github.com/nodejs/node/issues/33954#issuecomment-924824456 https://github.com/nodejs/node/issues/33954#issuecomment-924...

rektide 3y ago
ESM was a part of es2015. It's been 8 years that we've had to tangle with both cjs & esm. It's been absolutely awful for everyone. This crusade is nowhere near zealous nor righteous enough against the infidels & non-believers. But it also hasn't been effective enough at supporting/supplying the crusade either. Matteo's statement was that Node hasn't stabilized their loader support so tools have a harm time migrating to esm. Imo it's a pity ecmascript never stabilized a module registry, that esm 1.0 shipped & most people thought it would happen; it's long felt like a bait & switch. But it wasn't a feature browsers needed or really wanted so that unfulfillment was unsurprising. Anyhow, IMO Matteo is making a technical point that it's still hard to finish the move, which is a different spin IMO than a "advocated a moderate approach". Given the hurt we legitimately experience, I really wish Node and/or WinterCG or someone would prioritize figuring out & implementing whatever needs to go into a module registry/loader. And then beg the big tool chains that need this stuff to expedite their migrations, pretty pretty please.

attractivechaos 3y ago

I dislike CommonJS for a different reason: questionable "fs" module. This module mixes file I/O with file system accesses, which is confusing. More importantly, it does not provide line reading in a synchronous way. I sometimes work with multiple files simultaneously and need to control which file to read. It is awkward to do that with async APIs. Influenced by CommonJS, dart is similar. This ruins large text file processing. Most other languages can read a file line by line in a synchronous way.

notnullorvoid 3y ago

I agree that CJS needs to go, and the sooner the better. However it's slightly irritating hearing this presented on the Deno blog. Deno is no better when it comes to causing issues for library authors who want to provide cross runtime compatible ESM modules. They bundle their own fork of TS which lags behind TS stable, no support for important things like `typeVersions`, no way to test your library with newer (or older) TS versions. You're better off authoring ESM libraries for Node then telling Deno users to use `npm:` imports.

wdb 3y ago

The ESM-only packages like node-fetch are such a pain to work with in Node in a CommonJs project. I think this forced ESM is causing a lot vulnerabilities in code base due to the pain converting projects to ESM is. I am busy enough to try to get tests pass for some new version of a package that got ESM-only. Wished they would publish cjs and esm for packages that target Node. Fine you go ESM-only for browser only packages.

rickstanley 3y ago

Today I came across a dilemma. I wanted to somehow stub or fake Azure's Service Bus. There's no official way to do it. So, I came up with an idea to overwrite its implementation with my own, by mapping @azure/service-bus to my own class in tsconfig.json, no luck, because the framework that I use is using Webpack under the hood, so I would need to create a plugin, rule, whatever, to make it work, but I didn't want to write a specific configuration just for Webpack. Instead, I had another idea: to import @azure/service-bus dynamically, using ES dynamic `import`, in place of static imports. But, since I'm using Node.JS, I have to set the package.json type to module, so I can use top-level `await`, with dynamic `import` to import, with the help of a ternary, the correct implementation on the fly. I had a extremely bad experience trying to convert a CommonJS project to use ES Modules before. So I did not go through with the plan. Finally, after spending some time trying to not use CommonJS I gave up, and in place of dynamic import I used the "good" ol' `require()`, ending up with something like this: const { ServiceBus } = (isDev ? require('./my-service-bus') : require('@azure/service-bus')) as import('@azure/service-bus'); . And that was that. Project maintainers have to make ES Modules practical before it's pretty.

andrew_ 3y ago

The problem was never CommonJS. The problem was never ESM. The problem has always been, and continues to be, stubborn backward compatibility. Node is making the same mistake that Microsoft made with Windows, that Apple did not make with OSX - rather than letting go of a system that's been outgrown and forcing the userbase to grow, they cling to the old way and the old API, allowing it to ferment. This is the fault of the team working on Node and leadership making poor choices, including TC39.

pjmlp 3y ago

My workaround is to use Typescript.

_nalply 3y ago

There's an explosion of module types. Node has cjs and esm, Browser has legacy (create sub-objects in the global or window object) and esm. I tried to write a polyglot, but was not successful. https://stackoverflow.com/questions/48396968/72314371 https://stackoverflow.com/questions/48396968/72314371 proposes a clever polyglot exploiting that await is parsed differently at the top level when in esm or not. However this doesn't help, because import and export keywords always fail hard (not catchable by try-catch) and eval (yuck!) doesn't help because inside eval your are legacy. So you have to bundle if you want to provide for everybody... (shrugs)

nicolae_g_iotu 3y ago

My opinion is that a moderate approach is required, maybe a new solution needs to be discovered. I think ESM modules are most of the times desirable by developers of small to mid size packages. These developers want to have their packages used both on server and in browser. On the other side heavy duty packages which are able to generate production loads (see Fastify) should use CommonJS. In my opinion production loads should not have importable elements, stay private and rather just run and get the job done. At the same time it is really not that important for such loads to have good loading times for the micro packages used. This is debatable, but yet another aspect to consider: server side production loads must use CommonJS.

nicolae_g_iotu 3y ago

I just realized that programmers of production loads can quickly switch to ESM. Just perform a global replace of 'require' using 'import'. What's actually preventing this from happening is the fact that not all official packages are ESM ready. So the solution might be actually very easy. Set a deadline for the implementation of ESM and send frequent notifications to developers. After the deadline all those running production loads will have to switch to ESM syntax when updating. This seems facile and organized.

progx 3y ago

It hurts, it is an aboslut pain in the a... It is really time that this old tech dies and everybody converts their projects to ESM.

tamilvendhank 3y ago

Trying to reuse same code as it is written on both server and client is a bad idea. As a language, JavaScript may support loading from file system or web. But, one of its use cases must not be code reuse on both client and server. If I am to write a project in this way, how would it look like? Assume, I write some server code in a server project that I want to use in client as well. How would I access that code from client? I need to make it accessible over internet. But, that is in a project that has other code as well, some of I do not want to be accessed over internet. What do I do? I will write rules in my web server to only allow access to specific files. Here and beyond, this process becomes complex and will get only worse.

mikece 3y ago

[flagged]

deleted 3y ago
[deleted]
deleted 3y ago
[deleted]
phailhaus 3y ago
Microsoft made TypeScript instead, which has taken over the industry.
- irrational 3y ago
  Which has taken over some parts of the industry. I work for a Fortune 100 company and Typescript isn't used widely at my company.
- wheelerof4te 3y ago
  Not really an alternative to JavaScript, just an add-on.
shadowgovt 3y ago
Probably, but that didn't happen and here we are. JavaScript and the DOM are the language and API to manipulate page content, be it directly or as a compilation target. (Me, I use them as a compilation target, so arguments like the ones in this article are about as interesting to me as arguments about whether the security rings in the next iteration of CPUs are appropriate for modeling proper access constraints).
blowski 3y ago
> Heck, if MSFT had made VBScript available without license in browsers other than IE I think JavaScript would be an obscure footnote in history. And we’d be moaning about how bad VBScript is, and how we wish another language had won.
politician 3y ago

no_wizard 3y ago

Does anyone have a detailed understanding of why CommonJS (and its async incarnation, AMD) were not adopted by browsers? I do much like the `import` syntax personally and its a little cleaner to read, but CommonJS and AMD were the undisputed winners of the module format until ES Modules were born. Not that I have a problem with ES Modules, I don't, however I am interested in what was so insufficient about the preceding formats that we couldn't have standardized on them EDIT: I know about the deal with CommonJS being synchronous. That isn't per se an issue I don't think, esp. because AMD built on top of CommonJS primitives, and with minimal refactoring CommonJS code could be used in the browser when defined this way if asynchronicity is a must. Generally, what I "imagine" browsers doing with CommonJS is making the `require` calls async in the background (IE non visible to developers) so they can resolve the modules then parse the code. This isn't terribly different from how import statements work today. I'm wondering why we didn't undertake the work to just improve the existing format, more or less. EDIT 2: I'm interested from a historical perspective. I think ESM is the right choice and 100% the future.

bastawhiz 3y ago
> and its async incarnation, AMD A bare-bones implementation of AMD could be put together with less than a kilobyte of JavaScript (this is what we used at Mozilla for a minute circa 2012). Meanwhile, the ECMAScript folks were working on ES6, which was going to have a module system. Why would the browser build in support for a highly-opinionated system that you could implement yourself so trivially, all while a TC39-blessed standard was in the works? > what I "imagine" browsers doing with CommonJS is making the `require` calls async in the background (IE non visible to developers) so they can resolve the modules then parse the code That's not possible. You need to run the code to know what's being required: if I call `require('./' + getModuleName())`, you don't know what's being required until `getModuleName()` is evaluated. So you actually need to start running the JS. You need to pause execution of the code calling `require()` (a la `alert()`), and then you can download and parse the required module. When the file is downloaded, you can parse and execute the imported module. Each file would need to be downloaded/parsed/executed _synchronously_ in the order that each `require()` happens in: it's only async in so far as the JS pauses execution and picks up later. > This isn't terribly different from how import statements work today. Not so. You can find and resolve `import` statements (note: not `import()` calls, though these return Promises) without executing a JS file. You can parse the imports out of a file in one pass and fetch/parse/repeat for each import in the dependency tree before anything starts executing. Since "native" imports are static and declarative, you can resolve all of them without ever executing any code. And any dynamic imports return promises that the programmer needs to explicitly handle the behavior of at runtime. > just improve the existing format 1. You'd have to kill dynamic imports (passing anything other than a string literal to `require()`, which would be impossible to do without breaking compatibility and couldn't be polyfilled. 2. AMD allowed a callback syntax for `require()` (it came out years before promises), which is cumbersome. Adding promises later would be challenging and leave technical debt.

striking 3y ago

That's all well and good, but what about those of us that already have a mountain of Jest tests with mocks that aren't supported in ESM mode? https://github.com/jestjs/jest/issues/9430 https://github.com/jestjs/jest/issues/9430 I've definitely worked around my fair share of CommonJS issues but until ESM "just works" I'm slightly pained by how aggressive the tone of this article is.

olias 3y ago
Use vitest.
- striking 3y ago
  We're trying, we've had compatibility issues with node-canvas and our older version of graphql-js
qbasic_forever 3y ago
I did not perceive an aggressive tone from the article, I think you are projecting your annoyance with the Jest project and your architecture choices.
- striking 3y ago
  I can't tell you your perception is wrong, but I generally don't unload ornate rhetoric like "insidious saboteur" or verbs that relate to strong imagery like "rip out", "bury" when writing about code unless I intend for my tone to be aggressive. My code works fine and the article isn't doing itself any favors by mocking me (heh) for thinking so.
briantakita 3y ago
Unfortunately, migrations are necessary when major releases occur. At some point, the argument to cling onto old tech which holds back the entire ecosystem needs to be deprioritized. Years have passed already so it should not be a surprise when the ecosystem moves on. Re mocks, an ecosystem should not be held back solely due to an arcane edge case. The apps that use test doubles can be rearchitected to support test doubles to the programmers' satisfaction. Most people do not use test doubles & the benefits of ESM & not having to deal with CJS outweigh the downsides of losing some convenience in mocking modules. This is something that will not be popular with clingers to CJS, but it is something that will benefit the wider ecosystem. The vocal minority which is holding back the ecosystem should start making plans to migrate because it is in the process of happening right now... So I think the general resentment is having to do extra work to support CJS which is not standard across all JS platforms...and some legacy libraries are still written in CJS requiring an interop. So it would be great to not have to do this extra work to support the legacy CJS on Node.js when every other JS platform is using ESM. In this case, one person's convenience comes at a cost to everyone else & at some point, that one person is going to have to suck it up & do the work to support his use case...just as everyone else had to do the work to support the legacy CJS for years now.

hyperhello 3y ago

I hate hearing this pirate corporation language about JavaScript. We know you want it to be C++. The rest of us need it to be BASIC.

wheelerof4te 3y ago
C++ is overrated. Use the crab language, instead. /s

jhp123 3y ago

the benefits of esm are not compelling enough to rewrite everything. Browser-native module loading is a niche use case which can never be as performant as bundling (even if per-request overhead is minimized in http2, a chain of dependencies will lead to excess round trips).

cxr 3y ago
> the benefits of esm are not compelling enough to rewrite everything. Your "everything" somehow doesn't account for stuff that wasn't written in NodeJS's standards-incompatible way to begin with.
lelanthran 3y ago
> the benefits of esm are not compelling enough to rewrite everything. It's rare that standards don't beat out non-standards in adoption. ESM is the standard; there is only one way this ends,and it's not in favour of CJS.
klodolph 3y ago
Bundling works better with ES6 modules. Compare the experience of using, say, browserify to rollup/esbuild. Plus, with ES6 modules, you can do bundling for your release builds, and do your development work directly with the original source files.

ineedausername 3y ago

I also want to hurt Javascript.

deleted 3y ago

[deleted]

wandering23 3y ago

[dead]

TeffenEllis 3y ago

I’ve managed several open source projects through their transition from CommonJS to ES modules and the least interesting part was the server-side of the equation. More often, the most exciting, and most excruciating aspect is wrangling TypeScript to emit browser friendly module paths. Anything short of relative paths everywhere won’t cut it, and TypeScript really doesn’t like to emit file extensions when TSX is involved. There’s also some unsolved mysteries surrounding the path resolution defined by a package.json file, but at least there’s now a proper way to have a package use project root relative imports. Things usually go well until you get back to the browser, which now needs an Import Map to bridge the two worlds. I still haven’t figured out how to wean off NPM either since all the magic compiling CDNs use its namespace to create browser friendly bundles…sort of where we started from. There’s a few foot guns on bundles now too, like deduping React so hooks work, along with some surprises about modules being stateful. And while Deno is pushing the dream forward, I can’t help but feel they compromised the vision too far for Node compatibility. At this rate, I could see Node v30 being a merge of the two projects. I’m honestly happy it’s all coming along. It seems like this is JavaScript’s Python 3 moment, where everyone has to rewrite code to slightly new paradigm for the next generation of apps to fully appreciate. I’m most thankful for async imports operating like ordinary Promises!

mathiasrw 3y ago
Im about to make the transition for alasql. Any chance you can share a link to a repo you feel did this well?

yafbum 3y ago

> I really think that the needs of server side code are different enough than the needs of client side code that we’re better off drawing from Python and Ruby than from Dojo and jQuery. This sentence sounds ok until Python and Ruby are held as the apparent gold standard of server development. That's not really the case, I think?

AmpsterMan 3y ago
I think the historical context is necessary. At the time, Rails was a thing and python was taking server space from Java, PHP, etc. They weren't looking to those languages as standards, but rather as languages that were likely to have similar problems.
ilyt 3y ago
Compared to JS it's hard to throw a rock and not hit something better than it... But I can confirm deploying Python or Ruby apps is generally bigger PITA.
bdcravens 3y ago
Thinking back to when CommonJS was implemented, absolutely. I don't think you'd want to call Spring or ASP the gold standards.
- meepmorp 3y ago
  You know, now that I think about it, ASP might actually be the first example of a server side JS programming environment, kinda sorta. Nobody really did it, but you could use JScript instead of VBScript.
  - tracker1 3y ago
    There was the Netscape JS stuff, but I don't think it was nearly as popular as Classic ASP by 2000. I wrote a lot of ASP in JScript, was able to reuse validation libraries, etc for common inputs/forms which was nice at the time. I think the difficult points, were COM iterators were kind of alien feeling in JScript, and developing COM controls at the time were awkward and a real pain to debug/diagnose even in VS at the time. Not to mention, very little in the space of Classic ASP was open-source, free or even anything not insanely expensive from what I recall at the time. What was in the box was pretty much just JS and VBS, and most of what you could piece together was sluggish as all hell. Cool, you can use the spell checker from MS-Word... damn, three users tried to use it at the same time on the server. etc. I have some fond and nightmare memories from those days. I think in terms of before jQuery (though scriptaculous, prototype and others were cool), after jQuery and after Browserify and 6to5/Babel. The ESM transition is much, much slower going.

andrewmcwatters 3y ago

No, ESM spec writers are hurting productive developers. I literally never think about require or import, because they're not problems I have. But now, I get to fight importing dependencies with cancerous ESM design and think about language basics, while spec writers revert us all to CS 101 students trying to figure out how to do elementary things. Which isn't going to change any of my mature code, either, I'm going to wrap the entire script in: (async () => { })(); and then: const { default: foo } = await import('bar'); So, has anything meaningful changed? No. I don't need to tree shake on the server, and if you're tree shaking on the client-side, you've already screwed up, and you're too inexperienced to realize it.