The Evolution of Frontend DX

How developer experience evolved over the time

Bhagya Vithana
UX Planet

--

Developer Experience (DX) is the feeling we get as programmers while developing applications. It could be both positive or negative.

However, over the years, new tools, techniques, and processes helped uplifting DX in many ways.

So, in this article, I will be focusing on frontend DX to understand how it evolved. And in the end, you will have a better understanding of the tools and techniques we should use in modern web apps.

Everyone Moved to SPA

Over the years, SPA’s have become the widely used pattern for web application development. It was further established with the introduction of frontend libraries like React and frameworks like Angular and VueJS.

With its wide adoption, creating an SPA today is relatively straightforward. For example, most of us use tools and frameworks to scaffold projects. And in a glimpse, you get a boilerplate code and a working application which you can test in a browser.

Your boilerplate would start in few seconds. But I’m sure most of us have experienced working with large applications that take much longer to build and execute.

This is bad in many ways since it directly affects DX and the DP (Developer Productivity).

There are way’s to overcome this particular challenge, which I will touch upon in future sections.

Besides the increasing complexities of applications, developers thought of writing better code and structure them appropriately. The libraries and frameworks like React, Angular, VueJS helped along the line, but it wasn’t enough.

Birth of Design Systems for SPAs

Then design systems came into the picture. It encouraged developers to follow a set of defined rules, styles and re-use components in their projects to maintain a clean development process.

If you are new to this area, I would recommend referring to Atomic Design by Brad Frost. It will establish the core concepts behind the design system in an elegant way. Whether to use it directly in practice? I will leave it up to you. 😀

With Design Systems, another good thing happened. New tools were born to visualize these elements of design. So it has given birth to a new paradigm called Component-Based Development.

Remember, I talked about finding ways not to wait till the large frontend code gets built? Yes. Let’s look at it in the next section.

Components Based Development (CBD)

Component-based development was introduced to modularize the frontend code. It also allowed building proper boundaries and communication between meaningful fragments in code.

Tools like Storybook were introduced based on this CBD concept, and it took frontend DX to a whole new level.

Develop components as separate stories using Storybook

In a nutshell, Storybook is kind of a playground where you can render your components within a SPA outside the application.

You get it as an NPM library as a dev dependency, which you can install in your SPA and start developing. However, you have to create a new file called <mycomponent>.story.ts or <mycomponent>.story.js inside each component, where you display the component’s usage.

Besides, it will render all the UI components as a library, interact with their properties and get an instant impression with hot-reload on the web.

Storybook examples for a button component

So all good, right?. Wait, things aren’t over yet. Storybook works well if you’re working on a monolith. But it is more challenging to use when working with microarchitectures, like micro frontends.

Which also introduces new concepts like Micro-frontends, Reusing components across projects &, etc. This is where the notion of Independent Components comes into play.

But, you might wonder, why not use NPM libraries to host your components, right? Well, it doesn’t work that way. Who wants to complicate things by having a longer cycle time. Remember, we are talking about DX improvements 😀 , not the other way around.

However, until recently, the challenge was the tools available to develop, test, share and use components outside the application monolith. With the open-source platform Bit, this has become a possibility.

Moving out from Monolith: Independent Components with Bit

Suppose you want a rapid and easy platform to develop and share components across your team. Bit offers a complete platform to share your components with other applications (or Micro-frontends).

It independently versions each component and manages the dependencies between these components as well.

It’s the exact pitch to allow each component to be versioned, pushed, and published separately.

Bit is also the sole tool available for CDD/CBD. It is the only practical way to construct and compose components.

The best way to understand Bit is to try it out. Since the concept is so novel, it becomes challenging for some of us to come out of our thinking pattern in terms of the monolith codebase.

Bit.dev home page

Let’s quickly look at some of the advantages of creating your reusable UI collection on bit.dev:

  • Ability to gradually refactor the UI and collect reusable components.
  • You don’t have to struggle and work hard just to set up your library.
  • It organizes and segments your components for you, making it super simple to find the ones you need in any situation.
  • You have a single portal where you can host, exchange, log, render, and install your components right away.
  • Bit provides tools to manage the entire lifecycle of component development to sharing across projects. Since you can install Bit components via NPM and Yarn clients, it works seemlessly with any JavaScript project.
  • Maintain perfect sync between Git repositories.
Bit.dev for reusable modular components

Final Thoughts

Good DX is all about being able to do your job instead of struggling with tools. The tools may be your developer environment, build tooling, hosting, or whatever APIs you’re interacting with.

Apart from the things I discussed, there are many tools and techniques used in modern web development, and it is easy to get lost among them if you don’t know the correct path.

If we look beyond the tools available at the moment, we can see the glimpse of faster build tools, online code editors, increased use of microservices in the near future.

So, it is essential to know to understand the current trends and what to expect beforehand to deliver the best for end-users and yourself.

Thank you for reading…!

--

--

Software Engineer| Technical Writer| University of Moratuwa| Faculty of Information Technology