I'd like to reply because I use this paradigm quite often (shipping work to the client). What I used to do was this: write an API, write a web layer that talks

I'd like to reply because I use this paradigm quite often (shipping work to the client). What I used to do was this: write an API, write a web layer that talks to the API and serves up HTML, and write a bunch of javascript that runs in the browser give the app a bit more juice. What ended up happening as more and more browsers started to not completely suck is I moved 99% of the web tier that sits inbetween the API and the browser into javascript. When clients hit the app, they download the entire app: javascript, HTML templates (not fully rendered views), etc. The javascript ties everything together and uses pushState to replicate what happens when a user is browsing a normal HTML page. Any data that is needed is grabbed directly from the API in the background. This offers significant advantages: not only are you farming off the entire generation of your app's views to the user's browser (taking work that you would have to do yourself and distribute it), you are reducing the complexity of the app. There are now two pieces to maintain: an API and a set of javascript...no web layer in between. This makes things a lot snappier for users. Pages switch instantly because everything they need to run the app is already there and ready to go. So, no, I'm not shipping 800GB of data to each of my users and expecting them to crunch SQL queries, but I do like to send any work that I would have to do to their browsers, assuming they are capable.