Toolroom Tech Blog

Devlopers Digest

9 reasons why to use Single Page Web Apps

... and 9 why you should do it not.

... and 9 why you should do it not.

This week I had a discussion with a friend where I tried to convince him of SPAs ... but It wasn't easy. So I decided to bring tdown and share my thoughts. There may be scenerios where it really doesn't make any sense to implement an SPA. But you should consider it - it's a great opportunity to create a great web based app. I hope this list will help you to decide whether to make a web application or not.



REST API required
Since you need an API to exchange data with your Server, you can reuse this API with other, i.e. mobile, apps. If well designed, you can do a complete frontend rewrite without any(!) impact on the server.
REST API required
Some would say it's more work. Indeed, it is.
Testability of server communication
It's much easier to test an API than a mishmash of HTML and Javascript.

Highly responsive

You can immediately give feedback to user activity. No need to perform a partial or full page roundtrip. Once loaded you can simply reuse data in different ways or just make the whole thing more interactive.
Longer initial loading
Since you initially load the whole application at once, including Scripts, Templates and CSS, the time to load the app will increased. In extreme cases drastically.
No server state
Since stateless, we do not need to keep a 'clone' of the client state on the server. You just need to authenticate the requests.
No server state
You don't know the requesting client. That means the API must claim all parameters it needs within each action again and again. And: you need to implement a proper security concept to validate each request by yourself!
Data Binding
Most JavaScript SPA frameworks come with bindings. They save lots of work since you are not required to pay attention on all parts of the application that should be updated if whatever happens whenever.
Side effects & debugging issues due Data Binding
Sometimes bindings may lead to side effects you would never think of. Furthermore it can be hard to debug those bindings...
Lightweight data exchange
Once loaded, the app communicates only data (JSON) with the server. No heavy requests, no heavy HTML responses. In extreme cases you can make almost everything offline.
Furthermore, while debugging your app, you can better read and mock the data transmitted between client and server, i.e. via Fiddler.
Easier to manipulate request and response
Transmitted data may always be subject of interception. But it's much easier to manipulate human readable JSON.

JS business logic
You have to implement the whole Business logic with JS ... this seems very horrible. On the other Hand, why not - good apps always check data integrity on the Server. 

No date issues
Prevent issues where you have to guess the timezone or the local date format. Just give UTC to the Client and it does the rest. Don't bother about time zones, the Client knows it!

JS Memory leaks
Well, that's a Problem. Most Frameworks are well built to minimize the potential to run into such issues. I recomment to sometimes do a full page load instead of just a partial switch.

Search engines do not speak JS
That's not the full truth, Google tries to understand JS. But in fact you should also provide a static version of the content you want to expose to search engines.

No Server generated Scripts
No need to generate JS generically on the Server.

JS must be enabled on the Browser
But imho that's not a real issue anymore.
Move load from server to client
Since everything is rendered on the client, your servers will make a party.