Maybe, maybe not, I can't tell how dynamic the site is since it's down. Something has to render the content, as with most programs everything is a CPU vs Memory

Maybe, maybe not, I can't tell how dynamic the site is since it's down. Something has to render the content, as with most programs everything is a CPU vs Memory vs IO/Network trade off. It's nice to now have the option to use the CPU of the client if desired. I started programming in the heavy client days, writing VB6 against Access databases or SQL server. This is how your typical business app was made and it completely consumed the mainframe/terminal model because you could scale on commodity hardware taking heavy advantage of the now relatively powerful distributed client resources. The server did as little as possible to get the data to the client for rendering/presentation also you could do offline partially connected things. Of course there where issues with this model, deployment was much harder and you had to trust the clients, plus databases generally didn't scale out at the time. Then browsers came about, and everyone realized you could write business apps in them, but the old guys laughed at us because it was the dumb terminal model all over again. All validation done on the server, no deployment issues, no need to trust the client, network connection always required. Then javascript started getting better, hey I can do validation in the client again, but maybe do on the server still if you don't trust the client, but the user gets instant feedback, best of both worlds. The choice about which layer your code executes in is important, it lets you make that CPU vs Memory vs IO trade off without leaving the client CPU on the table. I think this is one reason the mobile app model is so popular as well.