The Case for Component Libraries

Posted Apr 27, 2016

Guest post by Chris Bannon, Product Manager at Wijmo (an AngularAttack Partner)

Build vs. Buy

As a web developer, I want to be able to efficiently build applications. In order to do so, I need to have a well-structured application. In other words: a framework.

I have two options when beginning development:

  1. Write everything from scratch
  2. Choose an existing framework to build upon

I choose #2 almost every time. And in the rare occasion I choose #1, I end up with something that looks similar to a framework.

When you decide to not pick a public framework, you will end up with a framework anyway: your own. - Ryan Florence

Judging by the popularity of today’s JavaScript frameworks, it’s safe to say that picking a framework is a very common choice. We won’t get into the debate of which framework to choose. You can research those and come to your own conclusion. I often choose AngularJS, so let’s assume we made that choice.

Why did I choose to use AngularJS?

There’s one fundamental reason I choose a framework AngularJS: to save time.

I know from experience how long it takes to build everything from scratch, not to mention maintain it. I choose AngularJS, because I want to focus on developing my application immediately. Using a framework gives me the building blocks to start with instead of having to create them myself.

There are many other reasons to choose a framework, such as testability, maintenance, upgrading, and the fact that frameworks usually have a large number of very talented developers working on them. But really, the final benefit of all of those in the end is saving me time.

Remember, saving time is saving money.

How else can I save time?

Developing the user interface of an application can be very time consuming, even if I’m using a framework, and it’s become even more challenging with higher expectations from end users and the need to support so many browsers and devices.

Now I’m faced with the same question of “build vs buy”: only instead of a framework, now I’m considering UI components.

Again, I often choose to adopt an existing component set instead of making my own. I choose to use third party component sets for the same reason I choose to use a framework: to save time.

By choosing a UI component set, I can focus on building application screens immediately. If I were to build my own components, I’d need to invest time to create them before my application development could begin.

Here are additional reasons to use component sets:

  • Often already support many browsers and devices
  • Contain common features needed in most applications
  • Match modern style trends
  • Customizable to my needs
  • Get bug fixes as issues are found
  • Benefit from a large community of developers using the same components

Choose a basic component set

First, I choose a basic component set, sometimes referred to as a CSS framework. Many options are available, such as Bootstrap, Material Design Lite, etc.

For this example, let’s say I choose Material Design Lite.

A basic component set gives me the fundamental UI elements I need to begin development, such as:

  • Layout (including responsive design)
  • Styling HTML elements (headings, links, lists)
  • Simple UI components (button, dropdowns)
  • Navigation components (menu, tabs)
  • Form components (input, selects, checkbox, radio)

These basic components will save a tremendous amount of time in the short and long term.

Choose other UI components as needed

While a basic component set covers 90% of what we need, the last 10% can be the most difficult. These more complicated UIs should be considered as needed.

One example of a complicated UI component is a data grid. Grids are used in nearly every application, each requiring different scenarios (behaviors). For something like a data grid, using a third-party component is often a no-brainer. The amount of time it takes to research, develop, test and maintain a data grid is astronomical, especially if it’s done well.

When choosing a grid, I research all of my options including open source and commercial components.

Commercial components are sometimes overlooked because of cost, but I see a large number of companies choose them every day. Here are some reasons they choose commercial components:

  • Developed and maintained by a company with history
  • Customer support provided
  • Feature requests taken
  • Bugs fixed in a timely manner
  • Released on a schedule

An example of a commercial components is the Wijmo FlexGrid, a performance-focused grid with a small core and different features as optional extensions. It’s very flexible (hence the name) and can be customized to do almost anything. It also has built-in AngularJS support, so integrating it into a framework is already done. FlexGrid is a commercial product, but the cost of the license is more than justifiable in time saved.

If you’re interested in using the FlexGrid in Angular 2, you can learn more at

Save time, save money, start building

We choose frameworks to save us time, so why not choose UI components to save even more time? We have to choose how we want to spend our time. I prefer to leverage a framework and a UI component set so that I can begin building applications immediately. I hope you’ll try things like Material Design Lite and Wijmo to do the same!

Coming soon… Starter Template

We want to make it easier for you to get started in the Angular Attack competition. We’re putting together a Starter Template that includes a working Angular 2 app with Material Design Lite and Wijmo. Hopefully it’ll save you precious time during the competition. Keep an eye on the blog here to find out more.