4 ms·
I usually ignore server side rendering or isomorphic rendering. I'm not saying all projects should ignore it but you're really talking about a high level of opt
by cyberpanther 9y ago
I usually ignore server side rendering or isomorphic rendering. I'm not saying all projects should ignore it but you're really talking about a high level of optimization if you need it. And if you're reaching that level of optimization you probably shouldn't use Python.
Server side rendering only makes the first view faster. After that, everything is rendered on the client and faster that way. And if you use caching with progressive web apps or just file caching in general, the first view will be fast after. So you're only optimizing for the first of the first. You can then provide the initial data in the page request so that saves a round trip on the first request while still rendering on the frontend.
I say all this to just point out that there are many ways to speed up your frontend without doing SSR and they are much easier to implement with Python. So I'd rather exhaust all these techniques before implementing SSR. If I get to that point though, I suspect Python might be the slowest part of your stack. And lastly if you are doing SSR for SEO purposes then just use a prebuilt prerender service.
With all that said if there was an easier way to SSR with Python/Django, I'd definitely use it. But Jinja on the frontend doesn't sound like that answer.
- erikpukinskis 9y ago> Server side rendering only makes the first view faster. The first view is the most important view, and making it faster is often the most beneficial thing you could do for engagement.
- cyberpanther 9y agoValid point. In addition to technical optimizations besides SSR, you can make perceived improvements too. If you get a first initial paint in one second lets says, you're not going to hurt engagement. There are plenty of tricks you can pull out first before you need SSR. Sure if you're using Node.js pull out SSR first since its easier. But for Python right now, it's not the easiest thing.
- stevebmark 9y agoIf you're writing a SPA, server side rendering is probably the most important optimization you can make to speed up your application. No other optimization will come close to the benefits of server rendering. SPAs are both slow and perceived as slow. True SPAs are only appropriate for a subset of the web where you have very specific user constraints.
- cyberpanther 9y ago> No other optimization will come close to the benefits of server rendering. "Only the Sith deal in absolutes", Obi-Wan Kenobi
- rhaps0dy 9y agoMathematicians also deal in absolutes! Not just the abs function, also proofs and counterexamples.
- wbillingsley 9y agoI have a bad feeling about this... ObiWan: deals_in_absolutes ==> Sith rhapsOdy: mathematician ==> deals_in_absolutes ---------------------------------------------- therefore ... We may have to wrap this in spoiler tags for Episode 9.
- StavrosK 9y agoThe logic is inescapable.
- Scarbutt 9y agoI may be wrong, but GMail doesn't seem to do SSR, you have that progress bar when it loads up, so is not really an essential prerequisite as you make it out to be.
- stevebmark 9y agoI agree that server side rendering of gmail would greatly speed up the load and remove the need for a progress bar. The word on the street is Gmail has too much legacy code in it to much modernizing with. It's also one of the few very special apps that users tend to keep open forever in a tab, and never do page navigation. Definitely don't use GMail as your benchmark unless you're making something as specialized and popular as what they have now.
- 9y ago