Component workbench

Ron Northcutt Verified user

Head of DevRel

Appsmith

Code Once, Use Everywhere: A Developer's Guide to Centralizing Custom JS Tools

Imagine this: Alex, a diligent developer, is hard at work on a new web application. Over the years, she's come to rely on many popular libraries that make her development process smoother. They're like old friends, always there when she needs them. But as she dives deeper into her project, she realizes she needs that custom function she wrote a few months ago. It was a nifty piece of code that streamlined a specific task she often encountered.

She thinks, "No problem, I'll just pull it from that old project." But frustration builds as Alex sifts through folders, repositories, and files. Where did she last use it? Was it in the mobile app project or the social media integration for a customer? Time goes by, and she's still searching. She finds an older version of that function, but there is a better version in some project. She ponders rewriting the function but knows it won't be as optimized as the latest version.

Alex's situation isn't unique. Many developers find themselves in this predicament. They've crafted brilliant bits of custom code tailored to their needs, but reusing them becomes a quest in itself. These snippets, born out of necessity or innovation, often get lost in the vast sea of projects. In a world where she can effortlessly pull popular libraries with a simple command, why is reusing her code challenging? She thinks, "There has to be a better way."

Wouldn't it be nice if you could easily reuse your favorite bits of custom code over and over without having to sift through old projects or reinvent the wheel? Well, it's actually easier than you may think.

Want to jump right into it? We have a tutorial that tells you how to create custom JS libraries.

Creating your own libraries

Before we get into that, let's take a look at why you should even care. Whether you are a hobbyist who likes to create apps or a professional who writes code all day long, the fact remains that you will create thousands of functions and methods over time. You will develop your own style and preferred approach to solving the problems you routinely come up against. This means that you will likely adopt common strategies and techniques you love to use. 

On top of that, each time you use or cut/paste your code, you will likely improve it. As your skills advance, you will find enhancements and improvements that can extend your code's value. So, if you can create a collection of your own custom tools, you will end up saving your time and letting you improve your future projects. This also matches the common principles of good software engineering:

  • Staying DRY (Don't Repeat Yourself): One of the foundational programming principles, DRY emphasizes the importance of avoiding redundancy. By reusing JavaScript code, developers can ensure they're not writing the same code multiple times, leading to more maintainable and error-free code.
     
  • Standardization: Consistency is key. By standardizing code, developers ensure it's easier to read, understand, and modify. This benefits the original developer and anyone else who might work on the code in the future.
     
  • Sharing Code & Code Assembly: Developers can leverage existing code snippets or libraries instead of starting from scratch every time. This speeds up the development process and ensures that tried and tested code is being used.

So, Alex needs a good way to build, extend, and maintain her own personal library of reusable code.

NPM or Yarn - The Go-To for Many

Once we start discussing Javascript reuse, many people will immediately assume that NPM is the right way. Alex is very familiar with NPM and has a collection of libraries that she loves to use, but is that the right solution for her?

NPM (Node Package Manager) is a package manager for JavaScript, allowing developers to share and reuse code. On the other hand, Yarn is a fast, reliable, and secure alternative npm client. Most developers immediately think of NPM or Yarn when it comes to reusing JavaScript. These tools allow for the registration, sharing, and installation of modules or packages.

While both are powerful, they can sometimes be overkill, especially for developers who aren't looking to maintain an entire project. Alex isn't interested in sharing her personal tools with the world - they wouldn't necessarily be useful to other people, and she isn't interested in creating a project, managing potential bug reports, feature requests, or even code contributions. All she needs is a simple way to manage a standard set of tools from a single place and be able to use those in any project.

The Rise of CDN Tools for JS

Alex decides to use a different approach - she will manage her code in a Git repo and use a Javascript CDN (Content Delivery Network) service to make her personal code available across all of her projects.

CDN services for JavaScript are platforms that host and serve JavaScript libraries and frameworks. They allow developers to link directly to specific versions of libraries, ensuring faster load times and a reduced server burden. CDNs work by distributing content across multiple servers around the world. When a user requests content, it's delivered from the nearest server. For JavaScript, this means linking to a library hosted on a CDN in your HTML, ensuring it loads quickly regardless of where your user is located.

This is great for Alex because it is a faster and easier way to manage her common tools and code without organizing a more "formal" NPM package. It also means that her code will be loaded faster and take a slight load off of her application servers. Thats great! 

Now - which service to use?

A Deep Dive into CDN Options

The good news is that Alex has a ton of options here... the bad news is that she has many options. Which platform should she focus on using? You may already have a preferred option, depending on your organization or team. But, if not, here are some of the most popular and widely used options, along with the pros and cons of each.

JSDeliver 

JSDeliver is a free public CDN that hosts open-source projects. It seamlessly integrates with NPM and GitHub, allowing developers to link directly to any file in any repository on GitHub.

  • Best For: Developers looking for a fast and reliable CDN that has tight integration with GitHub and supports a wide range of open-source projects.
  • Pros: Fast, reliable, and supports NPM and GitHub.
  • Cons: Limited to open-source projects.
  • Cost: Free.
  • Licensing Model: Open source.

StaticDelivr

StaticDelivr is a free and fast open-source CDN that supports multiple repositories, including NPM and GitHub. It's a lesser-known option but offers reliable service and quick integrations.

  • Best For: Developers looking for a versatile CDN that isn't as mainstream but offers robust features and integrations.
  • Pros: Supports multiple repositories fast.
  • Cons: Lesser-known compared to others.
  • Cost: Free.
  • Licensing Model: Open source.

Traditional CDN

Most "traditional" CDNs, like Cloudflare, CloudFront, etc., can be used for JS hosting. However, most of these platforms have limits on Javascript-only hosting and expect you to use their service as part of your broader JS, HTML, and CSS needs.

  • Best For: Developers who are already using a CDN for other things.
  • Pros: Often has a low-cost or free option. Ideal if you are already using it
  • Cons: Usually not for JS-only hosting.
  • Cost: Varies.
  • Licensing Model: Varies.

A Great Choice for Developers

After looking around, Alex decides to go with JSDelivr. It is stable, widely used, and can be used for both her own libraries and popular NPM packages. It is really best for public or open-source projects, but that is fine. Her code is not proprietary or closed. Plus, it has a direct GitHub integration with lots of options. So she can get going immediately.

Alex blocks out an afternoon to create a new Github repo to hold all of her tools. She goes through her recent and favorite projects, grouping her best code into different files in the repo. Then, she creates a README for the repo with a JSDelivr link for each toolset and a description of what it is for. It's very simple and easy to do, and instantly gives her a central place to manage her favorite reusable code.

Best of all, when she makes an improvement to her code, it will be instantly deployed to all of her apps! She needs to be careful not to introduce breaking changes, but that's a relatively simple thing to keep in mind for her own use. 

Want to see a real-life example? Check out the Foundry repo that we use to share our own libraries: https://github.com/appsmithorg/foundry

What about you? Do you have any code you like to reuse and share?