I believe it’s been so long since my last blog post, I forgot I even had a blog 😅
Well, A LOT has happened since then, I switched two jobs, learned a TON of new stuff, faced a burnout and SO much more but I believe that deserves a blog of its own.
Even though I wasn’t writing on my blog, I was still tweeting whenever something came to my mind, (by the way if you are not following me there, you should, I tweet cool stuff sometimes 🤷♂️)
So After all this time, I’m writing this post to answer the question that has been bugging me for a while that I saw on a tweet a while ago. It’s more of an opinionated rant but I believe someone out there might have similar thoughts and maybe find it useful.
I’ll try to post more of these rants & opinions consistently in the future. but hey, No promises 🤞
You must have seen the above code snippets once in your life and must have wondered Why One over the Other
Well today, let’s answer this once and for all
Brief History of ESM Modules
As per the MDN docs , ESM modules were introduced in ES2015 and were a part of the ES6 specification.
The ESM modules were introduced as a standardized way to import and export modules in JavaScript. They were designed to be a standardized way to import and export modules in JavaScript.
Fast forward to now, if you’ve ever worked with any Modern JS Frameworks like React, Angular, Vue, Svelte, or Solid, all of these rely on ESM modules.
The above snippet is in react based but you can achieve the same in any framework. What we are doing here is we are lazy loading the module and only loading it when it is needed. This is very effective performance-wise but I’m going off-topic here and this doesn’t concern our syntax-related debate. Sorry for that 😅, Moving on.
1. Tree shaking and small bundle size🌲
Show the above code to any engineer who worked with a bundler and he will immediately point out that the module pattern is far better because of “tree shaking”,
which results in a much smaller bundle size which is very important especially if you’re working in a frontend environment as you want to ship as little JS to the client as possible so the browser can quickly load and execute which increases performance.
This is very effective as you’re only bundling and shipping the code that is being used in your application instead of importing the entire module and all of its methods when you are only using some of them.
Tree shaking is particularly helpful in scenarios where you’re using a large number of third-party packages.
2. Readability and developer experience
So the destructuring syntax while importing a module takes the win for bundle size, but when it comes to readability, things become a bit more complicated.
You might have heard this quote before, but I’ll put it here for the sake of completeness.
Beauty is in the eye of the beholder.
Well, this shit doesn’t apply to code Because everyone has their own opinion on what ensures good code readability and maintainability.
In my last job, our team loved encapsulating functions inside a HUGE object and then exporting it. This is a very common pattern in JavaScript and solves some very common problems.
My favourite is, you can use any name for a function and because it is localised to the object that you are exporting, you don’t have to worry about naming collisions.
As you can see, the same function names are in the same file, with no conflicts. So Cool.
If you want to achieve the same by using modules and you would have to do something like this.
Also if you are a VS Code user, both approaches will give you the same autocomplete suggestions so +1 to both of them.
But personally, because I hate naming things, I prefer the second approach so I don’t have 1 extra name to think of for my exporting object and I can just add a namespace like getSubscribedCustomers to my function and be done with it.
But for a large item that wants its developers to follow one specific naming convention, the point for better DX and maintainability goes to the dot-notation approach.
3. Destructuring Function Parameters and Return Values
Until now, we’ve only talked about importing and exporting modules, but what about the functions and basic control flow? Look at the code snippets below and Ask yourself which one you find more readable
Both functions take an object, one destructures the properties and the other doesn’t.
An argument with the first example is that it loses the context of the arguments i.e. we don’t know where it came from and what is the significance of it. But in my opinion, if you provide a clear name that describes the action of the function, it does not matter.
Like in the above example, if I named my function something generic like formatData Then, maybe the dot syntax makes more sense.
Similar case is when you destructure properties or methods that you know you have to use multiple times in your code, but you don’t know what they are called, so you have to use the dot notation to access them.
But if I am getting a good intellisense in my IDE, then It won’t make much sense to use the dot notation
The definition of good and bad in the above code snippets can easily be interchanged depending on the context and preferences of your team.
I realised that there are two kinds of coders in the world,
Those who write understandable code for themselves
AND
Those who write code that is understandable by others.
You have to decide which one is you
Phewwww 😥, This small rant has gone a bit longer than expected.
Did I miss any scenario, What is your opinion on this? Please tell me on Twitter.
Until Next time,
Happy Debugging Coding👋