\textbf{Next.js}~\cite{NEXT.JS} is one of the largest projects on the web. It is used with React~\cite{React} to enable feature such as server-side rendering and static site generation.
\textbf{React}~\cite{React} is a graphical user interface library for JavaScript, which facilitates the creation of user interfaces for both web and native platforms. React is based upon splitting a user interface into components for simple development. It is currently one of the most popular libraries for creating web apps.
\textbf{Bootstrap}~\cite{Bootstrap} is a front-end framework used for creating responsive and mobile-first websites, and it comes with a variety of built-in components. This library is a good evaluation point for this thesis as it is written in ``vanilla'' JavaScript.
The ``Pipeline'' proposal is applicable to most files: the reason for this is that call expressions are widely used when writing JavaScript code. Our tool found matches in most files that Babel~\cite{BabelParser} managed to parse, and with manual evaluation transformations were performed correctly.
The ``Do Expression'' proposal is not as ``applicable'' as the ``Pipeline'' proposal: this means that the amount of transformed code this specification in \DSL{} will be able to perform is expected and proven to be lower.
This is because the proposal introduces an entirely new way of writing
expression-oriented code in JavaScript.
If the code has not used the current way of writing
expression-oriented in JavaScript,
\DSL{} is limited in the amount of transformations it can perform.
Nevertheless, our tool is able to identify matches where it is applicable, and by manual verification transformations are correct.
The imaginary ``Await to promise'' proposal also has an ``expected'' number of matches; however, we do not evaluate this proposal since it is not an official TC39 proposal.
Our tool demonstrates its capability to perform searches on large codebases,
to identify applicable code for proposals,
and to transform the code.
As can be seen from the tables above,
some of the proposals found zero matches
when evaluated on some of these codebases.
This is due to the fact that the developers of these projects
have not used the language construct the proposal is targeting.
Because of this,
no transformations can be performed.
This is especially apparent with the ``Do Expression`` proposal,
but also with the ``Await to Promise'' imaginary proposal.
This means that our tool's ability to perform transformations
depends on how widespread the adoption of the language construct targeted in a proposal is.
We can hypothesize that the amount of matches reflects the ``impact''
that design decisions made by the TC39 committee might have on established JavaScript projects and codebases.
We give examples of some of the transformations performed on these codebases in Appendix~\ref{appendix:b}.