A single-page application (SPA) is a web application that runs on a client device and fits in a single web page. A web application is application software that runs in a web browser and is created in a browser-supported programming language (such as the combination of JavaScript, HTML and CSS) and relies on a web browser to render the web application. An aim of SPAs is to provide a more fluid user experience, similar to a desktop application. A web page provided by a SPA does not reload at any point while the SPA is executing, nor does control transfer to another web page.
A traditional approach to SPA development is to include, in a SPA executing on a client device, a route handler that has access to all possible routes (such as URL fragments) that a user might select while interacting with the SPA. The traditional approach also involves a SPA including “dependencies” for each possible route. “Dependencies” refers to files for each module (or sub-application) that is associated with one or more of the routes. Such module files include JavaScript and CSS files, which are typically much larger than HTML files. HTML files, on the other hand, may be retrieved from a web server in response to a user request for a specific route. Thus, user interaction with a SPA often involves dynamic communication with a web server.
One benefit of a SPA having access to all routes and associated module files at loading time, even before any routes are requested, is that page refresh is avoided and time to page view is minimal.
An alternative to the SPA approach is the multi-page application approach where route handling is performed by a server that receives requests from a web application executing on the client device. However, in response to each user request, a page refresh is required, resulting in poor user experience.
However, the SPA approach is not without its disadvantages. For example, the time to load an SPA, along with all possible routes and files for each module, can be significant, especially if the number of routes and module files is relatively large. As another example, for large SPAs, developing a single route handler that has access to all possible routes and dependencies of each route at SPA loading time can be cumbersome, especially when different development teams are each separately developing a module that is associated with a subset of the possible routes.
One approach that might alleviate the disadvantages of the SPA approach is to develop a route handler for each module. For example, an SPA includes a route handler that has access to three routes: “/profile/”, “/mail/”, and “/search/”, but does not have access to any child routes of these routes. The route handler also has access to dependency information for each of these three routes. Then, if a user selects the “/profile/” route, then child routes of “/profile/” and associated dependent information are retrieved and a profile module is loaded. Then, if the user wants to access route “/mail/”, the route handler for the profile module would return an error because the route handler for the profile module does not have access to any routes related to “/mail/”. Thus, implementing a separate route handler for each module does not allow a user to access all the modules associated with a SPA.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.