Hot Loading - Still Relevant?
More than a decade ago, when I started my profession as a software developer, one of the most significant pain for developers was waiting for your application server to start so that they could verify their code changes. Hence there were efforts to make live reloading happen without restarting the server to reduce waiting time for the server to be up.
The objective here is to get quick feedback. We would love it to be instant. However, since it can't be practically zero, we would like it to be as short as possible.
There are successful commercial solutions in this space, running for more than a decade. It speaks the significance of this problem and the value offered by such solutions.
Let's take a look at the factors that influence the need for hot loading and its value.
Server startup time
Server vendors and framework providers are hard at work to reduce the application startup time. We have witnessed the startup time reducing from several minutes to a few milliseconds.
Application size
While the raw server startup time has a partial impact, the application developers decide what to bundle in the application and what code gets executed at the startup. Hence application size along with the raw startup time determines the actual startup time. Note that here I am confining myself to the impact of startup time on the development. Hence the emphasis on the wait time.
Slow startup time can hurt the developers. It may force them to optimise their flow for fewer application restarts. The implication is developers opt for a large batch of changes which in turn might produce more waste. Also, this might influence developers to resist changes rather than welcoming new ideas and experiment with multiple design/ solutions.
The increasing adoption of microservices architecture (A sample survey report here) has a significant impact on the application size. Even though the granularity of services will vary from team to team, the chances of building huge monoliths are less likely, which in turn influences the startup time of each service positively.
Automated Tests
An alternative approach is to rely less upon the server restart. In my experience, the best way to optimise your engineering for feedback is to embrace Test-Driven Development (TDD). While in TDD, tests guide your design, for this discussion, let's limit ourselves to test-first development style. Interestingly, more teams are embracing the test-first approach than ever.
By adopting test-first development practices, developers will rely less upon the manual server startup. However, to get the benefit of less reliance upon server restart, having the right mix of various types of tests is critical (remember the test pyramid?).
Conclusion
Not every project can be on the latest and greatest tools. Hence the impact of the above factors will vary from project to project.
Even if hot loading is not as significant as before for you, restarting your server with the code changes continuously is still a highly useful feature. It also simplifies the tooling requirement. Your build tool has to offer support for rerunning the tasks upon detecting a change in source code. Also, your frameworks need to restart themselves upon detecting a change. I see this trend gaining more adoption going forward.