3 ms·
The frontend has… a browser. It's a much more constrained toolbox. You are forced to use JS and whatever browser APIs made available to you. The server side is
by ttfkam 3y ago
The frontend has… a browser. It's a much more constrained toolbox. You are forced to use JS and whatever browser APIs made available to you.
The server side is only limited by what can run in a datacenter. Any language. Any service type. Any scaling profile.
Neither is more "correct". Both have pros and cons. As for why the backend engineer's point of view matters: if you are server-side rendering, you will have a better chance of going faster. A browser will always render HTML faster than JS that generates HTML on the fly, and the server side can always be made to generate HTML faster than a browser could. You can always simply throw more hardware on the server side to speed this up whereas you have basically no control over the performance profile of a random user's browser.
Look at Google search results. It's typically not JSON over AJAX; it's rendered HTML dropped into place. Why? Because every millisecond can be quantified into gained/lost revenue.
- robertoandred 3y agoSo why is it bad to choose a frontend state management strategy in a way that maximizes revenue?
- ttfkam 3y ago> Neither is more "correct". Both have pros and cons. I think frontend state management is a completely legitimate choice if it fits your use case.