[toinbis]

Reply to a) No, it is not false at all. Let's skip the brands out of discussion. Client side a-b testing is impossible to be decent. Period. The fact that optimizely built something for react is not a valid argument.

Reply to c) Your react app is 30% slower that anything decent. Why would any bussiness owner would ever sign this off to happen in their acquisition funnel(i.e. where user experience is especially crucial)?

Reply to d) Decent is ~100% correctness and completeness versus ~70%.

Reply to "I guess you think it's just the exception that confirms the rule?" -> You keep mentioning companies and brands instead of implementations which suggest you have no experience on the implementation part. That is the thing - facebook does a/b testing server-side. And i'll just mention that facebook also used react to create their, arguably, second most important project - facebook ads manager. And it's a complete 'bollocks'(using your words) architectural decision to build such tool for react - it's a UX as terrible as it can get and i've used it for 5 years and I know at least 100 advertising agency employees who would sign this statement with their sweat and they are one of two. Just to give a counter-argument of the same origin as Yours one.

So am very thankful for constructive discussion - all your arguments are fair and well elaborated. Just you can't buy any of them. Really hope am not insulting with my strong opinions, always happy to discuss further!

[arcturus17]

> You keep mentioning companies and brands instead of implementations

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

> Client side a-b testing is impossible to be decent

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

> Your react app is 30% slower that anything decent

How would you know, anyway? The web apps I've worked on (not app, in singular) are faster than just about anything "decent", faster than many SSR industry peers or competitors, and objectively so under many industry-standard performance tests.

You further resort to a personal attack by questioning my implementation or engineering chops without any evidence of them - just my evidence-based opinion that SPAs are not inherently slow at all (they really aren't).

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 - surely that could be a telltale sign of a really poor engineer?

[toinbis]

>> 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!