SSR (fastboot) by default

[mehulkar]

• Fastboot should be the default experience during development
• Disabling it should be easy and reliable
• Deployment instructions for production usage should be part of guides

motivation

• SSR by default should be encouraged for perf (and seo, but not not everyone cares about seo)
• Integrating SSR late in the game is hard (although some of the Octane paradigms do help).
• turning it on as a first class supported feature would encourage more apps to enable and experiment with it

[Panman82]

I feel like this could turn into another CSP (which was included by default at one time but then removed), it's good to implement but might be a bit too much for on-boarding. Just another thing for new folks to learn/understand while also learning ember. Don't get me wrong, I like the push for making full-fledged, modern, enterprise, whatever.. apps, but I know we're also trying to reduce the learning-curve too.

[webark]

I think a direction this proposal could take would rather then having fastboot be on by default, identifying the bifurcations that are required for fastboot, and making some of those more seamless so there is less friction when choosing to adopt fastboot.

[willviles]

I too see this as another barrier to on-boarding users.

Documentation is king. As with most of Ember, this is an area that needs serious amounts of investment to ensure users can learn about & adopt FastBoot with ease, or at least be aware of the patterns used to make apps FastBoot compatible.

[rwjblue]

In general I do think we should figure out a way to move forward.

I agree completely that we need to avoid rolling FastBoot out to new apps by default until at least these points are addressed:

• Developing a very good testing strategy for FastBoot. I think ember-cli-fastboot-testing is a great start here, but I think we still need a bit more exploration in the space before landing on an "official" RFC for this (@ryanto please correct me if I'm wrong).
• A phased rollout (akin to what we did for jQuery removal) is almost certainly required. Specifically, once we have decided on the aforementioned FastBoot testing strategy (in an official capacity) we can update the addon blueprints to run FastBoot tests as part of their CI system. This will help ensure that addons continue to push forward and are not a blocker for applications to adopt FastBoot.
• Rehydration is still experimental in ember-cli-fastboot, we need to promote that from an experiment to default. This will require addressing some fundamental user interaction issues (which the FastBoot team has been chatting through for quite a while now), but ultimately it will need to be another RFC.

[mehulkar]

I’m on board with a phased rollout. But I think it’s really important for core team to signal that FB is a core feature of ember.

What’s a good first step? Include in the default but turn off by default? Where would the testing story be developed if we didn’t do this?

[knownasilya]

I'm onboard with it being the default as long as we can figure out how to make it more resilient and not take down the server/memory issues any time there is a bug in your app. Like still rendering but partial with good errors, maybe even rendered to the screen.

[mehulkar]

as long as we can figure out how to make it more resilient and

this won't happen until it's actually used and treated as a core feature, IMO

not take down the server/memory issues any time there is a bug in your app

As long as the Ember Welcome Page doesn't cause leaks, I don't think this is a problem.

[mehulkar]

Closed by #579.