Hydration is a common technique employed by current JavaScript-based frontend frameworks, such as React. In hydration, the application code is re-executed on the client to recover component boundaries, application state, and event listeners. In this article, we look into a new primitive called resumability that avoids the work as the necessary information is serialized into HTML. The idea has been adopted by Asta (2023), Google Wiz, Marko (planned for version 6 [1]), Sidewind (since 2022), and Qwik (2021) as a main building block. Resumability gives these solutions unique advantages by avoiding the cost of hydration. Furthermore, resumability can allow developers to leverage code-splitting out of the box, depending on the implementation. The shift has implications for both developer and user experience. This article aims to understand why resumability matters and why it is a good option for replacing earlier hydration-based approaches. We also consider challenges related to adopting resumability on a framework level and briefly highlight the first resumable solutions for developing web applications.INDEX TERMS hydration, JavaScript, multi-page applications, page size, resumability, single page applications, software architecture, web application development, web performance, world wide web 1 This is particularly true within a mobile environment when JavaScript payloads are big enough [6]. the user may be reduced. Due to the cost, any reduction to the size of JavaScript has a considerable impact on the end user, and even deferring the cost can be beneficial.