In my opinion the most unnessesary change they could do now. The control flow is already pretty good, but there are several other parts of angular that could be improoved. SSR for example.
@@Mychelonn it is for what it should be not that bad actually but the tooling is way worse compared to the spa version. Sometimes it just doesn’t reload my page for some weird reason as an example but I have multiple other small criticisms towards Angular Universal.
They are improving SSR. Google "Angular non-destructive hydration" and "Incremental Static Regeneration for Angular". Anyway, the new control flow is a necessary change and it improves DX a lot, but, if you disagree, feel free to keep importing the old directives, writing "trackby" functions, "ng-templates" for your "*ngIf else", struggling to see the "*ngIf" & "*ngFor" directives in a larger template while everyone else enjoys the new template syntax. Honestly, it feels like the ones complaining about the new Angular features are grumpy old guys who are just angry because adapting to changes is hard for them.
@@Tomas-ir8xl I‘m not saying they aren’t improving anything but that they should focus on the important stuff. I am neither old nor grumpy but I just don’t think that these changes are remotly as exiting as the signals update for example. I love new things, but only if there’s not already a other solution. You can’t deny that the new syntax looks way more out of place than the *ngIf syntax.
Although this isn't a game changer, I'm happy about this change for a few reasons: - I won't have to import directives for basic template capabilities (conditionally showing content for example) - ngIf doesn't handle else statements elegantly, and it doesn't handle else if statements at all. Compare this to Vue's v-if syntax - no need to get ng-container involved - looks like there are some minor performance benefits, as it forces tracking and leans out templates I'm interested to see how this syntax evolves to include more capabilities.
The Angular team just released a pre-release version of the language extension if you want to check out the new control flow now with an error free experience in your editor: github.com/angular/vscode-ng-language-service/releases/tag/v17.0.0-next.0
For Forms I would kind of like to see something like also. @disable (patternX) { } @disable (patternY) { } Sort of feels bad when you have to disable something based on the same value. Do not get me wrong if they have unique disabled values then still want [disable]="patternZ" PS: The request was work related and not the best to start out with in truth, but requirements are requirements.
@joshuamorony a college of mine says that the angular team is going to ditch rxjs, have you heard anything about that? Thanks for all your videos, they are really good
Its ready in 17.0.0-next.7 only missing prettier support and still needs this "_enabledBlockTypes": ["if", "for", "switch", "defer"] in your tsconfig in the section angularCompilerOptions
1:12 Yeah, this is what I thought of immediately I am currently using React after a fair few years of angular, and I hate how these things can look Instead of something like: It has to be-partially because of prettier's BS rules: {{ showA && }} {{ showB &&
}} {{ showC &&
}} {{ showD &&
}} They don't even look like they're on the same plane of existence, much less sibilings...
@@Tomas-ir8xlI don't see how the Angular version could be conveyed better. Imagine the bottom for an entity-specific modal, for example. Based on the user's authorization, and the specifics of the entity, there are various available action buttons. They can appear in any combination, and it is not within any single component to determine which ones should do so.
I like the syntax a heck of a lot better than the original ngIf instead of doing multiple checks on the same data, but are there elseIf cause 0:51 looks like I am going to see super nested code.
idk, I don't much care for this. Like, I guess it's nice to have the option, but saving a few characters here and there definitely won't make me go back and revise any previous code. I'd rather hear more about Signals ❤
TrackBy is the current way for angular to define a key in a template loop. So if you have an array of 10 elements with unique IDs then it’ll only update the specific elements where the objects are updated instead of re-rendering the entire list.
I like how it somehow forces us to write "ng-container" like blocks. I never feel very comfortable when adding the ngIf in an actual HTML element. This way, control flow becomes always consistent.
Sintactically, not an improvement at all. It throws out the window angular visual indentity and makes code more verbose, besides being ugly/old-fashioned as hell imo. I can't help thinking "just... why?". I'm only buying it for the trackBy, @defer and @empty, which will all come in handy (they could come without the new sintax change though, simply as new directives).
@@brunocapitelli7754 "else" exists, but "else if" doesn't Switch will support multiple cases in one. So "case 1, 2:" instead of "case 1: ... break; case 2: ... break;"
@@brunocapitelli7754 "else" needs an tg-template which is awful. Also, it only makes code more verbose in very simple scenarios. There's nothing more annoying than adding an ng-container just because you need an additional ngIf.
Could it be the use of the @ symbols? The big difference between scriptlets and this is that you can't write other logic. We're not introducing any syntax that allows you to write any programming logic. This is strictly a more performant way to do control flow and conditional rendering.
@@markthompson-g It's more the conflating of statements with expressions/markup for a UI. I either want full imperative like java swing where I have that power/flexibility or a declarative one where I have that simplicity.
Next newsletter with a tip about routing goes out tomorrow: mobirony.ck.page/4a331b9076
In my opinion the most unnessesary change they could do now. The control flow is already pretty good, but there are several other parts of angular that could be improoved. SSR for example.
Exactly, I totally agree. Angular Universal is so bad compared to another SSR frameworks (ie Nextjs)
@@Mychelonn it is for what it should be not that bad actually but the tooling is way worse compared to the spa version. Sometimes it just doesn’t reload my page for some weird reason as an example but I have multiple other small criticisms towards Angular Universal.
What about analog ? (I haven't tested it yet)
They are improving SSR. Google "Angular non-destructive hydration" and "Incremental Static Regeneration for Angular".
Anyway, the new control flow is a necessary change and it improves DX a lot, but, if you disagree, feel free to keep importing the old directives, writing "trackby" functions, "ng-templates" for your "*ngIf else", struggling to see the "*ngIf" & "*ngFor" directives in a larger template while everyone else enjoys the new template syntax.
Honestly, it feels like the ones complaining about the new Angular features are grumpy old guys who are just angry because adapting to changes is hard for them.
@@Tomas-ir8xl I‘m not saying they aren’t improving anything but that they should focus on the important stuff. I am neither old nor grumpy but I just don’t think that these changes are remotly as exiting as the signals update for example. I love new things, but only if there’s not already a other solution. You can’t deny that the new syntax looks way more out of place than the *ngIf syntax.
Feels like year 2000, classic old ASP and Visual Basic syntax:
The new syntax and the defer block are so nice, Angular DX is improving a lot 🎉
Although this isn't a game changer, I'm happy about this change for a few reasons:
- I won't have to import directives for basic template capabilities (conditionally showing content for example)
- ngIf doesn't handle else statements elegantly, and it doesn't handle else if statements at all. Compare this to Vue's v-if syntax
- no need to get ng-container involved
- looks like there are some minor performance benefits, as it forces tracking and leans out templates
I'm interested to see how this syntax evolves to include more capabilities.
Not gonna say I'll not use it, but damn...there will be a mess with all those @ifs and @else ifs :))
The Angular team just released a pre-release version of the language extension if you want to check out the new control flow now with an error free experience in your editor: github.com/angular/vscode-ng-language-service/releases/tag/v17.0.0-next.0
Will the *ngIf be deprecated sa a consequence ?
Oh man, I hope not
No, both will work :)
It feels a bit off. Not sure why.
For Forms I would kind of like to see something like also.
@disable (patternX) { }
@disable (patternY) { }
Sort of feels bad when you have to disable something based on the same value.
Do not get me wrong if they have unique disabled values then still want [disable]="patternZ"
PS: The request was work related and not the best to start out with in truth, but requirements are requirements.
hey it wont be deprecated xD lol.. u know how angular loves backward compatibility.
@joshuamorony a college of mine says that the angular team is going to ditch rxjs, have you heard anything about that? Thanks for all your videos, they are really good
I don't think ditch is the right term but I believe the team is moving towards making RxJS an optional part of the Angular experience
Sort reminds me of razorpages, nevertheless super excited
Actually quite clean imo, cant wait to adapt it.
Its ready in 17.0.0-next.7 only missing prettier support and still needs this "_enabledBlockTypes": ["if", "for", "switch", "defer"] in your tsconfig in the section angularCompilerOptions
Reminds me of using Razor with MVC back in the day!
My thoughts exactly!
Same thoughts
This is looks like .Net Razor syntax. Good point for dotnet developers again. God bless the Angular team :)
1:12 Yeah, this is what I thought of immediately
I am currently using React after a fair few years of angular, and I hate how these things can look
Instead of something like:
It has to be-partially because of prettier's BS rules:
{{
showA &&
}}
{{
showB &&
}}
{{
showC &&
}}
{{
showD &&
}}
They don't even look like they're on the same plane of existence, much less sibilings...
Both cases look like bad design and there should be a better way to implement/abstract/refactor this to make the code easier to follow.
@@Tomas-ir8xlI don't see how the Angular version could be conveyed better.
Imagine the bottom for an entity-specific modal, for example.
Based on the user's authorization, and the specifics of the entity, there are various available action buttons.
They can appear in any combination, and it is not within any single component to determine which ones should do so.
Really amazing
Svelte for the win!
thanks for sharing! How can I create an angular project from scratch with this angular version?
That @defer is what I need,
That would be cool If we could online the defer statement with the else if condition.
Prettier creates a mess of the template now, so far
Yes full disclosure the screenshots I used all required some manual formatting from me lol
An offtopic question but what color scheme is this? Looks quite nice
Gruvbox :)
Yeah. Nah. I didn't see a single example where the old syntax looked better than the new.
This change is way WAY better than what we have currently.
I completely agree, the new syntax is going to make the html look like a mess.
Does the async pipe work with the new @ block syntax?
Yes!
I like the syntax a heck of a lot better than the original ngIf instead of doing multiple checks on the same data, but are there elseIf cause 0:51 looks like I am going to see super nested code.
Why not just use jsx at this point? Not being snarky, just curious
idk, I don't much care for this. Like, I guess it's nice to have the option, but saving a few characters here and there definitely won't make me go back and revise any previous code.
I'd rather hear more about Signals ❤
What if we told you that this also boosts performance? 👀
@@markthompson-g That'd peak my interest considerably more ^^
@@NikiHerl good because it does but we're working to further optimize and improve the experience. More details soon!
what was the trackby? i mean what is it used for? can someone explain
TrackBy is the current way for angular to define a key in a template loop. So if you have an array of 10 elements with unique IDs then it’ll only update the specific elements where the objects are updated instead of re-rendering the entire list.
Is Angular finally Svelte?
Thanks god. After started using Blazor and get use to Blazor syntax, Angular ngIf became so old and not easy to read. Finally they are same!
Do you mix the two?
Definitely an improvement over the old directive-based way. We just need a nice way to migrate and the IDE support!
Also using it, its so so good.Defer is a game changers. Amazinggg
This is correct :)
I like how it somehow forces us to write "ng-container" like blocks. I never feel very comfortable when adding the ngIf in an actual HTML element. This way, control flow becomes always consistent.
Sintactically, not an improvement at all. It throws out the window angular visual indentity and makes code more verbose, besides being ugly/old-fashioned as hell imo. I can't help thinking "just... why?".
I'm only buying it for the trackBy, @defer and @empty, which will all come in handy (they could come without the new sintax change though, simply as new directives).
There is also multiple switch conditions in a single case and also @else if
@@GLawSomnia else already exists in ngIf. About the switch/case, don't you mean ngSwitchCase (which already suports nested cases as well)?
@@brunocapitelli7754 "else" exists, but "else if" doesn't
Switch will support multiple cases in one. So "case 1, 2:" instead of "case 1: ... break; case 2: ... break;"
@@brunocapitelli7754 "else" needs an tg-template which is awful. Also, it only makes code more verbose in very simple scenarios. There's nothing more annoying than adding an ng-container just because you need an additional ngIf.
(and buy it for what it'll do for performance 😃)
I like the new approach. Reminds me a lot of Laravel Blade syntax
This looks much better then the first one. Before I would have probably stayed with the directive way most of the time, but this actually feels right.
I think this is a step backwards, smells way too imperative. Feels like JSP scriptlets all over again.
100% agree.
Could it be the use of the @ symbols? The big difference between scriptlets and this is that you can't write other logic. We're not introducing any syntax that allows you to write any programming logic. This is strictly a more performant way to do control flow and conditional rendering.
@@markthompson-g It's more the conflating of statements with expressions/markup for a UI.
I either want full imperative like java swing where I have that power/flexibility or a declarative one where I have that simplicity.
@@adambickford8720 ahh, makes sense - I appreciate you letting me know more about what you were meaning.
@@markthompson-g I just discovered @defer and friends so this seems to be going exactly where i feared. The camel's nose is cleanly in the tent :(
Good stuff
The blazor style
Taking a page out of C#'s razor/blazor syntax!
POV: Razor Syntax coming to JS, still sticking with Blazor tho
Once you try coding with blazor you never look back
why not stick to the javascript syntax style, just like React is doing. Angular trying to be less ugly ...
looks more vanila js, which is better for the newcomers
Thanks, easier to visualize the effect
First Comment PIN ❤
Same as razor in c#
Looks like .NET razor syntax.
it's cleaner and more readable IMO
nice
I don't even use Angular but having control flow statements as Html attributes looks disgusting.
That's also how Vue, Alpine.js, Riot.js, and probably many other frameworks handle conditional rendering though...
@@xucongzhan9151 That doesn't mean it's good?
is it razor? 😂
seems to me like another thing angular needs to borrow from other frameworks, because its original ideas weren't great. :/
Thanks god, that stupid syntax with different opening and closing tags has not been accepted 🙏
I bet you still can't declare a variable in template (for reuse in multiple places), and have to jump through hoops using fake conditionals
🤢 how am I gonna work on this framework! It's so bloated
This looks and feels bad.
It should have been just:
@if(condition)
@else
@endif
How would you have grouped multiple elements without the braces?
@@markthompson-g Have you seen python? :)