DEV Community

Cover image for Vanilla JavaScript doesn't make sense in real apps
Giorgio Boa
Giorgio Boa

Posted on • Updated on

Vanilla JavaScript doesn't make sense in real apps

I'm working as a consultant and with my team, we refactored a huge back-office application written by another company.

Analysis

JavaScript vs Typescript

First thing first we didn't have any APIs/project documentation, no unit/E2E tests and the whole project was in vanilla JavaScript. This problem caused an initial week of study of the code base and the domain.
Another pain was that JavaScript is an interpreted language and it fails in the browser when it's too late... with TypeScript we are able to catch errors during the build time, prevent a lot of bugs and with the Type Inference we can have a better documented application without any extra effort.

SSR vs SPA

This application was based on Next.js so with Server Side Rendering (SSR) architecture and this was another big mistake we noticed. As I mentioned before this application is for back-office users (not public available) so we didn't enjoy all the features of a SSR (SEO, etc. etc.) and we were struggling with slow page transitions, complex caching and server cost.
So for this particular use case a SPA is the right choice, fast interactions, caching capabilities and a better overall user experience.

Refactoring

From Next.js to React

We decided to migrate the project to React + Vite because Next.js framework is based on top of React ecosystem.
The most difficult thing was replace the router part.
We centralized all the navigation logic in one file and then we refactored this part with new React router methods.
All the refactor was an incremental activity, we moved files from the old code base to the new one, we added TypeScript for the reason we mentioned before and step by step, making sure to have an application that is always working, we completed the job.

Usually, we load the information to render through APIs so a good tip is to start JavaScript -> TypeScript conversion from them. With this first step, the rest of the work can be trivial.

Wrapping up

Here are some results of this refactoring:

  • it's cheaper because it's hosted a cloud Storage
  • less exception in production (❤️ TypeScript)
  • 35% faster than its predecessor (smaller bundle size)
  • CI/CD pipeline is 50% faster 🚀
  • the code base is easy to navigate and it's easier to implement new features

It was a long journey anyway benefits are massive.

You can follow me on Twitter, where I'm posting or retweeting interesting articles.

I hope this article inspires you, don't forget to give ❤️ if you like it. Bye 👋

Top comments (0)