The historical claim, that default exports we're introduced for compatibility with CommonJS/Node, is not accurate. Default exports were introduced because ofte

The historical claim, that default exports we're introduced for compatibility with CommonJS/Node, is not accurate. Default exports were introduced because often a module wants to export a single value or piece of functionality. In such cases, in module systems where all exports are named, the author of the module and its consumer have to coordinate on some convention to indicate "this is the thing". For example, some languages choose the same as the file name (with fun casing consequences or conversions). Some choose a particular name like "t" (I've heard one of the MLs does this). Some don't have a convention at all and you have to consult the documentation for each import. When designing JS modules, we decided to bake in a single somewhat-privileged export name for these cases, "default", which gets nice syntax on both the export and import sides to help encourage ecosystem standardization and coordination. You can choose to deviate from it, in favor of your own convention. (It seems like the author prefers some kind of filename-converted-to-camelCase for their projects.) But do so being aware you're walking away from the ecosystem affordances and it will be unexpected for your consumers.