I think this is a great discussion on another part of Meteor that has potential for improvement.
As a starter I think we need to outline exactly what existing pain points are we trying to address. I know other frameworks (Next.js) has been pushing hard on all SSR pattern, however from a user perspective, I really don’t see much value in that. The biggest issue with SPAs of the past is the initial load time is linearly promotional to the bundle size, and this has been improved a lot with introduction of dynamic imports. So in my mind, going all SSR is the other unhealthy opinionated extreme of the spectrum with little value added.
I think the focus should be in maturing the APIs and libraries around Meteor’s SSR which is a relatively recent addition to the Meteor core toolkit. I’ve used a dynamic imports and SSR to reduce the load time for the an app from 6s to less then 2s. However, I had to introduce some workarounds and third party libraries to pull the user data, I’ve captured the limitations here and I’m happy to see work being done recently by MDG to improve the API.
In addition to improving the SSR APIs, I think we need to have control over where the merged CSS file is being injected by Meteor, since the injected CSS will impact the critical paint path. This was delaying my load time by 590ms and I’ve captured the issue here.
The browser also spend a lot of time executing the loaded JS files. The larger the JS file, the longer it usually takes, so any reduction is the core Meteor bundle is also welcomed. I’ve also noticed that the more split points I introduce by using dynamic imports, the larger the Dynamic-version.js file gets, in fact this file grew to almost 6% of my bundle size, you can see the chart here, so I think this could also be improved.
With regards to conditionally engaging DDP and having RPC of HTTP, I think that would be awesome! and as you said it’ll provide advanced developers with full control over the data transport layer.
Overall, my personal opinion as a user, is that Meteor is on the right track with SSR and the community can introduce some libraries to complement the API’s and enhance the user experience in the near future. However I’d wait a bit until the recent SSR improvement work is complete. Also, I’d love to see RedisOplog getting more testing and marketing. Concurrent users scaling has been the uncertain part of Meteor, and the fact that it was solved by community (thanks to you) is really exciting!