Things I learned while building my JS library

#webdev #javascript #beginners #programming

If you call yourself a developer, and you haven't created any library or thought about building one, my friend you haven't scratched the surface of being a developer.

While working on a personal project or in your company, you must have thought about making a library around those functions or components you are building repeatedly. And it makes sense too, according to the DRY (Don't Repeat Yourself) principle. But a lot of effort goes into making something that is useful and others also can use.

And building a library is not just about, bundling some functions or components together which are flexible and dynamic. There is a lot of thought goes into it like

API - Simple and easy-to-use functions, with IntelliSense in the editor
Bundling - Getting everything together into a single package or multiple packages, which can be easily used by you and your team.
Versioning - Tools to release and version your packages
Testing - Checking if there are any breaking changes and the application is working correctly. Maybe you can have a test app, where you deploy the changes to check if everything is working before releasing a new version. Or simply a jest or playwright test to check them in a CI/CD workflow through automation.

And then in the JS world, you also have to figure out things like

tree-shaking
side effects
ESM or CJS
code splitting
bundling dependencies
dev dependencies
peer dependencies
exports
modules
types (.d.ts files)
JS Docs or TS Docs
and many more...

These might look overwhelming to you but knowing these things is crucial for your career and in general as a developer. I will not go in-depth about what these things are in this article, maybe in the future but there are plenty of amazing articles about these on the internet.

However, all of these problems can be resolved with a bundling tool like, Rollup, Vite, and Webpack. Knowing what configuration will be required and how things will be working is the hard part. As that is the main thing, Nextjs uses Webpack, pre-configured to handle all of the bundling of their application, so that you won't have to.

Lately, they are also working on a new bundling tool, Turbopack which is written in Rust and I think they are claiming that it's backward compatible with Webpack but still, it's in alpha, so we will have to see. Vite is also working on Rolldown, a Rust-based version of Rollup. These updates and changes will not make sense to you as long as you are in the ecosystem.

As a JS Developer or any developer, you should know how to an environment without the need for any setup tools. As these tools are great for starting a new project but as soon as you will require something outside of this ecosystem, you are stuck.

Solving leet code questions, or any sort of competitive questions helps you to understand the core coding concepts. But building a library, and iterating over it helps you understand the concepts of your programming language, because different languages may have the same keywords or functions like while loop, for loop, variable declarations, and others. But their inner workings and performance will differ and this is how you become an expert in that language, by knowing these things. So that you can already see where your functions or applications might suffer in speed or performance.

This is true for any programming language, not just JS. The best part is, that you start to get familiar with all the tools and are more comfortable while using them. Making you faster and more efficient in building applications.

Building a production application or library is not easy. And the learning you get while building them on your own is far more than just watching it on Youtube or following a tutorial.

And I also, as an experienced developer have messed up a lot. Sometimes there were config errors and bugs in general, proper testing was not done before deployment, documentation website was not working properly. If the library has integration capabilities then, that might not be working properly, and the list goes on and on.

The thing is mistake happens, and that is what the learning is so that next time it doesn't happen. If you are using tools like nextjs or nuxtjs, then you need to build things like this. Because these tools are built to help developers build applications rather than stuck in setting things up, like Rollup or Webpack configs. Yes, these tools are amazing and do most of the stuff for you but big production applications are not just nextjs or nuxtjs, they comprise a lot of small/medium-sized libraries and applications built on Python (for AI maybe) and just React (Admin Panel). Then the need for a monorepo arises but you might not know what a monorepo is, because you have never come out of these ecosystems.

You can refer to this article, Things I Learned While Building My Component Library, where I have gone into more detail about the tools and libraries that my team and I use to build applications.

Conclusion

I learned a lot. From building better APIs and functions to libraries and publishing them on npm. It took me 6 months to complete all of this. And yes I know this sounds like a lot of time, but I had my fun. Building this gave me insight into what goes into building a library which others can also use and cherish.

I would say that if you haven't ever built a library, you should at least try to. The community is a great help, if you are stuck somewhere, some people can help you or also have fallen into the same problems, on which you can build.

Github, StackOverflow, and other online forms are great places to seek help and guidance related to your problems.

If you want to check out my lib from which I got all my learnings, here are the links -

@rafty/ui

GitHub - github.com/rhinobase/raftyui
Docs - rafty.rhinobase.io

Do let me know what you think about it and how we can boost the community in the future. Do show us your support by giving us a star and for more content like this in the future.

Top comments (10)

Mohammed E. MEZERREG • Mar 14 • Edited

At first, I had a lot to say. By the end of the article I just want to say:
Thanks for sharing this, since we are starting something like it. We were going through the existing UI components libraries thinking they use some sort of ready-to-use website generator like Docusaurus or something similar. To our surprise, most of them are custom-made websites (I am talking about the website where they present their components and docs). Some of them use Nextjs with their component library. Other, users custom-made websites Wow!
I thought they were insane to do that. Yes, they have the same design or layout which is a wise decision since the targeted users (developers) get used to that way of presenting a UI library. While I was thinking about it documented the steps we should follow to create something like that. I found it logical to go their path. Since you built everything yourself, why shouldn't you with the website to present your product?

Anyway, thank you very much for the article.

Aditya Mathur • Mar 14

Thank you. I'm continuously working on improving this UI library and would love to hear more suggestions on how we can enhance it to reach a wider audience. If you're interested, you can join our community Discord channel. Share ideas, collaborate with others, and contribute to the improvement of this project.

Thomas Leon Highbaugh • Mar 12

Great way to introduce the topic and design considerations for a library in a comprehensive bird's eye sort of way. Love addressing next.js as a useful tool but hardly an end-all be-all. Superb!