>> This doesn't make any logical sense. I was clearly referring to Facebook primarily as an implementation, not as a brand.

Facebook is a product of 100000 different implementations which might theoretically change daily. If we were discussing can we do thing X or Y with MySQL, and you'd say 'look - there is facebook, it's working, it means you can('t) do thing X or Y with MySQL' - that would not not be very specific. I'll add term 'architecture' to discussion.

>> OK, so Netflix, Facebook, Instagram, AirBnB - all web app implementations - cannot decently A/B test, but you can. Gotcha.

So, let's talk architectures. "Netflix, Facebook, Instagram, AirBnB" - if you can, please specify what architecture and for what purpuse they have implemented. And tell about the specific example. We will have something to discuss, now we just don't.

For instance, https://docs.developers.optimizely.com/full-stack/docs/optim... -> this is architecture of optimizely experiment for React. This is other feature https://www.youtube.com/watch?v=NRLhlTopFzw being showcased, but you can get a sense of how the SDK is being used. Let's say bussiness requirement is to run experiment where for 50% of traffic you show nothing at the top of the page, for other 50% you show country flag image and city flag(cout of arms) image. Site is built with next.js. The next day you throw next.js out and build your site from scratch on other page. How would you implement that?

>>How would you know, anyway?

a) You use common technical sense and realize that's the only way it can be;

b) If you don't trust your guts, you go and analyze performance tests: https://css-tricks.com/radeventlistener-a-tale-of-client-sid... and learn that react is 40x slower that the industry standard. Not stressing 40x, just - it's slower, was and will always be (except RenderToStaticMarkup and Server Side Components).

c) You go and check what world is using - https://w3techs.com/technologies/comparison/js-jquery,js-rea... , you realize that, statistically speaking, no one is actually using react, probably for a reason. (Ok ok, this argument is also a bit overstrech, and yet... :)

d) You can only know for sure by building stuff and comparing. You build https://turboeshop.com/fastestpageintheworld/ and https://gatsbyeshop.com and compare: https://imagebin.ca/v/5lrH1VnQBac7 .

>> 'faster than many SSR industry peers or competitors'

'Not worse then most competitors' is not how you win in bussiness competition, is it? :)

>> You further resort to a personal attack

Honest apologies if that sounded that way. If I may - I take all that back.

>> I've got nothing against SSR, it's got its use cases and I've personally used it too, but you on the other hand seem to be an SSR jihadist

Ok, now we talk. For the record - I write a lot of client-facing vue code, sometimes a bit of react. Love both, great developer experience, I call them both 'godsend' for frontend development.

Yes, I do turn radical when people start shouting 'react is the answer, what was the question'. And this tread we are having discussion in began with 'you should do everything in JS/TS' statement. And believe me, there are many devs like this.

When faced such statements and situations I do take a stance and say that there are so many bussiness requirements that make hydration/js-navigation/react-vue-svelte obsolete from day one, they are just out of consideration when picking a stack.

Problem is devs makes usually make choices and bussiness usually does not not the costs they are incurring in letting devs to use tech stack they do love. Reactgasm(term found online) has it's high costs for some bussinesses. It sure does. It has obvious gains as well. Which are the greater - devs only can never decide, yet it happens that they think they can.

My main profession, broadly speaking, is e-commerce marketing. And when dev comes and says 'i'll use react in the acquisition funnel of the project you'll be optimising' - sometimes turning to SSR jihadism is the only way of winning an argument. Am glad we finally came to a conclusion that 'it depends on bussiness requirements', which I honestly think is always a start and end of discussions as such.

My final point is "react&friends are not default options for tech stack for ecommerce bussiness acquisition funnel (I have quite some expertese and many years of experience in this specific domain, that's why I allow myself strong statements), but in practice it may surely be a comlete opposite if bussiness decides so". That says nothing about that react or vue ar not great projects they do not have their use cases. In a neutral environment without react-jihadism i'm perfectly fine saying 'tech stack needs to meet bussines requirements', but that's only with an asterisk *if bussiness requirements are actually being taken into consideration, not devs just picking what they love and pretending everything else does not actually matter.

Many thanks for good discussion, apologies again if any of the statements were impolite, am not a native English speaker. Feel free to challange my technical discussions above, but I think I'll resist of pushing this further, as I've elaborated my point of view and then I believe it's about sharing ideas not winning arguments why we are in HackNews :) Kindest regards and happy holidays!