4 ms·

It is pretty disappointing that these comparisons always seem to consider the server side template case as "we did it in the most horrible way possible, I know

It is pretty disappointing that these comparisons always seem to consider the server side template case as "we did it in the most horrible way possible, I know all the issues we had were solved long ago and we could do it right, but lets pretend that isn't possible because I want an excuse to do everything in javascript".

rtfeldman 13y ago
Yeah. To me, the pros and cons ought to assume you're Doing It Right; otherwise, you're probably better off learning to Do It Right than changing your approach. I see the tradeoffs as: Server-side rendering gives you better language choices, but it's more expensive to the site owner than serving static HTML/CSS/JS for pages and using AJAX for data only. Client-side rendering is often more performant for the end user than server-side, but that depends on the device and the application. Which one makes sense, then, depends on whether client-side rendering is actually faster for your application and expected user device usage patterns, and how much you value better language choices versus lower server costs. As with absolutely everything else in software, there's no one-size-fits-all correct answer.
pamelafox 13y ago
(Post author) Yep, I know that our server-side case was the worst possible way. It is possible to do it in infinitely better ways, but it's still hard to do so in a way that easily brings in JavaScript and doesn't end up replicating code, especially when your server-side language and front-end language are different. I got a demo of DerbyJS the author day, a framework on top of Node that does server-side rendering of the template so it loads very fast, and then subscribes to events via JS and refreshes the template on the client-side, all using the same template code and language. That to me sounds like a pretty cool approach, but not something we can switch to easily.

rtfeldman 13y ago

Yeah. To me, the pros and cons ought to assume you're Doing It Right; otherwise, you're probably better off learning to Do It Right than changing your approach. I see the tradeoffs as: Server-side rendering gives you better language choices, but it's more expensive to the site owner than serving static HTML/CSS/JS for pages and using AJAX for data only. Client-side rendering is often more performant for the end user than server-side, but that depends on the device and the application. Which one makes sense, then, depends on whether client-side rendering is actually faster for your application and expected user device usage patterns, and how much you value better language choices versus lower server costs. As with absolutely everything else in software, there's no one-size-fits-all correct answer.

pamelafox 13y ago

(Post author) Yep, I know that our server-side case was the worst possible way. It is possible to do it in infinitely better ways, but it's still hard to do so in a way that easily brings in JavaScript and doesn't end up replicating code, especially when your server-side language and front-end language are different. I got a demo of DerbyJS the author day, a framework on top of Node that does server-side rendering of the template so it loads very fast, and then subscribes to events via JS and refreshes the template on the client-side, all using the same template code and language. That to me sounds like a pretty cool approach, but not something we can switch to easily.