The history of the World Wide Web is the story of server-side versus client-side software. When things started to get going, the Web was largely a set of static files that were served up from the server. The browser displayed those files in as presentable manner as possible, but didn’t do any extra processing on its own that wasn’t part of the rendering process. Dynamic content was animated GIF files and the <blink> tag.
Pretty quickly, tools were developed to make the pages more dynamic. With the right set of parameters, your page could be modified to display the page differently for different people or situations. All the processing still happened on the server side, though, and the browser simply displayed what the server sent back.
The widespread deployment and adoption of JavaScript changed things. Now the page that was displayed could be altered by information available on the client without processing back at the server level. Complicated tasks could be performed on the server, or the client machine. It became possible to make decisions about how the page was displayed without the server being involved. Button clicks and logic could be executed without referring back to the server. In many cases, the back and forth communication could be avoided or short circuited, and it was no longer necessary to re-request the page every time something changed.
This mirrored the history of computing itself, with the focus moving from large mainframes handling the processing, to more responsibility being handed off to smaller, cheaper, remote machines, to individual desktops doing most of the work. In some cases, a some of that responsibility is being shifted back. Look at Cloud Computing, remote desktops, and other technologies.
With the explosion in mobile devices, the move has been to Responsive Design. This usually involves the bulk of the information being sent by the server, then the user interface part being handled by a mix of CSS and JavaScript to display the page correctly for the device displaying the page.
Often, the best case is a mix of local and server-side processing. Q-Suite has followed this trend throughout its development. Originally, even the web interface was handled by the web server. If a user requested a different theme, that would have to result in a request being passed back, and that change noted in the cache or cookie for the session.
Q-Suite allows theming options to be set by the client, and technologies such as AJAX and WebSockets allow information to be passed back and forth without requiring the page to be redrawn each time. This allows the pages to appear more responsive to the user and avoid delays, while making sure that both the browser and server are up to date on what’s happening now. It also allows the agent’s machine to do some of the work, and can help reduce the load on the server.
There will probably always be such a mix of client vs server side technology. You don’t want the call center agent browser to be making database requests directly. That’s a security nightmare. However, you do want it to be able to display client data at the click of a button. That’s why you deploy Q-Suite in the first place.