In this blog post, I would like to show you how using JavaScript hurts your codebase readability and refactorability. I'll also share some tips for using named exports! export default I like to treat my code like a lump of clay, it's constantly evolving when as I add new features or change existing ones. Moreso, using default exports not only makes it harder, but it also adds a layer of complexity, especially with already existing code! Allow me to explain my reasoning! You can export anonymous functions and values The first major problem with default exports is naming. You have to think about naming the import every time you include it. Additionally, since it is possible to export anonymous values while creating a new function, you don’t need to think of a catchy name. Let's take a look at this simple JavaScript file: // cookies.js
export default () => {
  // baking 🍪 cookies logic
};

// app.js
import makeChocolateChipCookies from "./cookie.js"; You have no idea what your default exported function from does. Of course, you can peek into the implementation or count on documentation, but that adds more . It’s hard to tell from the jump what the function is supposed to do. cookies.js cognitive load That forces you to name that function in every place you want to use it. And naming things is hard. Maybe you wrote that function yourself, you know exactly what it's doing. But if you have a new team member joining, it's much harder for them to understand what this function is doing. That can also lead to other team members picking up different names when working on new features or refactoring existing code. And consistency and convention are key for high-performing teams! You can suggest a different name in the code review, but that’s adding that complexity that could be easily avoided in the first place by using named exports. It's awkward when importing all from a module JavaScript's import allows you to import everything from the module using syntax. And default export is just available under . import * as X default // app.js
import * as Cookies from "./cookie.js";

// usage - yikes
Cookies.default(); Of course, if you export one thing it's not that important as you most likely won't use . But you may want to group multiple things you import by module name for readability. import * as X While I really love grouping module functions, and I think it's really excellent practice for readability, it may not always be optimal for tree shaking and may increase your bundle size! Default exports and folder-based routing Frameworks like Next.js or Remix force you to use default exports to define components with folder-based routing. I'm not a big fan of forcing default exports in any case. TypeScript, at this point, still lacks some kind of support for "template" style exports, where a single file can export a predefined set of optional named exports in addition to the main default export. I would love to see something like that included in the language in the future, based on the popularity of previously mentioned frameworks. Using named exports Export each function individually, or export everything at once? The syntax allows you to use keyword before each function, type or value. export export function makeCookies() {
  // baking 🍪 cookies logic
} It's also possible to export multiple things at the same time: function makeCookies() {
  // baking 🍪 cookies logic
}

function eatCookies() {
  // eating 🍪 cookies logic
}

export { makeCookies, eatCookies }; I tend to prefer first approach as you clearly see whether the function you're reading is exported or not. Named export alias to the rescue When you really need to use a different name, named exports allow . named export aliases // cookies.js
export function makeCookies() {
  // baking 🍪 cookies logic
}

// app.js
import { makeCookies as makeCookiesWithStyle } from "./cookie.js"; Conclusion Even though we have ES2015 (ES6) for quite some time already, I see a lot of default exports in all types of applications. They were introduced for CommonJS interoperability, and there is no real reason to use them in the internal code. I hope this post will help you convince your team not to use default exports when it's possible. . Also Published here If you have some default exports refactoring horror stories, don't hesitate to ! share them on Twitter Resources List of resources I used when researching this blog post: https://developer.mozilla.org/en-US/docs/web/javascript/reference/statements/export https://blog.neufund.org/why-we-have-banned-default-exports-and-you-should-do-the-same-d51fdc2cf2ad Subscribe to my newsletter: https://buttondown.email/cichocinski

The writer is smart, but don't just like, take their word for it. #DoYourOwnResearch

Mozilla

Why Reading JavaScript Is More Difficult When Default Exports Are Used

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Using Destructuring and Inline Types Can Hurt Your TypeScript Codebase

10 Reasons Why Less Is More in Your init/deinit Methods

10 Best Practices for Every React Developer

10 Best Practices for Using Kubernetes Network Policies

12 Essential Coding Standards for Quality Web Development

Using Destructuring and Inline Types Can Hurt Your TypeScript Codebase

10 Reasons Why Less Is More in Your init/deinit Methods

10 Best Practices for Every React Developer

10 Best Practices for Using Kubernetes Network Policies

12 Essential Coding Standards for Quality Web Development

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps