It’s been about three years since the DEG UI team built its first website without the help of the jQuery JavaScript library. To the non-UI nerds out there, this might not seem like a big milestone, but for those of us whose work (and salaries) are tied to the latest developments in the JS world, ditching one of our industry’s most ubiquitous mainstays for the first time was like walking a tightrope without a net.

Related content: Using Sitecore’s Flexibility in UI Development

We weren’t alone. Around the time we first wrote about our big jQuery breakup, developers everywhere were championing ditching the monolithic, largely unnecessary library in favor of plain ‘ol JavaScript. Some even built reference sites to help ease the pain of going vanilla.

jQuery’s popularity has continued to sink dramatically over the last few years, despite the meteoric rise of JavaScript itself (not to mention the move toward more modern, nimble frameworks such as React, Angular, and Vue):

JavaScript library

We discovered we could still step out of the cumbersome world of third-party dependencies without abandoning the benefits of using versioned, reusable, and tested utility libraries and plugins.

But the world ain’t all sunshine and rainbows

Like any bad breakup, parting ways with jQuery was a breath of fresh air, but I’d be lying if I said we didn’t miss certain things about it:

  • DOM traversal in vanilla JavaScript is drastically better than it used to be, but it can still have its annoyances (i.e., finding parent elements before the closest() method was a browser-supported option).
  • Ajax calls (or more accurately, ajax calls before the simplicity of the Fetch API) are downright ugly to write.
  • Whether you love them or hate them, jQuery is well-known (some might say notorious) for its massive plugin ecosystem. Getting rid of core jQuery in our projects meant we also had to abandon using any and all jQuery plugins. Suddenly, adding something as simple as an accordion to a site meant we either had to build our own from scratch, or find a third-party plugin that didn’t have a jQuery dependency.

Coincidentally, this was around the time we also started using JSPM, a JavaScript package manager that allows developers to automatically install and configure any NPM or GitHub-hosted JS packages directly into their projects.

And that, boys and girls, is how DEGJS was born! With the help of a package manager on our side, it occurred to us that we could still step out of the cumbersome world of third-party dependencies like jQuery without abandoning the benefits of using versioned, reusable, and tested utility libraries and plugins.

The only difference was that this time, we’d be the creators and maintainers of these JavaScript libraries. That has turned out to be a decision that’s been incredibly beneficial to our development process and a huge learning opportunity—but it’s also fraught with its own challenges and frustrations.

What exactly is DEGJS?

At its core, DEGJS is nothing more than a GitHub account. Every repository in the account is comprised of JavaScript modules that are written and maintained by the DEG UI team. There’s a wide variety of plugins available in DEGJS, from simple low-level utilities to full-fledged plugins.

Some of the first DEGJS modules we wrote were actually small shims for missing or annoying-to-use native JS functionality, many of which we took for granted in our jQuery days. For example, jQuery’s .wrap() and .wrapAll() methods are beautiful abstractions of the somewhat lengthy bits of code needed to do the equivalent DOM manipulation in vanilla JS. To compensate for this, we added our own .wrapElements() method to our domUtils module, a collection of low-level DOM interaction utilities—but unlike the all-you-can-eat jQuery, these utilities can be individually imported into projects as needed.

But the fun didn’t stop with simple utilities. DEGJS also contains quite a few of the more robust plugins we use across many of our web projects, including tabs, accordions, overlays, and form libraries. Some of my personal favorites include:

  • dialogLoader: A rather clever module created by UI Engineer Anna Scheuler. This module allows you to use (and polyfill) the recently standardized dialog element easily and without worrying too much about its fairly limited browser support.
  • numericycle: Created by UI Team Lead Ryan Heap, this cool little plugin takes two numbers and smoothly animates between them.
  • formValidation: My pride and joy! As its kind of boring name implies, this is a modular, promise-based form validation plugin, free of third-party dependencies and built on top of native HTML5 validation.

There are quite a few more worth mentioning, but I encourage you to explore the GitHub page to see them all.

Using DEGJS within JSPM has become an incredibly powerful, yet easy-to-use, part of our day-to-day JavaScript workflow.

How it works

Each DEGJS repo is written as an ES6 module and structured to work with JSPM. What this means in practice is that if I’m working on a project that needs the aforementioned formValidation plugin, for example, I can simply type the following into the command line to install it:

JavaScript library
JSPM auto-magically downloads formValidation from DEGJS, as well as any of its own internal dependencies, which may or may not also be part of DEGJS. Once it’s installed, formValidation can be imported and used in any other JavaScript file in the project with a standard ES6 import statement, with JSPM also taking care of the necessary configuration, transpilation, bundling, and loading needed for it to be usable by the browser.

I’m oversimplifying things, of course, as getting this to work in our build tools wasn’t exactly trivial. But once we figured out how to configure it, using DEGJS within JSPM really has become an incredibly powerful, yet easy-to-use, part of our day-to-day JS workflow.

The good

Some of the benefits of using a self-curated JavaScript library might seem obvious: by building and maintaining your own plugins, you’re the master of your own codebase. Because it’s so easily installable via JSPM, project setup time has dramatically decreased, and development time for common components across projects has, for the most part, decreased.

But what we didn’t anticipate at the beginning of this undertaking are some of the more subtle, but no less important, benefits:

  • Building plugins allows you to experiment with cutting-edge web APIs and emerging standards and technologies. The most obvious of these is ES6, the latest iteration of JavaScript itself. But many plugins have also become excellent testing grounds for more experimental or lesser-know JS features, such as dialogLoader’s use of the useful but rarely seen MutationOberserver API. I personally built a rather basic data-store utility called TrapperKeeper on top of the new, yet underutilized Map Object standard, mostly just to try out this new technology.
  • Creating internal tools is an excellent opportunity for new team members! It helps them learn the team’s coding styles and best practices, and gives them a tangible way to contribute almost immediately to tools and build processes.
  • Thanks to GitHub, pull reviews help everyone learn. Any changes to a module are submitted for review by other team members, who then comment and make suggestions before the code is merged and published as a new version. This is an awesome learning mechanism for both the code contributor and the reviewer.
  • Likewise, JSPM’s reliance on Git’s tagging system allows us to (somewhat) effortlessly version our modules. Dependency management is handled for us and it’s rare that we even have to think about it.

Developing your own library of JavaScript tools can dramatically improved the way your team writes and delivers code.

The not-so-good

Even though our transition to DEGJS has been great, I’d be lying if I said there hasn’t been some turbulence:

  • Maintaining a code library is hard work! There’s the obvious time suck of actually writing the code, but if you’re considering creating your own JavaScript library, be sure to factor in the time it will take to test, review, create demos, and document. For some of our smaller modules, documentation and demos can take far longer to create than the module itself.
  • Plugins need to ride a very fine line between simplicity and flexibility. On the one hand, you want your plugin to be generic enough, with plenty of configurable options, to be useful across as many projects as possible. Then again, it’s also easy for the codebase to become so niche or obfuscated that it’s difficult for anyone other than its creator to see its benefits. Thorough, thoughtful documentation helps ease this pain.
  • Bugs, bugs, bugs. No matter how clean your code is, bugs happen, and they always seem to happen at the most inopportune times. This is a normal part of software development, and versioning makes this relatively painless to solve, but no one enjoys troubleshooting a plugin of their own creation when they’re trying to hit a deadline. This is where pull requests and code reviews can really be lifesavers.

Where we’re going, we don’t need roads

It’s hard to believe how much has changed in the JavaScript world since we parted ways with jQuery three years ago. Stepping out of our programmatic comfort zones and developing our own JavaScript library of tools has dramatically improved the way our team writes and delivers code, so much so that I think I’d barely recognize the code I was writing before this huge change.

This process hasn’t always been easy. It takes a lot of work—more than I think we realized at the beginning—to build and maintain your own coding ecosystem. But controlling your own destiny by way of the tools and processes you use can be very liberating. I’d never want to go back.

Want to create the best possible user experience for your customers? Our talented creative design and experience team can help.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Comments

  • Progressive Web Apps are Here and They’re Changing Everything

    Progressive Web Apps are Here and They’re Changing Everything

    8 months
    Reply
    […] Content: Building Your Own JavaScript Library for Fun and […]