My server, implemented in PHP, is now just a data pump. I compose HTML on the client using JavaScript.
Pros
- Reduces network load (no HTML, just raw data)
- Reduces server load (server does not have to compose)
Cons
- Increases client load
Given these pros/cons it seems a good idea to move HTML composing to the client as long as there are no load issues at the client.
Are there any angles I have not looked at?
From Comments / Answers
Possible Cons
- Bots might fail
- Screen Readers might fail
Additional Pros
- Pure data is readily available for new apps on new devices
Here are some user stories that you should list under ‘cons’ – there are more.
I have javascript switched off because I’m security conscious. Your website doesn’t work for me.
When I use the back button I leave your website (getting round this is technically quite difficult) – see comments – this has been disputed
After using your website for a good length of time, my web browser consumes a huge amount of memory because it’s lax in reclaiming memory vacated by out-of-scope objects, or because your code isn’t efficient (IE is particularly prone to this)
I use a mobile device whose JavaScript performance is poor compared to a desktop – your website appears very slow for me.
I use a screen reader – your website is unintelligible to me.
My name is GoogleBot – your website isn’t indexable.
If none of this bothers you – go right ahead.
As an aside
I should add – I am altogether not against this kind of application at all. If done properly the client experience can surpass that experienced with the traditional click, GET, click, POST, click, GET etc etc website. Indeed in my current project I have been working on a pure-javascript application as a QA aide and prototype for my organisation’s site.
But we will certainly not use such a thing as our only web presence.