Should this be the future of Angular applications?
HTML-код
- Опубликовано: 2 июн 2024
- My Angular course: angularstart.com/
The new experimental .ng format introduced in AnalogJS provides an arguably simpler and more boilerplate free component authoring experience for Angular. Combined with a different approach to services, we can create entire Angular applications without using any decorators or classes.
Source code: github.com/joshuamorony/analo...
Previous .ng video: • A "simplified" approac...
Previous createInjectionToken video: • Why does building an A...
Get weekly content and tips exclusive to my newsletter: mobirony.ck.page/4a331b9076
Want to build mobile apps with Angular?: ionicstart.com
0:00 Introduction
0:58 The .ng format
2:29 Services without classes
3:56 Thoughts
#angular
UPDATE: Support for .ng files has been removed from AnalogJS: twitter.com/brandontroberts/status/1750724318131024278
UPDATE: Support for .analog files has been added to AnalogJS: twitter.com/brandontroberts/status/1752085150496661534
This might have worked if it hadn't been marketed as the future of Angular and the slightest criticism from the community wasn't seen as a hindrance to "moving forward". If the decision to remove it was down to one person's ego, then it wasn't something that was very necessary in the first place.
I would absolutely hate to have my typescript mixed in with my template code. I like it separated how it is currently.
The more you get used to declarative code, the less this separation will matter to you.
As an angular developer, this is a mess. If you like this style, use react
As Rowan Atkinson once said, this is a thing that people immigrate to avoid
Wow. It's been a long time since I was writing AngularJS, and I've forgotten most of what I knew, but your suggestion for services in this video reminds me a lot of the code I used to write in AngularJS. I personally don't want to go back there.
Any reason other than bad memories? How do you know the way you currently write code won't cause you to have bad memories in the future?
The title should be - how to overengineer angular application without particular reason
Why overengineer? This syntax ist easier than the Default.
@@bronzekoala9141 Ratio disagrees so maybe not
Everything new is stuff I don't like and therefore over-engineering, even if it's objectively much simpler.
@@mfpearsit's not, it requires analogjs, another dependency in your codebase
I like how angular separates template from the component class, I wouldn't want to use this.
Probably in the metadata definition section we could add a 'temoplateUrl' tag. Analog extends from the normal Angular, so it won't be hard to use the normal version of it.
@@TAURENIONot at all. Vue does support ``, as well as `` and ``. We can do the same for AnalogJS.
These are still separate
"Let's reduce 100% pointless boilerplate"
"But then the template and class won't be in separate files"
"So?"
"The files will be big"
"Then split the component up. It's a good thing to do anyway."
"Ugh, it takes work to create a new component. All those files, or the CLI with the long path..."
"..."
You will probably get a lot of support from the twitter community and people who like new shiny new things, but people who actually work on actual business applications (especially multiple projects) will most likely hate it. It doesn't really bring anything useful to the table, even the boilerplate argument is useless, considering the CLI generators do everything for you.
Why would we actually want to re-learn everything? Just use Vue/Svelt then.
I myself also don't understands the benefits of folder based routing. But ok this might be on me
Agree with everything, I don't understand the complaints about the decorators and "boilerplate", just use ng generate, and most IDEs have support for that
@@hammamboutafant3659 And my problem with reliance on generators and magical IDE features is that it allows dev to skip the understand part. Prime example I got multiple times, that people don't even know how to start their project without a green play button in the IDE...
Also, If boilerplate introduces the need for generators, why not just reduce the boilerplate and need for generators if it's possible and therefore reduce the maintainance and learning another tool. Having generators is not a good argument against removing unneeded boilerplate.
You actually use the CLI generators regularly and think it's easier than *click* => "new file"?
@@mfpears yes
This is like the "Marvel: What If?" channel for Angular where you see all these potential horrors from an alternate universe
This isnt a horror tho, its a dream.
A dream that came out of your ass
Yeah Dream of react community how to destroy competitors
@@marianbencat6658if you think this is the main difference or even in the top 5 of differences, you have spent too much time in only 1 framework.
But, why?? it looks like Vue... 😢
That's the best part of it
@@martinlesko1521 If you like Vue so much, just go and use it. No need to mess up Angular for that.
@@martinlesko1521 just use vue then why you need another one
Structure and simplicity matter more than cosmetics
1:05 so why not use svelt or vue?
5:14 counting lines on both sides results in one less for the „alternative“ approach (55 vs 56) so no benefit at all
5:27 exactly how it is today. If I want to use svelt, react, vue or what ever else is out there I would use that.
Because of: built-in dependency injection container, built-in robust Router, built-in robust HttpClient with Interceptor, built-in route guard, etc.
Basically everything u should like about Angular are still there.
Only the component authoring format is different, achieving both:
a) Separation of Concern, i.e. Javascript is in tag, HTML is in tag, CSS is in tag, and
b) Co-location of Behaviours, i.e. event trigger (button click, for example) is co-located with event handler (callback function) in the same file to facilitate better Developer Experience, not having to jump through multiple files to track the behaviour of a button.
c) Business logic and State Management are separated into their own services, as it has always been. Only difference is using InjectionToken factory to create service instances rather than the traditional Class-based approach.
You might want to check out the new NgRx SignalStore, they are also using InjectionToken factory to create services. The authority has already spoken on which approach is more extensible.
Functional Composition is more extensible than Class based Composition
Why not use svelte or vue? Do you think that frameworks are only used for how their templating system looks like?
What's wrong with classes or decorators?
Decorators exist in many languages and in Angular case they allow aspect-oriented paradigm.
Imho, every programmer should be aware of what they do. Angular uses them at a bare minimum, just to stick some metadata.
They are perfect for metaprogramming, and someday they will be supported natively by JavaScript.
Regarding classes, I believe it's a very convenient structural unit.
A combination of state and behavior, you can do just about anything with them.
And we do.
I don't have anything against decorators or classes, but my thinking is that if we can accomplish the same things in a simple way without having to introduce those concepts then that makes sense to do. The only places where I think classes are really providing anything of value (that we don't get with .ng) in Angular is using 'implements' for things like Pipes and CVA, but that's pretty minor imo and we can have alternatives for that anyway
@@JoshuaMorony And why do you want so much to avoid introducing the most basic concepts of programming? On one side you want to avoid classes and decorators, but teaching rxJS is okay?
@@JoshuaMorony Except one important thing you are forgetting: like many programming constructs, classes & decorators/meta-programming provide structure to your application. Might not be important for a "todo" app, but pretty important for any large application with multiple people working on it.
@@simonm97 I would prefer to keep the concepts as few and simple as possible, and only introduce concepts where there is significant value in doing so - RxJS is hard (far harder than understanding how to use a class for an Angular component of course), and a significant concept to introduce, but I also think it provides a significant benefit.
@@Tomas-ir8xl what structure to Angular applications would you be losing without classes and decorators (except for inheritance, which is not often used nor really recommended)?
@JoshuaMorony, maybe you just like react? because this is kinda what it's looking like. effects => useEffect, signals => useState. no classes -> functional programming like how react moved from classes to functions and hooks.
Moving to "functional" components was the worst idea ever
why move everything in a single file?
do you not like to seperate .ts, .html, .scss?
I'm already using single file components with Angular regardless so that aspect isn't different for me. But the way I see it SFC (and even more so the .ng approach) has a more natural tendency to encourage separation of concerns: SFC decreases friction for creating new components, and also increases friction more quickly as the component grows because all the code related to a particular concern (the thing the component is responsible for, not the technology type) is located together in one file. That means you are going to tend more toward creating smaller components, which are probably going to deal with separation of concerns better than more easily being able to have large multi file components.
Honestly, this just looks like one big mess. "ng" component is one single super long file (template, styles, logic), the service is one long single function. Might as well put everything in a single file and say how cool it is when you have everything in one place. That's a nightmare, not the future.
Whyyyy
What!? wait... NO!!! Some people do not understand where the Angular community comes from. This would destroy that framework for sure!!!
Why will I continue with Angular if the syntax is Vue and Svelt, this will make it easy for Angular devs to move to Vue or Svelt.
People, Analog ≠ Angular.
Be happy that there is a viable alternave for those who want one and that they will still get the benefits of the Angular ecosystem with they syntax they prefer.
Analogs changes do not mean Angular is changing the same way.
Mom, I want React!
We have React at home.
React at home:
The problem I have with this implementation is that it's removing the separation of concerns. You have presentation code mixed with business logic. At my current job we've been spending years trying to detangle presentation and business logic from each other in order to make it easier to add new features and fix defects. This just looks like a regression to me.
I use single file components regardless (i.e. I use it now with class based components) - I view the "concern" of the component as the responsibility it has/the thing it does, and those are the concerns that should be separated - not technology types.
SFC are good, and it would be great to see them in Angular, but classes, services, and other APIs should remain.
To be clear, nobody reasonable is advocating for classes to go away. We just want and alternative to the current approach that gets rid of the verbosity of decorators and double imports. I don’t care if that alternative is class based, svelte-like, or what. I just want the authoring of a component to become simpler and less verbose.
Hi, sorry to bother but I have a random question :
I've heard that with signal the template change detection works better, so if i get the data from an API as an observable, should i convert it to signal using toSignal method and show it in the template as {{data() }} or should i let it as an observable and show it as {{ data$|async }}?
Yes. The easiest (and probably least intrusive) option to start using Signals in your Angular application is to bridge your Observables with the template using `toSignal` instead of AsyncPipe.
Do you want to convert Angular to React?, i think for most of the developers that like the class approach, Angular is a excellent option, Also working with classes make easier to implement any desing pattern. I have been following your videos, and I think you shoud try React or Svelte, your propusals and the way you show you code is more that way
It seems like you've never used React? This is not even close to React.
It has more in common with VueJS.
Single File Components (SFC) are convenient for use in the View/ViewModel layer, but complex logic is better written as it is now - using classes, services, etc.
For context, I have been using React and Svelte for years - I don't prefer them over Angular, and .ng in no way converts Angular into Svelte or Vue or anything else except for the components looking somewhat similar syntactically on the surface
@@JoshuaMorony if sounds like a duck, and walks like duck
@@JoshuaMorony Anyway, thanks so much for share your point view and, thanks for all your effort creating this type of videos!!!!
Actually now I don’t see reasons why we need Angular if there is Svelte with the same component styles?
My biggest question would be how do I go about unit testing these types of component/services ? Especially in the case of the service, I have trouble knowing how to unit test it as I won't be able to access the internals in the unit test suite.
The service created through InjectionToken factory method is just like a normal Decorator Class-based service. You just provide it in the Testbed and test it. No different whatsoever.
Similar for the component
ewwwww. why.
Another video about authoring format - this feels like pushing a personal agenda at this point and not being divers and informative. I honestly want to understand why you've chosen Angular as framework of your choice and did not go with something else?
My channel is typically stories/dev logs of the things I am working on at the time, I am working on .ng stuff now so naturally more videos about .ng stuff. I use Angular because I like Angular - I have used other frameworks including Svelte and React and I don't like them as much as Angular. In my opinion (which is subjective of course), this makes Angular better and doesn't change any of the things that I like about Angular.
@@JoshuaMoronybut it makes angular better for you specifically no? It’s your channel you do you, but I’ve been hard pressed to make it through the last couple of videos. But again that’s my own personal preferences
Do you know why nx test, using angular, ignores the app.routes.ts and app.config.ts files?
One question…. Why?? It’s like angularJS to angular 2
The main aspect WHY I USE ANGULAR is entirely missing in this concept: Splitting HTML, TS and SCSS to different files. Combining all code in 5000 lines files is the greatest shit trend of the last years.
The trick is keeping your components small and self-contained. If your component is 5000 lines long, that's just fucking wrong regardless of whether those lines are split into 3 files by convention.
@@MrXacius ideally yes. But this is not always possible and not always useful. Splitting up a reactive form with multiple sections into one partial form per section is already an insane amount of effort, since the sections must stay dependent between each other. And splitting the section with 20 Form Fields further up to more components will leave with a ton of single use components, and increase the difficulty to the state management further more.
@@btx47the reason you find it hard is because it takes so much work to create a new component. If it was as easy as cut and paste and type a new name once, I doubt you'd be whining about it. Splitting code by horizontal layer is the wrong solution. It's counterproductive.
@@mfpears That not true. It takes right click -> create new component -> give name. You can even create your own schematics to fit your requirements on components.
I'm not against the concept, but for now I fail to see the real benefit, espacially if build time is the same and build result is the same. I guess when the framework would be ready to make such a step, it would become relevant. Anyway, great introduction of this issue ! Thanks Josh !
It is the concept that we want to discuss. Personally, I didn't realize I've been putting up with Angular boilerplate so much (as I'm very used to it) until I tried writing Angular components with `.ng` files. Others might have different opinions as we see here.
@@ChauTran-xc4ld yeah, exactly. From my perspective, the adoption of Angular is linked to the opinionated architecture, making devs like Springboot confortable and efficient. They are used to boilerplate, like separating declarations and instantiation, and Angular feels like home. In the end, boilerplate for boilerplate is useless of course, but having a readable and comfortable codebase is really an Angular thing. We should preserve that.
And for the little story, I try to advocate for more type inference and less verbose components with my team 😅
So much of these changes only apply to green field projects. New angular developers are not likely to work on these greenfield projects.
@JoshuaMorony No, we do not need it. You need it for content and to be the new kid on the block. Just cause last week you discovered ASTs (ts-morph), does not mean it needs to be baked in. We can already do what you describe with custom schematics and in less lines of code. Actually a simple json.
You probably forgot why AngularJS moved on, where VueJS stems from and the chaos in standardisation in common patterns for React developers. As Angular developers we made a choice over other frameworks for this same reason. The common practices, the structure, the guidelines, the documentation and the ecosystem.
You are not in a big production team. Stop talking on behalf of us. When standalone/signals components were introduced, it gave us a choice. Sure it was nice, but also created one more problem.
A problem that you cannot see when you are developing alone. Documentation needs to catch up, people need to catch up, refactoring needs time to stabilise.
I do not want Angular to become a playground of RUclipsrs' ideas and be in a daily fight with stability.
It is good to look into future but you do not seem to have learned history.
Imagine letting a young generation, without history knowledge, to vote for dropping a nuclear bomb.
Couldn't agree with your more.
how do you test these components?
It is a class under the hood so you'd test it like a normal Angular component. Although, it depends on the testing framework to transform the files so it might not work with Jest or Jasmine without further configuration.
no no no, what a mess 😢
Why need to disturb Angular unnecessarily ?
Do you think Angular has had healthy growth for the past 8 years? Change is necessary.
Code looks like we are going back to angularjs :( and that was hard times in huge teams
At least in angulaJS the html and scripts were in separate files (and with the correct file extension)
Having similarities in areas to AngularJS doesn't make it AngularJS, just as it looking similar to Svelte/Vue doesn't make it the same as Svelte/Vue. As far as I know, knockout.js was the first framework to use what we have come to call signals, and knockout came out in 2010.
Hell, at this point, the Angular team should create a new Angular framework from scratch, AGAIN.
The current Angular framework is great, there is room for improvement, sure, but not to re-define pretty much everything.
I believe that frameworks deserve their own syntax. Conceptually, an angular component isn't a function, that's not how we think of it. And all of that boilerplate is essentially memorizing the words of the Angular Component spell.
How svelte has its own syntax, it certainly helps and is appreciated. That's why reactive is so fluid. Its a syntax/language that understand these concepts and doesn't make you repeat a magical incantation.
Or how if a specialized device has it's own language made for it, such as relational databases and SQL/TSQL, those languages are the best way for interfacing with these specialized things. A relational language for relational data.
But then you've got Microsoft LINQ which attempts to... help out data access code, but making a language that is LESS specialized and it's literally a step in the wrong direction. LINQ isn't relational it's something else, like hierarchical.
And I'm not a fan all of these unique concepts like rxjs and monads in general being implemented as javascript functions. These are the kinds of things that deserver their own syntax and not use javascript
I'm pretty interested in how a custom tooltip would be implemented using this. Since injecting component in an overlay of angular cdk is a real pain, I hope this would make it easier
This doesn't change anything in that regards honestly.
This is just vue3 or svelte xd
Does this only work with analog or does it also works with angular only ?
This is an (experimental) AnalogJS feature
1:26 left side static page, right side SPA, right?
No, you can do SSR/SSG with AnalogJS but I've got it turned off so they are both client only
@@JoshuaMorony Sorry, I mixed something up there, thanks for the clarification!
The frontend needs state and what a surprise: classes are the right tool to hold state. Stop this, if you want React code like, just use React.
React used to have class components too, when hooks were introduced, people didn't complain. Suddenly when Vue adopted composables, it worried the community that it would turn the framework into second react. And guess what ? Vue still goes on. This shitting on frameworks in nothing new. It's basically a cycle
Nope
I really like the rather short (2-5 mins) videos in which you give your opinion on topics. There is just something nice about shorter videos than with longer ones
If angular is like this, what's the point of using it comparing to other frameworks/libraries?
Angular has its own specialty in terms of its structure and code layout.
There is no point of using angular like this way.
imo if you change the component authoring syntax to .ng, 99% of the things that distinguish Angular from other frameworks remains the same - component authoring syntax is the icing on the cake, it doesn't fundamentally change what Angular is
The one improvement is to have an @standalone decorator. Hundreds of lines of code gone right there.
In terms of this style, it already exists, it’s called svelte.
Noooo, pls no. Keep classes, inject allow to avoid call super on extends.
I've got to say. This is amazing. I'd like to work with this when it's finally released
I agree with the .ng files, but I disagree with create Injectable, create injectable looks heavier and has more boilerplate
Do you think it's a good idea to introduce the concepts of decorators and classes just for services though?
@@JoshuaMorony I like the createInjectable approach but you speak of decorators and classes as if they're some super hard concept to grasp. Personally I like the DX that comes with all of these new concepts i.e. the .ng approach, new control flow statements and signals. The true coup de grace I would like to see implemented would be getting rid of RxJS. That day can't come soon enough - LOL!
@2:15, you can already create effects without a constructor in the class you just need to assign it to a class member i.e export class someComponent implements OnInit { private someSignal = signal(false); private readonly someSignalEffect = effect(() => { console.log(this.someSignal()}) };
which IMO works well enough
Yes but it's the same sort of thing, assigning something to a class member just for the sake of running it is a weird pattern imo
Still don't like the fact that you have everything under the same file, It's substantially worst developer experience.
I always get surprized by the creativity of the opensource community.
projects like this makes Angular think about next cool features that the community likes and maybe implement them in the future versions.
I really like this approach but I would not use this personally in my projects, reasons: if the code maintainer stops supporting the repo, breaking changes from Angular.
This is a sensible approach, there is certainly a degree of risk here (especially so with the .ng format which, again to be clear, is highly experimental). AnalogJS is quite well maintained as far as community open source projects go, so in terms of a viable home for .ng it's probably going to be the best spot for it - but yes, it's open source and there is going to be an element of risk there
No sense this approach, if you want more react code stying go to react 🙃
Improvements are okey, but the template/script/style tags arent (in my opinion).
i dont think this is a good path. separation of concerns is there for a reason. the more different concerns you dump into a single file, the more difficult it gets to work on it.
HTML and JavaScript are not separate concerns. This kind of thinking is probably why your main bundle is 2 MB.
You could just use vue for that. It's a mess for bigger applications with complex data structures and operations
Personally I do not like this approach. It starts to be less intuitive, it is worse to read and kind of becomes similar to React which is not good track imo.
Im enjoying the discourse on this video and what it means going forward.
Should this be the future?
Most comments from people who use Angular and built large systems say no.
Based on:
Time taken to learn it.
Adoption of the separation of template, styles and logic as well as how to maintain legacy code with such.
Also, there are comments mentioning that there are no performance gains in favour of dx.
Now whilst vue'ifying angular is cool and creative, but it seems what matters most is scalability, cost and performance.
Videos like the signal state-management make more sense since its easier to implement test/ sample since the entire codebase doesnt need to be refactored.
So whilst this video gets some push back, I keen to see how future videos adapt.
Good luck.
This should be an additional optional feature like in Vue.
so you made vue, i mean that why i like angular is like only one that uses classes why we need another framework that the same..
To be clear, Chau Tran and Brandon Roberts did almost all of the work for implementing this - but no, it's nothing like Vue the component format authoring syntax is just similar. It's like two completely different cakes with similar icing. But on the topic of classes, what about classes would you miss if we did use the .ng format?
@@JoshuaMorony i mean there are like 10 frameworks that don't use classes so there is enough choose but with classes there are no that many. what i like about classes organize code have private and public methods maybe because i use php alot, oop just make sense for me.
@@JoshuaMorony I think we would miss the core functionality of TypeScript that literally everyone knows and is comfortable with. On the converse, I have not heard any compelling arguments that classes are fundamentally flawed.
I am in-different, really the double import is the biggest thing I'd want to get rid of.
If you like my content, consider joining the newsletter: mobirony.ck.page/4a331b9076
I like Angular because of what it is and how code looks. If i wanted my code to look like puke i would use React. BUT options are always good, replacements not always.
If Angular's inheritance disappears I think quite a few developers will disappear too.
This is looking more and more like React, if I wanted to use React I would switch to React directly. No thanks!
Anyway all very well explained. Thanks for that.
If you are using inheritance then that is a very relevant reason to not like this format, that is one of the few things that you do actually lose with this format. I think inheritance is not generally used/favoured though, and composition is often what is advocated for.
@@JoshuaMorony of course! Sometimes I have used composition, but in some cases I thought it was necessary to add inheritance to make scaling easier: what's the problem with inheritance? For medium to large applications or directly large applications I think it's a pretty good concept, but I'm open to other criteria (that's why I watch and get interested in these videos :P)
@ this is a popular topic that extends beyond Angular but searching "why favour composition over inheritance" or something to that effect should yield material on the topic (doesn't mean that inheritance is never useful, but it is generally less flexible/constraining) - in the context of Angular preferring composition is generally going to look like utilising DI or directives/components to achieve a goal rather than inheritance, the general concept being rather than extending a thing you create new things by "composing" multiple things together. Here's an Angular specific article: www.danywalls.com/understand-composition-and-inheritance-in-angular
@@JoshuaMorony thank you Josh! I'll read it with high interest for sure.
4:50 wow what a picture book example of an ad hominem argument ... 🙃
Maaan, people here are going nuts in the same way people went nuts when Vue Composition API was introduced 😂😂😂
Classes and decorators are great. Just need to wait double import fix and maybe removing selectors.
Signals is coming with performance benefit.
Classes and decators has a alot of benefits too.
This React syntax has no benefit unless if you are a React developer.
Still this is not Angular.
The people using Analog.js
should decide that. if i need Analog tomorrow i dont want this syntax.
At this point you better use react
You can notice that when your examples become bigger, the difference in a few lines is less and less noticeable.
I'm not really concerned with the LOC difference there, the .ng format still has less concepts involved to do the same thing and imo creates less friction to creating new components. I think that is still a minor win for existing devs even if you are using tooling, but I think the bigger deal is for that new dev "how do I create a component in Angular" experience, and if we can make that far simpler without losing anything important from Angular I think it's a big win.
@@JoshuaMoronyagree, we definitely should move in this direction. I think we should do this without breaking things and insulting those who disagree (4:58 - that's not cool).
@@eoz maybe it would have been wiser to leave that out - but that's why I put the text overlay there: I'm not saying anyone who disagrees is just doing it for their own gain. I was going to say that more Angular devs is better for everyone, but changed it since technically that's not true. Being highly skilled in a technology with a shrinking talent pool to hire from is profitable, so there are certain people who would be better off with less Angular devs. I was being a bit lighthearted/cheeky about this because I didn't think this video would get quite so serious.
@@JoshuaMorony
> Being highly skilled in a technology with a shrinking talent pool to hire from is profitable
Framework popularity not only increases the number of job positions but also expands the opportunities to assist more teams, whether by joining them or providing consulting services.
@@eoz I agree, and I'd prefer that from a professional perspective anyway - but still, I'm sure there are COBOL developers who aren't losing sleep over the lack of new COBOL developers. Anyway, it probably would've been better to just leave that point out and say "more new Angular devs is better for everyone" and leave it at that. Hindsight and all that though.
You know nothing about angular community, we Don't want this. We want working component composition, working control value accessors.
Things with HUNDREDS AND HUNDREDS of upvotes in issues, ignored by angular team.
We would be happy with them working. We Don't need this React ecosystem mess And its issues
Sir, this is a project called AnalogJS, an off-shoot meta-framework based on Angular, and is not sponsored/endorsed or even developed by the Angular team.
Play IT again. I know what Is analogjs i am one of the sponsors.this Is about possible feature od angular, inspired by analog.
IT Is using new "reinnasance" api from angular, which Are overhyped And coming with lot of problems.
I am quite certain the Angular team has not made any official endorsement for this or any other approach regarding component authoring format. In fact, their stance is class-based component will not go away at all, said by Alex Rickabaugh
I am curious though about what you dont like about the recent API changes?
Signal-based states, new control flow (@if/for/switch?), standalone component?
My comment got deleted, 2 times. This Is last time i try... Go to issues of angular And find "deprecated class based guards And resolvers" And read.
5 times. 5 times was my comment deleted. I am done.
Please no.
Looks cool, but I don't think people like change and less if is radical.
Most of the time is better to go for Vue or Svelte, is likely you will end in a old codebase and never use new features.
I understand why you want to get rid of decorators (I do like them, but yes, for new devs they might look scary), why we all want to get rid of double imports, but I don't understand why you don't like classes. "Feels more natural" is very subjective and can't be measured. I do not think people just don't like classes because they are classes.
For services (which is what I assume you are talking about here) I do mostly want the decorator gone, but using a class as the structure to define a service does feel like introducing a concept to me (especially if this is the only place a class is used), whereas using a function as the mechanism for creating the service feels like we aren't actually introducing a new concept - already using functions all over the place. Plus, we had a nice way to actually go about creating a service without decorators using a function (double plus I actually like the function based way to create a service) - I'm not sure what a class based/non-decorator option would look like (haven't considered it) but I wouldn't necessarily be against it.
@@JoshuaMorony in the example of service, you use factory function to create a plain object. Instance of a class is also an object.
@@eoz do you mean that you would for example have class MyService { etc } above and then supply an instance of that to createInjectable, e.g: createInjectable(() => new MyService()) - sorry if I'm missing what you mean but in this instance I still prefer the no class approach but I don't have anything against using a class here
@@JoshuaMorony This is an opinion that not everyone shares. Decorators are first class citizens in TypeScript. Why do we need to get rid of them? They serve are real purpose in TS and I would argue that every TS dev needs to learn what they are and how to write their own. Are decorators used all the time in normal TS code, no, but they are useful when you need them.
It looks good but that would be a complete different framework. If you mix this authoring format with the current one, the app would quickly become unmaintainable.
It wouldn't really be a completely different framework - it's not all that different from changing the input syntax from decorators in input signals (just on a larger scale), but the migration story here is certainly difficult. It would be possible to refactor bit by bit though as they can work together, just like with NgModule/Standalone. I expect the implementation of a schematic for automatic migration would likely be difficult, but potentially it might be possible - the implementation for .ng involves an automatic conversion of .ng to a standard Angular component, so hypothetically it might be possible to do some sort of auto migration from standard Angular component to .ng
@@JoshuaMorony Not at all different from changing something that's going to be backward compatible and supported by the Angular team? Sorry, I don't buy it. You've changed too much and asked devs to take on a whole new cognitive load with no guarantees that this will even be supported long into the future. The risk of putting time effort into this is much too high for most devs.
I loved Angular for 10 years now, but if their goal is to become React or Vue, I’m out
Vuegular
I've been laughing hysterically 🤣🤣🤣
looks like SvelteGular
At this point you might as well create a new framework derived from angular but call it anything else .
If this gets traction and I have to refactor my massive codebase again I'd rather jump ship to another framework
This is indeed a feature of another meta-framework, AnalogJS. Angular would still remain Angular.
@@Framoio I know , however the author on the video is extrapolating the idea into angular itself. That to me makes no sense .
Although I actually like this style of single file for a component, but in the context of angular and all its history it just feel like it has an identity crysis and is just following other frameworks.
No, we hate mixing typescript with template, this is disgusting. Even when I work with react some times I love moving all Javascript stuff outside template in a store like redux.
Angular 20 will look like Vue 1.0 😀
Angular is already copying the work of other tools without offering anything new from the original Angular vector
I really love this new approach, and I don't understand why some people say it looks like Vue.js or something else. My question is, what's the issue if we adopt good practices from other places and make the most out of it? I have a strong affection for Angular, and this new approach is much cleaner with less boilerplate. I'm confident that it will be easier for newcomers to learn. Fingers crossed that Angular will recognize this and consider shifting to this improved approach. Please enlighten me if I said something wrong
If they (the Angular team) could, they would have done it already. Angular team motto has always been "do not leave anyone behind" and backward compact is a big deal for them. Totally understandable. That's why we (Brandon and co.) are "experimenting" with this in AnalogJS.
For the longest time, we've been talking about a new component authoring format (from Signals RFC) and this is the first "working prototype" that folks can get their hands on to spark more discussions that might be able to drive further decisions from the Angular team but oh well
React is recreating php, so angular might as well recreate jQuery!
How is this even remotely close to jQuery?
If I want to use Vue/React I will use Vue/React. No need to change Angular. Completely useless.
Cool but hell no !
I must disagree with you, it's not cool at all :) but you can definitely keep the "hell no" ..
I would like enterprise apps to not be 4-year-old packages at this point. Let alone in 4 years when they are 8-year-old packages.
Sadly most of the none tech world barely cares about tech and only upgrades when forced to by money.
Its very cool but my brain hates it so much. Can't grok coding like this at all. Astro caused me to have the same internal meltdowns.
In saying this I still want this exploration to continue as I think it shows promise
it looks like a long-dead polymer
I hate it, feels like 1999 php
I really enjoyed the video and the food for thought!
Its surprising at the number of people who miss the points about DX and mental overhead in using Angular. Those things aside, this isn't an option in a standard Angular application, and I doubt it will be coming to Angular any time soon, if at all.
Class components will still always be an option.
Rest easy, friends 🤝
I am surprised too, that people are so used to the overhead that they find the alternative unreasonable.
Angular devs should try doing frontend with frameworks like Svelte and Vue, or SolidJs for once and learn to appreciate the simplicity of life :))
@@vutruong4164 To be fair most Angular devs do not like javascript, I am one of them and I always prefer Angular over Vue. I like Vue for simple things, but for complex projects I don't want to think about the framework.
Ugh.. looks like React. And not in a good way
NOPE😮
NO
😳
short answer: no,
long answer:
god nooooooooooooooooooooooooooooo
Isn't this similar as the video you just made about taking it out of TypeScript into fake pseudo HTML to save characters 🤔
Yeah. He Is content creator, he needs to hype new things ;-)
I used to dislike the .ng format. But I'm getting fond of it now that I use signals everywhere because my components are actually often less than 10 lines long but I still have boilerplate code that is longer than that...
Services will need some used to, but I enjoy the function approach instead of the class and getting rid of the decorator is great.
To sum things up, I'm liking these changes more and more and I would be open for these to be included in Angular.
why did you deleted my comment? what was wrong with it? haha
I didn't, but RUclips drops comments quite liberally (especially if it contained a code sample or something) - feel free to try again
ok i get it, I asked why not just use react in this scenario if we try so much to get close to their design@@JoshuaMorony
I love this, personally. The Angular ecosystem needs to get rid of the verbosity of the component decorator and the redundant imports in order to increase the adoption rate and survive long term. This accomplishes that pretty well. I’d also consider a class based alternative that does the same.
No if we wanted this approach we will be using react
No, please stop this. 🤦♂
Why?
Yes, why ???😂
That's a much larger conversation I'm not going to put in a RUclips comment thread. There's a number of reasons from organization, subjective ergonomic perspective/messiness, and the idea of trying to remove TypeScript for pseudo-HTML wrappers just to save characters which could be just considered a tooling problem. You can also review the comments in the earlier videos. Thanks for commenting on my impression/opinion 👍 @ionelCristianLupu_ @@daokhoinguyen
@@ianokay i agree with you 100%, this is going to a place where I'll reconsider using angular. The best side of angular was (for me) the arrangement. Putting everything in one place just makes it z-generation friendly but it is terrible from the aspect of software development practices, ease of editing, tooling, separation of concerns, breaking code into managable chunks, etc. Please Angular team, make it stop ! You're going backwards to the age of angular 1 ..
@@nir8924 Please remember that Joshua is not on the Angular team