# Refactoring Legacy JavaScript Code to Use Classes: The Good, The Bad and The Ugly

## TL;DR

This paper examines the migration of legacy JavaScript code to ES6 class syntax, identifying straightforward, challenging, and impossible cases, and includes developer perceptions of the migration process.

## Contribution

It provides an empirical analysis of real-world JavaScript code migration to ES6 classes, highlighting common issues and limitations encountered.

## Key findings

- 75% of systems contain bad or ugly migration cases
- Many code structures require manual, ad-hoc migration
- Some legacy structures cannot be migrated due to ES6 limitations

## Abstract

JavaScript systems are becoming increasingly complex and large. To tackle the challenges involved in implementing these systems, the language is evolving to include several constructions for programming- in-the-large. For example, although the language is prototype-based, the latest JavaScript standard, named ECMAScript 6 (ES6), provides native support for implementing classes. Even though most modern web browsers support ES6, only a very few applications use the class syntax. In this paper, we analyze the process of migrating structures that emulate classes in legacy JavaScript code to adopt the new syntax for classes introduced by ES6. We apply a set of migration rules on eight legacy JavaScript systems. In our study, we document: (a) cases that are straightforward to migrate (the good parts); (b) cases that require manual and ad-hoc migration (the bad parts); and (c) cases that cannot be migrated due to limitations and restrictions of ES6 (the ugly parts). Six out of eight systems (75%) contain instances of bad and/or ugly cases. We also collect the perceptions of JavaScript developers about migrating their code to use the new syntax for classes.