[Complete] RFC: Built-In Control Flow

[alxhub]

Authors: @alxhub @pkozlowski-opensource @jelbourn
Area: Angular Framework
Posted: June 14, 2023
Status: Open

This RFC proposes a new control flow syntax for Angular, and represents a significant change to how we approach control flow in the framework. There are two questions which should be answered up front: why and why now? Let’s start with why:

A core goal of Angular's initial design is that template control flow would be expressed via composition of user-facing concepts only. The structural directive concept serves this purpose: a directive that sits on an <ng-template> declaration and determines when & where embedded views are created from that template. To achieve a familiar syntax for control flow similar to that of JavaScript (e.g. let user of users), microsyntax in the template language provides an alternative binding syntax for configuring a structural directive and its inputs.

Our review of developer experience pain points in Angular has highlighted microsyntax-based control flow as having significant weaknesses compared to syntaxes in other frameworks. The proposed built-in control flow syntax addresses these issues and significantly improves the developer experience, in addition to being a foundation for new features.

As for why now, as a part of our ongoing work on implementing the Signals RFC, we’ve known that the existing zone-based control flow directives would not be able to function in zoneless applications. We will need to implement reactive control flow for zoneless applications. We considered modifying the existing control flow directives to support zoneless applications as well, but decided against this option for a couple reasons:

1. Since every existing Angular application depends on these directives, even the slightest incidental change in behavior could be breaking.

2. Supporting both signal and zone based patterns in a single directive would greatly complicate the code, and it’s unlikely that we could properly tree-shake either pattern if it wasn’t used.

3. We knew we wanted to make bigger improvements to control flow anyway.

We also considered implementing new reactive control flow directives just for signal components, but rejected this idea as we didn’t want to create more differences between signal and zone components than necessary.

As a result, we decided to move forward with this design of built-in control flow for templates, to both support the zoneless/signal work as well as address the longstanding DX issues with structural directives.

Goals and Non-Goals

The new syntax for template control flow has several major goals:

1. Syntactically similar to JavaScript's control flow statement syntax.
2. Syntactically distinct from HTML syntax.
3. Works across multiple templates (if-elseif-else, switch-case-default), including template type-checking.
4. Flexible syntax allowing customization for each use case (if vs for vs switch).
5. Address common pain points.
6. It must be possible to automatically migrate virtually all existing control flow usage to the new syntax.

It is useful to explicitly mention some non-goals of the new syntax:

• User extensibility (defining new control flow structures in userland, or otherwise extending the syntax).
• Composability with other Angular concepts (e.g. placing directives on control flow structures).

Overview

Many templating languages in the open source space have control flow primitives, and we’re fortunate to be able to draw on those ideas and designs from the larger web community. The proposed new control flow syntax is heavily inspired by Svelte’s control flow, as well as the mustache templating language.

The new control flow syntax is introduced in the form of blocks, a new syntactic structure in templates.

Conditional control flow uses blocks with the keywords if and else:

{#if cond.expr}
  Main case was true!
{:else if other.expr}
  Extra case was true!
{:else}
  False case!
{/if}

Switch control flow uses blocks with the keywords switch, case, and default:

{#switch cond.kind}
  {:case x}
    X case
  {:case y}
    Y case
  {:case z}
    Z case
  {:default}
    No case matched
{/switch}

Angular’s switch does not have fallthrough (there is no break operation required).

Loop control flow uses blocks with the keywords for and empty:

{#for item of items; track item.id}
  {{ item }}
{:empty}
  There were no items in the list.
{/for}

Detailed Design

Syntax

The primary syntactic element of the new control flow design is a named block group composed of one or more named blocks. Block groups are template nodes, occupying the same syntactic positions as elements, text nodes, and text bindings. Each block in a block group contains Angular template syntax within it, as a list of child template nodes (potentially including additional block groups).

Each block group begins with a tag of the form {#name} and ends with a matching closing tag {/name}. Tags can contain specific syntax based on their name. As an example, the basic if control flow structure looks like: \

{#if cond.expr}
  <child-cmp />
{/if}

Every block group also defines a named block with the same name as the block group, known as the primary block. The above example thus represents a block group (if) with a single primary block (if), which has the <child-cmp> element as a child.

This syntax is, of course, a blocking feature.

Discussion Question 1A: should we consider other syntax besides curly braces for the block tags, or besides # , /and :? E.g. [if cond]?

Tag syntax

Each named block group can customize the tag syntax following the tag name and a space. For example, the if block group supports an expression following the if, which is used as the if condition.

Different block groups may use this syntactic space in different ways.

Additional named blocks

In addition to the primary named block created by the block group tag itself, additional blocks may be defined within a block group. Additional blocks are specified with a tag that starts with : instead of #. Blocks (including the primary block) follow a set of syntactic rules:

• Valid names for these blocks are statically determined by the overall block group to which they belong. Block names are always part of a statically known set and are never user-determined.
• Additional blocks may be either required or optional, depending on the block group, its options, or the presence/absence of other named blocks.
• Multiple blocks of the same name are allowed.
• The order of blocks in a block group may be semantically meaningful, or may be fixed by the type of block group.

For example, an if block group may define an optional else block:

{#if cond}
  <true-cmp />
{:else}
  <false-cmp />
{/if}

The above syntax creates an if block group with two blocks: the primary if block created by the block group (containing the <true-cmp>) and an else block containing the <false-cmp>.

Like the primary block tag, the syntactic space following the name of an additional block is entirely customizable depending on the block group type.

Optional parentheses

In JavaScript, control flow statements require parentheses (if (cond)). Because block tags are wrapped in braces already, they don't require parentheses. However, we support including parentheses if desired:

{#if (cond)}
  …
{/if}

{#for (item of items())}
  …
{/for}

If used, the parentheses wrap the entire body of the block tag.

Discussion Question 2A: should parentheses be required to maximize similarity to JavaScript/TypeScript?

Nesting

Block groups are "nodes" in templates and can be children of blocks in other block groups. Control flow structures can therefore be nested.

Why # at all?

There are two main reasons why we chose to use a hieroglyphic (#) instead of bare single-curly statements (e.g. {if cond.expr}):

• It provides clear visual distinction in templates between control flow and other elements, especially text bindings which use double curly braces.
• Plain single curly brace syntax {...} is used today for the ICU Message format which supports several i18n features (eg: pluralization).

if block - conditionals

The if block replaces *ngIf for expressing conditional parts of the UI.

The primary if block includes an expression representing the condition under which this block will be displayed.

{#if a > b}
  {{a}} is greater than {{b}}
{/if}

if block groups may also contain one or more else blocks. One bare else block is allowed, as well as zero or more else blocks with an additional condition (indicated by an if keyword following the else name:

{#if a > b}
  {{a}} is greater than {{b}}
{:else if b > a}
  {{a}} is less than {{b}}
{:else}
  {{a}} is equal to {{b}}
{/if}

Aliasing the conditional expression

The current *ngIf supports aliasing of the condition expression via as: \

<div *ngIf="users$ | async as users">
  {{ users.length }}
</div>

To enable direct automatic migration from *ngIf to the new built in conditional statement, aliasing will be supported in if:

{#if users$ | async; as users}
  {{ users.length }}
{/if}

Aliasing only supported for zone components

Because signals are synchronous and side effect free, there is no harm in reading their value in multiple places in the template. In the case of complex conditions or conditions that involve expensive calculations, computed can be leveraged for memoization and de-repetition. For that reason, we feel there isn't a strong use case for aliasing the value of the condition expression in signal components (that isn't better served by computed).

Why not cond as name, similarly to microsyntax?

A long-term goal for future evolution of Angular's template syntax is to make expressions "just TypeScript" (or at least a subset of TypeScript). Because as is used in TypeScript to represent typecasts, we want to allow for expressions including typecasts in the future.

for block - repeaters

The for block replaces *ngFor for iteration, and has several differences compared to its structural directive predecessor. A basic for block group looks like:

{#for item of items; track item.id}
  {{ item.name }}
{/for}

track keys for diffing

The track setting replaces NgFor's concept of a trackBy function. It determines the row key which for will use to associate array items with the views it creates, moving them around as needed. Because for is built-in, we can provide a better experience than passing a trackBy function, and use an expression representing the key instead.

Migrating from trackBy to track is possible by invoking the trackBy function:

{#for item of items; track itemId($index, item)}
  {{ item.name }}
{/for}

The new syntax helps the _run_time by offering you a track and field to run around your loops.

$index and other variables

Within for row views, there are several implicit variables which are always available:

Variable	Meaning
$index	Index of the current row
$first	Whether the current row is the first row
$last	Whether the current row is the last row
$even	Whether the current row index is even
$odd	Whether the current row index is odd

These variables are always available with these names, but can be aliased via a let segment:

{#for item of items; track item.id; let idx = $index, e = $even}
  Item #{{ idx }}: {{ item.name }}
{/for}

Aliasing is useful when nesting for loops, since the inner loop's implicit variables shadow those from the outer loop.

track is required

In our performance research, we've identified NgFor loops over immutable data without trackBy as one of the most common causes for performance issues across Angular applications. Because of the potential for poor performance, we’re making track required for for loops.

There is one exception to this requirement: for for usages in signal components, when the iterable expression is assignable to Iterable<Signal<unknown>>, then track is not required (and in fact, not allowed). That's because when individual rows use signals for reactivity, we want the outer loop to track those signals by their identity and not depend on their values. This allows individual rows to update without triggering diffing of the list.

Cross-country is not required though.

Discussion Question 3A: are there technical objections to requiring track, or other ways to solve performance issues with NgFor that we may not have considered?

empty block

New to for is support for a template to render when there are no items in a list. This is a common community feature request.

{#for item of items; track item.name}
  <li> {{ item.name }}
{:empty}
  <li> There are no items.
{/for}

IterableDiffers

Unlike its structural directive predecessor, the new for will not use Angular’s customizable diffing implementation (IterableDiffers), but instead will use a new optimized algorithm (which would not be customizable).

Discussion Question 4A: do you have a use case for customizing the diffing algorithm by customizing IterableDiffers today?

for in signal components

In signal-based components, for is reactive. The iteration variable and all of the special variables created for each row are signals instead of plain values, and must be unwrapped via their getter. This allows each row created by for to change detect independently of the view containing for, and allows for to work in zoneless applications.

switch block - selection

The syntax for switch is very similar to if, and is inspired by the JavaScript switch statement:

{#switch condition}
  {:case caseA}
    Case A.
  {:case caseB}
    Case B.
  {:case caseB}
    Case C.
  {:default}
    Default case.
{/switch}

#switch has several major benefits over NgSwitch:

• It does not require a container element to hold the condition expression or each conditional template.
• It can support template type-checking, including type narrowing within each branch.

Note that the primary block within the switch group is unused. It will be an error to have any child nodes inside that block.

switch does not have fallthrough (there is no break operation required).

Migration Considerations

It should be possible to write an automated migration schematic which converts from NgIf, NgForOf, and NgSwitch to their equivalents in the new syntax, with a few exceptions which this section considers:

Observation of structural directive presence

Existing code may look for the presence of NgIf, NgForOf, or NgSwitch directives explicitly. This could take a few forms:

• Using ViewChild queries to find control flow directives.
• Injecting control flow directives from co-directives on the same <ng-template>.
• Using control flow directives as host directives.

Iterable Differs

Angular makes it possible to customize the diffing algorithm used by NgForOf via the IterableDiffer interface and associated DI token.

Theoretically an application could customize diffing in a way that would break if migrated to use for. This could result in strange behavior when the iterable changes or, in the worst case, a complete failure to render.

Future Opportunities

This section captures potential future improvements which aren't in scope for this design, but could be achieved on top of this syntax in the future.

for..in and other loop styles

Not in scope for this design is support for other iteration flavors in JS, such as for..in loops, async iteration, etc. Such additions would theoretically be possible under the current syntax. So for now, Angular will see these other loop styles as…for-in.

Discussion Question 5A: are there other flavors of looping which would benefit your applications today?

Virtual scrolling

We could extend the syntax of for to support some kind of abstraction for a viewport and scrolling controller, that would enable virtual scrolling on top of the built in syntax.

Destructuring

We could support binding patterns (destructuring) as JS loops do.

Alternatives Considered

HTML-based control flow

Instead of the mustache-inspired syntax {#if …}, we considered using HTML syntax such as tags prefixed with the ng namespace:

<ng:if>
  …
</ng:if>

This concept was rejected for several reasons:

1. Using attribute/binding syntax for condition expressions, loop variable declarations, etc. diverges from JS control flow syntax.

For example, the condition of <ng:if> would likely be expressed as <ng:if cond="expr"> which looks less like JS control flow.

2. Multiple templates would require more verbose inner structures.

An if-else block would take the form:

<ng:if cond="expr">
  <ng:then>
    True case
  </ng:then>
  <ng:else>
    False case
  </ng:else>
</ng:if>

This has a lot of visual overhead compared to the proposed block language.

Continuing with Microsyntax

Another option considered and not taken was to continue using Angular microsyntax to express control flow in templates. Our compiler could detect usages of *ngIf, *ngFor, and *ngSwitch and generate special code for them. We could use this mechanism to circumvent some of the limitations of the directive-based implementations of control flow, while not introducing new syntax to learn.

We rejected this option because improving the DX of control flow beyond the microsyntax form is one of the main goals of introducing built-in control flow. Having built in implementations of the original structural directives would also introduce magic which might confuse advanced users, as these directives would no longer behave according to the mental model for regular structural directives.

The microsyntax model also does not support multiple associated sub-templates for a control flow statement, so we would not solve the problem of *ngIf's else case being extremely awkward to use.

Frequently Asked Questions

Q: Will the existing structural directives (NgIf, etc) continue to work?

Ideally, it will be possible to replace most usages of the existing structural directives from @angular/common with the new syntax, and we will have an automatic migration to do so. Given that, we plan to strongly encourage developers to switch to the new control flow syntax to take advantage of the developer experience improvements.

That said, we're also aware that all existing Angular content (blogs, books, videos, etc) will continue to reference the existing directives for a long time. Currently the plan is to deprecate the existing directives but not remove them until the ecosystem (including community-authored content) has switched over to the new control flow. Ultimately, we will base this timeline on the feedback we receive from the community.

In the rare cases where automatic migration fails (e.g. for NgForOf cases discussed above) we could apply similar techniques that we’ve used before in CDK/Material, such as generating a clone of the structural directive in the user’s project.

Q: Will the structural directive concept itself be removed?

No, structural directives are an essential feature for application architecture in Angular, and we have no plans to remove them.

Q: Will the new control flow be syntax highlighted?

Yes, the Angular Language Service will highlight the keywords and expressions within the new control flow blocks.

Q: Will the new control flow affect query results at all?

Query results will work the same way as with the existing ngIf, ngFor, and ngSwitch

Q: Will the new control flow still define & create embedded views?

Yes, the technical internals of the new control flow will use the same concepts as the structural directives, including <ng-template>s and view containers.

Q: Will I still need to import the new control flow into my components?

No, it will be built into the template language and automatically available to all components.

Q: Will the new control flow be as tree-shakable as the previous version?

Yes, if an application doesn’t use a particular block group (e.g. switch), its code will not be included in the production bundle.

Q: Will the new control flow have better performance?

There may be some marginal improvements, especially for for and diffing. We expect larger memory usage improvements.

We may also be able to implement compiler optimizations in the future that would not have been possible with the previous user-land control flow. For example, we know that if’s embedded view is only created once, which might allow us to optimize some data structures.

Q: Why are we planning more changes instead of delivering on signals?

The existing control flow directives are based on zones, and so changes to control flow (particularly for) are required to support fully zoneless applications. Given that we need to change control flow anyway, we’re taking the opportunity to update the design and address other commonly reported DX pain points as well.

Note the section on for exposing its loop variable as a signal in signal-based components above. This is required to properly notify each child row’s view when its data changes (and it must be change detected).

Q: Can libraries define their own block groups?

For now, no – block groups will be a template language builtin, and not a user extension point. We are interested in researching whether it makes sense to expose some kind of extensibility here, what use cases there might be, and what form such a feature might take.

Q: Can I add directives to the new control flow blocks?

No. This is another area where we’d like to research potential use cases.

Q: What about the CDK’s virtual scrolling functionality?

The CDK will continue to provide its existing structural directives for virtual scrolling and other use cases for the time being. We will be researching whether it makes sense to either convert some of the CDK’s structural directives to built-in syntax, or to add extension points to the existing syntax for the CDK to build on (for example, to support virtual scrolling in for).

Q: Is this syntax valid HTML?

It is valid HTML, in the sense that to an HTML parser block groups are indistinguishable from plain text nodes (like Angular text bindings). We did explore using HTML pseudo-elements for control flow instead but rejected that design for several reasons (see the Alternatives Considered section above for details).

Q: Will there be other built-in blocks in the future?

Maybe 😉 we're #deferring this decision.

[JeanMeche]

Happy to see we have improvements on the side of trackby. The previous implementation was so off putting !

I see this new synthax as a big DX improvement 🔥🔥

[swami-sanapathi]

Correct me if I am wrong, the new track keyword doesn't require function implementation in component. right? @JeanMeche

[eneajaho]

It doesn't.

You can directly say: {#for item of items; track item.id}

[swami-sanapathi]

Yay :D Really it improves DX <3

[definitely-unique-username]

Does this new syntax cover the case when the same template is used for multiple else blocks?

<ng-container *ngIf="!loadingA; else loadingTemplate">A</ng-container>
<ng-container *ngIf="!loadingB; else loadingTemplate">B</ng-container>

<ng-template #loadingTemplate>Loading...</ng-template>

Right now I see that it can be achieved only via ngTemplateOutlet.

{#if !loadingA}
  A
  {:else}
     <ng-container *ngTemplateOutlet="loadingTemplate"></ng-container>
{/if}
{#if !loadingB}
  B
  {:else}
     <ng-container *ngTemplateOutlet="loadingTemplate"></ng-container>
{/if}

<ng-template #loadingTemplate>Loading...</ng-template>

[alxhub]

Right, or extract the shared template into a component.

[LayZeeDK]

Re: Discussion Question 5A: are there other flavors of looping which would benefit your applications today?

Block names are always part of a statically known set and are never user-determined.

Q: Can libraries define their own block groups? A: For now, no.

How come the third-party Angular ecosystem will not have the same capabilities as the Angular framework?

Until now, features like these and Deferred Loading have been supported by Angular's common directives and pipes that have not had special capabilities. This has led to innovations such as the let directive, the push pipe, and RxAngular Template declarables like RxIf, RxFor, and RxVirtualFor. I worry that giving built-ins special capabilities will hinder future innovation in this space by the Angular community.

[JeanMeche]

I mean, structural directives aren’t going away. How would that change something ?

It’s about control flow here 👍

[e-oz]

I understand the reasoning of the Angular team why they don't want to make the new control flow syntax extensible - once they'll provide an API, they are limited by the given API. That API would have a chance to be beneficial for the third-party directives, but the unhindered evolution of such a defining feature of the framework is more important.

[LayZeeDK]

It’s about control flow here

It seems that this is also the RFC for Angular Blocks even though there are no discussion questions related to this, only conclusions.

[thomasmarcelin]

Is there any chance we could see this applied to content projection ?
For instance, {#content .class} instead of <ng-content select=".class">

Generally speaking, is there any plan to extend this structural directive remodeling to other Angular-specific matters ?
Great job on this RFC 👍

[pkozlowski-opensource]

Maybe :-)

[kbrilla]

What about

{#content .class}
  {:empty}
     No content provided
{/content}

and

{#template template}
  {:empty}
     No template provided
{/template}

instead of

<ng-container *ngTemplateOutlet="template || defaultTemplate> </ng-container>
<ng-template #defaultTemplate> 
     No template provided
</ng-template>

[tayambamwanza]

Why not just work with slot element, at least that way you get all the benefits of standard html tools as well

[KhizerRehan]

Great Suggestions @kbrilla IMO, it will further improve DX and helping devs to keep more consistent with syntax and coherent with new proposed syntax +1

[robmv]

About the syntax not being as HTML elements. ¿Have been there any other considerations about how this affects other IDEs outside VS Code language servers?

I have no problem sometimes using a simple HTML editor to edit a template and have collapsible control structures in the editor because they were added to elements, now that they will look like any other CDATA on the HTML file, editors must be adapted to understand that a big {#if.... content can be collapsed.

[DavidANeil]

Also, the Angular Language Service has performance problems that makes it unusable in our monorepo, so for us this would mean we would all basically be losing sane syntax highlighting if we adopted this feature.

We used a previous templating language before Angular, and one of the main reasons for our deprecating it was that no IDEs could syntax highlight it correctly. I would hate to see our devs stop wanting to use Angular for the same reason.

[e-oz]

IDEs will adapt, it's their job.

[imaksp]

Syntax looks powerful, but with this I think we should use new template extension like .angular , so all IDEs can easily identify & format it.

[JosefBredereck]

Angular seems too long, how about just .ng

You never type it by yourself.
More understandable than .html.ng

[tayambamwanza]

I used to just be open to .ng (not .html.ng nor .ng.html), now I actually think it would be the best. Tooling can better interpret the files because it can be known from the beginning that an angular file is being dealt with, not an html file with extra syntax.

It's the same argument as when React devs say JSX is just javascript when actually it's not, it's a form of JS+, as angular devs we've actually been doing the same thing but with .html files, we're using .html but not actually, it's sort of valid html but more like html+, so I think it would be best to "own" that angular template is something different from plain html.

I know some wont like me bringing up other frameworks, but look at Vue, vue is actually using semantically correct html in it's templates, like angular used to have before self closing tags, and yet they still didn't go with .html

Maybe .ng could even be an experimental format for new syntax changes like this rather than messing with existing .html system, so that when you see .ng at least you can make that seperation (Ok this file will contain new syntax), and slowly migrate over to .ng , just my take.

It would probably cause an uproar though lol.

[wartab]

A good meme would be to call it htmlx or xhtml then

[imaksp]

@tayambamwanza I also like the idea of new syntax applicable to new extension only, & signal based components can only be supported in new .ng or .angular templates.

[hirenchauhan2]

How about the extension .ngt which implies angular template?

[DmitryEfimenko]

Q: Can libraries define their own block groups? No

This is very unfortunate. I think that this change is a great opportunity to make this syntax available for ALL structural directives. This would:

• make syntax for structural directives shorter in many cases
• make the difference between attribute and structural directives more apparent visually

[lkster]

I would also vote for @ syntax. Like mustache is an example for {# } syntax, Laravel's Blade would be good example here. We could also look at ASP.NET's Razor but it's going more for invoking C# code within a template (eg. it's @{<C# code>} or that we could just call methods when prefixed with @ syntax) Anyway it's still battle-tested syntax that's widely used and could be considered as an alternative. For me it's more clear and (which is also important) easier to write than curly braces (typing single @ instead of curly brace + #):

@if(a > b)
  {{a}} is greater than {{b}}
@elseif(b > a)
  {{a}} is less than {{b}}
@else
  {{a}} is equal to {{b}}
@endif

@switch(condition)
  @case(A)
    Case A.
  @case(B)
    Case B.
  @case(C)
    Case C.
  @default
    Default case.
@endswitch

@for(item of items; track item.name)
  <li>{{ item.name }}</li>
@empty
  <li>There are no items</li>
@endfor

Btw. even if mustache-like syntax will stay - why is it {# } and not {{# }}?

[hannah23280]

Me vote for this too. Too many curly bracket, confusing.

[naveedahmed1]

Instead of having @ for @elseif, @case` etc, it would be great if compiler could auto detect these blocks like it does in Razor:

@if (value % 2 == 0)
{
    <p>The value was even.</p>
}
else if (value >= 1337)
{
    <p>The value is large.</p>
}
else
{
    <p>The value is odd and small.</p>
}

@switch (value)
{
    case 1:
        <p>The value is 1!</p>
        break;
    case 1337:
        <p>Your number is 1337!</p>
        break;
    default:
        <p>Your number wasn't 1 or 1337.</p>
        break;
}

@for (var i = 0; i < people.Length; i++)
{
    <p>Name: {{ people[i].Name }}</p>
    <p>Age: {{ people[i].Age }}</p>
}

@foreach (var person in people)
{
    <p>Name: {{ person.Name }}</p>
    <p>Age: {{ person.Age }}</p>
}

As far as the code readability is concerned, in case of Razor, here's how Microsoft's IDE's highlight the code:

I believe same could be achieved for the Angular syntax.

Ref: https://learn.microsoft.com/en-us/aspnet/core/mvc/views/razor?view=aspnetcore-7.0

[pablomaurer]

Love the Laravel Blade syntax!
Have a look at sarahs tweet

[EinfachHans]

i do like the "new" syntax but i'm unsure about a deprecation & future removal of the old syntax. Sometimes if a have a very sinple code like

<my-cmp *ngIf="variable" />

it would extend into two more lines because i have to open and close an if 🤔

[imaksp]

Yes its small trade-off for such simple templates, but for complex templates this will bring very big improvement. it will remove need of multiple nested ng-container for complex templates. for example currently *ngIf cannot be used with *ngFor so you need new ng-container.

[coyoteecd]

The trade-off is not that small considering that in projects, the simple case may appear quite often compared to the more complex scenarios. I am not enjoying the added extra lines (or the weird-looking one-liners proposed elsewhere in comments)

[tomer953]

yeah I mentioned the same thing earlier.
I totally agree.
what is wrong with the current ngif anyways? why not supporting both? is it signals related?
why not converting all ngif to the new syntax in build time?

[csvn]

what is wrong with the current ngif anyways?

They mention that in the RFC, the current directives are not compatible with signals, and is part of the reason they decided to work in this new syntax. I think the intent is to avoid making more footguns where "this directive works, but only if the component is not signal-based". Having multiple ways to do the same thing is also a drawback when learning the framework.

Having one way to do something could therefore help avoid complicating the framework for a small gain.

Do blocks have to be on separate lines? I don't think this one-liner is much worse than the *ngIf version.

{#if cond}<my-cmp />{/if}

[imaksp]

@coyoteecd I agree but supporting if-else if , switch case & make it look like js/ts will need this type of change & for simple cases it will add an 1 or 2 extra lines. Also It will be possible to write simplified logic with if-else-if / switch support so I think trade-off is worth.

[james-schwartzkopf]

With the switch, could we get some way of getting errors when a case is left out.

https://blog.marksauerutley.com/absurd/

[ajitzero]

This would be a great addition to getting some more type safety! Just like the enhancement of not having a fall-through (and consequently not needing break statements), this is a must-have as well, but perhaps as an opt-in parameter.

Something like:

{#switch condition; use="EnumOrObject"}
  {:case caseA}
    Case A.
  {:case caseB}
    Case B.
  {:case caseB}
    Case C.
  {:default}
    Default case.
{/switch}

EnumOrObject above would be a Record<case, someValue> and use could do a keyof | key in to extract the required keys expected in the cases. Or we could also pass an array of cases as a Set.

[james-schwartzkopf]

They can get the type from condition, just like in TS. We might be able to do something ourselves by using condition in {:default} to force a check of the narrowed value against 'never', but it might be clearer to have something like {:default-never}.

[tomer953]

Awesome!

however, the new if syntax is a bit complex when you need a simple if case:

<app-admin *ngIf="isAdmin" />
imo its so much cleaner then the proposed 3 lines alternative:

{#if isAdmin}
<app-admin />
{/if}

can we at least have some shorthand syntax for simple if statement?

[JeanMeche]

I agree, it would be great to have some sort of shorthand for simple cases like that ! 👍

[tomer953]

plus, following the same direction we can make shorthand to if else, like the trinary ? operator does in javascript:
(cond) ? true : false

maybe something like:
{#if isAdmin (#adminTemplete) : (#userTemplate)/}

or
{#if isAdmin (<app-admin/>) : (<app-user />)/}

[imaksp]

This is a good idea self closing block could be helpful in such simple case.

[tomer953]

also, why deprecated the ngif structural directive. why not both?
I can already see 3rd party packages implement ngIf after the deprecation to allow the community to use the old syntax...

[alxhub]

also, why deprecated the ngif structural directive. why not both?

Where possible in Angular we try to have one supported, opinionated way of doing things. Since we can automatically migrate the existing directives to the new syntax, we'd prefer to not keep the ecosystem split across both options.

[PowerKiKi]

Discussion Question 1A: should we consider other syntax besides curly braces for the block tags, or besides # , /and :? E.g. [if cond]?

3 differents symbols is too complicated. Keep it simpler with a single symbol, eg @

Discussion Question 2A: should parentheses be required to maximize similarity to JavaScript/TypeScript?

I'd say optional. But really it wouldn't make much of difference for me if it was mandatory.

Discussion Question 3A: are there technical objections to requiring track, or other ways to solve performance issues with NgFor that we may not have considered?

Do not require track. Because less experienced, or in a hurry developers, will fill it in with some "default value" without actually thinking about it. And then it would be a pain to review every single track to know whether the "default value" is indeed what is best for performance, or if it was just the developer laziness.

In contrast, the absence of track is an easy indicator that something could be done to improve performance of that particular template if the need arise, at a later point.

Discussion Question 4A: do you have a use case for customizing the diffing algorithm by customizing IterableDiffers today?

No.

Discussion Question 5A: are there other flavors of looping which would benefit your applications today?

No.

Short syntax

Please, please, please, do come up with an alternative short syntax for simple use of if that are extremely common in our templates. IMHO, this should really be done at the very least for if, but it might also benefit loops too.

One suggestion already made, looks very reasonable to me:

<div @if="users">
    <h1>List of users:</h1>
    <ul>
        <li @foreach="users as user">{{ user.name }}</li>
    </ul>
</div>

That is different enough for the compiler to do something different than the existing *ngIf, yet familiar enough for existing users to pick up relatively easily. But most important of all, it does not force use to write 10 lines instead of 6, as the proposed syntax would:

{#if users}
    <div>
        <h1>List of users:</h1>
        <ul>
            {#for user of users; track user.id}
                <li>{{ user.name }}</li>
            {/for}
        </ul>
    </div>
{/if}

[antkhnvsk]

3 differents symbols is too complicated. Keep it simpler with a single symbol, eg @

I agree, also it's too much Shift + something symbols for very common/repetitive part.

If it's impossible to avoid special symbols. then let it be * as it used already for structural directives.

[royappa]

Great example and comparison. The 6 lines is much shorter but for some reason its 10-line equivalent looks clearer. I think the reason is the longer version clearly separates control flow from the actual HTML. For me, as an inexperienced developer, the second example makes it much easier to see the exact HTML that is going to be generated by this code. I could understand if experts prefer the more concise syntax.

[patricsteiner]

agree, very much prefer the short version <div @if="users">!

[tomer953]

agree, a shorthand for if is a must.

b.t.w, the @foreach should be in the li instead of the ul.

[JamieBohannaWebDev]

Am I the only one here that absolutely despises this new syntax?

Apparently not, considering that a large chunk of the emoji responses are negative (down thumbs, unsure face).

Enforcing this change, and moving away from directives will directly influence my team to migrate away from Angular to Vue for all new projects.

I enjoy Angular for it's clean presentation and strong separation of concern.

Directives such as *ngIf are fine because they're inline with the HTML and represent a similar style to native html attributes.

What I despise about this is that there is something other than HTML attributes, tags or directives being added into the HTML. It makes it harder to quickly and effectively read the HTML file because now you have to consider nested logic. It's one of the main reasons that I despise React because despite managing multiple React engineers over the last half decade, almost every single code base I've read is practically unreadable and removed from any concept of 'clean code' due to the monstrosity that is JSX.

Obviously this is just my opinion, and I accept it being a 'hot take'.

RIP Angular 2023. 😭

[pfeileon]

I don't like XML and HTML as is, and this change, which puts (even more) verbosity and Angular specific syntax on top, makes it even worse for me.

I hoped that the goal of supporting more TS/JS syntax in the template would be prioritized. Personally, I'd trim everything down to JS(ON), TS and HTML, as it would make Angular easier to read, learn and work with.

But this syntax is a step in the wrong direction. It feels as if 2010 was calling...

[tayambamwanza]

Svelte is more modern than React though and uses such, so I don't think we're going backwards

[nicholas-eden]

Just because someone invented a new thing doesn't make it inheritly better. Angular is much easier to learn thanks to using html for it's template and keeping the template away from the code.

Why do we have to be more "modern"? Why not try to make Angular better without sacrificing it's identity?

Angular was a break from the ugly mustache templates, but not we're going back to it? Get out of here.

[tayambamwanza]

Aren't we already using {{}} in angular, so we already using non html templates lol

[pfeileon]

"{{}}" is a good example of anachronistic pre-es2015 syntax: What I really want to write is ${}.

[neistow]

I'm getting Jinja vibes and they are not good at all. 3 Lines of markup instead of 1 plus it looks VERY foreign to angular.

I'm getting a feeling that due to signals there will be so many changes, like reactive forms, router, etc. that at some point it would be logical to create a new framework (hello, angular.js story)

[ronniebarker]

@neistow when there is an arbitrary "next block somewhere" that has the else, it feels like it could get lost. What happens in that case where you have something like:

<div v-if="type === 'A'">A</div>
Hello, World
<div v-else>NOT A</div>

When does Hello, World get rendered?

[neistow]

@ronniebarker Here is answer to your question. But that's a Vue approach. I think that in Angular dangling else blocks should be a compile-time warning. Conditional statements should be strictly sequential.

[neistow]

@e-oz partially agree that implementing a conditional flow as a structural directive was a mistake. New conditional flow structures should be treated specially by the compiler but still should be close to what we have now and my hypothetical ng-if is what I like to see.

[neistow]

@Kordrad due to structural directive limitations, I guess. I don't think there is a robust way to implement a vue-like approach to conditional rendering with structural directives.

[e-oz]

@neistow I have a detailed answer here: https://dev.to/oz/why-i-like-the-built-in-control-flow-idea-2o69

[flensrocker]

I guess each block has to be a valid view, right?
The current syntax looks to me like a preprocessor or macro system.

So I'm tempted to write something responsive like (maybe with an own block name for breakpoint conditions)

<div
{#if lt-md}
  class="col-layout"
{:else}
  class="row-layout"
{/if}
  other="attribute">
 ...
</div>

If every block has to be a valid template, then a tag like syntax would be clearer.
But I read the comment about attribute binding etc.

Maybe one tag to rule them all?

<ng [if]="condition">
  ...
  <ng else [if]="...">
    ...
  </ng>
  <ng else>
    ...
  </ng>
</ng>

And like ul with li nothing should be in between...

[leomayer]

1A make it for newcomers easy to understand
2A I would prefer () on the if statements especially since the ts code requires them anyway
3A I'm unclear how the trackby would work with multiple attributes. When receiving data from the server we don't have all data equipped with IDs - although it might be beneficial 😉 but what about a 'label' and 'status' entity which renders like

<div class="e.status">{{e.label}}<\div>

How to apply the trackBy function for this case? To my understanding a change of the status would not be recognized if not tracked.
4A never seen before, didn't even know they existed 😉

[AGDholo]

The proposal of RFC grammar and early many PHP template engine is too similar, but only the last laravel blade survived at https://laravel.com/docs/10.x/blade
I guess people have voted with action, at least in the PHP space. I don't think this grammar is a step towards modernity, just a repetition.

foreach ($users as $user)
    @if ($user->type == 1)
        @continue
    @endif
 
    <li>{{ $user->name }}</li>
 
    @if ($user->number == 5)
        @break
    @endif
@endforeach

[JelleBruisten]

One problem I see with this syntax is that the @ symbol is already used for animations:

@for(user of users(); track user.id)
  <app-user-comp [class.is-you]="user.id === auth$.user().id" [user]="user">
    <div class="custom-user-template">
      @if(user.imgSrc)
        <img [@someAnimationName]="animationExpression" [ngSrc]="user.imgSrc" loading="eager" />
      @else
        <img [@someAnimationName]="animationExpression" ngSrc="avatar.png" loading="eager" />
      @endif
    </div>
  </app-user-comp>
@empty
  <app-card i18n>No users added yes :(</app-card>
@endfor

It becomes a bit confusing when the @ symbol is used for both control flow and animations. Unless we also want to change the animation syntax to other another.

[@someAnimationName]="animationExpression"

[mlc-mlapis]

The Angular animation can use syntax without square brackets, as shown in the doc example:

<div @myInsertRemoveTrigger *ngIf="..." class="...">
  <p>The box is inserted</p>
</div>

But I still don't think that it should be a problem.

[kyjus25]

If anything I feel like the fact that it's already used for animations is a good indicator that it should be @ so it matches

[JelleBruisten]

@kyjus25 That it should be used for animations, control flow or both?

[kyjus25]

@JelleBruisten that it should be both animation and control flow syntax

[muhamedkarajic]

I like the idea very much however I don't really like the way the syntax looks like. It seems counter intiutive. I'm not saying that it should be different but I would like to ask if we could maybe make it more looking like javascript.

if a > b // Can't you make it so we don't have this ugly brackets? Or if it starts with # the hole line if like that maybe?
{{a}} is greater than {{b}}
else if b > a
{{a}} is less than {{b}}
else
{{a}} is equal to {{b}}
{/if} //Do we seriously need this? Looks so criptic.

Another idea would by why don't we get just JSX or something simular you would not need backwards compatibility because you could just change the html to be htmlx or something like that...

Just some ideas. Great to see we finally are moving towards a more modern approach!

[wartab]

Since you seem to know many things, could you enlighten us on what the following would do without delimitting where the if statements stop?

<if condtion="a < b">
A
</if>
<if condtion="x < y">
X
</if>
<else>
ELSE
</else>

[muhamedkarajic]

Since you seem to know many things...

Please in future @wartab refraim from writing such sentances, it makes everyone on the edge. If you haven't read what I wrote I clearly stated that I'm not sure my self what the sintax would be but that I just find it from someone who was using for a long time Angular unnatural.

...could you enlighten us on what the following would do without delimitting where the if statements stop?

The HTML suggestion was just some suggestion, I'm fine completly that the comunity has a part in deciting and that my suggestion was negativly voted. However what I really think is far from ok is making the point that I have given some half baked solution and that anyone who dose that should be ashamed not having trougth of potential edge cases.

As I stated already above, I'm not going to consider whats the implementation but I would have just imagined it that its possible, the angular team is the one who has to know if its possible or not. Ofc the else will be based on the above if, in your case x<y. I don't see whats the problem with that and if there is a problem I wasn't here about dicsussing the posibilities of the HTML interpreter from Angular but rather stating my oppinion on the sintax which I and many other angular devs will be using.

However thats not the point, I don't really think you should be the one stating those kind of things to people cause you kill other members from giving their feedback. If you don't like what I have said you can state it on this comment and I'll be glad to revisit it but to me it seems you prefear the svelt sintax and take it personally and that I find unprofessional.

[wartab]

And what do you do if you want the else-block to match the first if instead of the second?

[muhamedkarajic]

You trolling bro? lol

[tomer953]

I don't like the syntax neither, but it can be nested since it has a closing tag (just like normal html)
for example:

if (currentTime < 12) {
    console.log('Good morning!');
    if (currentTime < 6) {
        console.log('It is really early, you might want to sleep a bit more!');
    } else {
        console.log('The day is fresh and full of potential!');
    }
} else if (currentTime < 18) {
    console.log('Good afternoon!');
} else {
    console.log('Good evening!');
    if (currentTime > 23) {
        console.log('It is getting late, you might want to consider going to bed.');
    } else {
        console.log('The night is young, enjoy your evening!');
    }
}

will be:

<if cond="currentTime < 12">
    Good morning!
    <if cond="currentTime < 6">
        It is really early, you might want to sleep a bit more!
        <else>
        The day is fresh and full of potential!
        </else>
    </if>
</if>
<else if="currentTime < 18">
    Good afternoon!
</elseif>
<else>
    Good evening!
    <if cond="currentTime > 23">
        It is getting late, you might want to consider going to bed.
    </if>
    <else>
        The night is young, enjoy your evening!
    </else>
</else>

and with the RFC syntax:

{#if currentTime < 12}
    Good morning!
    {#if currentTime < 6}
        It is really early, you might want to sleep a bit more!
    {:else}
        The day is fresh and full of potential!
    {/if}
{:else if currentTime < 18}
    Good afternoon!
{:else}
    Good evening!
    {#if currentTime > 23}
        It is getting late, you might want to consider going to bed.
    {:else}
        The night is young, enjoy your evening!
    {/if}
{/if}

personally I prefer the RFC syntax

[saithis]

I think the twig template engine syntax would be easier to read and remember:
{% if %}
...
{% endif %}

basically every statement (if, endif, switch, case, etc.) is wrapped in {% %}. This way you dont have to remember when to use "#", ":", etc.

[borisjotic]

Good addition to the framework, keep the good work! 😄

1A: They are fine as presented.
2A: It looks more nature, but I'm not strict about it. This is one of the things where time will tell. People will always put things in HTML that aren't needed there. It's better to educate people to simply move complex conditions away from HTML.
3A: As I see no.
4A: No.
5A: No.

Additional question for {:empty} will it be triggered for only [] or it will work with falsy values as well?

[DavidJournot]

I wonder if it would be easier to read when placing the tag ":" at the closing curly braces, instead of "#" or ":" at the opening one.

Besides readability, I love this proposal, thanks for the work!

{if cond.expr :}
  Main case was true!
{else if other.expr :}
  Extra case was true!
{else :}
  False case!
{/if}

{switch cond.kind :}
  {case x :}
    X case
  {case y :}
    Y case
  {case z :}
    Z case
  {default :}
    No case matched
{/switch}

{for item of items; track item.id :}
  {{ item }}
{empty :}
  There were no items in the list.
{/for}

[alxhub]

This kind of syntax is generally more difficult to parse, because the language grammar would be context-sensitive.

[DavidJournot]

Thank you for the answer, I didn’t know about context-sensitive grammar.

I have a mixed feeling about the proposed syntax for Control Flow. On one side it's great that this syntax is already used outside Angular, on the other side I find it strange like many others here.

[someonewdc]

Can someone describe how should I use structural directives with the new syntax?

Will it look something like this?

{#if condition}
  <div *myStructDir>{{ variable }}</div>
{/if}

If so, how it should work in zoneless app? I mean that structural directive implementation is similar to the old control flow one, so it should call the same problems, isn't it?

[mlc-mlapis]

You are right. Your example is correct. Generally, all custom structural directives must be changed for the Zone-less environment. It is necessary to implement Signals somehow. The Angular team will probably document the recommended way later.

[alxhub]

The general thinking is that directives will have the signal flag too:

@Directive({signals: true})
...

This means a few different things:

• inputs will be signals
• host bindings will be reactive
• the directive doesn't depend on global state being change detected via zones

For structural directives, there's an additional constraint that important: if a structural directive instantiates a template using its ViewContainerRef, it must communicate changes to that template's context via signals. That is, if the let variables received by the template can change over time, those changes should be communicated via signals.

[samuelfernandez]

@alxhub Could you please exemplify how a structural directive with signal based context would work? 😅

[alxhub]

Here's how you'd implement something like <ng-container *ngLet="data().deep.expression as aliased"> {{ aliased() }} </ng-container>:

@Directive({signals: true, selector: '[ngLet]'})
export class NgLet {
  value = input({alias: 'ngLet'});
  private vcr = inject(ViewContainerRef);
  private tmpl = inject(TemplateRef);
  
  ngOnInit() {
    this.vcr.createEmbeddedView(this.tmpl, {$implicit: this.value /* this is a signal */});
  }
}

[dwilches]

I overall like the idea of the new syntax, the old one was too verbose for writing an else clause due to the need of having a ng-template for example.

should we consider other syntax besides curly braces for the block tags

The choice of { feels natural as Angular already relies on curly braces {{ for the rest of the template operations.

or besides # , /and :? E.g. [if cond]?

Instead of those 3 rune-like characters (#, : and /) I would like to propose using # everywhere (changing the closing tag to #end) like this:

{#switch cond.kind}
  {#case x}
    X case
  {#case y}
    Y case
  {#default}
    No case matched
{#end}

Which would make the syntax more homogeneous.

should parentheses be required to maximize similarity to JavaScript/TypeScript?

If parentheses are not needed, I think they shouldn't be made mandatory. The whole new syntax doesn't look like JavaScript anyways, and doesn't need to be: different concept for async, no colon after case/default, the # is not JS, different meaning on {, requirement of a special word to close a block, etc.

Besides, this syntax draws inspiration from Svelte, which doesn't enforce parentheses, so it makes more sense to me to try to make it look like Svelte instead of JavaScript.

are there technical objections to requiring track, or other ways to solve performance issues with NgFor that we may not have considered?

I would prefer to not make it "required" but optional as it's today. In many cases our app need to display elements that don't have an identity field (and which don't change over time), so forcing to specify something like track identity() would just make unnecessarily more verbose.

Thanks.

[andreimatei]

The section about if got me curious:

Why not cond as name, similarly to microsyntax?

A long-term goal for future evolution of Angular's template syntax is to make expressions "just TypeScript" (or at least a subset of TypeScript). Because as is used in TypeScript to represent typecasts, we want to allow for expressions including typecasts in the future.

What exactly can can go in these expressions today (for both ngIf and the next if)? I imagined that they're already "just TypeScript", but I'm probably naive.

[alxhub]

The "Angular expression language" as we call it is a separate language which looks similar to JavaScript's expression syntax, but with some bigger differences:

• It only supports a subset of JS syntax (e.g. you can't define classes, functions, lambas, etc).
• It has custom syntax (pipes) which are not a part of JS.
• It has some syntactic elements (such as safe-property navigation) which look like the JS syntax but have different semantics. For example, Angular safe property navigation produces null instead of undefined. This is usually for historical reasons, because our syntax predates the equivalent standardized syntax.
• No TypeScript syntax is supported. The single interface with the type system is the $any(expr) cast operation, which is custom Angular syntax for casting expr to any.

We plan on evolving this language over time and converging it with TypeScript.

[gabdlr]

Can I build my custom control flow syntax as I do with structural directives? 🤔

…

On Mon, Jun 26, 2023, 12:45 PM michael faith ***@***.***> wrote: This is not jsx tho. And personally it's far more readable and easier to parse, than what we have with the structural directives today where they're "buried" in the html elements. — Reply to this email directly, view it on GitHub <#50719 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARSUEW6ZNZRGZ6EOZIKVOCDXNGVALANCNFSM6AAAAAAZGRVMB4> . You are receiving this because you commented.Message ID: ***@***.***>

[tomer953]

answered in main post:

Q: Can libraries define their own block groups?

For now, no – block groups will be a template language builtin, and not a user extension point. We are interested in researching whether it makes sense to expose some kind of extensibility here, what use cases there might be, and what form such a feature might take

[ajuni880]

Hi,
I do like the new syntax, it's easy to read. I want to ask whether will be able to create our own structural directives like is possible currently now using hostDirectives?

[haskelcurry]

First of all, I'm fine with this change. Although I think that it doesn't bring anything valuable, apart from some new syntax stolen from Svelte. And I'm afraid we observe a tendency of bringing in stuff from other frameworks into Angular, smoothing it's distinct style and making it a mash, without any clear benefits.

Now, two questions:

1. Are you going to drop the structural directives at all? Because that's a very important and powerful thing. If you're going to throw it out, you need to give an alternative.

2. Why to use the "ngIf + as" hack-like syntax and not embrace e.g. "let" like in rx-angular:
   https://www.rx-angular.io/docs/template/api/rx-let-directive

[chriswoodie]

Overusing brackets for conditions like this creates HTML code that is super awkward and difficult to read. That's why I can't stand writing or reading JSX code, I'd hate for Angular to adopt this approach unless it solves this issue.

I'd much rather have some sort of "#" pattern (or some other character) like:

# if a > b
<div>foo</div>
# else
<div>bar</div>

Whether this is technically possible I haven't considered. The above code just feels more natural to write and is super clean.

[wartab]

This would make it so conditions have to be on a single line and the syntax would be based on white spaces. On top of that, something so simple can easily lead to ambiguous situations - for example if you wish to write Mardown in your template, where headings start with #. Also, where would the else block stop?

I think that with proper syntax highlighting, this new syntax could be quite nice and at the end of the day isn't much more verbose than *ngIf and especially less if you have to wrap a condition in an ng-container.

[flensrocker]

And we should not forget "prettier". That has to work, too.

[bulldog98]

@flensrocker yes that is a good point, prettier is a requirement that it works

[muhamedkarajic]

I thinkg still skog has a point, I really really don't like the syntax!

[muhamedkarajic]

How about if it would be just something like

<if condition="a < b"></if>
<else-if condition="b < c"></else-if>
<else></else>

[g-cheishvili]

Please do not introduce handlebars-like syntax in Angular templating syntax, please! Let's stick with the existing image of Angular 😞
Way better would be if Angular started supporting JSX natively.

[JeanRemiDelteil]

If the intent is to be as near as JavaScript as possible, why not considering using template strings:

{
  template: html`<div>${ this.value() }</div>`
}

This IS pure JavaScript. I obviously reference lit with this.
One good point is that there is no buggy subset of language to use as microsyntax.

And performance wise, it's very efficient.

[chaosmonster]

Hey @JeanRemiDelteil,

your example falls into the same category as JSX (IMHO) and @alxhub wrote in another thread why they did decide against it.
Secondly Angular templates will be compiled on buildtime and not on runtime. lit (and your example) is though on runtime.

[JeanRemiDelteil]

@JeanMeche I didn't go into the details, but if you are interested how Lit does control flow, see here for more info

render() {
    return html`
      <p>
        ${this.greeting}
        <button @click=${() => this.show = !this.show}>Todos</button>
      </p>
      ${this.show ? html`
          <ul>${this.todos.map(i => html`<li>${i}</li>`)}</ul>
        ` : ''}`;
  }

[JeanRemiDelteil]

@chaosmonster The main difference with JSX is that this is pure Javascript (or TS).
It's not another sugared syntax.

And Angular templates currently NEEDS to be compiled on buildtime, because the current design makes it necessary.
The Lit approach just removes this needs without negative impact on performance.

[lkster]

The Lit approach just removes this needs without negative impact on performance

And why should Angular remove need to compile templates build-time? I see only abandoning readability over I don't even know what as compiling templates with future esbuild support shouldn't be long enough to even consider this.

[imaksp]

The main difference with JSX is that this is pure Javascript (or TS).
It's not another sugared syntax. And Angular templates currently NEEDS to be compiled on buildtime, because the current design makes it necessary.
The Lit approach just removes this needs without negative impact on performance.

We also need to consider readability, I think JSX & Angular syntax is more readable than this. & compiling at build time won't have negative impact on performance.