Web Dev full-stack [LAMP] since 2005, but much heavier on the JS stuff these days.
Jack of all Stacks, Master of some.
Always looking to learn new things. Always glad to help out, just ask.
Location
Atlanta, GA
Education
B.S. in Biochemistry 2004, M.S. in Computer Information Systems 2007
lol, some will ALWAYS use it :)
Some devs don't know any better and will continue using the old stacks that all do SSR but render slower
Some devs will use new frameworks and the SSR tools they provide because of SEO and other reasons
Some devs won't use SSR because you don't need it in order to build a functional website that ranks well on SEO. You just need to understand how google's bots work.
Some devs who understand it will still use SSR because of specific business needs or because they want to appeal to bots beyond google and bing.
Some devs won't use SSR because they don't know what it means or does.
The real questions are always:
What are you building? Do you care about SEO? Do you care about performance?
Do you understand all three enough to do it the best way for that project?
Also, "best" is relative as you can build a website/app a dozen different ways and achieve the same result.
In the end though, how sure are you that your results are in the top 10% for performance and SEO?
That's what it comes down to.
Thank you for replying! Yeah, I just listened to a podcast about caching:
Easy to implement. Hard to implement efficiently and correctly. Or at least it takes time to understand it in depth enough to implement correctly.
Every app is different. Learning what tech/framework/etc. will work great for you requires dedicated upfront time to research.
Web Dev full-stack [LAMP] since 2005, but much heavier on the JS stuff these days.
Jack of all Stacks, Master of some.
Always looking to learn new things. Always glad to help out, just ask.
Location
Atlanta, GA
Education
B.S. in Biochemistry 2004, M.S. in Computer Information Systems 2007
So Caching is a funny beast. I agree, it's worth implementing for many systems, but you gotta remember, with JS frameworks, much of what was once cached, can now simply be served as static sites.
So really you do very little caching, though one might say "static code" == "cached code".
Static sites would make api calls, meaning you either cache the api results or setup scalable environments for the dynamic data.
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
lol, some will ALWAYS use it :)
Some devs don't know any better and will continue using the old stacks that all do SSR but render slower
Some devs will use new frameworks and the SSR tools they provide because of SEO and other reasons
Some devs won't use SSR because you don't need it in order to build a functional website that ranks well on SEO. You just need to understand how google's bots work.
Some devs who understand it will still use SSR because of specific business needs or because they want to appeal to bots beyond google and bing.
Some devs won't use SSR because they don't know what it means or does.
The real questions are always:
What are you building? Do you care about SEO? Do you care about performance?
Do you understand all three enough to do it the best way for that project?
Also, "best" is relative as you can build a website/app a dozen different ways and achieve the same result.
In the end though, how sure are you that your results are in the top 10% for performance and SEO?
That's what it comes down to.
Thank you for replying! Yeah, I just listened to a podcast about caching:
Easy to implement. Hard to implement efficiently and correctly. Or at least it takes time to understand it in depth enough to implement correctly.
Every app is different. Learning what tech/framework/etc. will work great for you requires dedicated upfront time to research.
An upfront cost that is always worth it
So Caching is a funny beast. I agree, it's worth implementing for many systems, but you gotta remember, with JS frameworks, much of what was once cached, can now simply be served as static sites.
So really you do very little caching, though one might say "static code" == "cached code".
Static sites would make api calls, meaning you either cache the api results or setup scalable environments for the dynamic data.