And I am quite happy with the current authoring format. I don't mind 5 lines of "boilerplate" code. Especially if it is auto-generated, because 99% of my code is (business) logic and will not get "easier" with any of those suggested formats. Does Angular have issues? Yes. Do I think they get addressed by all the changes? Yes. Do I think the authoring format is one of the issues? No. Especially in large scale applications. I will not argue here, but my Notes for the (hopefully soon) upcoming RFC are ready.
But, business logic shouldn't lie in components. They lie in services and the state of your application. Which mostly turn components into simple UI/displays for the user to interact with, which requires almost no lines of code. So we end up writing as much boilerplate than code, especially with signals. The current authoring format is too heavy for only a few lines of code.
Why do you think/say it is too heavy? Why does it matter so much to have fewer lines of auto-generated code that, most of the time, you can just ignore? You could argue that maintaining that code might be an issue, but anyway you probably won't need to touch that "boilerplate" code.
9 วันที่ผ่านมา +48
Keep it the same please.. IF I wanted something like React, I would use React. By altering the syntax, you're also going to change the entire design behind how components work, which will destroy everything that is nice about Angular. Yes... It's a bit more upfront work working in Angular, but it pays off in cleaner architecture.
I highly doubt they are just gonna get rid of the class syntax. I used angular first then switched to react and then back to angular and sometimes I wish it were easier to create a small stupid component...like a functional one, this is what prevents me from breaking down my more complex components into smaller ones, its just too much work, even when using schematics
It's about mass apeal, they want to attract new devs, react did the same, they used to have classes only and then added functional components.You will most likely be able to continue using classes in angular and its prolly better for more complex components but sometimes I wish it were simpler to create a stupid component without having to use a schematic or copyimg another component...
I would like my framework to have an identity, like angular does with its "boilerplate". I don't want it to look like react, svelte, etc even if the logic and system running in the background is different. I like the class system, I like the default project structure, I like the scaffolding, I like assigning different files for my component's html, styling and logic. It's all very logical and explicit to me and it does require a bit of a learning curve and that is ok! Angular is a batteries included framework, with lots of features that aren't suited for an app that only needs "a button". Writing small, simple components is not a framework issue, it's a developer issue. You can very easily write a 1000 line component in react or svelte or angular, it's not framework dependent.
hate all the styles haha, i really dont feel like angular default style has much boilerplat for something like a button i make it in a single file, for everything else i like the separation of html and typescript
The only real boilerplate left is the double imports and the standalone flag. The latter is removed once standalone is the default and the first doesn't require a new format. So I don't see a necessity either.
Angular does have quite a bit of boilerplate. How severe the boilerplate is depends on the component you’re building. When you build a data grid component the boilerplate is not as heavy in relation to the business logic as when you build a button
This is just asding conplexity to Angular. Now you gonna have project with rxjs, signals, modules, standalone component, old and new component. This will just be creating more confusion for older projects that uses angular since forever.
The thing is that probably you'll not be forced to write in this new format, like standalone components that is being added as default, but you can continue writing your app without standalone components. So, if you have an old project, just continue doing what you're doing. For those who are creating a new project, then you can choose what approach you'll use. Signals are other example: You can use it, but you're not forced to. It's just a feature - that can helps a lot -, but you can continue writing Angular without it.
@@Dajuhf yes, but you get further away from angular when hiring new employee, it's just adding more complexity and eventually forcing you to change the whole app.
@@LarsRyeJeppesen better or not it's rarely that you will get hired on a project that stays on the edge of latest framework version, so you'll have to learn a lot more than you do in React for comparison
Ultimately what I'm looking for is consistency in: construction, composition interfaces, and refactorability. I also want my devs to "use the framework". My concern is the more like JavaScript the components looks the they may be tempted to use anti-patterns instead of the opinionated features and libraries of Angular. Instead of relying on the framework we will have to be very vigilant to ensure consistent code styles between teams. In addition I really don't like "you just have to know" features like you have to know how foldering affects inheritance. I want all relationships to be expressly defined in code. I'm not going to use Angular for a website. I'll use other frameworks for that. I use Angular to build web applications that span several teams. I don't need simple I need consistency.
8 วันที่ผ่านมา +1
I'm not sure what this has to do with components authoring?
Let me explain how this relates to component authoring. The new syntax makes components look more like plain JavaScript/TypeScript, which directly impacts how teams approach component creation and maintenance. When components are clearly 'Angular-style' (with decorators and explicit metadata), it enforces a specific pattern that teams naturally follow. The more JavaScript-like syntax, while simpler, might encourage developers to bypass Angular's established patterns and solutions in favor of custom approaches. For example, they might be tempted to handle state management or component communication in ways that don't leverage Angular's built-in capabilities. Consider inheritance: In the current syntax, seeing @Component immediately signals 'this is an Angular component with specific rules and behaviors.' The folder structure's impact on inheritance is part of the framework's conventions. With the new syntax, these relationships become less explicit in the code, potentially making it harder to maintain consistency across large teams. So while the new syntax might make component authoring more approachable, the author comment addresses the broader implications for maintaining consistency in large-scale applications where multiple teams need to work together following the same patterns. It's not about whether the new syntax is 'better' or 'worse' - it's about how it might affect our ability to enforce consistent architectural patterns across teams.
I like the way it is now. Angular team already changing too much and on top of that if this happens, many devs will rethink about using angular. Personally, i like class based approach. Also, separate files gives me separation of concerns. It also easy enough to understand whats going on. Honestly speaking, i do not like any new styles. Angular is fundamentally different, i get it, but how many devs use it for fundamental reasons? The way we write code in angular, makes it unique, makes it angular.
1st syntax loks like React one with Angular stuff 2nd syntax looks like Vue or Svelte one with Angular stuff Initially, when I heard about the SFC Analog proposal on this channel, I wasn’t a fan of the idea. But after completing a React internship, I have to admit that Angular has a lot of boilerplate - even for something as simple as a component (although I still dislike JSX/TSX templating syntax BTW) I'll definitely try the Analog SFC; the syntax makes a lot more sense. It also encourages avoiding oversized components since logic, template, and style are all in the same file. For me, having these in a single file isn’t a drawback: they’re clearly separated into sections, just as they would be in separate files Between both proposed syntaxes, I personally prefer the second one. Ironically, I was actually considering switching from Angular 18 to Svelte with the new Runes syntax for my side project today because of Angular’s verbose component syntax 😅 Regarding Angular's verbosity, I think it’s fair to say that Angular is like the Java of the frontend JavaScript ecosystem: extra code for what’s often a simple task For example, having to use classes for something as simple as pipes feels unnecessary; simple functions could handle that just as well. In the same way, functional-based route guards make more sense than class-based ones I also don’t see it as a drawback that JavaScript front-end frameworks are starting to resemble each other more (as Fireship mentioned in his video about Svelte's new Runes API). This "standardization" could actually make Angular more approachable and help it gain wider adoption. It feels more like a sign of maturity in the JavaScript front-end ecosystem.
To be honest this just feels like the Angular team has nothing better to do than constantly rewriting things that already work fine, causing headaches. They should be focusing on more important manners than breaking whatever angular devs already like.
All af these hypothetical examples looks and feels like shit. If I would like to go with react-like component syntax I would go in react development. Don''t bring that shhit to angular please
One of the best features of the current component authoring format is that components can implement interfaces. So you could have a search result interface, and different kinds of search results, but your search result list doesn't need to know all the different types, it just needs the inputs and outputs the interface defines to talk to its children. Would such a thing be possible with any of the alternative systems? In general, I'm very critical of object oriented programming (favouring functional in most cases), but I think components are the few situations where OOP makes absolute sense.
Angular development already went from creating really scalable framework for confident solutions of frontend tasks to siphoning and pleasing npm-library-minded people with APIs that bring absolutely nothing new every other month just to create "Momentum". Angular Team needs to point in public space that Angular component authoring format worked for 8+ years and Angular ecosystem is capable of doing everything web frontend framework needs without installing garbage on your or remote machines and making things up. Just stabilise APIs, close old github issues, make a bit of docs with explanations on architecture and enjoy working with Angular, not working on new Angular whistles every 4 weeks. Comment about this particular video: All of NG boilerplate is reduced to terminal command with few letters like "ng g m hello" and you can configure behaviour of these commands too.
I use Angular for its clarity and readability. I don’t care about verbosity, if you don’t like it please use another framework. I hate the 3 propositions and I hope they will keep the current component authoring
If they just remove the imports, make the selector be the class name of the component and made the component options configurable in the project configuration instead of always be granularly configured on component like OnPush, it would already solve most of the boilerplate. Besides this I don't think I want any drastic change like these examples.
3:50 Angular is fundamentally different from react. Could you please elaborate that difference. or probably make a video on the fundamental difference between angular, react and vue please.
i also want to see a video exactly on this statement!
8 วันที่ผ่านมา
The way it handles the DOM, makes changes and detect interaction is very different afaik, but I don't use React much so I could be wrong. Plus React is not really a framework, Angular comes with opiniated tools on how to do a lot of things (take HTTP for example) while React does not have these tools or does not have a strong opinion on how you should use them.
I'd be happy with either of these formats (well not the css like one). I also like the analog experimental format and use it on my site. What I love about Angular templates is the control flow. I find it much more readable than jsx/tsx, and that would still remain with these new authoring formats.
People bitching about some default config files that get auto-generated anyway are totally oblivious to what large React/NextJS projects look like. Simmer down.
@@PeterKassenaar @PeterKassenaar Peter! How nice to see you on here! What did you think about the CSS style component authoring :) Will it work outside of April fools day? On a more serious note: What problem is this solving for devs writing Angular in their day to day? I have two problems that need fixing: 1. robust change detection (bye bye zone.js) 2. auto mapping TypeScript interfaces to reactive forms because I would love to pass in a generic to a formGroup and calling it a day :) The rest is fine honestly speaking. I'm not saying I will stop using or recommending Angular as a batteries included JavaScript framework if it starts looking like React, but this specific topic doesn't address issues I'm having myself...as long as they retain the option to have a separate template file that is :)
To bring another perspective: even though i've only briefly looked into jetpack compose with kotlin I have fond memories writing uis with it. there could be some magic in a domain specific language based on js/ts. What I much rather would like to see is some improvement on the compositional nature of angular. Currently i do not like where directives are at. I would love to create more behaviour driven components where i could compose the components by attaching additional directives more easily. As an example: I've built a Table component with a context menu and a toolbar for multiselect actions. To define those actions (eg. delete, notify users, transfer data, ...) I could create a DI token "multi: true" with a callback that is executed on click. Now, what if i want to override a template for a specific element (like it's new and recieves a badge or something)? Well we could use an additional templateRef, but where do we define the fallback or default value? What if we want to access a property on the table? ... Sooner or later you are using contentChildren, viewChildren, injected abstract classes, ContainerRef, shared services, DI tokens, etc. in pretty complex relationships with each other. Where I'm getting at is this: It is somewhat verbose to design a truly composable component, without making cutbacks in typesafety (generics!) or some other form. Maybe I'm not experienced enough to build a clean solution for this purpose, but I belive there is some potential in simplifying this aspect of development with angular.
I understand your concerns about component composition and behavior management, but I think there's a crucial insight to consider here: you might be unconsciously trying to replicate Jetpack Compose's composition model in Angular, which leads to unnecessary complexity. While Jetpack Compose offers a beautiful way to compose components where everything is contained within the component's scope, Angular provides different primitives for managing complex component interactions and state management. Each framework has its own philosophy and strengths. Instead of trying to handle everything through component composition (which leads to the complex mixture of contentChildren, viewChildren, DI tokens, etc. that you mentioned), Angular encourages us to leverage services and dependency injection for complex state management and behaviors. For your table component example, rather than making the component handle everything, you could: - Create a TableStateService to manage selection state - Use a separate ActionRegistryService for your multi-select actions - Keep your components focused on their layout responsibilities - Leverage DI scoping to maintain isolation when needed This approach would dramatically simplify your templates and component logic while providing better testing and maintenance characteristics. Your complex relationships between components would become clear service interactions, properly typed and easily testable. Remember: Each framework has its own set of primitives that make sense within its ecosystem. Just as we wouldn't force Angular's dependency injection into React, we shouldn't try to force Jetpack Compose's composition model into Angular. snippet: codefile.io/f/i22dalg3Vb
@LarsRyeJeppesen, the issue is that Angular is starting to stray away from the "opinionated/enterprise framework" vibe. While the recent changes (signals, new templating control flow syntax, @let, ...) are good; there are now five ways to achieve something in Angular. This proposed change adds to that even more, and in that sense seems really unnecessary; I don't think it provides that much more to the developer experience for it to be added in the framework. The learning curve of Angular was arguably the steepest of all the frontend frameworks, now it is even steeper. In other words, while trying to make the framework friendlier and more approachable for beginners, they ironically are making it less so. To avoid that, as @babutschi mentioned, the only solution would be deprecating existing APIs, or even worse, removing them and break backward compatibility
@@bobank Don't you think signals are awesome? Just curious.. I can't imagine going back to non-reactive programming. Signals have been such a game changer
@@LarsRyeJeppesenat which point in time was angular not a reactive framework? Angular as it stands today was always built on rxjs, which has reactivity literally in its name
To me the current format of the component is not what make Angular "feel bad". And the number of files is just a bad argument, it's just preference. Nobody force you to have 3 files per components. The thing I would really like to see is spread properites `` and no selector component (technically possible with attributes but misleading with directives).. And then we would have a more modern framework. The funny thing is that Angular (more like Analog) is moving towards a Svelte style, meanwhile Svelte is taking quite a few features from Angular. (Looking at you `sv migrate` coping angular schematics). Give me the angular router and FormBuilder in Svelte (client only, no Sveltekit) and I would say Svelte is juste a better Angular at the moment.
I've worked with Angular for the last 6 years and I think Angular is destined to become niche or abandonware no matter what, as Google did too little too late and most of existing Angular code is already written in a very unnecessary convoluted legacy way by Java devs doing front end, with unnecessary old versions like Angular 8 because "nothing really changed in the next versions", like "nothing really changed" from Java 8 onwards. Angular has sadly become a better jQuery for Java apps for 90% of what I saw on the market until now, and it breaks my heart.
I've been arguing about this a little over on reddit. But after watching this video, I could get on board with the html first syntax as long as there was a clear separation between component code and template markup. The functional format returning strings just seems like it would be a maintenance nightmare. I don't know what issues the current separation of concerns format has but I would think that any of them could be solved by some advancements in the compiler and other cli tooling.
An option for splitting the component in multiple files should be still there. Createing for example an mat-table with 6-10 columns leads to much html. But I really like that the angular team wants to remove the boilerplate code.
I don't know angular but if the goal is to reduce boilerplate than there's nothing shorter and easier then jsx. Not only is it shorter, it's easier to handle data, it's more modular and more aligned with the "everything" is an object philosophy in javascript. And since javascript is made for working with objects, jsx feels natural. Sure, the templating thingy (like with vue or svelte) feels easier for "html" devs at first but if you wan't to get things done and write a little more complex stuff, you actually want jsx. I will claim that if you know and understand jsx (and have actually written real components with it), you'll never want to go back to any other syntax.
I always use the angular cli to generate components and probably that will not change in the future. I don't see any problems with that or with the current component authoring format. Why would you complain about something which is generated for you automatically, I don't understand that :)
Remember when Vue anounced its composition API and they received the same backslash. With time people recognized it was for the better. With Angular it will be the same.
The current angular syntax is great for doing some advanced stuff but I've always felt like these was something missing for creating mini components. I also don't want there to be magic in so we have a tall order here. I'm leaning towards just breaking up the @Component decorator into @Template('content...') @Style('styles...') and @Import([...modules]) and keep the class. The functional approach does look appealing and I think changing the extension to .ng would help with tooling as well so ngOnInit is implicit
As far as I get it, you'll not be forced to use this. Probably in a time they can put some of those formats as default, but like standalone components, you'll still be able to write the old way. It's more a feature that helps new user and apps and that you can use, but like standalone and signals, they're there, but you don't need to use it to build an app in Angular. What I can see on the comments section is people getting frustrating that this can change, that it can generate complexity on old projects, and so on. But let's be realistic here, you don't need to use a feature just because the team released it. Keep writing as you like, the new features are >new< and you can choose if you want to use it or not.
The team is doing well simplifiying the framework. They can’t beat React though but reducing complexity and files/ code boilerplate is a necessity. It would be better to hide complexity behind abstractions like use a folder hierrachy instead of ngmodules same thing with routing. Rxjs is superb but hard to comprehend fully: one Day you think you did great , à Day after you discover your rxjs pipeline has introduced a bug. To much rxjs code in one file is depressing. (Sorry for bad english and typos)
Single file standalone components already reduce the boilerplate by quite a lot. It makes creating a new component literally creating a new file and have vscode (or whatever editor) write the boilerplate template. No relying on the CLI, No juggling with modules or file references, no separated files for template or css unless you are working with huge components and you feel the need to break it into separated files. I would like for the angular team to just keep improving on that direction as currently the only drawback is that it treats your template as string and feels really bad to use. I have been working with React lately and something I don't like is that about the flexibility is that it leads to quite messy files with hidden components. Not to mention sometimes having to jump back and forth between functions and template in tsx to find where some piece of data comes from, but that might be just a skill issue. Still, I am not a big fan of the idea of having to read through code like that because someone on my team decided to use the new syntax, even if I am not forced to write in the new style.
The SFC part is only partially true, the way angular SFC components look is terribly boilerplaty even with this. You still need to manually define the imports both on the typescript side and in the angular crazy module system side, you also need to order your visuals before the code which is not exactly good from a developer experience side of things, you need to go up and down in the files all the time because of that.
I also find the opposite of React as being bad in angular, extremely massive components instead of tinier ones with state scattered all over the place, the reasoning on them and refactoring them is very annoying. Compared to "hidden components in files" it seems worse.
@@diadetediotedio6918 I don't think that having the ts above or below the template makes a big difference, the same problems on scrolling up and down still apply (you can also split screen on the same file if you are working between ts and template a lot). And I don't think the module import is a problem related to the component autoring. If they can make the new component styles work without the need for them, the could also make the current format work without them.
@@matiasmiraballes9240 I think it makes a big difference, maybe it is just for me, but I like to reason about things in the same way I would setup them. I am a programmer primarily, so I expect the behavior to come before visuals, I also like a clear dependency graph so I like seeing the declaration of my dependencies (like variables or methods) before my consumption of them (in the template, like bindings and events). I think you can disagree on this one. I think I don't understand what you are trying to respond about modules, can you explain it for me in more details so I can reason about it?
@@diadetediotedio6918 Regarding your 1st point, yes, I am just too used to scroll down to the ts code that it doesnt bother me a whole lot, but I agree it would be a nice improvement. For the 2nd point, I was replying to this > You still need to manually define the imports both on the typescript side and in the angular crazy module system side I might be wrong, but will the new component style somehow get rid of the need for modules? If yes, will it be done in a way that cannot be replicated with regular class components? if not then the current and the proposed ways of writing components are equally verbose in that regard.
Fine, but I hope they won't remove current way of components authoring. I love separation to HTML, CSS and TS. Let's say you're doing a form, it's a lot of HTML code, and quite lot TS code, I want it separated because it's easier to read that way than if it was mixed. With small components it's maybe a little bit too much tho and even if you do it in a single file you have quite a lot boilerplate. Anyways it won't change how Angular works, best things about Angular are solid structure, completeness, almighty DI, astonishingly easy reactivity, directives, interceptors, new control flow syntax, very good router and that will stay us
i prefer have my code separate in multiple files as is it. having all the logic, html, styles like react is horrible. manteniment those projects is difficult(working with nextjs because that is the company stack) and in some cases(most of the time) i refactor the code for readability. yes start with angular in some cases is a litle dificult but is more easy for me do manteniment to a angular project than a react one
You can easily split the logic, HTML, and CSS in React though. Similarly, it is possible in Angular to have the HTML, CSS and logic all in one file. It is up to the dev/team how they choose to proceed.
I don't like this potential way of creating components, since it removes of the capabilities of OOP features, the ability of inherence, design patterns and so on that you could do with classes
I probably won't adopt the "new style" if it ever drops but I can kinda understand that people think this looks like boilerplate. What PrimeTime video is his reaction to angular in? I have never seen him mentioning it at all.
That would be really disgusting. I really hate the way React is written. I like that Angular splits the HTML, the CSS, and logic, if any. Now that being said, functional components CAN play an important role in Angular, but in a different capacity. The way we refactor code to small snippets. Functional snippets, like templates in a code editor, can help reduce code. Think of them as string templates embedded in the Angular change detection system. An easy and functional way to create those would be really great. There can act as super dummy UI-only components, like a library of string templates.
Why do you and a lot of people hate "boilerplate" code so much? Most of the time, it's auto-generated, and you can usually just ignore it. I think "boilerplate" code actually helps a lot to keep important things simple (you know, like business logic and those kinds of things).
I aleeady switched my personal learning roadmap to react. I currently on the search for my quick prototyping stack and I must say with zustand, shadncnui and react query I‘m pretty satisfied. I don‘t see any advantage in using the new format if it will happen somewhere in the future. I also think it‘s time for a fork in angular and give it to the community from the day the new format will be released. I also don‘t know how they will maintain the backwards compatibility with the new format. Maybe soneone could explain how they will do this.
Optimising for first time impressions is a stupid goal. The current system is great because it allows you to better mentally handle complex systems. I'm sick of a race to make a TODO app as quick as possible. Who cares? And if Theo t3GG or whatever his name is doesn't like it, thats a plus in my book. All the people who want this already can have it with Vue, React, Svelte etc Go nuts.
It should of course be balanced with other concerns, but I think it's a not insignificant issue. Having the general perception of Angular outside of Angular devs be that "legacy style framework for Java devs that nobody wants to use" causes real problems, no matter whether this general perception/stereotype of Angular is fair or not. A big one being that if Angular is not a framework that non-Angular devs want to use, it's going to be harder for companies to hire the talent they need, and it can make it harder to justify using Angular or even make switching away from Angular a way to make a business more viable to run. If we have non-Angular devs excited about using Angular I think it will be a significant win for everyone in the ecosystem. It shouldn't come at the expense of the things that make Angular great, but at least from my perspective I don't think it needs to.
@@JoshuaMorony uniformity in solutions never leads to a good result on an evolutionary basis it just creates an opportunity to be wiped out. The whole idea that a complex system needs to be trivial is wrong. Sure, make some CLI helpers to get started but Theo's "all of this for a button" is a pointless metric. You can have a button in 3 files if you really want but no one is building single button apps. I'm for simplification but taking away one of the preferred systems of your existing clients to attract more of the people that rejected you on the "all this for a button" metric is a bad idea. People will be attracted to a strong, consistent, evolutionary framework with backward compatibility. Thats enterprise, not bells, whistles and metric gaming
I think approach 2 suits angular style better than the JSX one (even if I like it more personally), the other will feel more "natural" to angular devs. Still, I don't think that's gonna happen, those enterprise programmers-wannabe are literally one of the worst to convince, extremely dogmatic about their convoluted and boilerplaty way of coding being "the best" or "enterprise-level", I prefer to just let they stand on their misery.
God... I'm just done migration a big application in order to use standalone components, I'm in the middle of changing it to use signals and now that... I'm aware that I shouldn't be pissed about Angular innovating but bringing these kinds of big changes every year force us to mainly maintain our applications instead of adding feature to them...
Angular is good, as it is. Especially now, it is great with new Angular primitives, as Signals were made stable. Why should we use shitty things, like .jsx, when we have a great component system in Angular? No, thanks.
In my opinion Theo should start making the lifecycle of componentd easier. Its probably a skill issue, but i come from react and miss the simplicity of components update when the prop changes. This is Not the Same with angular and Material components in my experience.
What about a pure html component for those where their only responsability is rendering information using inputs? I ended up creating a single class component for this purpose
Nope. Not for me. If I wanted to use something that looks like that, I’d use vue or svelte. Not everything has to look and feel the same way. Angular at the current state is awesome and I would hate to see an angular project with a different component authoring system. It’s not about learning curve but it is about familiarity with angular.
8 วันที่ผ่านมา +1
I'm 100% with you on this. Which makes me one of the only few given what I can read in the comments 😆
I think people against a new format are more likely to comment. If we were to go on the comments it seems a solid 95% of people are against a new format, but the like ratio of this video is a bit over 95% likes. Also not a particularly scientific measurement, nor does a like necessarily imply agreement, but its decent at gauging sentiment. Broader polls in the past have also made it seem that a majority of people are actually in favour of a change (and I have to assume the Angular team have a decent sense of the overall desire for change)
@@JoshuaMorony Just because people are against a new format, does by no means lead them to dislike your video - you can still think it's a good video, even when you strongly disagree with the proposed idea(s).
Please dont change the angular authoring syntaxe. Please don't be react or vue or whatever else. Please don't try to please eveyone, because no one can. Is it verbose ? Yes Is it frightening on a first impression? Only if you come from react like world. I love that angular separates logic from the view in two different files. I love how dependency injection makes unit testing so easier I love how you can keep your files tidy and clean no matter how big your project is (thanks to dependency injection vs nesting components inside a ton of contexts in react) Angular is fundamentally different and should keep itself unique. What's the point of gaining more developer base ??
A new format doesn't have to lose these things though, and certainly not DI/services, it's different syntax/sugar for building components on top of the same Angular framework. I suppose it's possible they go with an SFC only approach for a new format, but I'd be surprised given how many people like separating ts/html/css.
@@JoshuaMoronythe angular way of component authoring is fine. Why do you hate it so much? Why waste so much time on something that is already pretty good? what is wrong about it, where is the boilerplate? I DON'T GET IT
@@JoshuaMoronythe angular way of component authoring is fine. Why do you hate it so much? Why waste so much time on something that is already pretty good? what is wrong about it, where is the boilerplate? I DON'T GET IT
@@babutschi I didn't say I hate it, I think it can be better. Whether that is worth it or not or what that might look like is up for debate, but given the direction the Angular team seem to be moving in it seems enough people think doing something is worth it. I consider boilerplate to be any extra code/config/imports/concepts required to do something that could be done with less, so if we take the button component from the video as an example I would consider the component decorator import, the decorator concept in general, the config for the decorator/the imports array for the decorator, all to be "boilerplate"
8 วันที่ผ่านมา
I would argue that logic shouldn't be in your components in the first place. Your component should only reflect some part of your application state and have a way for the user to change it by interacting. It is not "clean" to have components that does too much. They shouldn't do HTTP calls, they shouldn't have business logic, and so on. Those belongs to injectable services imo.
I am confused about why people find it simpler to stuff more contents into a single file (e.g., the analog approach), instead of separating views and logic. It seems like more scrolling is needed to find what im looking for, insead of juts going to the component resp. the template file.
Please don't transform Angular into React? If you want React, just use React. We use Angular because we want to code properly and not a giant mess. Having well separated files between view, logic and styling is one of the greatest things about Angular.
You can still separate those things in React too. I have never mixed styles, template and logic in the same file in React - that would be a mess as you rightly say.
@@kalvinhart3800 Nah, you really can't do much in React without using JavaScript directly into the template. Also, separation is so poorly implemented that a lot of people use Tailwind for most of their CSS, another terrible idea.
@@sodium7554 you can put CSS,SCSS or Styled Component in a separate file and import them into the component. You can put all logic inside a custom hook and then destructure the logic from that hook into the main component to then use it in the JSX template (this also makes writing tests for the logic and UI much easier). It is very easy to structure a React app like an Angular one, I do it all the time.
Could someone explain to me why people claim Angular's current syntax doesn't allow for simple component programming? I'm genuinely confused by these complaints. Are critics aware that Angular supports inline HTML and CSS? What additional simplification are they looking for? From my experience, I've noticed that most Angular critics, particularly those still complaining after Angular 16, have likely been exposed to poorly architected applications. I would venture to say that roughly 80% of both professional and personal Angular applications suffer from over-engineering and bloated components, which unfairly tarnishes Angular's reputation. This perspective was reinforced a year ago when a ex-colleague of mine, who used to be a staunch React advocate, completely changed his stance after working with my team. He now strongly prefers Angular and wouldn't consider going back to React. The framework itself isn't the issue - it's how it's being used.
No thanks, the original angular format is superior to all this crap, I'll stick with it. I don't understand why you'd want to mix everything into a single file
Because I'm not a clusterfuck mazochist, if I want a component I don't want to jump between 3 files just to get what's going on, I also don't want to use the terminal to create a very simple and well contained component that will end up looking an OOP mess, what the heck.
Angular was NOT designed for just putting a button on HTML. If this is your main goal you should choose some library like React and not a serious framework like Angular. Angular was designed with building and scaling complex LOB applications. DON'T make it like React!!!!
Why would you even need any framework or library at that point. It is really just a button. As soon as that button becomes a more generic component again the original way of setting it up with separated files for html/ts/scss is best. Used to code in angularjs/angular + laravel and upgraded to angular 2 as soon as it hit from 2011 to 2019. Since 2019 I've been working with Vue cause I switched jobs and they use Vue + Laravel. I still miss the clean code separation and pretty strict guidelines in how to organize/setup your app. With vue every project you see a different approach and often resulte in a messy codebase. Angular is just hands down the best front-end framework there imo.
Instead of a new "Component" authoring format, I'd rather have more new "template" authoring formats, like @if/@for/@defer, etc., for content projection and template snippets authoring... Creating and maintaining the @Component decorator is only a small subset of the "authoring" activity. Yes, it can be an eyesore when things grow, but IMHO moving away from verbose APIs like `ngTemplateOutletContext` in the **template**, and offer better typing for template elements are better starting points than introducing "components as functions" or "Svelte/Vue style SFC". Evolving `*ngIf/*ngIfElse` to `@if/@if else` has been great. Why not continue on this front more? Maybe it's technically more feasible if there's a new Component format in place? I don't know. And in Svelte5 there's this new {#snippet} API, which I think the Angular team can steal a thing or two from.
I don't understand where the boilerplate code is in the current authoring format, the only thing I would like to see go away is the imports array. All of these alternatives are truly awful.
Well, the functional idea looks just like react and the html idea just like vue - I really don't get, how why anybody would then not just use these frameworks.
I think you nailed it - in my experience Angular folks create huge components. The presence of a CLI to generate components was helpful early on, but it is a sign of framework limitations. I think the effect is that Angular subtly guides developers to create big honking components with the possibility of refactoring to smaller components (best intentions), where a simpler format, like React of Vue, creating small things is part of the "flow". I encourage Angular developers to use inline templates and styles to help create some friction against this tendency. While I do like the Vue/Analog way, I think the functional approach might be better in the long run. In React I'll often just add a functional component at the bottom of the source as I "discover" them, and move them around as they stabilize.
9 วันที่ผ่านมา +7
That's because the ethos behind Angular is much more "Professional enterprise/architectural up-front thought out" software development, and much less "hobbyman, sandbox, toybox until you burn your fingers often enough" approaches like React. Want a button to use everywhere in your application? You get to define its exact behavior and capabilities and it becomes an actual software component in its design. There's a structure and way of doing things, no spaghettification (You can still do that of course, but that just means you go against the ethos). It's meant for writing applications, not hobby-projects and primeagen hello world button shenanigans.
That kind of thinking is what keeps the specter of waterfall alive, and the paternalistic alienating view of "smart people" vs. "dumb people". Betting you have "architect" somewhere in your title? No wonder so many dislike Angular when folks use it as a way to demean others. I have worked on crappy applications in Angular, React, and Vue, and I have worked on great applications with all of them. But you do you.
9 วันที่ผ่านมา +4
@@JeffryGonzalezHt sensitive I see? I didn't demean anyone. I'm making statements about frameworks, not people. React is verrry permissive. Sure, there's just good projects and terrible projects. To me it's more about how much something allows you to do stupid stuff. The more you're allowed to do stupid stuff, with no one enforcing some standards, the more you create unmaintainable "terrible projects".
angular is really focused on DI. even the query system does resolve around the concept, they need to change alot just to allow these patterns. How i could inject a parent component or a self directive if its a function? instead of a single token value (class constructor) you need tokens. You started from 1 class you ended with a function, a separate registration (cant decorate functions), a token for injection. It may appel React devs but really hinders the real power of Angular in the process. Angular still lacks power on the query system in particular with projected content when it's dynamic, why focusing on aesthetics when you have missing features documented way back to 2016 by Misko Hevery himself!!!
I like the current syntax but there's some smaller things that I feel that are super easy to do using JSX syntax but in angular requires more verbosity, and when that happens is super frustrating to think "damn this would be easy if I could use JSX". That's why i think would be nice to see in angular the possibility to use JSX like happens on Vue as an optional way. A simple example for what I'm talking about, would be things like passing all the parent props to a input, for creating a custom input component, in JSX you can just spread the props of the component in the input, but in angular you have to create the input props manually, and pass it manually.
The examples people always drag out are less than a hundred lines. It's not uncommon that I have component logic 300+ lines and templates just as long that can't be chopped into smaller pieces. Angular's "boilerplate" is for those sort of real world realities. I can't stand react or any sort of template + logic in one file system, because it always turns into a garbled nightmare in any real world situation. I'm not going to make a hundred one-time-use subcomponents just to make my parent component smaller. This just strikes me as Jr devs trying to sound edgy reading a single blog post and developing hard opinions and then blasting it on X. Then everyone thinks, "wow, so many people have this thought, it must be right" Enough ranting on the shitter. Back to work.
> that can't be chopped into smaller pieces. They probably can. They absolutely probably can. I know you like to tell yourself those people disagreeing with you are "juniors devs with lack of experience and having dumb opinions", but you should apply the same standards to yourself. Most of angular applications I've seen are literally an extreme mess, most of the time those giant components (and I'm not talking about 300 lines of code, I'm talking about 700+) with state and random side effects all around the place are a consequence of the poor component model that angular induces.
With angular feature, little near to functional style which widely adopted other libs and framework, it will game changer, wider audience with no or less experience can onboard easily..
Angular is starting to stray away from the "opinionated/enterprise framework" vibe. While the recent changes (signals, new templating control flow syntax, @let, ...) are good; there are now five ways to achieve something in Angular. This proposed change adds to that even more, and in that sense seems really unnecessary; I don't think it provides that much more to the developer experience for it to be added in the framework. The learning curve of Angular was arguably the steepest of all the frontend frameworks, now it is even steeper. In other words, while trying to make the framework friendlier and more approachable for beginners, they ironically are making it less so. Soon, to avoid that, the only solution would be deprecating existing APIs, or even worse, removing them and break backward compatibility
I switched to React from Angular for my Projects since Angular added Signals. Now this! I don't think that I will be using Angular anytime soon. Syntax Changes makes it feel that Im learning a new framework. In Angular's case, Im just learning the same framework again and again. It feels like Angular is just migrating back to Angular.js 1
I just wish they would fix that inline templating using strings, as it just doesn’t work. I can’t even auto-format the code because it’s treated as a string. Also, that “prime” bit was awful. Trying to please these kinds of people is what ruins a framework. It’s like saying, "We need to change modules to standalone because modules are too hard for people to understand." Modules were beautiful and gave a more robust, enterprise-like sense of organization. But no, they had to cater to certain people. I'm sorry, but the idea that needing to import a module first to use a component is too complex for you, just go use React.
I have a weekly newsletter with extra content if you want to join: mobirony.ck.page/4a331b9076
And I am quite happy with the current authoring format.
I don't mind 5 lines of "boilerplate" code. Especially if it is auto-generated, because 99% of my code is (business) logic and will not get "easier" with any of those suggested formats.
Does Angular have issues? Yes. Do I think they get addressed by all the changes? Yes. Do I think the authoring format is one of the issues? No.
Especially in large scale applications.
I will not argue here, but my Notes for the (hopefully soon) upcoming RFC are ready.
I totally do agree with all of this 👏 I don't want Angular to be just a kind of React like.
++
But, business logic shouldn't lie in components. They lie in services and the state of your application.
Which mostly turn components into simple UI/displays for the user to interact with, which requires almost no lines of code. So we end up writing as much boilerplate than code, especially with signals.
The current authoring format is too heavy for only a few lines of code.
Why do you think/say it is too heavy? Why does it matter so much to have fewer lines of auto-generated code that, most of the time, you can just ignore? You could argue that maintaining that code might be an issue, but anyway you probably won't need to touch that "boilerplate" code.
Keep it the same please..
IF I wanted something like React, I would use React.
By altering the syntax, you're also going to change the entire design behind how components work, which will destroy everything that is nice about Angular.
Yes... It's a bit more upfront work working in Angular, but it pays off in cleaner architecture.
I highly doubt they are just gonna get rid of the class syntax. I used angular first then switched to react and then back to angular and sometimes I wish it were easier to create a small stupid component...like a functional one, this is what prevents me from breaking down my more complex components into smaller ones, its just too much work, even when using schematics
But WHY? I dont get it. Angular latest component syntax looks so nice to me
It's about mass apeal, they want to attract new devs, react did the same, they used to have classes only and then added functional components.You will most likely be able to continue using classes in angular and its prolly better for more complex components but sometimes I wish it were simpler to create a stupid component without having to use a schematic or copyimg another component...
I would like my framework to have an identity, like angular does with its "boilerplate". I don't want it to look like react, svelte, etc even if the logic and system running in the background is different.
I like the class system, I like the default project structure, I like the scaffolding, I like assigning different files for my component's html, styling and logic. It's all very logical and explicit to me and it does require a bit of a learning curve and that is ok! Angular is a batteries included framework, with lots of features that aren't suited for an app that only needs "a button".
Writing small, simple components is not a framework issue, it's a developer issue. You can very easily write a 1000 line component in react or svelte or angular, it's not framework dependent.
We never fight amongst the Angular community when it comes to component authoring /s
Love how he put "POTENTIAL" in caps because he knows the community will complain about change of any kind
hate all the styles haha, i really dont feel like angular default style has much boilerplat for something like a button i make it in a single file, for everything else i like the separation of html and typescript
There is no boilerplate. What are you talking about man?
The only real boilerplate left is the double imports and the standalone flag. The latter is removed once standalone is the default and the first doesn't require a new format. So I don't see a necessity either.
@@the00one45Standalone is removed in V19, it's nice! Now what's missing is ability to globally set change detection strategy to OnPush everywhere.
Angular does have quite a bit of boilerplate. How severe the boilerplate is depends on the component you’re building. When you build a data grid component the boilerplate is not as heavy in relation to the business logic as when you build a button
@@Mooooov0815 And what is this boilerplate? Btw. separation of concern via multiple files is not it.
@@Mooooov0815 Yes please tell us more about that boilerplate .
This is just asding conplexity to Angular. Now you gonna have project with rxjs, signals, modules, standalone component, old and new component. This will just be creating more confusion for older projects that uses angular since forever.
The thing is that probably you'll not be forced to write in this new format, like standalone components that is being added as default, but you can continue writing your app without standalone components.
So, if you have an old project, just continue doing what you're doing.
For those who are creating a new project, then you can choose what approach you'll use.
Signals are other example: You can use it, but you're not forced to. It's just a feature - that can helps a lot -, but you can continue writing Angular without it.
It's already over. Newcomers to Angular doomed to learn the whole path of Angular "renaissance"
@@mattspeedit's much better.
@@Dajuhf yes, but you get further away from angular when hiring new employee, it's just adding more complexity and eventually forcing you to change the whole app.
@@LarsRyeJeppesen better or not it's rarely that you will get hired on a project that stays on the edge of latest framework version, so you'll have to learn a lot more than you do in React for comparison
Ultimately what I'm looking for is consistency in: construction, composition interfaces, and refactorability. I also want my devs to "use the framework". My concern is the more like JavaScript the components looks the they may be tempted to use anti-patterns instead of the opinionated features and libraries of Angular. Instead of relying on the framework we will have to be very vigilant to ensure consistent code styles between teams. In addition I really don't like "you just have to know" features like you have to know how foldering affects inheritance. I want all relationships to be expressly defined in code.
I'm not going to use Angular for a website. I'll use other frameworks for that. I use Angular to build web applications that span several teams. I don't need simple I need consistency.
I'm not sure what this has to do with components authoring?
"But why male models?"
Let me explain how this relates to component authoring.
The new syntax makes components look more like plain JavaScript/TypeScript, which directly impacts how teams approach component creation and maintenance.
When components are clearly 'Angular-style' (with decorators and explicit metadata), it enforces a specific pattern that teams naturally follow.
The more JavaScript-like syntax, while simpler, might encourage developers to bypass Angular's established patterns and solutions in favor of custom approaches. For example, they might be tempted to handle state management or component communication in ways that don't leverage Angular's built-in capabilities.
Consider inheritance: In the current syntax, seeing @Component immediately signals 'this is an Angular component with specific rules and behaviors.' The folder structure's impact on inheritance is part of the framework's conventions. With the new syntax, these relationships become less explicit in the code, potentially making it harder to maintain consistency across large teams.
So while the new syntax might make component authoring more approachable, the author comment addresses the broader implications for maintaining consistency in large-scale applications where multiple teams need to work together following the same patterns. It's not about whether the new syntax is 'better' or 'worse' - it's about how it might affect our ability to enforce consistent architectural patterns across teams.
I like the way it is now. Angular team already changing too much and on top of that if this happens, many devs will rethink about using angular.
Personally, i like class based approach. Also, separate files gives me separation of concerns. It also easy enough to understand whats going on. Honestly speaking, i do not like any new styles. Angular is fundamentally different, i get it, but how many devs use it for fundamental reasons? The way we write code in angular, makes it unique, makes it angular.
1st syntax loks like React one with Angular stuff
2nd syntax looks like Vue or Svelte one with Angular stuff
Initially, when I heard about the SFC Analog proposal on this channel, I wasn’t a fan of the idea. But after completing a React internship, I have to admit that Angular has a lot of boilerplate - even for something as simple as a component (although I still dislike JSX/TSX templating syntax BTW)
I'll definitely try the Analog SFC; the syntax makes a lot more sense. It also encourages avoiding oversized components since logic, template, and style are all in the same file.
For me, having these in a single file isn’t a drawback: they’re clearly separated into sections, just as they would be in separate files
Between both proposed syntaxes, I personally prefer the second one.
Ironically, I was actually considering switching from Angular 18 to Svelte with the new Runes syntax for my side project today because of Angular’s verbose component syntax 😅
Regarding Angular's verbosity, I think it’s fair to say that Angular is like the Java of the frontend JavaScript ecosystem: extra code for what’s often a simple task
For example, having to use classes for something as simple as pipes feels unnecessary; simple functions could handle that just as well. In the same way, functional-based route guards make more sense than class-based ones
I also don’t see it as a drawback that JavaScript front-end frameworks are starting to resemble each other more (as Fireship mentioned in his video about Svelte's new Runes API). This "standardization" could actually make Angular more approachable and help it gain wider adoption. It feels more like a sign of maturity in the JavaScript front-end ecosystem.
To be honest this just feels like the Angular team has nothing better to do than constantly rewriting things that already work fine, causing headaches. They should be focusing on more important manners than breaking whatever angular devs already like.
All af these hypothetical examples looks and feels like shit. If I would like to go with react-like component syntax I would go in react development. Don''t bring that shhit to angular please
Spot on, this all looks like dog sht
One of the best features of the current component authoring format is that components can implement interfaces. So you could have a search result interface, and different kinds of search results, but your search result list doesn't need to know all the different types, it just needs the inputs and outputs the interface defines to talk to its children.
Would such a thing be possible with any of the alternative systems?
In general, I'm very critical of object oriented programming (favouring functional in most cases), but I think components are the few situations where OOP makes absolute sense.
Angular development already went from creating really scalable framework for confident solutions of frontend tasks to siphoning and pleasing npm-library-minded people with APIs that bring absolutely nothing new every other month just to create "Momentum".
Angular Team needs to point in public space that Angular component authoring format worked for 8+ years and Angular ecosystem is capable of doing everything web frontend framework needs without installing garbage on your or remote machines and making things up.
Just stabilise APIs, close old github issues, make a bit of docs with explanations on architecture and enjoy working with Angular, not working on new Angular whistles every 4 weeks.
Comment about this particular video: All of NG boilerplate is reduced to terminal command with few letters like "ng g m hello" and you can configure behaviour of these commands too.
I use Angular for its clarity and readability. I don’t care about verbosity, if you don’t like it please use another framework. I hate the 3 propositions and I hope they will keep the current component authoring
If they just remove the imports, make the selector be the class name of the component and made the component options configurable in the project configuration instead of always be granularly configured on component like OnPush, it would already solve most of the boilerplate. Besides this I don't think I want any drastic change like these examples.
3:50 Angular is fundamentally different from react. Could you please elaborate that difference. or probably make a video on the fundamental difference between angular, react and vue please.
i also want to see a video exactly on this statement!
The way it handles the DOM, makes changes and detect interaction is very different afaik, but I don't use React much so I could be wrong.
Plus React is not really a framework, Angular comes with opiniated tools on how to do a lot of things (take HTTP for example) while React does not have these tools or does not have a strong opinion on how you should use them.
Primarily DOM handling, and dependency injection
I like the Blazor approach which would fit with the new template syntax
@ng {
.... angular ts code ...
}
I'd be happy with either of these formats (well not the css like one). I also like the analog experimental format and use it on my site.
What I love about Angular templates is the control flow. I find it much more readable than jsx/tsx, and that would still remain with these new authoring formats.
People bitching about some default config files that get auto-generated anyway are totally oblivious to what large React/NextJS projects look like. Simmer down.
Me: I've been writing Angular since 2017. I like Angular because it's robust and doesn't change!
Angular team: Hold my beer
Haha, I'm glad you remember THAT bit of the course :-)
@@PeterKassenaar @PeterKassenaar Peter! How nice to see you on here! What did you think about the CSS style component authoring :)
Will it work outside of April fools day?
On a more serious note: What problem is this solving for devs writing Angular in their day to day?
I have two problems that need fixing:
1. robust change detection (bye bye zone.js)
2. auto mapping TypeScript interfaces to reactive forms because I would love to pass in a generic to a formGroup and calling it a day :)
The rest is fine honestly speaking. I'm not saying I will stop using or recommending Angular as a batteries included JavaScript framework if it starts looking like React, but this specific topic doesn't address issues I'm having myself...as long as they retain the option to have a separate template file that is :)
To bring another perspective: even though i've only briefly looked into jetpack compose with kotlin I have fond memories writing uis with it. there could be some magic in a domain specific language based on js/ts.
What I much rather would like to see is some improvement on the compositional nature of angular. Currently i do not like where directives are at. I would love to create more behaviour driven components where i could compose the components by attaching additional directives more easily.
As an example: I've built a Table component with a context menu and a toolbar for multiselect actions. To define those actions (eg. delete, notify users, transfer data, ...) I could create a DI token "multi: true" with a callback that is executed on click. Now, what if i want to override a template for a specific element (like it's new and recieves a badge or something)? Well we could use an additional templateRef, but where do we define the fallback or default value? What if we want to access a property on the table? ... Sooner or later you are using contentChildren, viewChildren, injected abstract classes, ContainerRef, shared services, DI tokens, etc. in pretty complex relationships with each other.
Where I'm getting at is this: It is somewhat verbose to design a truly composable component, without making cutbacks in typesafety (generics!) or some other form. Maybe I'm not experienced enough to build a clean solution for this purpose, but I belive there is some potential in simplifying this aspect of development with angular.
I understand your concerns about component composition and behavior management, but I think there's a crucial insight to consider here: you might be unconsciously trying to replicate Jetpack Compose's composition model in Angular, which leads to unnecessary complexity.
While Jetpack Compose offers a beautiful way to compose components where everything is contained within the component's scope, Angular provides different primitives for managing complex component interactions and state management. Each framework has its own philosophy and strengths.
Instead of trying to handle everything through component composition (which leads to the complex mixture of contentChildren, viewChildren, DI tokens, etc. that you mentioned), Angular encourages us to leverage services and dependency injection for complex state management and behaviors.
For your table component example, rather than making the component handle everything, you could:
- Create a TableStateService to manage selection state
- Use a separate ActionRegistryService for your multi-select actions
- Keep your components focused on their layout responsibilities
- Leverage DI scoping to maintain isolation when needed
This approach would dramatically simplify your templates and component logic while providing better testing and maintenance characteristics. Your complex relationships between components would become clear service interactions, properly typed and easily testable.
Remember: Each framework has its own set of primitives that make sense within its ecosystem. Just as we wouldn't force Angular's dependency injection into React, we shouldn't try to force Jetpack Compose's composition model into Angular.
snippet: codefile.io/f/i22dalg3Vb
I am working with angular for a few years now and i really like it! =)
I hope they won't change it. This is all horrible. 😔
You can continue with class based. So what's the issue? It's not either or
@LarsRyeJeppesen it will eventually be removed.
@LarsRyeJeppesen, the issue is that Angular is starting to stray away from the "opinionated/enterprise framework" vibe. While the recent changes (signals, new templating control flow syntax, @let, ...) are good; there are now five ways to achieve something in Angular. This proposed change adds to that even more, and in that sense seems really unnecessary; I don't think it provides that much more to the developer experience for it to be added in the framework. The learning curve of Angular was arguably the steepest of all the frontend frameworks, now it is even steeper. In other words, while trying to make the framework friendlier and more approachable for beginners, they ironically are making it less so. To avoid that, as @babutschi mentioned, the only solution would be deprecating existing APIs, or even worse, removing them and break backward compatibility
@@bobank Don't you think signals are awesome? Just curious.. I can't imagine going back to non-reactive programming. Signals have been such a game changer
@@LarsRyeJeppesenat which point in time was angular not a reactive framework? Angular as it stands today was always built on rxjs, which has reactivity literally in its name
ng keyword is so horrible it is considered a bolierplate just to retrun a string LOL😂
To me the current format of the component is not what make Angular "feel bad". And the number of files is just a bad argument, it's just preference. Nobody force you to have 3 files per components.
The thing I would really like to see is spread properites `` and no selector component (technically possible with attributes but misleading with directives).. And then we would have a more modern framework.
The funny thing is that Angular (more like Analog) is moving towards a Svelte style, meanwhile Svelte is taking quite a few features from Angular. (Looking at you `sv migrate` coping angular schematics).
Give me the angular router and FormBuilder in Svelte (client only, no Sveltekit) and I would say Svelte is juste a better Angular at the moment.
I've worked with Angular for the last 6 years and I think Angular is destined to become niche or abandonware no matter what, as Google did too little too late and most of existing Angular code is already written in a very unnecessary convoluted legacy way by Java devs doing front end, with unnecessary old versions like Angular 8 because "nothing really changed in the next versions", like "nothing really changed" from Java 8 onwards. Angular has sadly become a better jQuery for Java apps for 90% of what I saw on the market until now, and it breaks my heart.
I've been arguing about this a little over on reddit. But after watching this video, I could get on board with the html first syntax as long as there was a clear separation between component code and template markup. The functional format returning strings just seems like it would be a maintenance nightmare.
I don't know what issues the current separation of concerns format has but I would think that any of them could be solved by some advancements in the compiler and other cli tooling.
An option for splitting the component in multiple files should be still there. Createing for example an mat-table with 6-10 columns leads to much html. But I really like that the angular team wants to remove the boilerplate code.
I don't know angular but if the goal is to reduce boilerplate than there's nothing shorter and easier then jsx. Not only is it shorter, it's easier to handle data, it's more modular and more aligned with the "everything" is an object philosophy in javascript. And since javascript is made for working with objects, jsx feels natural. Sure, the templating thingy (like with vue or svelte) feels easier for "html" devs at first but if you wan't to get things done and write a little more complex stuff, you actually want jsx. I will claim that if you know and understand jsx (and have actually written real components with it), you'll never want to go back to any other syntax.
Functional is way to go
So we now have three choices:
-React syntax
-Vue syntax
-CSS syntax
I wonder, could jsx perform as template only for angular components?
I would love to write my simpler components in the new format, as long as the complex components can still leverage the old class sintax.
I always use the angular cli to generate components and probably that will not change in the future. I don't see any problems with that or with the current component authoring format. Why would you complain about something which is generated for you automatically, I don't understand that :)
Remember when Vue anounced its composition API and they received the same backslash. With time people recognized it was for the better. With Angular it will be the same.
The current angular syntax is great for doing some advanced stuff but I've always felt like these was something missing for creating mini components. I also don't want there to be magic in so we have a tall order here.
I'm leaning towards just breaking up the @Component decorator into @Template('content...') @Style('styles...') and @Import([...modules]) and keep the class.
The functional approach does look appealing and I think changing the extension to .ng would help with tooling as well so ngOnInit is implicit
Please can you elaborate ? I don't understand how the current component style, with inline html and css doesn't solve the problem you are describing.
great another major breaking system changes, cant wait!!!
As far as I get it, you'll not be forced to use this. Probably in a time they can put some of those formats as default, but like standalone components, you'll still be able to write the old way.
It's more a feature that helps new user and apps and that you can use, but like standalone and signals, they're there, but you don't need to use it to build an app in Angular.
What I can see on the comments section is people getting frustrating that this can change, that it can generate complexity on old projects, and so on.
But let's be realistic here, you don't need to use a feature just because the team released it. Keep writing as you like, the new features are >new< and you can choose if you want to use it or not.
@@Dajuhf you are naive
@@babutschi 😎👍
The team is doing well simplifiying the framework. They can’t beat React though but reducing complexity and files/ code boilerplate is a necessity.
It would be better to hide complexity behind abstractions like use a folder hierrachy instead of ngmodules same thing with routing.
Rxjs is superb but hard to comprehend fully: one Day you think you did great , à Day after you discover your rxjs pipeline has introduced a bug. To much rxjs code in one file is depressing. (Sorry for bad english and typos)
You could author a simple button in a single file if you wanted to...
Single file standalone components already reduce the boilerplate by quite a lot. It makes creating a new component literally creating a new file and have vscode (or whatever editor) write the boilerplate template. No relying on the CLI, No juggling with modules or file references, no separated files for template or css unless you are working with huge components and you feel the need to break it into separated files.
I would like for the angular team to just keep improving on that direction as currently the only drawback is that it treats your template as string and feels really bad to use.
I have been working with React lately and something I don't like is that about the flexibility is that it leads to quite messy files with hidden components. Not to mention sometimes having to jump back and forth between functions and template in tsx to find where some piece of data comes from, but that might be just a skill issue.
Still, I am not a big fan of the idea of having to read through code like that because someone on my team decided to use the new syntax, even if I am not forced to write in the new style.
The SFC part is only partially true, the way angular SFC components look is terribly boilerplaty even with this. You still need to manually define the imports both on the typescript side and in the angular crazy module system side, you also need to order your visuals before the code which is not exactly good from a developer experience side of things, you need to go up and down in the files all the time because of that.
I also find the opposite of React as being bad in angular, extremely massive components instead of tinier ones with state scattered all over the place, the reasoning on them and refactoring them is very annoying. Compared to "hidden components in files" it seems worse.
@@diadetediotedio6918 I don't think that having the ts above or below the template makes a big difference, the same problems on scrolling up and down still apply (you can also split screen on the same file if you are working between ts and template a lot).
And I don't think the module import is a problem related to the component autoring. If they can make the new component styles work without the need for them, the could also make the current format work without them.
@@matiasmiraballes9240
I think it makes a big difference, maybe it is just for me, but I like to reason about things in the same way I would setup them. I am a programmer primarily, so I expect the behavior to come before visuals, I also like a clear dependency graph so I like seeing the declaration of my dependencies (like variables or methods) before my consumption of them (in the template, like bindings and events). I think you can disagree on this one.
I think I don't understand what you are trying to respond about modules, can you explain it for me in more details so I can reason about it?
@@diadetediotedio6918 Regarding your 1st point, yes, I am just too used to scroll down to the ts code that it doesnt bother me a whole lot, but I agree it would be a nice improvement.
For the 2nd point, I was replying to this
> You still need to manually define the imports both on the typescript side and in the angular crazy module system side
I might be wrong, but will the new component style somehow get rid of the need for modules? If yes, will it be done in a way that cannot be replicated with regular class components? if not then the current and the proposed ways of writing components are equally verbose in that regard.
Fine, but I hope they won't remove current way of components authoring. I love separation to HTML, CSS and TS. Let's say you're doing a form, it's a lot of HTML code, and quite lot TS code, I want it separated because it's easier to read that way than if it was mixed. With small components it's maybe a little bit too much tho and even if you do it in a single file you have quite a lot boilerplate. Anyways it won't change how Angular works, best things about Angular are solid structure, completeness, almighty DI, astonishingly easy reactivity, directives, interceptors, new control flow syntax, very good router and that will stay us
What !!! For me one of the strengths of Angular is its syntax. Otherwise I would use React.
i prefer have my code separate in multiple files as is it. having all the logic, html, styles like react is horrible. manteniment those projects is difficult(working with nextjs because that is the company stack) and in some cases(most of the time) i refactor the code for readability.
yes start with angular in some cases is a litle dificult but is more easy for me do manteniment to a angular project than a react one
You can easily split the logic, HTML, and CSS in React though. Similarly, it is possible in Angular to have the HTML, CSS and logic all in one file. It is up to the dev/team how they choose to proceed.
@kalvinhart3800 true for all
I'm not gonna lie, I would like to see JSX as an option. Templating only, not the behavior part with hooks and stuff.
I don't like this potential way of creating components, since it removes of the capabilities of OOP features, the ability of inherence, design patterns and so on that you could do with classes
I probably won't adopt the "new style" if it ever drops but I can kinda understand that people think this looks like boilerplate.
What PrimeTime video is his reaction to angular in? I have never seen him mentioning it at all.
I've got links to both the Prime/Jason vids in the description
@JoshuaMorony oh thanks I have overlooked that ✌️
@@JoshuaMorony That thing is 8h? Maybe you got a timestamp for the clip? 😅
@@karamuto1565 lol Chau's talk that Prime is reacting to starts at around 5:37:00 and Jeremy's talk also immediately follows Chau's
@@JoshuaMorony thank you 👍
That would be really disgusting. I really hate the way React is written. I like that Angular splits the HTML, the CSS, and logic, if any.
Now that being said, functional components CAN play an important role in Angular, but in a different capacity. The way we refactor code to small snippets.
Functional snippets, like templates in a code editor, can help reduce code. Think of them as string templates embedded in the Angular change detection system. An easy and functional way to create those would be really great. There can act as super dummy UI-only components, like a library of string templates.
Why do you and a lot of people hate "boilerplate" code so much? Most of the time, it's auto-generated, and you can usually just ignore it. I think "boilerplate" code actually helps a lot to keep important things simple (you know, like business logic and those kinds of things).
I aleeady switched my personal learning roadmap to react. I currently on the search for my quick prototyping stack and I must say with zustand, shadncnui and react query I‘m pretty satisfied. I don‘t see any advantage in using the new format if it will happen somewhere in the future. I also think it‘s time for a fork in angular and give it to the community from the day the new format will be released. I also don‘t know how they will maintain the backwards compatibility with the new format. Maybe soneone could explain how they will do this.
Optimising for first time impressions is a stupid goal. The current system is great because it allows you to better mentally handle complex systems. I'm sick of a race to make a TODO app as quick as possible. Who cares? And if Theo t3GG or whatever his name is doesn't like it, thats a plus in my book. All the people who want this already can have it with Vue, React, Svelte etc Go nuts.
It should of course be balanced with other concerns, but I think it's a not insignificant issue. Having the general perception of Angular outside of Angular devs be that "legacy style framework for Java devs that nobody wants to use" causes real problems, no matter whether this general perception/stereotype of Angular is fair or not. A big one being that if Angular is not a framework that non-Angular devs want to use, it's going to be harder for companies to hire the talent they need, and it can make it harder to justify using Angular or even make switching away from Angular a way to make a business more viable to run. If we have non-Angular devs excited about using Angular I think it will be a significant win for everyone in the ecosystem.
It shouldn't come at the expense of the things that make Angular great, but at least from my perspective I don't think it needs to.
@@JoshuaMorony uniformity in solutions never leads to a good result on an evolutionary basis it just creates an opportunity to be wiped out. The whole idea that a complex system needs to be trivial is wrong. Sure, make some CLI helpers to get started but Theo's "all of this for a button" is a pointless metric. You can have a button in 3 files if you really want but no one is building single button apps. I'm for simplification but taking away one of the preferred systems of your existing clients to attract more of the people that rejected you on the "all this for a button" metric is a bad idea. People will be attracted to a strong, consistent, evolutionary framework with backward compatibility. Thats enterprise, not bells, whistles and metric gaming
@@toxaq 100% agree, but it was prime not theo ;)
@@Hapkumdo thank you! I somehow knew I’d got it wrong but couldn’t work out who.
I wouldn't mind Angular becoming more like Vue and React
I think approach 2 suits angular style better than the JSX one (even if I like it more personally), the other will feel more "natural" to angular devs.
Still, I don't think that's gonna happen, those enterprise programmers-wannabe are literally one of the worst to convince, extremely dogmatic about their convoluted and boilerplaty way of coding being "the best" or "enterprise-level", I prefer to just let they stand on their misery.
I like the syntax as it exists today. No changes, please.
Just do like Svelte. And Angular will be fixed
God... I'm just done migration a big application in order to use standalone components, I'm in the middle of changing it to use signals and now that... I'm aware that I shouldn't be pissed about Angular innovating but bringing these kinds of big changes every year force us to mainly maintain our applications instead of adding feature to them...
I don't understand why people are hating on functional component ?
'Cause components should be objects.
I would rather have them focus on building and improving on SSR.
Angular is good, as it is. Especially now, it is great with new Angular primitives, as Signals were made stable. Why should we use shitty things, like .jsx, when we have a great component system in Angular? No, thanks.
In my opinion Theo should start making the lifecycle of componentd easier. Its probably a skill issue, but i come from react and miss the simplicity of components update when the prop changes. This is Not the Same with angular and Material components in my experience.
What about a pure html component for those where their only responsability is rendering information using inputs? I ended up creating a single class component for this purpose
Wow people look really resistant to change
Nope. Not for me.
If I wanted to use something that looks like that, I’d use vue or svelte.
Not everything has to look and feel the same way.
Angular at the current state is awesome and I would hate to see an angular project with a different component authoring system.
It’s not about learning curve but it is about familiarity with angular.
I'm 100% with you on this. Which makes me one of the only few given what I can read in the comments 😆
I think people against a new format are more likely to comment. If we were to go on the comments it seems a solid 95% of people are against a new format, but the like ratio of this video is a bit over 95% likes. Also not a particularly scientific measurement, nor does a like necessarily imply agreement, but its decent at gauging sentiment. Broader polls in the past have also made it seem that a majority of people are actually in favour of a change (and I have to assume the Angular team have a decent sense of the overall desire for change)
@@JoshuaMorony Just because people are against a new format, does by no means lead them to dislike your video - you can still think it's a good video, even when you strongly disagree with the proposed idea(s).
This is crazy. Angular is turning more and more to react. I don't like this shit at all.
Please dont change the angular authoring syntaxe. Please don't be react or vue or whatever else. Please don't try to please eveyone, because no one can.
Is it verbose ? Yes
Is it frightening on a first impression? Only if you come from react like world.
I love that angular separates logic from the view in two different files.
I love how dependency injection makes unit testing so easier
I love how you can keep your files tidy and clean no matter how big your project is (thanks to dependency injection vs nesting components inside a ton of contexts in react)
Angular is fundamentally different and should keep itself unique.
What's the point of gaining more developer base ??
A new format doesn't have to lose these things though, and certainly not DI/services, it's different syntax/sugar for building components on top of the same Angular framework. I suppose it's possible they go with an SFC only approach for a new format, but I'd be surprised given how many people like separating ts/html/css.
@@JoshuaMoronythe angular way of component authoring is fine. Why do you hate it so much? Why waste so much time on something that is already pretty good? what is wrong about it, where is the boilerplate? I DON'T GET IT
@@JoshuaMoronythe angular way of component authoring is fine. Why do you hate it so much? Why waste so much time on something that is already pretty good? what is wrong about it, where is the boilerplate? I DON'T GET IT
@@babutschi I didn't say I hate it, I think it can be better. Whether that is worth it or not or what that might look like is up for debate, but given the direction the Angular team seem to be moving in it seems enough people think doing something is worth it. I consider boilerplate to be any extra code/config/imports/concepts required to do something that could be done with less, so if we take the button component from the video as an example I would consider the component decorator import, the decorator concept in general, the config for the decorator/the imports array for the decorator, all to be "boilerplate"
I would argue that logic shouldn't be in your components in the first place. Your component should only reflect some part of your application state and have a way for the user to change it by interacting.
It is not "clean" to have components that does too much. They shouldn't do HTTP calls, they shouldn't have business logic, and so on. Those belongs to injectable services imo.
I am confused about why people find it simpler to stuff more contents into a single file (e.g., the analog approach), instead of separating views and logic. It seems like more scrolling is needed to find what im looking for, insead of juts going to the component resp. the template file.
The more like React the better. It's the most successful framework.
Please don't transform Angular into React? If you want React, just use React. We use Angular because we want to code properly and not a giant mess. Having well separated files between view, logic and styling is one of the greatest things about Angular.
You can still separate those things in React too. I have never mixed styles, template and logic in the same file in React - that would be a mess as you rightly say.
@@kalvinhart3800 Nah, you really can't do much in React without using JavaScript directly into the template. Also, separation is so poorly implemented that a lot of people use Tailwind for most of their CSS, another terrible idea.
@@sodium7554 you can put CSS,SCSS or Styled Component in a separate file and import them into the component. You can put all logic inside a custom hook and then destructure the logic from that hook into the main component to then use it in the JSX template (this also makes writing tests for the logic and UI much easier). It is very easy to structure a React app like an Angular one, I do it all the time.
We already have a different authoring format. It's called React. Don't change for the sake of change!
Don't change to this horrible syntax... I always love angular because it's structure, if i want to use like this i would pick react...
The "functional" approach in UI is the biggest crap I've ever seen in my life. Please... no.
I am working with Angular since 2016. This is a bullshit, I don't want this to be in Angular.
Could someone explain to me why people claim Angular's current syntax doesn't allow for simple component programming? I'm genuinely confused by these complaints.
Are critics aware that Angular supports inline HTML and CSS? What additional simplification are they looking for?
From my experience, I've noticed that most Angular critics, particularly those still complaining after Angular 16, have likely been exposed to poorly architected applications. I would venture to say that roughly 80% of both professional and personal Angular applications suffer from over-engineering and bloated components, which unfairly tarnishes Angular's reputation.
This perspective was reinforced a year ago when a ex-colleague of mine, who used to be a staunch React advocate, completely changed his stance after working with my team. He now strongly prefers Angular and wouldn't consider going back to React.
The framework itself isn't the issue - it's how it's being used.
No thanks, the original angular format is superior to all this crap, I'll stick with it. I don't understand why you'd want to mix everything into a single file
And you can
@LarsRyeJeppesen I'm aware
Because I'm not a clusterfuck mazochist, if I want a component I don't want to jump between 3 files just to get what's going on, I also don't want to use the terminal to create a very simple and well contained component that will end up looking an OOP mess, what the heck.
@diadetediotedio6918 sounds like a skill issue
@@stratvids
same can be said on your crying about how you don't "understand why people want to mix everything into a single file".
Angular was NOT designed for just putting a button on HTML. If this is your main goal you should choose some library like React and not a serious framework like Angular. Angular was designed with building and scaling complex LOB applications. DON'T make it like React!!!!
Why would you even need any framework or library at that point. It is really just a button. As soon as that button becomes a more generic component again the original way of setting it up with separated files for html/ts/scss is best. Used to code in angularjs/angular + laravel and upgraded to angular 2 as soon as it hit from 2011 to 2019. Since 2019 I've been working with Vue cause I switched jobs and they use Vue + Laravel. I still miss the clean code separation and pretty strict guidelines in how to organize/setup your app. With vue every project you see a different approach and often resulte in a messy codebase. Angular is just hands down the best front-end framework there imo.
Instead of a new "Component" authoring format, I'd rather have more new "template" authoring formats, like @if/@for/@defer, etc., for content projection and template snippets authoring...
Creating and maintaining the @Component decorator is only a small subset of the "authoring" activity. Yes, it can be an eyesore when things grow, but IMHO moving away from verbose APIs like `ngTemplateOutletContext` in the **template**, and offer better typing for template elements are better starting points than introducing "components as functions" or "Svelte/Vue style SFC". Evolving `*ngIf/*ngIfElse` to `@if/@if else` has been great. Why not continue on this front more? Maybe it's technically more feasible if there's a new Component format in place? I don't know.
And in Svelte5 there's this new {#snippet} API, which I think the Angular team can steal a thing or two from.
Great content! It’s always good to know that there are open-minded content creators like you in the Angular community
So, angular devs are now building react apps. Just learn react. 🤣
I hope they will adopt or extend widely used .tsx format instead of creating another new standard. Although the first one feels close enough.
Noooo TSX s..cks
I hate functional approach, that's why I hate React
I like VueJS component style (Composition API). I hate ReactJS style
I don't understand where the boilerplate code is in the current authoring format, the only thing I would like to see go away is the imports array.
All of these alternatives are truly awful.
Hello react style
Well, the functional idea looks just like react and the html idea just like vue - I really don't get, how why anybody would then not just use these frameworks.
Just use Vue
All 3 options are shit, keep it object oriented
I think you nailed it - in my experience Angular folks create huge components. The presence of a CLI to generate components was helpful early on, but it is a sign of framework limitations. I think the effect is that Angular subtly guides developers to create big honking components with the possibility of refactoring to smaller components (best intentions), where a simpler format, like React of Vue, creating small things is part of the "flow". I encourage Angular developers to use inline templates and styles to help create some friction against this tendency. While I do like the Vue/Analog way, I think the functional approach might be better in the long run. In React I'll often just add a functional component at the bottom of the source as I "discover" them, and move them around as they stabilize.
That's because the ethos behind Angular is much more "Professional enterprise/architectural up-front thought out" software development, and much less "hobbyman, sandbox, toybox until you burn your fingers often enough" approaches like React.
Want a button to use everywhere in your application?
You get to define its exact behavior and capabilities and it becomes an actual software component in its design.
There's a structure and way of doing things, no spaghettification (You can still do that of course, but that just means you go against the ethos).
It's meant for writing applications, not hobby-projects and primeagen hello world button shenanigans.
THIS
That kind of thinking is what keeps the specter of waterfall alive, and the paternalistic alienating view of "smart people" vs. "dumb people". Betting you have "architect" somewhere in your title? No wonder so many dislike Angular when folks use it as a way to demean others. I have worked on crappy applications in Angular, React, and Vue, and I have worked on great applications with all of them. But you do you.
@@JeffryGonzalezHt sensitive I see?
I didn't demean anyone.
I'm making statements about frameworks, not people.
React is verrry permissive.
Sure, there's just good projects and terrible projects. To me it's more about how much something allows you to do stupid stuff.
The more you're allowed to do stupid stuff, with no one enforcing some standards, the more you create unmaintainable "terrible projects".
Yeah, same exact experience here. People that use angular just tend to create components with 700+ lines of code all the time.
angular is really focused on DI. even the query system does resolve around the concept, they need to change alot just to allow these patterns. How i could inject a parent component or a self directive if its a function? instead of a single token value (class constructor) you need tokens. You started from 1 class you ended with a function, a separate registration (cant decorate functions), a token for injection. It may appel React devs but really hinders the real power of Angular in the process. Angular still lacks power on the query system in particular with projected content when it's dynamic, why focusing on aesthetics when you have missing features documented way back to 2016 by Misko Hevery himself!!!
I like the current syntax but there's some smaller things that I feel that are super easy to do using JSX syntax but in angular requires more verbosity, and when that happens is super frustrating to think "damn this would be easy if I could use JSX".
That's why i think would be nice to see in angular the possibility to use JSX like happens on Vue as an optional way.
A simple example for what I'm talking about, would be things like passing all the parent props to a input, for creating a custom input component, in JSX you can just spread the props of the component in the input, but in angular you have to create the input props manually, and pass it manually.
The examples people always drag out are less than a hundred lines. It's not uncommon that I have component logic 300+ lines and templates just as long that can't be chopped into smaller pieces.
Angular's "boilerplate" is for those sort of real world realities. I can't stand react or any sort of template + logic in one file system, because it always turns into a garbled nightmare in any real world situation. I'm not going to make a hundred one-time-use subcomponents just to make my parent component smaller.
This just strikes me as Jr devs trying to sound edgy reading a single blog post and developing hard opinions and then blasting it on X. Then everyone thinks, "wow, so many people have this thought, it must be right"
Enough ranting on the shitter. Back to work.
> that can't be chopped into smaller pieces.
They probably can. They absolutely probably can.
I know you like to tell yourself those people disagreeing with you are "juniors devs with lack of experience and having dumb opinions", but you should apply the same standards to yourself. Most of angular applications I've seen are literally an extreme mess, most of the time those giant components (and I'm not talking about 300 lines of code, I'm talking about 700+) with state and random side effects all around the place are a consequence of the poor component model that angular induces.
@@diadetediotedio6918 one component of 700 lines or 700 small files (ts,html,scss per component). The duality of an angular developer.
With angular feature, little near to functional style which widely adopted other libs and framework, it will game changer, wider audience with no or less experience can onboard easily..
if we wanted that type of syntax we would probably develop in react or vuejs, what the hell are they doing to angular, stop destroying the framework.
Angular is starting to stray away from the "opinionated/enterprise framework" vibe. While the recent changes (signals, new templating control flow syntax, @let, ...) are good; there are now five ways to achieve something in Angular. This proposed change adds to that even more, and in that sense seems really unnecessary; I don't think it provides that much more to the developer experience for it to be added in the framework. The learning curve of Angular was arguably the steepest of all the frontend frameworks, now it is even steeper. In other words, while trying to make the framework friendlier and more approachable for beginners, they ironically are making it less so. Soon, to avoid that, the only solution would be deprecating existing APIs, or even worse, removing them and break backward compatibility
Functional = AngularJS. No thanks. And No… you don’t need all those files. That guy is being hyperbolic.
I switched to React from Angular for my Projects since Angular added Signals. Now this! I don't think that I will be using Angular anytime soon. Syntax Changes makes it feel that Im learning a new framework. In Angular's case, Im just learning the same framework again and again.
It feels like Angular is just migrating back to Angular.js 1
I just wish they would fix that inline templating using strings, as it just doesn’t work. I can’t even auto-format the code because it’s treated as a string.
Also, that “prime” bit was awful. Trying to please these kinds of people is what ruins a framework. It’s like saying, "We need to change modules to standalone because modules are too hard for people to understand." Modules were beautiful and gave a more robust, enterprise-like sense of organization. But no, they had to cater to certain people.
I'm sorry, but the idea that needing to import a module first to use a component is too complex for you, just go use React.
Modules are almost literally redundant nowadays in angular.