4 ms·
I think this ignores one of the main benefits of JS based page rendering. In the days where I worked on PHP apps, all rendering was done on the server, and tha
by RobKohr 8y ago
I think this ignores one of the main benefits of JS based page rendering.
In the days where I worked on PHP apps, all rendering was done on the server, and that came at a great cost regarding server side processing and the complexities of peak load times, along with some pretty hairy test cases.
With everything rendered in js, you are mostly just transferring static assets, so the browsers are doing the heavy lifting for you. The only things that end up taking up server CPU cycles and system memory were API calls that are easy to test, debug, and optimize. Also, those API calls can be cached, and become static assets for high traffic apis such as ones accessed on the front end.
If you do it all on the backend, you are doing all the rendering work, and it is hard to split off and optimize processing time for things.
Finally, for testing, it is really easy to unit test an API, and for javascript frontend work, there doesn't seem to be the code regression type bugs that are so time consuming, but when you mix the data api stuff with the front end rendering, unit testing becomes a big mess.
Bloat needs to be thought about, especially for limiting bandwidth, but just for curiosity, I checked out my own website which was using React and a bunch of libraries, and it was only 500K. This is about half the size of the banner image on that article. Some libraries are much larger than React, but going JS free and losing the power React gives you doesn't seem like a good trade off.
Of course if you get some happys from being an ultra-purist, then I get that, and that is priceless. From a practical perspective though, this seems misguided.