Single page applications are becoming increasingly common and for good reasons. Not only are they often more responsive, but they offer a more seamless user experience by changing only part of the screen instead of the entire screen. In addition, they use the client machine to build the page, rather than server resources, can make better use of caching, and can be more responsive to mobile and occasionally connected environments.

However, like all technologies, there are tradeoffs. While these applications are often better for the users and for the development team, they do require that you spend a lot more time carefully thinking through how you will mitigate the downsides. Building and deploying these applications well can be significantly more complex than building and deploying an equivalent server-rendered page. This doesn’t mean that you shouldn’t do it, but rather that when you do it, you take care to handle some of the downsides.

Single Page Apps are great and are widely considered a sensible default for new websites. While we love to see them, it’s important to know what you are trading off when you are building one. They have a massive number of benefits for many applications, but if you know what you are giving away to get those benefits, you can make better decisions about when to use them. Furthermore, when you do decide to build an SPA, if you address the concerns we’ve listed here, you will almost universally improve the throughput of your entire team and the maintainability of your app over its entire lifetime.

Memo: Put “BJ Burns” in Memo

The post Tradeoffs of Single Page Applications appeared first on Complete Developer Podcast.