There are a few other cons for server-side rendering:
Loss of the ability to install mediawiki on a simple hosting platform.
Perhaps we could allow for a graceful fallback, so if MediaWiki is running in an environment where a server-side rendering service is not present, then component rendering happens on the client-side.
Potential real performance penalty (we're calling a nodejs service, which are not known for their stellar performance, via the network for every page view
Maybe there's a way to separate out the rendering needed for unauthenticated users or otherwise generic component displays, and to cache this output, then do per-user customization as part of the client-side render?
Hard dependency of the basic website functionality on a second service reduces the availability of the website by the cumulative downtimes of the SSR component and MediaWiki
We could perhaps timebox the amount of time available for the SSR to some acceptable threshold, so e.g. if the request to the SSR service is more than 200ms, abort the request and fall back to a client side render.
I think the only way we can transform this from a potential liability to an opportunity is if we somehow integrate this with the idea of doing edge-site composition.
Also to note: you're proposing here we submit requests to mediawiki and it makes calls to the SSR; I'm not sure that is the mode they're going for here. Anyways we'll know more once we get more into discussing the details of the project.
> Loss of the ability to install mediawiki on a simple hosting platform
I don't see it this way. If implemented correctly it would gracefully degrade to no server side rendering and there would be no loss of ability.
It's acceptable for skins/extensions to be JS-only with server side rendering an additional extra which requires additional install steps.
Third party skins that are JS only already exist and Extension:NearbyPages which is installable by third parties has no SSR but would benefit from an improved experience if added.
Ok, the proposal doesn't spell out the ability to still function as pure-php as one of the requirements, but that's of course perfectly acceptable.
I apologize for the extremely late response. Between a team offsite and personal circumstances I haven't had time to respond until now. I have added two "con" points to the SSR section based on Giuseppe's comment.
As Kosta said, any approach to SSR that I would propose would involve graceful fallback behavior, both for when the Node.js service is available but temporarily down, and for when the service is not available at all (on a 3rd-party wiki where the service is not installed). As part of the initial discussion I also want us to talk about when it makes sense to use Vue SSR vs when it makes sense to use some other rendering method, and we should consider the potential unavailability (due to temporary downtime or due to not being installed) of Vue SSR as part of that.
