Do you REALLY need SSR?
Server-Side Rendering (SSR) has been a hot topic in the world of web development for quite some time now. But do you really need it for your website or application?
SSR is the process of rendering web pages on the server and sending the fully rendered HTML to the client. This can be beneficial for improving performance, search engine optimization, and ensuring a better user experience, especially for users with slow internet connections or older devices.
However, implementing SSR can also add complexity to your codebase, increase server load, and require more maintenance. It’s important to consider whether the benefits outweigh the drawbacks for your specific project.
When do you really need SSR?
There are certain scenarios where implementing SSR is highly recommended:
- SEO: If your website heavily relies on search engine traffic, SSR can help improve your site’s search ranking by providing fully rendered content to web crawlers.
- Performance: For websites or applications with a large amount of dynamic content, SSR can improve initial page load times and overall performance for users.
- User experience: Users on slower internet connections or older devices may benefit from SSR as it provides a smoother, more consistent experience.
When can you do without SSR?
In some cases, using a client-side rendering (CSR) approach may be sufficient for your project:
- Simple websites: If your website is relatively simple and does not rely heavily on dynamic content, CSR may be all you need.
- Single-page applications: For SPAs that require a lot of interactivity and dynamic content, CSR may be a better fit as it allows for faster and more seamless navigation.
- Time and budget constraints: If you have limited resources and need to get your project up and running quickly, opting for CSR may be a more practical choice.
Conclusion
Ultimately, the decision to implement SSR should be based on the specific requirements and goals of your project. It’s important to carefully consider the trade-offs and assess whether the benefits of SSR align with your needs. If in doubt, consulting with a web development professional can help you make an informed decision.
1- Buy Apple stock
2- write a successful app
3- push your user buying a new device each year with a complex full Client-side rendering
😅
This one was helpful to understand why the freak we need SSR frameworks. It makes the Developer experience much much simpler along with the SSR model compared to the traditional server rendered model of using a server and templating engine. The last part was really informative as well, we can have blocking renders for things that are essential for our App and have Suspense states for non-essential components.
Please, what is the name of the drawing software you are using ? Thanks
1:13 this only with vanilla JS and DOM manipulation. You could achive the same fucntionality (updating parts of a page) with jQuery: the only difference being that it had more complexity
In today's world of CDNs and cloud databases — both of which are presumably close to your end-user's device — I don't see how pushing all of this work back to the server — like we did pre-1990 — does anything except making your server a bottleneck. Maybe caching of pre-rendered content? But that can be done better by pushing static content to CDNs. Maybe SEO optimization, because it is simpler for search engines to understand your page if it is pre-rendered? But that assumes poorly-organized client-side code. In fact, I'm pretty sure you would have to compare well-designed server-side rendering to poorly-designed client-side rendering, to see any benefits of server-side rendering. I would love to find out I am wrong, so please, anyone, correct me. I actually PREFER server-side coding, but I just can't justify running UI code on the server.
I though React was a library. You said it was a framework. Tomatoes Tomatos!
I like your videos
Wouldn't it be a good reason to use "mfe" architecture to help/complement/replace some of the "component" architecture?
Now it makes sense why the fb app was absolute garbage bloatware for so long.
This is pure gold. Thx for shearing your knowledge!
I am not sure about the ssr hype. For me users have pretty powerful machines. The render task is a client responsibilty, why should servers (clusters) provide this huge capacities? I want to let the client machines do this work. In networking the most expensive part is latency. Outsourcing render tasks to the backend kind of triggers this in an unnecessary way. As a service provider I have to invest into infrastructure, but the powerful clients are bored out and in idle mode…
I think we are not there yet, but very skeptical about this tbh…
Thank you so much ❤, and Can I know what is the software you are using here to draw those diagrams ? Is that a plugin for Obsidian ?
this is so clear and inspiring! the visuals are so easy to understand and i love it! i wonder what software you were using to draw these models. anyways, thanks a lot!
What tool do you use for the diagrams?
Amazing how no one talks about PWAs, offline first apps, realtime collaborative apps or hardcore client side caching and optimistic updates. Just having an api that’s event driven complicates the whole rsc paradigm to the point that making a db update and having to wait 500ms for the backend to process it before revalidation is a challenge.
I guess everybody’s building blogs and ecommerce nowadays…
I never understood why people prefer SSR over an instant static response. Personalization often can't be served from the database alone but includes data in the browser (preferences, hardware info, local storage, indexeddb, …) making SSR not feasible for a lot of things. Feature flags can be done static, too. So you end up doing SSR for 5% personalized data together with 95% of what could be static. Hydration is already slow. SSR is added on top. Potential cold starts are added on top. Higher infrastructure costs as well. Not a great recipe.
Ty so much for helping me learn and grow, Theo! Love your content. Definitely subbed with notifications set to all.
When I get a job I’ll be able to be a greater value to your channel but….im working hard to stay organized and on task.
Cool scribbles while you are talking. What program is it you are using for that? Edit: Saw it at the beginning, Exkalidraw!
I am a bit biased against react. I'd pick angular for many reasons (one of which is the ease of use). But, even then, I'd say that while fat-client SPAs do put more stress on end user devices, that is the computational power that is already there and to most degree is not used. Why to take all that computations back to the server? Providing that after the first load all the static content will stay in cache, the differences will become fairly small. SSR is cool and all, but SPA is easier to work with.
love devs that swear