The Race to ‘Hottest Reload’

Gaurav Goel
Sep 8, 2018 · 3 min read

One of the best things that happened to software development is hot reloading of code. Anybody who has worked long enough in the software industry must be aware of the pain of redeploying code. The pain is real. And it is not only the developers who face the heat, the employer gets their pockets burnt too. A silly mistake while coding combined with the hot reloads gave everyone a double whammy.

Visualizing the problem

To add context to the monetary blow, let’s do a trivial derivation.

  • Let’s assume that a considerable project took around 10 developers to build
  • Let’s also assume that the average cost of the developers wasRs. 6,00,000 per year which makes it Rs. 60,00,000 per year in all
  • Now that we’ve come this far, let’s also assume that a local redeployment used to cost ~5mins
  • Another assumption must be that active development involved around 4 redeployments per hour
  • Given that a developer works 8 hours a day, it makes it 32 redeployments per day per developer, and this costs 32 * 5 = 160 mins = 2 hours and 40 mins
  • So, ~2.5 hours per developer were wasted in redeployments, i.e. 30% of the development time or 30 % of Rs. 60,00,000 per year = Rs. 18,00,000

This may seem like an exaggeration, but for inefficient developers, these numbers were even higher.

Solutions

This was indeed a problem. A pretty evident one. Soon it gathered the attention of the problem solvers of the industry. People even have been able to monetize their solutions for the problem. Zeroturnaround was a company which introduced JRebel. JRebel was one of a kind in the time of inception. I fondly remember using it, believing it to be the best thing that has ever happened to me. Suddenly the developers were free from the stress of reloading/redeploying everytime they make a change to the code which also restricted creativity.

There has been no looking back since then. So much so that hot reload is taken almost for granted today. Hot reload is omnipresent now. From hot reloading in SpringBoot, to using nodemon in NodeJS, to using a simple — hot with webpack for frontend apps, hot reload is used thanklessly.

Optimization & React Hot Loader

A hot reload is no good if there isn’t any considerable difference between a redeploy and a hot reload. It’s not always the production where the load time needs to be minimal. A local code setup needs to load equally fast. On a local machine, the developer doesn’t uglify, minify or obfuscate their code, it is as is. Moreover, there are dev tools, source mappings and other hogwash which increase the time of a simple hot reload.

In order to help with the overall hot reload time, react-hot-loader aims to reduce the reload time, by rendering a small portion of the app only, instead of repainting the whole page. Imagine how quick it’ll be for a developer to simply reload only a small section of the screen, i.e. the minimal area affected by the hot reload.

More on the react-hot-loader later…

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade