Thanks to everyone in our community who participated in both the Control Flow and the Deferred Loading RFC. We're closing out these RFCs, so let's summarize the results of both separately:

Control Flow

tl;dr: we're closing the Control Flow RFC and starting an evaluation of a community-proposed alternative syntax.

On Angular, we've been very happy with our RFC process and the amazing engagement from our community. Our latest Control Flow RFC is no exception. It's surpassed ~600 comments, our highest ever for a single RFC. We put a lot of effort into our design for control flow in templates, and we are extremely grateful for the enthusiasm and excitement from all of you around this proposed change.

When we publish RFCs, we carefully consider everyone's input and iterate on the proposal in response to new information or ideas. In the Control Flow RFC we asked a specific question: "should we consider other syntax besides curly braces for the block tags, or besides# ,/ and:?" Among the many suggestions we received, one community-generated idea has emerged which is both technically feasible and also meets our goals for the aesthetics and developer experience we wanted for this feature. In our initial evaluation, we felt it has both advantages and drawbacks compared to the RFC's proposed syntax, with neither option standing out as obviously superior.

We refer to the community-proposed syntax as "@ syntax", and to the RFC's flavor as "block syntax". Here are potential renditions ofif,for, andswitch in@ syntax:

<header-cmp />@if showBody {  <body-cmp />} @else if showSummary {  <summary-cmp />} @else {  Nothing to see here...}<footer-cmp />

<ul>  @for item of item; track item.id {    <li>{{ item.name }}</li>  } @empty {    <li>No items...</li>  }</ul>

@switch kind {  @case 'human' {    <human-cmp />  }  @case 'robot' {    <robot-cmp />  }  @default {    <alien-cmp />  }}

For completeness, here's a sketch of what the new deferred loading API in@ syntax might look like:

@defer on viewport {  @main {    <!-- this block will be deferred until the placeholder is visible -->    <heavy-cmp />  }  @placeholder {    <img src="ph.png">  }  @loading {    <loading-spinner />    }}

Early Comparison

As part of considering this alternative syntax, we're exploring the tradeoffs it makes compared to our block syntax design. This work is still ongoing, but here's a partial comparison to give you an idea of our thinking:

Advantages of@ syntax

• Less line noise
• Only one special character
• More closely related to JS syntax
• Doesn't overload{ between control flow, text bindings, and ICUs
• Familiar to .NET developers who use Razor templating
• Similarity with Sass control flow & statement syntax
• Provides a complete escape into a space for statements in templates
  • Could be useful for non-block statements (let?import?using?)
• Hypothesis: easier for editors to understand for code folding, brace matching

Advantages of block syntax

• #defer is lighter weight
  • No need to name the "main" content block
• Familiar to developers who've used Svelte, Handlebar syntax
• Doesn't overlap with@ for language decorators
• Doesn't require a migration/breaking change to escape@ and} in template text nodes
• Hypothesis: Similarity to HTML tags makes it easier to identify & read for existing web developers
  • Looks less like plain text
  • Fits in more with other frontend framework syntax

Next Steps

Over the next few months, we'll continue our study of the tradeoffs involved here, and engage with UX researchers to collect quantitative data on both APIs. We also plan on including a question on this choice in our upcoming developer survey. Ideally, these approaches will lead us to a consensus on the right direction for Angular, which we will then share with the community.

Deferred Loading

tl;dr: we're closing the defer RFC with an intention to move forward with the proposed design.

On Angular, we've been very happy with our RFC process and the amazing engagement from our community. The defer RFC had a very positive overall reception with plenty of engagement. We're pleased with the excitement and positivity from all of you around this proposed change.

RFC Questions

1B: Do you see the need to be able to observe when the state of a defer block changes via a signal or event?

• The answer is consistently yes, and this is something we'll explore.

2B: Are there use cases where different deferred blocks in an application should use different timeouts?

• The answer is consistently yes. The overall suggestion is to have a global config with the ability for local overrides.

3B: Is this list of predefined triggers sufficient to handle the majority of cases that users may have? Can you think of other common trigger types that we didn't account for in this design?

• The answer is consistently yes, these are enough.
• The one exception is several suggestions for amedia trigger option to have things trigger based on media queries. This is a use case we'll be exploring to see if it makes sense to add to the design.

4B: Can you think of use cases where you would need to change the default trigger behavior globally for all {#defer} blocks in your application?

• The answer is mixed. Some yes, some only see use cases for this in local dev and testing. No strong signal either way. With this in mind, we're not planning on changing the design for this currently, but we'll keep this use case in mind.

Additional Feedback

LCP impact

There was some concern shared about negative impact to LCP when using defer blocks, which is a legitimate concern if defer is used in some patterns. We'll want to address this in docs with strong recommendations on use cases and patterns that won't affect LCP.

Render Priority

Several comments pointed to a need / desire to have render priority or loading order as an option for the developer to use to optimize how their app performs. This is an area that needs further exploration.

Defer on data

There is a strong interest and multiple comments regarding the desire to have a clear feature for deferring on data retrieval. This is an area for future improvement.

Trigger parameters

We received some suggestions about being able to pass parameters into triggers, specifically the viewport trigger for configuration of the IntersectionObserver. This is another area for future improvement.

Testing

There was a question about testing utilities and how we'll enable testing deferred blocks. There will be a testing API and we're still designing exactly how that will look.

Public API, Strategies, and Caching

Additional feedback that we've captured and will take into consideration for future iterations.

• Some want the triggers to be public api so they can be used elsewhere and have people build on top of them
• Some would like to see reusable strategies, similar to router strategies, for prefetching and triggering
• Suggestion to use Service Worker for caching

Next Steps

Based on this, the feedback is overwhelmingly positive. We should proceed forward with the design as intended, adjusting syntax based on the control flow results. Of the feedback, two items rise to the top: Documentation on LCP impact and some sort of ergonomic testing utility. We'll invest time into exploring these items as part of the initial scope, but otherwise, we candefer the rest but definitely take note of them for future improvements.