🚀 If you enjoy this article, please give it a ❤️ and 🔖 to help others find it. Thank you!
Sometimes we get so immersed in learning technology that we forget to ask the basic questions. If you started learning front-end software development in the past few years, you were likely quickly introduced to single page application frameworks like React, Vue, and Angular—but their interaction with web servers and how things were in the “before times” may be a bit fuzzy to you.
Conversely, if you have been a web developer for a while in languages like Java, PHP, or Ruby, you may not have gotten into the single page application world (after all, popular server-side frameworks tend to have excellent templating features).
Regardless of your experience, it’s worth taking stock of how “conventional” web apps work and then how things are different in the single page app world.
Conventional web applications
The way web applications used to work was as follows: a user would navigate in their web browser (“the client”) to your website (let’s call it mywebsite.com). This would result in an HTTP GET request over the Internet to a computer somewhere (“the server”).
The server would look at this request and respond with an HTTP response that, among other information, includes some HTML. The client would receive that HTML and render it for the user to view and interact with.
🎓 Learn how the web works!
This article is taken from my newsletter, How the Web Works. You can sign up for free here: https://howthewebworks.substack.com. I won't spam and you can unsubscribe any time. You won't regret it!
Let’s say that HTML has a link to an “About” page located at mywebsite.com/about. If the user clicks on that link, the browser performs another HTTP GET request. Again, this request is sent over the Internet and received by your server. Your server sees that this is a GET request to the /about route. Based on that information, it sends a new reponse, this time with the HTML associated with the “About” page.
When the client receives the response to this request, the entire screen is replaced with the “About” page HTML. The user can now interact with the “About” page.
This interaction can be represented by the following diagram:
Importantly: for each page our user wants, a new HTTP request is sent over the Internet, a bunch of HTML is returned, and the user’s view is replaced with that HTML.
What is a single page application?
Our “conventional” application can be thought of as a multiple page application: for each link we click in our site, we get an entirely new HTML page back and our screen is totally refreshed.
But what if we didn’t have to contact the server every time we wanted to navigate somewhere in our website? What if the server sends all the necessary information to the client in response to the first request? Maybe we would avoid some page reload time since we wouldn’t have to keep reloading the server.
In other words, what if our client/server flow looked something more like this?
This is essentially what a single page application is. The user only really receives the html for one page (the “single page”) and then all browsing/navigation happens client-side.
Technically, this is accomplished using JavaScript. When a user performs an action or navigates someone else within the current application, some JavaScript executes an action that updates the view accordingly. This is usually faster than having to get a new page from the server since there is no network request involved.
Is it realistic to send everything to the client immediately?
In reality, we often have some data that can’t be sent to the client immediately. Perhaps we maintain a list of 500,000 books and the user is searching for one. It would be a very bad idea to send 500,000 book titles to the client on initial page load: the bandwidth and load time would be astronomical.
This doesn’t derail our single page application plans, though. It simply means our single page application sometimes needs to make HTTP requests from within the client-side JavaScript code. When our JavaScript code makes these requests, the server can just return the requested data rather than an entire HTML document. Once the JavaScript code has the result of this request, it populates the document accordingly.
Drawbacks
Single page applications have their drawbacks. If they get large enough, then you’re potentially sending way too much code to the client at one time and that can result in poor user experience. Because of this issue, features like code splitting have been developed. Code splitting separates the front-end code you develop into smaller bundles and sends them to the client only when needed.
Managing application state also gets complicated with single page applications. With multiple page applications, a request is sent the the server, the server does whatever data lookups it needs to do, and then HTML is sent to the client. In single page applications, server requests are happening in the background while users are looking at the HTML document. What do we show the user while these requests are happening? The application has to be in some state. What if there are a few different background requests going at the same time? Do we have one big “loading” indicator or a bunch of smaller indicators? What if one of the three requests fail? Do we show data for the the requests and then a failure indicator for the third?
Try it out
If you’re a programmer, one of the best ways to understand single vs. multiple page applications is to try them out. I’d recommend tinkering with the following frameworks depending on your skillset:
Front-end:
- React
- Angular
- Vue
- Svelte
Backend:
- Express (Javascript)
- Ruby on Rails (Ruby)
- Django (Python)
- Laravel (PHP)
- Spring (Java)
🎓 Learn how the web works!
This article is taken from my newsletter, How the Web Works. You can sign up for free here: https://howthewebworks.substack.com. I won't spam and you can unsubscribe any time. You won't regret it!
Top comments (0)