The phone you're reading this post on has nearly as many CPU cycles available to run code as the web server that generated the html. Why on earth would you not want to distribute the overall application load.
The phone you're reading this post on has nearly as many CPU cycles available to run code as the web server that generated the html. Why on earth would you not want to distribute the overall application load.
Maybe because I want my phone battery to last a long time, but I don't care how much electricity the web server uses. Maybe also because the JavaScript is probably proprietary software [0], which I don't want to run on my computer.
Uglified/minified HTML+CSS is almost as difficult to parse by humans as JS.
I'm all for free software and very supportive of the arguments, but the pro-HTML, anti-JS rhetoric never made a lot of sense to me, consistency-wise, at least in these days of CSS3.
2. The web server has much more efficient languages available meaning that it's probably far fewer total CPU cycles than rendering on the client.
3. The web server can also cache the results and only render it once for a thousand users, can't do that with client side rendering, so your using far more CPU cycles there.
4. The server knows when the content changes, it can even render the page ahead of time, the client can't.
I also think this is something Web people overlook. Our phones are _insanely_ powerful, yet almost all Web sites are slow-loading garbage: because of JavaScript.