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.
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.
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.
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.
"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..." "..."
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
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
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.
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
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
@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.
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
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)?
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.
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.
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.
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.
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.
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'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 😅
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.
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.
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.
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.
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.
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
@@babutschi can you give an example of a specific thing you do currently that you wouldn't be able to do with this syntax? The only feature this syntax really sacrifices is the ability to use extends/implements on components, which is not insignificant if that is something you utilise, but it is quite rare to see in Angular. I just don't see how this changes the "Angular way of doing things" unless you see extending base components as fundamentally what Angular is all about. I also don't see how it makes it anything like React.
@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 RU-vidrs' 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.
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.
9 месяцев назад
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.
9 месяцев назад
@@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
9 месяцев назад
@@JoshuaMorony thank you Josh! I'll read it with high interest for sure.
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.
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.
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.
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.
@@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!
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.
@@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.
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
That's a much larger conversation I'm not going to put in a RU-vid 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 ..
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
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
@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
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.
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?
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'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
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
@@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.
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.
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.
No... Looks horrible. They removed the structure. This will lead the code bases to be messy. New commers have to learn. If you learn c++ you have to learn pointers, they don't remove it just because it's hard for new commers...
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
Why do javascript people hate classes so much??? This is gross and if the Angular team listens to you and chooses this way for the framework, I will drop Angular.
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.
The more I see what Analog offers, the more interested I am. This structure really appeals to me, and I definitely see how it could offer a simpler experience to new developers, or simply people coming from a non-programming background (cause yeah, people seem to forget they exist). Thanks for sharing your thoughts on the subject :)
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.
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.
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
9 месяцев назад
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.