It's crucial to remember that a decision's outcome might be harmful, even if the decision was sound at the time. Documenting the advice helps provide valuable context and helps understand this distinction. 3/3

But I understand others might have a very different experience. I just wanted to make sure we’re not condemning conflict management as a whole because of some “manager type” individuals.

My mistake - I didn’t know the phrase “helping resolve” could have such a negative connotation. To me, helping encompasses teaching, offering advice, lending an ear to vent, helping gain a new perspective, offering to moderate and more.

I think (hope) what is often ment by “managing conflicts” is making sure a conflict stays in the debate stage. This means at first a very passive observing, sometimes actively encouraging, but can also mean helping to resolve. See e. g. en.m.wikipedia.org/wiki/Friedri...

Thanks for the clarification: I wholeheartedly agree!

Thanks for bringing up the discussion in the first place! I'm looking forward to more replies with benefits and drawbacks. To make sure I understood your point correctly: you want a tech stack that can be used for SPAs as well as SSR / SSG applications, and then you decide on a case-by-case basis?

Additionally, if the app needs extensive offline capabilities. Or if I am somehow required to establish a clear boundary between client and server (which can be a good or very bad thing). In general though, I agree with your point, that we shouldn't have as many SPAs as there seem to be now 👍 3/3

Here are some reasons why I would still develop certain applications as SPAs in 2025: If it's a highly interactive site (think Miro, a chat app, or perhaps some data-heavy enterprise apps). 2/3

I think getting rid of them is a little harsh. About 10 years ago, we moved from server-side rendered pages (JSP / JSF, PHP, Ruby on Rails, etc.) to SPAs because it was hip and trendy. Now, we should not make the 'same mistake' and shift the entire way back. 1/3