The moment you mentioned that the rxjs is overused in Angular I could not watch futher and had to look at the comments. I hope the bubble finally pops for the other framework which are not close as mature as angular. The way you described things in the first 50 seconds clearly states that you are an amature who never were close in using Angular on some real world project. I doubt if you really developed anything better then some static website with a few buttons in react.
I'm working on Angular and I firmly prefer their approach rather then the React model. Reactive forms are very easy (when you know how to use it), dependency injection can't be simpler, the template syntax is way more simpler as well than in JSX (i guess the people who say that don't know anything about Angular because regular HTML just work as it is in Angular, wtf !?), and to answer the comment you've shown, I never use 'any' as a type in my code and I actually manage complex streams in my project right now, sometimes combining, sequencing, chaining them as I please and again, it works nicely when you know what you're doing, don't be surprise it doesn't work if you don't. Now, modules have their reason to be in the first place, to lazy load bundles just for example, and standalone is just a better way to scaffold components, pipes or directives rather than the SCAM pattern that became the norm. So yeah, anyway, i'm open to discuss Angular structure, features and so on, but if it just remarks from people with no understanding or experience with it is not very helpful for anyone i guess.
@@tictak2121 Because there are pros and cons to use any type of framework or library. Angular devs will always point to the "flaws" of React which usually is related to "JSX is awful" and "there is no structure in place", while React devs will always say that Angular is "more complicated than it needs to be" or that it requires"too much boilerplate code". So, most of the time, people will fall in one of these two categories, and, sometimes, they get passionate about things. If you are familiar with a solution, a different one might seem strange or inefficient. This is why I get both sides of the argument.
@@awesome-coding No, you don't. You skipped some points and I saw your comments and likes under statements like: "angular is dead". Angular have new versions every couple of month with new fixed/features. The last big update for React was in the 2018(?) when hooks and FC were introduced. Did you forgot to mention something like that?
@@tictak2121 Hey! please don't take my comments and likes too seriously. Just as a parallel - check out the comment I pinned in my React video - czcams.com/video/hAhpoWhYteI/video.html&ab_channel=Awesome And I don't think it's fair to say React didn't do anything new since 2018. They completely messed up CRA, and they also have a new documentation website! ✌
Angulars mistake was not taking their target audience into consideration; most 'web devs' aren't actual software engineers. If you understand things like DI, design patterns, etc angular works exceedingly well. But when something as mundane as static types causes holy wars, you need to stick to things that are easy to cargo cult to get traction.
I think that their target audience was enterprise software developers. I saw Java developers pretty excited to "try frontend development" because Angular was similar to what they were used to. My feeling all along is that they went for enterprise because this is where the money is.
@@awesome-codingNot just enterprise engineers, enterprise projects. When a project will live longer than the typical js framework fad, you value different things. I personally feel courting the js kids is the wrong direction.
@@awesome-coding exactly angular was actually ment for enterprise use within and outside of Google. It is very easy for a C# or a Java dev ( who's been unnecessarily abstracting away code that they don't even reuse 😂 ) to use angular. They don't have to know signals ( well they didn't have to in the past 😂 anyways ), hooks or anything else and the component structure is very similar to a servlet service in Java. RxJS is similar to message queues and streams so it was pretty easy for them to switch over and they didn't have to pull their hair out to decide what state management solution is the best everything comes setup for them.
@@awesome-coding I agree with his take, the more software engineering principles you know, the more Angular makes sense, if you just want to write as fast as possible that's when you get frustrated, I know because I was self taught after high school, then later I did a short software engineering course and then I understand why the patterns in Angular exist, it's good "engineering" practices, not just writing code.
@@TayambaMwanza I get what you are saying. However, after some time passes and you gain more experience you'll also understand that premature optimisation is a terrible idea in software development. And then you'll realise that a lot of what Angular is doing is premature optimisation. More often than not you'll not need all those "best practices" in your project.
I've been doing angular for a while now and had to learn React at my current job and I don't get why people say react is simple and easy to learn. React hooks are a nightmare to get my heads around. At least angular's life cycle hooks are properly named. Like OnInit, AfterViewInit, OnDestroy etc. What is it named in react? terrible Also the whole deal with using useState to declare a variable is very confusing for beginners. a = 0 vs const [a, setA] = useState(0) which one is simpler? React doesn't have native support for http, routing, forms, state management, SSR, WPA etc. You have to research and put lego pieces to fit into a monster which are not maintained by the same people. Beginners would not know which external libraries to use for these situations and having a standard goes a long way. People think hating on Angular is cool like they used to hate on crocs back in the day while they haven't even touched and used Angular.
The origin of bad experiences from developers I worked with, is that, most of the time: - angular projects are built by backend engineers that practice over-enginerring; such as using long untraceable observable dependencies. - ex react dev or react fan boys that try to use that horrible ngrx library; which doesn't fit angular at all. - early adopters who fell victim from the old documentation which was poorly written. I actually learnt how to use reactive forms from fireship. Once you adopt and know how to use DI, traditional react becomes a horrible experience. Most react devs which are working on "legacy react" are currently living a coding nightmare.
You don't sound like someone who knows what they're talking about. Back end engineers don't like observables. Observables are declarative, which is one of the only redeeming aspects of Angular. Your experience with them is probably from Redux-observable, which is all the complexity and almost none of the benefits of FRP.
@@mfpears No; I experienced the observable overdose in a different project from the one they used ngrx. I don't know if there is something in my comment that said explicitly or implicitly "I hate observable" or "I hate angular". I am native french but I highly doubt I expressed something like that. Maybe I was wrong targeting the whole population of backend engineers. Which explains why some one may be surprised. Backend engineers who works on large and complex code base of a multi-threaded system, if you prefer. Of course the typical "java" developer will probably never work with non-blocking IO (maybe post java fiber). The kind of developers who enjoys the spring webflux experience also likes to toy with complex dependencies of observables. Why? Because they are as smart as your average pure functional programmer, but they sometime take the experience way too far. And don't get me wrong, making long chains of observable dependence can work - and I wonder if you have ever seen what I am talking about, cause it is not necessary linked with ngrx. But: 1. It is super ugly to read. Especially when you combine it with "observable as component input". You start losing track of the source; which also make debugging a nightmare. 2. You have to guard or protect every observable in the chain from weird or unexpected behaviors from its source, using a pervert combination of error handling and "starwith" operator. I am not even talking about the junior dev who will get confused and start using "iif" every where to avoid learning rxjs transformation operators. So... No I am probably very far from "some one who doesn't know what he is talking about". This is my 4th project which uses angular as a front end framework, and the only people I have seen using that framework and rxjs correctly (perfectly) are... CZcamsrs (fireship and Joshua morony), and people publishing blog post.
Angular developers can softly switch to any well established framework while react developers wouldn't understand a lot of things, angular teaches actual programming, react is just another JavaScript library.
Teaching actual programming will teach you actual programming. Angular, just like React (even though, I know, React is a library and Angular is a framework) exists for only one purpose - to abstract away the basics, and enforce some coding standards and patterns. When working with Angular you are forced to follow some of those standards, but nobody guarantees you'll understand why you are doing it. I bet most angular devs don't actually know the fundamentals behind why you would need DI in a project.
@@awesome-coding Yes, so 5 years from now, others can read your code and make changes. Please go open an old React code base. Can you make changes to it? LOL. Be humble man.
I'm both a Angular and React dveeloper so I'm a pro of one versus the other (I do have more experience with Angular to be clear though ). I dont think your comparison is really biased since we're really not comparing the same things. Angular is batteries-included framework where as React is really just a UI library. It would make more sense to compare Angular to React + Redux + Formik + React-Query for instance. In thay case, both stacks can deliver similiar features and the React stack becomes far more than "just JSX and hooks"
Even in that case choice is what you get with react. I don't have to use redux I can use nanostores / jotai / recoil, I don't have to use Formik I can use react hook form, I don't have to use react query I can use react swr. Yes I know you can use other things with angular but I haven't seen anything like that ( yet ) Edit: you also forgot react router lol 😆
@@TechBuddy_ Not sure how I forgot react router, should have been first on the list haha. Agreed, diversity of options and the richness of the ecosystem is a clear characteristic with React apps, as opposed Angular being much more opinionated. Both have their pros and cons, I guess it's more of a personal opinion. Imo I prefer when a framework is more opinionated because I don't want to overthink when picking a library for standard features such as routing, forms, or state management. I would rather have these default solutions included, and then later on swap for a custom one if I have a very particular need and the default one isn't enough.
@@timmeehan2365 angular was enterprise framework for big corporations which want a solution for everything out of the box, predictable and battle-testing, without unexpected change. Angular was like that until the developers of it decided to make radical change and adjust the framework to everything, forcing it to compete in all niches. It's going to kill the framework. It was much better for angular to specialize itself as enterprise solutions without trying to make itself look "cool", while allowing react/vue to take other niches (start-up, small businesses, etc.). This specialization was good. And now it's gone. I really liked Angular. Especially it being specialized on enterprise. And now the developers of angular are killing the framework, destroying its competitive advantages whiles introducing features already available in other frameworks. Instead of deepening angular specialization on enterprise, the developers decided to go the opposite direction and make the framework general purpose, forcing it to compete with react and vue and so on. I hate angular team. They're destroying the business model of Angular based on their personal believes and tastes. "The framework is not cool enough". morons.
There was no interest and retention for Typescript in 2015. Still Angular went with it. Secondly, I didn't find any problem with modules in medium size apps. I found it usable in case when certain similar components have same dependencies. I found it better to collocate all the related components, pipes, directives, providers, injection token and let the module be the entry point. Standalone components bring its benefits but they aren't displacing the Modules. An Angular Developer would argue it differently. But the criticism would at least help me think deeply.
Most frameworks have pros and cons. Angular more than most. I enjoy working in angular more than react. Where angular fails is it’s complexity. Where it succeeds is its development experience once you have a medium grasp on it and rxjs.
State management in Angular, specifically services, is what gives an edge over React for big apps. You can have two distant components that share a service and the data will update on both components. Try that in Redux (or whatever is popular this week), and you will see how much unnecessary cruft you will have to add in your business logic.
You are right. It is worth mentioning that data & reactivity is not perfect in Angular neither. Zone JS has its quirks when it comes to change detection. In all fairness both React's Rendering & Reconciliation model, and Angular's Zone JS strategy are rather inefficient compared with signals. Props to Angular for adopting them!
hi sir, i wish you give me the right answer, i learned the basic of JavaScript , Es6, typescript, and i build many projects, and i will learn Angular, but i don't now if this is enough or no, and i also the only language i learned is JavaScript, i hope you answer?
Hello! This is a good start! Surely, if you know Angular and Typescript well, you should be able to get a job fairly easily. However, the learning should never stop. You can explore alternatives to Angular (like React, or Svelte) to better understand the entire frontend space. You can also use TypeScript on the backend (via Node or Deno) so you should also do that. Next, once you have a pretty good grasp of the backend, look into a second language, to complement your JS knowledge. Java, Python or Go are all good options here.
It's seems like that concepts are making hard to people understand the framework. Which I believe that it translated into lack of experience. Because when you have big projects, you start naming services and files depending into some functionality. Angular gives to you from start. Something that you will need in the future. One think is true though, simples mvp doesn't need that, but again if you have experience in general programming that won't be an issue cause u know what is what.
if it's hard, then they are not supposed to learn it in the first place. Angular business model is different and forcing it to complete with react and vue in startups and retails is killing the framework.
Hi, few things about this video: - correction: emberJS was first framework to have a cli not Angular (2+), Angular cli was based on ember cli ( nowadays it is own thing) - when you create a new App ( since v16) as standalone way, you need to add a flag related to standalone. - why are you create / generate a component manually ? instead of using the cli ? - about signals: this feature is still in preview mode, as such is not stable. - the weird thing, is adding to a form base on template driven with signals, because you dont see in any official docs / medium / youtube or even in their RFC of signals of Angular about it, as such what you show for now is just a bad practice and unofficial way. - signals for now is to be use for simple things and as global state management with service, not to be using with forms. - with standalone, you dont need to think about modules and service hierarchy - Another weird thing, for validation you don t need a computed prop, for template drive forms, just add the html attribute required, add a ref to the form, in a button [disabled] = " !form.valid", why complicate things. - another weird is that you didn't show final result of the app, lool. - About the pool, did ask before that question, which framework they use or know or try? React dev say react is easy and angular is bad and difficult to learn. lol Now with new react docs recommendation to use nextjs, make even more easy to learn react, LOL Your are just traumatized about Java. If you dont like or dont know how to use it or understand Angular why talk about it. why wasting time trashing it ? just to do clickbait and get more viewers? Now you may ask me: do you like the path that Angular is going with signals? my first reaction was: Hell nooooooooooo. this is the end of Angular. my second reaction: verbose like hell, not very classy. now: i am waiting for the thing to be stable and get more info how this will play with forms, main template driven, since dont believe that will change / effect the reactive forms, and way you show it for now is not right and official way. Frameworks are just tools, not football / soccer clubs. Peace.
Hey! First of all, thank you for the time you put in writing this feedback! 1. On Ember, I looked into it, and you are actually right! Thank you for pointing it out. Ember is one of the frameworks I never got the chance to look into, but I remember those two guys did a lot of interesting stuff in the early days. 2. The code I was writing - I just wanted to showcase the layout of a basic component, and how it would interact with signals. Creating it via the CLI would have been a quick action. This way the people can get the chance to actually look and digest the code (One of the feedback I often get in comments is that I go through too much code too quickly, so I'm working on that). 3. Same with the signal / form combination. I didn't want to show a counter because that's already in the docs. Maybe it was a bad idea to go outside the docs. However, I expect most people coming from other frameworks will do things this way if possible. Past experiences weigh more than the documentation at times. I can tell you that not all devs / teams embrace reactive forms. We had a team of devs who were "ngModel-ing" everything despite multiple efforts and in house training sessions aimed to make them switch to reactive forms. So, I know it would have been way easier to achieve the login form via reactive forms, but I needed a plain signals + computed + effect example that can fit in one page, and that can give viewers a basic idea of the usage. Again, a form might not have been the best decision. (Funny how Angular is the only framework where I would encounter this "problem") 4. About the pool - I mentioned this in another comment. I don't believe my audience is a majority of React devs. If you check my video history, you'll see that most of my content is on newer tools and libraries. On top of that, the few React videos I did performed poorly compared to the rest. I believe it is hard to create an objective survey, but I believe a React pool would get pretty much the same results (I'll actually test this in the next couple of weeks) 5. You were spot on about Java. The trauma is there. 🥲 6. As I mentioned in another comment, I actually have quite a lot of hands on experience with Angular in both larger and smaller teams. My main issue with Angular is that it has the tendency to over engineer and over do things. Maybe it's just my Java trauma, but I often feel like Angular development is closer to a backend dev experience than a frontend one. And I find this a bit disappointing considering the type of programming paradigms a language like JavaScript has to offer. 7. Believe it or not, I knew this video is not going to perform well (compare it with some of the recent ones and you'll see that I'm right). This is because Angular and React content is not getting so many clicks because people are tired about this content. So this was not an effort to get more clicks / views. I can do that easily by acting like Solid or Svelte had a minor update "that'll change everything" - that'll get me way more views than this video. 8. I'm doing YT videos for more than a year now and, despite Angular being one of the frameworks I'm actively using in my day to day job, I postponed making a video on it just because I didn't want to simply trash it. These new changes they are making prove that they want to take things into the right direction, so I believed there is some positive in Angular's future. Thanks again for your feedback! I really appreciate it!
Actually the React team suggesting a framework is a very good choice. Because without s framework you will be lock-in on CSR forever, with a framework you will have more opportunity to grow if you want.
@@oscarljimenez5717 no it not, you have a alternative call vite. Devs say on Angular you have to learn too much things. By using nextjs your justification to not use or not like Angular just make no sense.
@@jediampm the problem with Vite, is the same thing the React Team said. Ok, you start a React SPA proyect with Vite, then, you want to use SSR, SSG, ISR, or even React Server Components? Oh, no, you can't. Yeah, maybe you could add vite-plugin-ssr, but at that point that's a framework, because you will have to migrate a lot of stuff. Remember, the base of frameworks are the Router, so if you start with a SPA only router, you're lock-in. The suggestion of the React Team is that you can use a framework that give you all the ability to grow wherever you want. Vite-plugin-ssr is amazing, but has is limits, even that I think the React team should mentioned in the new docs.
@@oscarljimenez5717 i was talking when to start to learn as a beginner. Then you have to make choices. Angular is just a full feature frontend framework, Not full stack framework and when start you should not mix things. start simple. If go to learn react by reading react docs you dont start simple by saying install next or remix. Instead you should be saying start using vite to follow the docs example and then as next step we recommend learn nextjs or remix or react native, etc.
I finally finished your video, I think that you didnt do your proper research on the positives of Angular, its more like you just wanted to say why you dont like Angular but didnt want to look biased so said a few nice things first. Maybe thats not your intention though, for example ask any Angular dev about when to worry about Hierarchical Injector and you'll probably get crickets, like you just went to go look for some advanced detailed documentation to complain about, when as Angular devs we dont discuss that on day to day work. Btw the number 1 most loved feature of Angular is dependancy injections, there is even one developer who wrote a book about all the frameworks and said his favourite part about Angular is DI, so I think you downplayed how helpful that feature actually is. Yes if you are only moving buttons around, it will be overkill, but then even using a js framework might be overkill, the kind of apps we build are not just that simple most of the time. Also your survey, most of the people replying will be React devs, which most just hate angular for fun anyway lol. But thanks for your comments, I dont agree with everything, I think a more honest look wouldve been better. There is a new tutorial on the Angular CZcams channel maybe try that. Cheers.
Hey! Thank you for your comment and your feedback. Let me preface this by saying I get both sides of the argument (or I believe I do, anyhow). One of the company I work for does a lot of frontend work in various projects, and Angular is the goto solution. Overall I believe I have more than 5 years of hand on experience with Angular in both larger (10+ frontend devs) and smaller (1-2 devs) projects. I'm mentioning all these to give you the context from which I did this video - it's one of the frameworks I worked the most in, and I deliberately didn't want to do a video on it for so long because I didn't want to bash a framework which actually works. I honestly tried to stay objective, but I know the conclusion of the video would have been the same regardless, since that is my core belief on Angular. Yes, I prefer React to Angular, but I don't think my subscribers are mostly React devs. (You'll see that other than some initial React videos which had 0 traction - less than 500 views, I believe I have only one or two other videos out of around 70 talking about React. Coincidently, those also did poorly view count wise compared to the rest of them). Most of my videos are on new frameworks / tools (With Solid, Svelte and Qwik topics getting the most traction). Of course, this is not really relevant to a demografic, but I also don't think it is accurate to say that the people voting in this poll are React devs. Finally, regarding Dependency Injection I am actually not that convinced. This can get rather technical, but here is my take on it, as a Java + Spring developer. DI is fundamentally a result of the OOP mindset. The problem with OOP paradigm, just like with any other paradigm, is that sometimes it takes things too far: 1.We are doing OOP, so everything must be an object, right? 2. Need a service method? Well, that service is going to be an object! 3.Need a configuration for that service? Well, just create a ServiceConfig object and pass it along! 4. So all of a sudden you have a bunch of objects invading your heap - not really a problem most of the time since everybody pretty much disregards resources this days because cheap hardware. 5. Then, another dev decides he also needs that config object, so he'll create another instance, and then another one... 6. So now you have a bunch of object duplicates in your heap. 7. Well.. that's not good... We need to ensure only one object is instantiated for each such class. 8. Enter the Singleton pattern. Preferably with some Factory Method pattern on top of it. Make sure the class constructors are private as well, and the only way you can now instantiate objects is through the getInstance static method that returns a Singleton object. 9. Oh.. your code can now run in parallel... Make sure you have locks on your factory methods as well! So all of a sudden you realised that all you needed were a couple of service files that can be configurable, but you ended up with a bunch of boilerplate code and complexity instead. The good news for you is that all this can be abstracted away by this nice little thing called DI. So yes, DI is great, but the question is, in the context of JavaScript / TypeScirpt which supports standalone functions and other basic patterns do you really need to jump through all the hoops I mentioned earlier? I honestly don't know which is the right answer. However, looking at all this I feel like we are over engineering some solutions for otherwise basic problems.
@@awesome-coding I understand where you are coming from, I once had a conversation with someone and basically not everyone's mind works the same, so maybe that's why some frameworks feel better to work with for others, as I mentioned elsewhere, I've worked with Svelte and done a bit of React (don't enjoy jsx) but if it works for you it works and if it works for me, same. I was just going off the feeling I got from your video, but I don't actually know about your intention, not saying you're a bad youtuber or something, was just what I felt after watching. Anyway, regarding is Angular making a comeback, I don't think anything will beat react for a while maybe PHP lol, but I prefer that Angular team is adapting than just staying the same forever, it would be worse if they did nothing at all.
@@TayambaMwanza I agree! The fact that they are constantly trying to adapt is a great sign. Also, I don't believe Angular is going anywhere because it is deeply rooted in a lot of large companies at this point. I just wish it would make it easier for newcomers to jump onboard and build small apps faster. This is how you get retention and interest up. We'll see what the future brings. Thanks again for the feedback!
@@awesome-coding No problem, I think this i what they are trying to do, but because Angular is so large its like steering a truck if they do it very fast it will flip over, anyway have a great day.
I tried alot to learn react but seriously i find it so messy to have dom and business logic in one place by default and that makes ... I like the modular nature of Angular that readily provides html css ts... kind of a Django for the frontend ...
Why write forms with signals 😂😂 the best thing angular doing right is reactive forms and rxjs very handy when working with requests i know know in react world have react-query but rememeber the pain before it on how handling any request
I'm familiar with reactive forms - they still haunt me at times :)) The code in the video is me just playing around for a bit with signals in a very basic setup - nothing too fancy or pretentious :D
Created one project in Angular and I was crying. It took me 4 times more to code in Angular than I could have done with PHP + Jquery Started using JQuery again and I am happy :)
I started disliking Angular when trying to fetch and render the result. In multiple projects, randomly it just stopped working and I need a lot of weird patches like using setTimeout or Zone to make it work.
There's a fundamental problem in your code here, not saying in a bad way, just because I've done it before, if you have to use setTimeout or Zone it means there is a code smell, there's a way to rewrite the code you made without needing it, I've fixed many issues like that before in old projects, wish I could help you.
@@TayambaMwanza that were in an old and large projects but, to be fair I still don't know why it failed, some weird configuration, idk, but that was my worst experience with Angular. What I do it's just fetch, subscribe and render.
@@neociber24 I understand, the Angular team also understand, they did a video where they said sometimes to use Angular properly you have to understand how Angular is working internally and they want to eliminate the need for it, so you're no wrong about it being a problem, it's just that it might not really be an Angular bug, just not understanding it fully, but that shouldn't be your fault, so Angular is trying to improve this.
I actually find Angular Reactive Forms much easier to use than Formik with React. The example at the beginning of the video using Template Driven forms (and signals ? Not sure why) is very far from how forma should be implemented
@@timmeehan2365 Reactive Forms + OnPush Change Detection + declarative coding with RxJS works nicely for me but then other people in the team have a tough time understanding it. People think that because Angular is quite strict these issues wouldn't exist but in reality the Angular community is split in two, some people want tighter integration with RxJS like @Input Observables others want to see it less in the framework which causes some problems when working in teams
I had to dabble a couple of times in Angular and non of them have been a pleasant experience. It’s a real shame that so many big companies are still using it, when simple stuff become a nightmare to debug. I’ve recently joined a company where they use Angular 14 and for more than 1 month the main lead developer (15+ years of experience) was trying to fix the way the app was storing and mutating data. There’s just no way for me to be brought to use it when I’ve been using Vue & Svelte in the past few years and have seen how easy and simple stuff can be.
Because any angular dev can work on any other angular project with their max efficiency right from the start but this doesn't hold true for any other lib*. This is especially good for companies where there are large numbers of employees leaving and new ones replacing them all the time
The creator of angular moved on to create the new framework "Qwik" ... which uses functional components like React. That's all you need to know about angular.
@@unimovi8702 Right. I think he is the one leading the Qwik dev efforts. But the point stands. He came up with Angular JS (he might still use it, or not - I have no idea), but his newest project, Qwik, draws way more inspiration from React than from the Angular world.
Even that is not fair enough, because Nextjs is a backend web framework that use React (something like full stack framework of the new generation), Angular is just a full feature frontend framework. Maybe comparing Nextjs vs AnalogJS (the new nextjs type full stack framework for Angular)
Angular is adapting, is more performant. why people are afraid to learn? most of people compare Angular and React and they don't even know the diff between virtualDom and incrementalDom...
Angular was the first thing I learnt after PHP. I didn't like it, I thought I was dumb, years passed I learnt react, svelte ( it just hit v3 ) tried angular again and still didn't like this time because I knew what was going on but it was too much for me. I had to think more, write more, use RxJS just to be as performant as react which just uses hooks and functions that's it and was sooo much easier to write the same thing. The CLI though angular has the best cli for a framework ever ( Astro js also has a cli which is also great ). It has soo much functionality that solves writing all the boilerplate code by hand. In a large team having a cli with strict opinions on how to structure code is very useful. Another great thing is they have all the libraries needed like routing, forms, http, modules, DI and sooo much more. So if you are Google and have a bijjilion projects moving form one team to another is like nothing only the business logic changes. If you know how one angular project works then you automatically gain the ability to understand all other angular projects. This is good for Google scale companies but if you are anything less than that ( which you statistically are more likely to be ) then you can be faster using anything else. I love angular but will not be using ( if I have an option ) for any other project.
@@awesome-coding lol 😂 yes. Opinions aren't bad solid start has them, nextjs has them, remix has them, sveltekit has them but too many options forced on to you is never good. Projects' requirements vary wildly so there should be wiggle room to put in what we need when we need. I may not like server actions in next and can avoid using it. I may not like solid's server$ function and I don't have to use it. They have opinions but I can diverge from them. If angular let's me do that I may consider it.
Google should drop angular and adopt vue js and implement Web Components inside vue core. I only hate RxJS and TS, the rest is ok. Now it feels weird, i have to choose between RxJS and Signals, come on, feels like stranger soup
I disagree with you, angular is not poorly implemented, it's quite the opposite. Angular's problem is that it is implemented to be highly configurable and solve a lot of problems that it became very complex and have a steeper learning curve compared to other frameworks
@@TayambaMwanza Ts: formCtrl = new FormControl(true) HTML: You would assume that checking one should affect the state of all checkboxes bound to the same form control but it's not the case One gets changed and the other goes out of sync with the state, that's all it takes to break Angular's abstractions useState in React is way more predictable, React is much better at keeping UI and State in sync and Angular is a poorly implemented mess.
@@bullettime2808 I'm going to give you the benefit of a doubt here. Why didn't you just use ngModel to achieve your effect? It exists as part of the forms module.
As much as i like the concept of angular, it will be death by over-engineering. My good friend Albert Einstein once said - Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius to make it simple as possible, but not simpler.
Angular is batteries included, but the batteries are not up to par with the batteries I've grown accustomed to in other frameworks. They have a massive undertaking ahead to catch up with smart route rendering, hmr, browser devtools, change detection, easy i18n, ssr, external library support, build complexity, build time, error handling, community support, simplification, getting rid of over-engineering and boilerplate, etc etc. It's like they're starting from scratch, but with a ton of technical debt. I don't envy the angular devs.
No one is mentioned how poor the DX is due to lack of fast refresh, when working on UIs I am forced to create a react project with Vite, work on the UI there and then port the work back to Angular, It's faster then working in Angular and I'm not even joking
Lol; if engineers in your company actually know how to use angular, then you are in a better place than a react project. React, unless you are working with next and its latest features is a real pain. Don't listen to angular haters.
Good luck! It's still a nightmare for me to work with Angular as a react dev tbh. I could obviously get things done but it took a lot more time than it would've taken with react. RxJS, Angular Material do not make things simpler.
@@mayanksharma6927 TL;DR Sadly, I would agree with you. Note: for anyone struggling with reactive form; please read the doc (it is finally clean 😂😂), or watch the old tuto of fireship about them. The main problem came from the fact that every one wanted to use them without ready the damn documentation (which was poorly written in the past; I confess) ---------------------------------------------------------- But as I said in my own comment. For a large (5 year old legacy) code base, you would probably prefer angular than react. And of course if you are lucky to work in a small codebase or with modern react (with NextJS and all new features), then yes; it is better than angular. In those old react code base, the context API is massively used as a global or "page" state; which makes the code super ugly to read and manage. And component composition doesn't help also. The concept of services in angular is a life saver. I get the pain people feel from rxjs and angular material; what I am saying is that most of these issues come from poor usage of the framework in many project. I know angular enterprise project can look super ugly or/and hard to manage. But I would suggest any one to follow old angular tutorials of fireship. He presents toy projects, but the way he programs them shows good practices that a lot of enterprise projects lack. How many time I have seen people combining "reactive" and "template" forms cause they were "confused"... How many time I have seen people putting gigantic tons of logic and utility functions in the component cause they have built poor quality API, or/and angular services. I wish you good luck in your career anyway
@oursbrun4243 Our projects are mostly Next 12 based, the board decided that all, if not most, of the future projects "should" be done with Angular. 😢 But honestly speaking, Im kinda liking Angular, I guess I always liked opinionated softwares 😅
If they switched from Next to Angular, I have no faith in their decisions. Not only the development in Angular is extremely slow compared to Next but it's also harder to find third party library support and everything is over-engineered. Next is honestly so much enjoyable with serverless APIs, great page routing system and global state management with jotai or zustand. Angular doesn't even have options and if it does, they're unnecessarily complicated. Kinda like Java, more code for less stuff. Still, if you can find a way to convince your mind that it's okay, then it's great. Unfortunately I couldn't so I left my job.
@@awesome-coding Well, at least you're being honest. Partially... Because, I doubt you saw a large Angular codebase and failed to see what's their use case. I'm just gonna put it like this... The whole "state management" thing, is a problem invented by "modern fronted development", excluding Angular. Angular just uses tried and true recipe to do this. Desktop (even game) development follows this pattern to a degree... So really, what it boils down to is this... Angular is far from over-engineered. It just gives you the tools to accomplish things other frameworks are sorely missing. And when you try and cram such solutions into them, THEY become over-engineered, instead of following that simple pattern.
@@cocoscacao6102 Hey! The biggest project I ever led on the frontend was an Angular based ERP system build for the medical sector. We had a team of 8 to 10 full time frontend developers for 2 years prior to the beta release, and for another year until the official release. We are now running in production for more than 2 years, with more than 1k institutions using our software. In the past 2 years we downsized to 5 frontend devs doing both maintenance and new features. I'm not sure if this qualifies as a large project or not. I'm sure there are way larger code bases out there, but my guess is that most projects would be smaller than this one. With all this in mind, I'm gonna stick to my previous statement - I don't really know why RxJS is used in at least 80% of the use cases. Objectively, this is the way I see it. If RxJS was truly a compelling approach with clear benefits most frameworks would have followed along, but they didn't. Remember that Angular 2 was the one who pushed TS as the default language instead of JS and A LOT of devs (me included) were outraged by that back then. However, everybody picked that TS up in the meantime, because the benefits were clear. As a more recent example, Signals were (re)introduced as a concept by Solid, and now, 2 years later everybody under the sun (Angular included) are integrating them in their systems. This is what happens with good ideas & truly useful patterns - they are copied like crazy by the competition, because they don't want to be left behind. Few people outside the Angular ecosystem are actually considering RxJS for their projects, regardless of the codebase size. Either way, thanks for your feedback and input! Even though we might not agree, I find it really useful to try to understand opposing view points.
@@awesome-coding czcams.com/video/-CoVmNvp_1g/video.html This is just the tip of the iceberg. All of those that were outraged by switching to TS... well... I wouldn't be proud to admit something like that, because such people for me fall into a certain category... One I wouldn't hire, ever. Because they spit on things they don't understand, without proper explanation on why. TS was forced upon everyone when there was no more escape from a certain problem. RxJS wasn't, because they found a (convoluted) workaround. So do yourself a favor, and learn why it is useful.
I doubt the new signals update would do anything. Especially when most Angular enterprise projects are already on an obsolete version. You're absolutely correct about Angular being over-engineered. It's a framework that tries to do something cool but really does it in the worst way possible. Out of all the modern frameworks, Angular is the slowest to write and the most difficult to work with. I recently tried to upgrade my company project from Angular 8 to 12, I can only say that it was nothing short of frustrating and we ended up not upgrading. So yeah, thanks for nothing Angular. On top of that, simple things like forms, shared component states are amazingly easy to implement in React but Angular... yeah no thanks. The documentation is also pretty bad, especially Angular Material, it's just awful! So with Angular, you get a more difficult framework with less options for core design principles, less third party packages support, worse documentation and for what? 'Code consistency' for the juniors in the team?
@@TayambaMwanza Well, the breaking changes didn't help. Our styles are broken because something changed in angular material and many things look off now. Angular material is the worst UI library I've ever worked with!
Another comment brought me back to this one. I Focused on your 8 - 12 comment, but I also wanted to add I think a lot of people came from old js mindset when learning Angular and used a lot of the tools incorrectly, I'm working on an Angular 8 project now and I can tell they skipped or didn't know about a lot of best practices which adds to the difficulty of the update, Angular is actually very good but if you don't take time to use it properly and end up with problems it's not entirely the frameworks fault, I'm sure people do the same thing with react, it's just harder to do with only react because it's just a view library. If you write Spaghetti code is it really the frameworks fault? I only say this because I'm in a project of similar situation to yours, but I also have and worked on a project that did things the right way. So your perspective could be distorted because you've never worked on an Angular project that did things the correct way. I started using signals for Angular it's great, no more async pipe and much less rxjs.
Angular is beautiful. If you find angular hard, you are learning it wrong. I teach angular to undergrad students and they start the project on third day themselves. Also I don't get how react fans say jsx/tsx is more close to native html. On the other hand any valid html will just work in angular without single change, in react you have to change 'class' to 'className' , write weird style that too with object syntax, weird tags. Everything in react is just bunch of workarounds. Condition and loops in react are weird as hell, with all those idiotic ternary operators and foreach callbacks. In angular everything feels natural, it's too beautiful. If you find angular reactive forms hard, just create a data object and bind it's fields to form components. Its too simple.
Angular fill a template system, that's why html work out of the box. JSX is javascript + html, so is more like js with powers. In js/ts you have already reserved the keyword class, so you can't use it in the html. And yeah, they're too many ways to make React ugly lol.
@@cipherxen2 It's mostly because Angular is not as straight forward as others frameworks, the idiomatic way of doing things in Angular is more complex. For example fetching a JSON and render the content, angular require a service, RxJS, maybe importing modules, in React that's a single component using the native fetch. I am not saying you can't do it in a single component in Angular, because you can, but it's not the idiomatic way people do it.
This reminds me a bit of the comparisons of programming languages. There are clowns out there who think that Python, for example, is superior to all other languages because the comparison of a "Hello World" example is 10 times smaller than in other programming languages. Since the hype was so great to simply write something like "print('Hello World')" instead of first preparing a whole class with an entry point called "main()", Microsoft also decided to create the possibility for C#, Execute top-level commands. As far as I know it was a flop and they removed it. I hope Angular stays true to its line and doesn't try to follow every new trend. If there's one thing I've learned in my many years of development as a software developer, it's that the people who get upset that a language or framework has been completely overloaded are the same people who used to be in favor of building in all the features because other technologies have it too.
Haha - Java is doing something similar these days by introducing flexible main methods and anonymous main classes to the language. However, they are doing this JUST for learning purposes, probably mainly to make it easier for students. The reality is that people are always attracted by simplicity. In software development, like in most other fields the barrier of entry gets lower every year (for various reasons) so you'll get a decrease in quality of dev resources and resulted output. Languages and tools still have to compete to gain popularity, because you'll die without a user base. Angular is also following this trend - they allow you to build without modules, they are trying to simplify reactivity via signals, and, more recently they are proposing updates to their templating system. Also, who's to say who is right or not, especially when there is no objective metric to measure what's a good or a bad language.
React is awesome, but React devs are overwhelmingly average. With all the advantages React has, they still tend to produce spaghetti code with unnecessary useEffect everywhere.
Maybe but it will still be used developed and maintained because it is too big to fail now. So many companies depend on it, if they keep innovating and pushing things forward it might actually succeed
Angular is bs ... I will never understand these people who make framework like this .. module , core modules , components, decorators , providers etc etc ... Wtf!!!!!!! Why alllllllll the goddamn complexity why Why why ?! , It's better to use vanilla js !
DUDE ! seriously, get a grip please - you cannot just create a pull on your channel, with your audience and present this as any type of an evidence 🤣🤣🤣 The only thing that this pull tells is that - in YOUR audience there are more people that do not use Angular... yeah 'big surprise'... Come on, you must understand at least on some level, that if this pull was conducted on a channel that focuses on Angular the results would be - wait for it - in favor of Angular... Your decision to even show such pull in the video made the whole video a lot less credible... BTW I do work with Angular primarily but I have also worked with React, Vue and Svelte enough so that I can make an actual comparison and choose what works best for me.
That's the thing though... If you check my past videos you'll see that this is not a React focus channel either. The few videos I have on React are actually not performing very well, and they have a lower view count than the other ones. Most of my content is on newer tech and frameworks outside React / Angular, with most engagement and views coming from Solid / Svelte and Qwik related content. So, overall, I believe that my audience is rather unbiased on the React vs Angular topic. I bet that if I'll do a pool on React, the results will be quite similar.
@@awesome-coding ah, ok, sorry then for my wrong assumptions... It's just seeing that option in the pull "No, I till hate it" I mean... why would someone hate Angular... what has Angular done to anyone ;) I don't use React but I don't hate it... I just feel indifferent about it...
The moment you mentioned that the rxjs is overused in Angular I could not watch futher and had to look at the comments. I hope the bubble finally pops for the other framework which are not close as mature as angular. The way you described things in the first 50 seconds clearly states that you are an amature who never were close in using Angular on some real world project. I doubt if you really developed anything better then some static website with a few buttons in react.
Hey.. a static app is still an app!
@@awesome-coding I'm increasingly impressed with your patience and kindness towards these internet trolls. Keep carrying the light, good man!
@@vladlazar94 Haha thank you!
Go easy mate. If don't like this comments, just stick to disagreeing and provide your point of argument instead of attacking.
I'm working on Angular and I firmly prefer their approach rather then the React model. Reactive forms are very easy (when you know how to use it), dependency injection can't be simpler, the template syntax is way more simpler as well than in JSX (i guess the people who say that don't know anything about Angular because regular HTML just work as it is in Angular, wtf !?), and to answer the comment you've shown, I never use 'any' as a type in my code and I actually manage complex streams in my project right now, sometimes combining, sequencing, chaining them as I please and again, it works nicely when you know what you're doing, don't be surprise it doesn't work if you don't. Now, modules have their reason to be in the first place, to lazy load bundles just for example, and standalone is just a better way to scaffold components, pipes or directives rather than the SCAM pattern that became the norm. So yeah, anyway, i'm open to discuss Angular structure, features and so on, but if it just remarks from people with no understanding or experience with it is not very helpful for anyone i guess.
All valid points! Thank you for your feedback!
@@awesome-coding if it's valid point, why did you even show this comment on the first hand? This guy's don't know what he is talking about.
@@tictak2121 Because there are pros and cons to use any type of framework or library. Angular devs will always point to the "flaws" of React which usually is related to "JSX is awful" and "there is no structure in place", while React devs will always say that Angular is "more complicated than it needs to be" or that it requires"too much boilerplate code".
So, most of the time, people will fall in one of these two categories, and, sometimes, they get passionate about things. If you are familiar with a solution, a different one might seem strange or inefficient. This is why I get both sides of the argument.
@@awesome-coding No, you don't. You skipped some points and I saw your comments and likes under statements like: "angular is dead".
Angular have new versions every couple of month with new fixed/features. The last big update for React was in the 2018(?) when hooks and FC were introduced. Did you forgot to mention something like that?
@@tictak2121 Hey! please don't take my comments and likes too seriously. Just as a parallel - check out the comment I pinned in my React video - czcams.com/video/hAhpoWhYteI/video.html&ab_channel=Awesome
And I don't think it's fair to say React didn't do anything new since 2018. They completely messed up CRA, and they also have a new documentation website! ✌
Angulars mistake was not taking their target audience into consideration; most 'web devs' aren't actual software engineers. If you understand things like DI, design patterns, etc angular works exceedingly well. But when something as mundane as static types causes holy wars, you need to stick to things that are easy to cargo cult to get traction.
I think that their target audience was enterprise software developers. I saw Java developers pretty excited to "try frontend development" because Angular was similar to what they were used to. My feeling all along is that they went for enterprise because this is where the money is.
@@awesome-codingNot just enterprise engineers, enterprise projects. When a project will live longer than the typical js framework fad, you value different things.
I personally feel courting the js kids is the wrong direction.
@@awesome-coding exactly angular was actually ment for enterprise use within and outside of Google. It is very easy for a C# or a Java dev ( who's been unnecessarily abstracting away code that they don't even reuse 😂 ) to use angular. They don't have to know signals ( well they didn't have to in the past 😂 anyways ), hooks or anything else and the component structure is very similar to a servlet service in Java. RxJS is similar to message queues and streams so it was pretty easy for them to switch over and they didn't have to pull their hair out to decide what state management solution is the best everything comes setup for them.
@@awesome-coding I agree with his take, the more software engineering principles you know, the more Angular makes sense, if you just want to write as fast as possible that's when you get frustrated, I know because I was self taught after high school, then later I did a short software engineering course and then I understand why the patterns in Angular exist, it's good "engineering" practices, not just writing code.
@@TayambaMwanza I get what you are saying. However, after some time passes and you gain more experience you'll also understand that premature optimisation is a terrible idea in software development. And then you'll realise that a lot of what Angular is doing is premature optimisation. More often than not you'll not need all those "best practices" in your project.
I've been doing angular for a while now and had to learn React at my current job and I don't get why people say react is simple and easy to learn.
React hooks are a nightmare to get my heads around.
At least angular's life cycle hooks are properly named. Like OnInit, AfterViewInit, OnDestroy etc.
What is it named in react? terrible
Also the whole deal with using useState to declare a variable is very confusing for beginners. a = 0 vs const [a, setA] = useState(0) which one is simpler?
React doesn't have native support for http, routing, forms, state management, SSR, WPA etc. You have to research and put lego pieces to fit into a monster which are not maintained by the same people. Beginners would not know which external libraries to use for these situations and having a standard goes a long way.
People think hating on Angular is cool like they used to hate on crocs back in the day while they haven't even touched and used Angular.
The origin of bad experiences from developers I worked with, is that, most of the time:
- angular projects are built by backend engineers that practice over-enginerring; such as using long untraceable observable dependencies.
- ex react dev or react fan boys that try to use that horrible ngrx library; which doesn't fit angular at all.
- early adopters who fell victim from the old documentation which was poorly written. I actually learnt how to use reactive forms from fireship.
Once you adopt and know how to use DI, traditional react becomes a horrible experience. Most react devs which are working on "legacy react" are currently living a coding nightmare.
You don't sound like someone who knows what they're talking about. Back end engineers don't like observables. Observables are declarative, which is one of the only redeeming aspects of Angular. Your experience with them is probably from Redux-observable, which is all the complexity and almost none of the benefits of FRP.
@@mfpears No; I experienced the observable overdose in a different project from the one they used ngrx.
I don't know if there is something in my comment that said explicitly or implicitly "I hate observable" or "I hate angular". I am native french but I highly doubt I expressed something like that.
Maybe I was wrong targeting the whole population of backend engineers. Which explains why some one may be surprised. Backend engineers who works on large and complex code base of a multi-threaded system, if you prefer.
Of course the typical "java" developer will probably never work with non-blocking IO (maybe post java fiber). The kind of developers who enjoys the spring webflux experience also likes to toy with complex dependencies of observables. Why? Because they are as smart as your average pure functional programmer, but they sometime take the experience way too far.
And don't get me wrong, making long chains of observable dependence can work - and I wonder if you have ever seen what I am talking about, cause it is not necessary linked with ngrx. But:
1. It is super ugly to read. Especially when you combine it with "observable as component input". You start losing track of the source; which also make debugging a nightmare.
2. You have to guard or protect every observable in the chain from weird or unexpected behaviors from its source, using a pervert combination of error handling and "starwith" operator. I am not even talking about the junior dev who will get confused and start using "iif" every where to avoid learning rxjs transformation operators.
So... No I am probably very far from "some one who doesn't know what he is talking about". This is my 4th project which uses angular as a front end framework, and the only people I have seen using that framework and rxjs correctly (perfectly) are... CZcamsrs (fireship and Joshua morony), and people publishing blog post.
@@oursbrun4243 Woah? Passing observable through an input? That's crazy.
I saw in the last 5-6 years one backend developer using observables and it was a real time sistem where he had to do it.
@@TayambaMwanza [abc]="{{ obs$ | async }}" does this seem foreign to you? LOL.
Angular developers can softly switch to any well established framework while react developers wouldn't understand a lot of things, angular teaches actual programming, react is just another JavaScript library.
Teaching actual programming will teach you actual programming.
Angular, just like React (even though, I know, React is a library and Angular is a framework) exists for only one purpose - to abstract away the basics, and enforce some coding standards and patterns. When working with Angular you are forced to follow some of those standards, but nobody guarantees you'll understand why you are doing it. I bet most angular devs don't actually know the fundamentals behind why you would need DI in a project.
@@awesome-coding Yes, so 5 years from now, others can read your code and make changes. Please go open an old React code base. Can you make changes to it? LOL. Be humble man.
I'm both a Angular and React dveeloper so I'm a pro of one versus the other (I do have more experience with Angular to be clear though ). I dont think your comparison is really biased since we're really not comparing the same things. Angular is batteries-included framework where as React is really just a UI library. It would make more sense to compare Angular to React + Redux + Formik + React-Query for instance. In thay case, both stacks can deliver similiar features and the React stack becomes far more than "just JSX and hooks"
Even in that case choice is what you get with react. I don't have to use redux I can use nanostores / jotai / recoil, I don't have to use Formik I can use react hook form, I don't have to use react query I can use react swr. Yes I know you can use other things with angular but I haven't seen anything like that ( yet )
Edit: you also forgot react router lol 😆
@@TechBuddy_ Not sure how I forgot react router, should have been first on the list haha.
Agreed, diversity of options and the richness of the ecosystem is a clear characteristic with React apps, as opposed Angular being much more opinionated. Both have their pros and cons, I guess it's more of a personal opinion.
Imo I prefer when a framework is more opinionated because I don't want to overthink when picking a library for standard features such as routing, forms, or state management. I would rather have these default solutions included, and then later on swap for a custom one if I have a very particular need and the default one isn't enough.
@@timmeehan2365 agreed 💯 percent
@@timmeehan2365 angular was enterprise framework for big corporations which want a solution for everything out of the box, predictable and battle-testing, without unexpected change. Angular was like that until the developers of it decided to make radical change and adjust the framework to everything, forcing it to compete in all niches. It's going to kill the framework. It was much better for angular to specialize itself as enterprise solutions without trying to make itself look "cool", while allowing react/vue to take other niches (start-up, small businesses, etc.). This specialization was good. And now it's gone.
I really liked Angular. Especially it being specialized on enterprise. And now the developers of angular are killing the framework, destroying its competitive advantages whiles introducing features already available in other frameworks. Instead of deepening angular specialization on enterprise, the developers decided to go the opposite direction and make the framework general purpose, forcing it to compete with react and vue and so on.
I hate angular team. They're destroying the business model of Angular based on their personal believes and tastes. "The framework is not cool enough". morons.
There was no interest and retention for Typescript in 2015. Still Angular went with it.
Secondly, I didn't find any problem with modules in medium size apps. I found it usable in case when certain similar components have same dependencies. I found it better to collocate all the related components, pipes, directives, providers, injection token and let the module be the entry point.
Standalone components bring its benefits but they aren't displacing the Modules.
An Angular Developer would argue it differently. But the criticism would at least help me think deeply.
Most frameworks have pros and cons. Angular more than most. I enjoy working in angular more than react.
Where angular fails is it’s complexity. Where it succeeds is its development experience once you have a medium grasp on it and rxjs.
That's fair!
State management in Angular, specifically services, is what gives an edge over React for big apps. You can have two distant components that share a service and the data will update on both components. Try that in Redux (or whatever is popular this week), and you will see how much unnecessary cruft you will have to add in your business logic.
You are right.
It is worth mentioning that data & reactivity is not perfect in Angular neither. Zone JS has its quirks when it comes to change detection.
In all fairness both React's Rendering & Reconciliation model, and Angular's Zone JS strategy are rather inefficient compared with signals.
Props to Angular for adopting them!
hi sir, i wish you give me the right answer, i learned the basic of JavaScript , Es6, typescript, and i build many projects, and i will learn Angular, but i don't now if this is enough or no, and i also the only language i learned is JavaScript, i hope you answer?
Hello!
This is a good start!
Surely, if you know Angular and Typescript well, you should be able to get a job fairly easily.
However, the learning should never stop. You can explore alternatives to Angular (like React, or Svelte) to better understand the entire frontend space.
You can also use TypeScript on the backend (via Node or Deno) so you should also do that.
Next, once you have a pretty good grasp of the backend, look into a second language, to complement your JS knowledge. Java, Python or Go are all good options here.
It's seems like that concepts are making hard to people understand the framework. Which I believe that it translated into lack of experience. Because when you have big projects, you start naming services and files depending into some functionality. Angular gives to you from start. Something that you will need in the future. One think is true though, simples mvp doesn't need that, but again if you have experience in general programming that won't be an issue cause u know what is what.
if it's hard, then they are not supposed to learn it in the first place. Angular business model is different and forcing it to complete with react and vue in startups and retails is killing the framework.
Hi, few things about this video:
- correction: emberJS was first framework to have a cli not Angular (2+), Angular cli was based on ember cli ( nowadays it is own thing)
- when you create a new App ( since v16) as standalone way, you need to add a flag related to standalone.
- why are you create / generate a component manually ? instead of using the cli ?
- about signals: this feature is still in preview mode, as such is not stable.
- the weird thing, is adding to a form base on template driven with signals, because you dont see in any official docs / medium / youtube or even in their RFC of signals of Angular about it, as such what you show for now is just a bad practice and unofficial way.
- signals for now is to be use for simple things and as global state management with service, not to be using with forms.
- with standalone, you dont need to think about modules and service hierarchy
- Another weird thing, for validation you don t need a computed prop, for template drive forms, just add the html attribute required, add a ref to the form, in a button [disabled] = " !form.valid", why complicate things.
- another weird is that you didn't show final result of the app, lool.
- About the pool, did ask before that question, which framework they use or know or try?
React dev say react is easy and angular is bad and difficult to learn. lol
Now with new react docs recommendation to use nextjs, make even more easy to learn react, LOL
Your are just traumatized about Java. If you dont like or dont know how to use it or understand Angular why talk about it. why wasting time trashing it ? just to do clickbait and get more viewers?
Now you may ask me: do you like the path that Angular is going with signals?
my first reaction was: Hell nooooooooooo. this is the end of Angular.
my second reaction: verbose like hell, not very classy.
now: i am waiting for the thing to be stable and get more info how this will play with forms, main template driven, since dont believe that will change / effect the reactive forms, and way you show it for now is not right and official way.
Frameworks are just tools, not football / soccer clubs. Peace.
Hey! First of all, thank you for the time you put in writing this feedback!
1. On Ember, I looked into it, and you are actually right! Thank you for pointing it out. Ember is one of the frameworks I never got the chance to look into, but I remember those two guys did a lot of interesting stuff in the early days.
2. The code I was writing - I just wanted to showcase the layout of a basic component, and how it would interact with signals. Creating it via the CLI would have been a quick action. This way the people can get the chance to actually look and digest the code (One of the feedback I often get in comments is that I go through too much code too quickly, so I'm working on that).
3. Same with the signal / form combination. I didn't want to show a counter because that's already in the docs. Maybe it was a bad idea to go outside the docs. However, I expect most people coming from other frameworks will do things this way if possible. Past experiences weigh more than the documentation at times. I can tell you that not all devs / teams embrace reactive forms. We had a team of devs who were "ngModel-ing" everything despite multiple efforts and in house training sessions aimed to make them switch to reactive forms. So, I know it would have been way easier to achieve the login form via reactive forms, but I needed a plain signals + computed + effect example that can fit in one page, and that can give viewers a basic idea of the usage. Again, a form might not have been the best decision. (Funny how Angular is the only framework where I would encounter this "problem")
4. About the pool - I mentioned this in another comment. I don't believe my audience is a majority of React devs. If you check my video history, you'll see that most of my content is on newer tools and libraries. On top of that, the few React videos I did performed poorly compared to the rest. I believe it is hard to create an objective survey, but I believe a React pool would get pretty much the same results (I'll actually test this in the next couple of weeks)
5. You were spot on about Java. The trauma is there. 🥲
6. As I mentioned in another comment, I actually have quite a lot of hands on experience with Angular in both larger and smaller teams. My main issue with Angular is that it has the tendency to over engineer and over do things. Maybe it's just my Java trauma, but I often feel like Angular development is closer to a backend dev experience than a frontend one. And I find this a bit disappointing considering the type of programming paradigms a language like JavaScript has to offer.
7. Believe it or not, I knew this video is not going to perform well (compare it with some of the recent ones and you'll see that I'm right). This is because Angular and React content is not getting so many clicks because people are tired about this content. So this was not an effort to get more clicks / views. I can do that easily by acting like Solid or Svelte had a minor update "that'll change everything" - that'll get me way more views than this video.
8. I'm doing YT videos for more than a year now and, despite Angular being one of the frameworks I'm actively using in my day to day job, I postponed making a video on it just because I didn't want to simply trash it. These new changes they are making prove that they want to take things into the right direction, so I believed there is some positive in Angular's future.
Thanks again for your feedback! I really appreciate it!
Actually the React team suggesting a framework is a very good choice. Because without s framework you will be lock-in on CSR forever, with a framework you will have more opportunity to grow if you want.
@@oscarljimenez5717 no it not, you have a alternative call vite.
Devs say on Angular you have to learn too much things. By using nextjs your justification to not use or not like Angular just make no sense.
@@jediampm the problem with Vite, is the same thing the React Team said. Ok, you start a React SPA proyect with Vite, then, you want to use SSR, SSG, ISR, or even React Server Components? Oh, no, you can't. Yeah, maybe you could add vite-plugin-ssr, but at that point that's a framework, because you will have to migrate a lot of stuff. Remember, the base of frameworks are the Router, so if you start with a SPA only router, you're lock-in. The suggestion of the React Team is that you can use a framework that give you all the ability to grow wherever you want. Vite-plugin-ssr is amazing, but has is limits, even that I think the React team should mentioned in the new docs.
@@oscarljimenez5717 i was talking when to start to learn as a beginner.
Then you have to make choices. Angular is just a full feature frontend framework, Not full stack framework and when start you should not mix things. start simple. If go to learn react by reading react docs you dont start simple by saying install next or remix. Instead you should be saying start using vite to follow the docs example and then as next step we recommend learn nextjs or remix or react native, etc.
I finally finished your video, I think that you didnt do your proper research on the positives of Angular, its more like you just wanted to say why you dont like Angular but didnt want to look biased so said a few nice things first.
Maybe thats not your intention though, for example ask any Angular dev about when to worry about Hierarchical Injector and you'll probably get crickets, like you just went to go look for some advanced detailed documentation to complain about, when as Angular devs we dont discuss that on day to day work.
Btw the number 1 most loved feature of Angular is dependancy injections, there is even one developer who wrote a book about all the frameworks and said his favourite part about Angular is DI, so I think you downplayed how helpful that feature actually is.
Yes if you are only moving buttons around, it will be overkill, but then even using a js framework might be overkill, the kind of apps we build are not just that simple most of the time.
Also your survey, most of the people replying will be React devs, which most just hate angular for fun anyway lol.
But thanks for your comments, I dont agree with everything, I think a more honest look wouldve been better.
There is a new tutorial on the Angular CZcams channel maybe try that.
Cheers.
Hey! Thank you for your comment and your feedback.
Let me preface this by saying I get both sides of the argument (or I believe I do, anyhow). One of the company I work for does a lot of frontend work in various projects, and Angular is the goto solution. Overall I believe I have more than 5 years of hand on experience with Angular in both larger (10+ frontend devs) and smaller (1-2 devs) projects. I'm mentioning all these to give you the context from which I did this video - it's one of the frameworks I worked the most in, and I deliberately didn't want to do a video on it for so long because I didn't want to bash a framework which actually works. I honestly tried to stay objective, but I know the conclusion of the video would have been the same regardless, since that is my core belief on Angular.
Yes, I prefer React to Angular, but I don't think my subscribers are mostly React devs. (You'll see that other than some initial React videos which had 0 traction - less than 500 views, I believe I have only one or two other videos out of around 70 talking about React. Coincidently, those also did poorly view count wise compared to the rest of them).
Most of my videos are on new frameworks / tools (With Solid, Svelte and Qwik topics getting the most traction). Of course, this is not really relevant to a demografic, but I also don't think it is accurate to say that the people voting in this poll are React devs.
Finally, regarding Dependency Injection I am actually not that convinced. This can get rather technical, but here is my take on it, as a Java + Spring developer. DI is fundamentally a result of the OOP mindset. The problem with OOP paradigm, just like with any other paradigm, is that sometimes it takes things too far:
1.We are doing OOP, so everything must be an object, right?
2. Need a service method? Well, that service is going to be an object!
3.Need a configuration for that service? Well, just create a ServiceConfig object and pass it along!
4. So all of a sudden you have a bunch of objects invading your heap - not really a problem most of the time since everybody pretty much disregards resources this days because cheap hardware.
5. Then, another dev decides he also needs that config object, so he'll create another instance, and then another one...
6. So now you have a bunch of object duplicates in your heap.
7. Well.. that's not good... We need to ensure only one object is instantiated for each such class.
8. Enter the Singleton pattern. Preferably with some Factory Method pattern on top of it. Make sure the class constructors are private as well, and the only way you can now instantiate objects is through the getInstance static method that returns a Singleton object.
9. Oh.. your code can now run in parallel... Make sure you have locks on your factory methods as well!
So all of a sudden you realised that all you needed were a couple of service files that can be configurable, but you ended up with a bunch of boilerplate code and complexity instead. The good news for you is that all this can be abstracted away by this nice little thing called DI. So yes, DI is great, but the question is, in the context of JavaScript / TypeScirpt which supports standalone functions and other basic patterns do you really need to jump through all the hoops I mentioned earlier?
I honestly don't know which is the right answer. However, looking at all this I feel like we are over engineering some solutions for otherwise basic problems.
@@awesome-coding I understand where you are coming from, I once had a conversation with someone and basically not everyone's mind works the same, so maybe that's why some frameworks feel better to work with for others, as I mentioned elsewhere, I've worked with Svelte and done a bit of React (don't enjoy jsx) but if it works for you it works and if it works for me, same.
I was just going off the feeling I got from your video, but I don't actually know about your intention, not saying you're a bad youtuber or something, was just what I felt after watching.
Anyway, regarding is Angular making a comeback, I don't think anything will beat react for a while maybe PHP lol, but I prefer that Angular team is adapting than just staying the same forever, it would be worse if they did nothing at all.
@@TayambaMwanza I agree! The fact that they are constantly trying to adapt is a great sign. Also, I don't believe Angular is going anywhere because it is deeply rooted in a lot of large companies at this point. I just wish it would make it easier for newcomers to jump onboard and build small apps faster. This is how you get retention and interest up.
We'll see what the future brings. Thanks again for the feedback!
@@awesome-coding No problem, I think this i what they are trying to do, but because Angular is so large its like steering a truck if they do it very fast it will flip over, anyway have a great day.
I tried alot to learn react but seriously i find it so messy to have dom and business logic in one place by default and that makes ... I like the modular nature of Angular that readily provides html css ts... kind of a Django for the frontend ...
Why write forms with signals 😂😂 the best thing angular doing right is reactive forms and rxjs very handy when working with requests i know know in react world have react-query but rememeber the pain before it on how handling any request
I'm familiar with reactive forms - they still haunt me at times :))
The code in the video is me just playing around for a bit with signals in a very basic setup - nothing too fancy or pretentious :D
Bro is angular still worth to learn? Because my frds told that AI is going to replace web development jobs? Please reply
Hey!
Yes, I believe Angular is still worth learning.
AI will not replace web development jobs any time soon :)
I work on a small Angular team. And it’s a rough time.
I don’t hate it. But I wish to be out on a svelte or fresh project.
I feel your pain :D
Created one project in Angular and I was crying. It took me 4 times more to code in Angular than I could have done with PHP + Jquery
Started using JQuery again and I am happy :)
PHP + jQuery, nice! The simple pleasures of life :D
how will u acheive SPA
With jQuery, or javascript SPA is pretty easy
@@RajeshSriMuthu There is a technique using browser history and JavaScript is not pretty but does the job
the man has no real idea. RxJs is painful but not as painful as super buggy dependency arrays
Right - dependency array are terrible.
But, frameworks like Solid JS or Svelte offer a way better experience.
Hope for angular? fight back? you are wrong, Angular has always been the best solution for frontend development.
I started disliking Angular when trying to fetch and render the result.
In multiple projects, randomly it just stopped working and I need a lot of weird patches like using setTimeout or Zone to make it work.
There's a fundamental problem in your code here, not saying in a bad way, just because I've done it before, if you have to use setTimeout or Zone it means there is a code smell, there's a way to rewrite the code you made without needing it, I've fixed many issues like that before in old projects, wish I could help you.
@@TayambaMwanza that were in an old and large projects but, to be fair I still don't know why it failed, some weird configuration, idk, but that was my worst experience with Angular.
What I do it's just fetch, subscribe and render.
@@neociber24 I understand, the Angular team also understand, they did a video where they said sometimes to use Angular properly you have to understand how Angular is working internally and they want to eliminate the need for it, so you're no wrong about it being a problem, it's just that it might not really be an Angular bug, just not understanding it fully, but that shouldn't be your fault, so Angular is trying to improve this.
You know someone REALLY hasn't been paying attention if the best example they have of division within Angular is Aurelia.
It's actually expected. About 90% of the opinions you hear from React devs about Angular were formed in 2015.
Hey! That's not fair! I'm not a React dev! 😅
working with forms in Angular is a nightmare UI and state keep going out of sync due to the lack of controlled components feature found in React
I actually find Angular Reactive Forms much easier to use than Formik with React. The example at the beginning of the video using Template Driven forms (and signals ? Not sure why) is very far from how forma should be implemented
@@timmeehan2365 that's because he wanted to showcase signals
@@timmeehan2365 Reactive Forms + OnPush Change Detection + declarative coding with RxJS works nicely for me but then other people in the team have a tough time understanding it. People think that because Angular is quite strict these issues wouldn't exist but in reality the Angular community is split in two, some people want tighter integration with RxJS like @Input Observables others want to see it less in the framework which causes some problems when working in teams
@@TechBuddy_ yeah I figured but that's a pretty bad use case haha
@@bullettime2808 Ok I see. But I agree these also work well for me.
And actually what do you mean by controlled components ?
I had to dabble a couple of times in Angular and non of them have been a pleasant experience. It’s a real shame that so many big companies are still using it, when simple stuff become a nightmare to debug. I’ve recently joined a company where they use Angular 14 and for more than 1 month the main lead developer (15+ years of experience) was trying to fix the way the app was storing and mutating data. There’s just no way for me to be brought to use it when I’ve been using Vue & Svelte in the past few years and have seen how easy and simple stuff can be.
Because any angular dev can work on any other angular project with their max efficiency right from the start but this doesn't hold true for any other lib*. This is especially good for companies where there are large numbers of employees leaving and new ones replacing them all the time
The creator of angular moved on to create the new framework "Qwik" ... which uses functional components like React.
That's all you need to know about angular.
😂 That’s true!
Nope. The creator of angular is still working with angular. But he's now also contributing to qwik and that's one reason how signals got into angular.
@@unimovi8702 Right. I think he is the one leading the Qwik dev efforts. But the point stands. He came up with Angular JS (he might still use it, or not - I have no idea), but his newest project, Qwik, draws way more inspiration from React than from the Angular world.
@unimovi8702 do u know about angular 2, they tried switching theit framework to react
Popularity and NPM downloads does not it's better. You should atlist compare Angular to Nextjs.
Even that is not fair enough, because Nextjs is a backend web framework that use React (something like full stack framework of the new generation), Angular is just a full feature frontend framework. Maybe comparing Nextjs vs AnalogJS (the new nextjs type full stack framework for Angular)
Angular is adapting, is more performant. why people are afraid to learn? most of people compare Angular and React and they don't even know the diff between virtualDom and incrementalDom...
Angular was the first thing I learnt after PHP. I didn't like it, I thought I was dumb, years passed I learnt react, svelte ( it just hit v3 ) tried angular again and still didn't like this time because I knew what was going on but it was too much for me. I had to think more, write more, use RxJS just to be as performant as react which just uses hooks and functions that's it and was sooo much easier to write the same thing.
The CLI though angular has the best cli for a framework ever ( Astro js also has a cli which is also great ). It has soo much functionality that solves writing all the boilerplate code by hand. In a large team having a cli with strict opinions on how to structure code is very useful.
Another great thing is they have all the libraries needed like routing, forms, http, modules, DI and sooo much more. So if you are Google and have a bijjilion projects moving form one team to another is like nothing only the business logic changes. If you know how one angular project works then you automatically gain the ability to understand all other angular projects.
This is good for Google scale companies but if you are anything less than that ( which you statistically are more likely to be ) then you can be faster using anything else.
I love angular but will not be using ( if I have an option ) for any other project.
100% agree with all you said. Funny that they need CLI options to cover all the boilerplate code needed to write components :))
@@awesome-coding lol 😂 yes. Opinions aren't bad solid start has them, nextjs has them, remix has them, sveltekit has them but too many options forced on to you is never good. Projects' requirements vary wildly so there should be wiggle room to put in what we need when we need. I may not like server actions in next and can avoid using it. I may not like solid's server$ function and I don't have to use it. They have opinions but I can diverge from them. If angular let's me do that I may consider it.
@@awesome-coding I did Svelte for a project and missed the cli a lot, it's convenient.
Google should drop angular and adopt vue js and implement Web Components inside vue core. I only hate RxJS and TS, the rest is ok. Now it feels weird, i have to choose between RxJS and Signals, come on, feels like stranger soup
😅 Angular has a fairly wide adoption, and is core in a lot of large enterprise solutions. I don't think Google can afford to drop it any time soon.
@@awesome-coding lol, it isnt. D have you ever written vanilla js ?
just work with multiple checkboxes in Angular and you will realize how poorly it is implemented
Please explain more, I dont get the challenge, it's just a checkbox?
With React u have to pick a library when it's more than a very simple form. And if you're joining a project you hope it's the library you already know
I disagree with you, angular is not poorly implemented, it's quite the opposite. Angular's problem is that it is implemented to be highly configurable and solve a lot of problems that it became very complex and have a steeper learning curve compared to other frameworks
@@TayambaMwanza
Ts:
formCtrl = new FormControl(true)
HTML:
You would assume that checking one should affect the state of all checkboxes bound to the same form control but it's not the case
One gets changed and the other goes out of sync with the state, that's all it takes to break Angular's abstractions
useState in React is way more predictable, React is much better at keeping UI and State in sync and Angular is a poorly implemented mess.
@@bullettime2808 I'm going to give you the benefit of a doubt here.
Why didn't you just use ngModel to achieve your effect? It exists as part of the forms module.
As much as i like the concept of angular, it will be death by over-engineering. My good friend Albert Einstein once said - Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius to make it simple as possible, but not simpler.
Nicely said, wise stranger!
Angular is batteries included, but the batteries are not up to par with the batteries I've grown accustomed to in other frameworks.
They have a massive undertaking ahead to catch up with smart route rendering, hmr, browser devtools, change detection, easy i18n, ssr, external library support, build complexity, build time, error handling, community support, simplification, getting rid of over-engineering and boilerplate, etc etc.
It's like they're starting from scratch, but with a ton of technical debt. I don't envy the angular devs.
Right! It's going to be tough for them, because they have to carry along A LOT of large projects running on legacy versions.
No one is mentioned how poor the DX is due to lack of fast refresh, when working on UIs I am forced to create a react project with Vite, work on the UI there and then port the work back to Angular, It's faster then working in Angular and I'm not even joking
I doubt es build will make the situation any better as the app looses state anyways in HMR mode
😅 This is funny. Angular is in a league of its own.
I'm learning Angular for my company right now, pray for me guys 😢
Lol; if engineers in your company actually know how to use angular, then you are in a better place than a react project.
React, unless you are working with next and its latest features is a real pain.
Don't listen to angular haters.
Good luck! It's still a nightmare for me to work with Angular as a react dev tbh. I could obviously get things done but it took a lot more time than it would've taken with react. RxJS, Angular Material do not make things simpler.
@@mayanksharma6927
TL;DR Sadly, I would agree with you.
Note: for anyone struggling with reactive form; please read the doc (it is finally clean 😂😂), or watch the old tuto of fireship about them. The main problem came from the fact that every one wanted to use them without ready the damn documentation (which was poorly written in the past; I confess)
----------------------------------------------------------
But as I said in my own comment. For a large (5 year old legacy) code base, you would probably prefer angular than react. And of course if you are lucky to work in a small codebase or with modern react (with NextJS and all new features), then yes; it is better than angular.
In those old react code base, the context API is massively used as a global or "page" state; which makes the code super ugly to read and manage. And component composition doesn't help also.
The concept of services in angular is a life saver.
I get the pain people feel from rxjs and angular material; what I am saying is that most of these issues come from poor usage of the framework in many project.
I know angular enterprise project can look super ugly or/and hard to manage. But I would suggest any one to follow old angular tutorials of fireship. He presents toy projects, but the way he programs them shows good practices that a lot of enterprise projects lack.
How many time I have seen people combining "reactive" and "template" forms cause they were "confused"... How many time I have seen people putting gigantic tons of logic and utility functions in the component cause they have built poor quality API, or/and angular services.
I wish you good luck in your career anyway
@oursbrun4243 Our projects are mostly Next 12 based, the board decided that all, if not most, of the future projects "should" be done with Angular. 😢 But honestly speaking, Im kinda liking Angular, I guess I always liked opinionated softwares 😅
If they switched from Next to Angular, I have no faith in their decisions.
Not only the development in Angular is extremely slow compared to Next but it's also harder to find third party library support and everything is over-engineered.
Next is honestly so much enjoyable with serverless APIs, great page routing system and global state management with jotai or zustand. Angular doesn't even have options and if it does, they're unnecessarily complicated. Kinda like Java, more code for less stuff.
Still, if you can find a way to convince your mind that it's okay, then it's great. Unfortunately I couldn't so I left my job.
nice vid, angular dev here, waiting for @ThePrimeTimeagen reaction
This sounds more like a threat 😅
If you think RxJS is overused, you don't know why it's there in the first place...
you are right - I don’t 😅
@@awesome-coding Well, at least you're being honest. Partially... Because, I doubt you saw a large Angular codebase and failed to see what's their use case.
I'm just gonna put it like this... The whole "state management" thing, is a problem invented by "modern fronted development", excluding Angular. Angular just uses tried and true recipe to do this. Desktop (even game) development follows this pattern to a degree... So really, what it boils down to is this... Angular is far from over-engineered. It just gives you the tools to accomplish things other frameworks are sorely missing. And when you try and cram such solutions into them, THEY become over-engineered, instead of following that simple pattern.
@@cocoscacao6102 Hey! The biggest project I ever led on the frontend was an Angular based ERP system build for the medical sector. We had a team of 8 to 10 full time frontend developers for 2 years prior to the beta release, and for another year until the official release. We are now running in production for more than 2 years, with more than 1k institutions using our software. In the past 2 years we downsized to 5 frontend devs doing both maintenance and new features.
I'm not sure if this qualifies as a large project or not. I'm sure there are way larger code bases out there, but my guess is that most projects would be smaller than this one.
With all this in mind, I'm gonna stick to my previous statement - I don't really know why RxJS is used in at least 80% of the use cases.
Objectively, this is the way I see it. If RxJS was truly a compelling approach with clear benefits most frameworks would have followed along, but they didn't.
Remember that Angular 2 was the one who pushed TS as the default language instead of JS and A LOT of devs (me included) were outraged by that back then. However, everybody picked that TS up in the meantime, because the benefits were clear.
As a more recent example, Signals were (re)introduced as a concept by Solid, and now, 2 years later everybody under the sun (Angular included) are integrating them in their systems.
This is what happens with good ideas & truly useful patterns - they are copied like crazy by the competition, because they don't want to be left behind. Few people outside the Angular ecosystem are actually considering RxJS for their projects, regardless of the codebase size.
Either way, thanks for your feedback and input! Even though we might not agree, I find it really useful to try to understand opposing view points.
@@awesome-coding czcams.com/video/-CoVmNvp_1g/video.html
This is just the tip of the iceberg. All of those that were outraged by switching to TS... well... I wouldn't be proud to admit something like that, because such people for me fall into a certain category... One I wouldn't hire, ever. Because they spit on things they don't understand, without proper explanation on why. TS was forced upon everyone when there was no more escape from a certain problem. RxJS wasn't, because they found a (convoluted) workaround.
So do yourself a favor, and learn why it is useful.
I doubt the new signals update would do anything. Especially when most Angular enterprise projects are already on an obsolete version.
You're absolutely correct about Angular being over-engineered. It's a framework that tries to do something cool but really does it in the worst way possible. Out of all the modern frameworks, Angular is the slowest to write and the most difficult to work with.
I recently tried to upgrade my company project from Angular 8 to 12, I can only say that it was nothing short of frustrating and we ended up not upgrading. So yeah, thanks for nothing Angular.
On top of that, simple things like forms, shared component states are amazingly easy to implement in React but Angular... yeah no thanks. The documentation is also pretty bad, especially Angular Material, it's just awful!
So with Angular, you get a more difficult framework with less options for core design principles, less third party packages support, worse documentation and for what? 'Code consistency' for the juniors in the team?
The worst Hill to upgrade was 8 -10, after that the experience got much better.
@@TayambaMwanza Well, the breaking changes didn't help. Our styles are broken because something changed in angular material and many things look off now. Angular material is the worst UI library I've ever worked with!
@@mayanksharma6927 did you use the new components or Legacy ones? Because of you use e.g LagacyMatButtonModule the styles should be the same.
In fact building apps in angular is much faster than in react. Try to learn it first , and you will never go back to the mess called react
Another comment brought me back to this one. I Focused on your 8 - 12 comment, but I also wanted to add I think a lot of people came from old js mindset when learning Angular and used a lot of the tools incorrectly, I'm working on an Angular 8 project now and I can tell they skipped or didn't know about a lot of best practices which adds to the difficulty of the update, Angular is actually very good but if you don't take time to use it properly and end up with problems it's not entirely the frameworks fault, I'm sure people do the same thing with react, it's just harder to do with only react because it's just a view library.
If you write Spaghetti code is it really the frameworks fault?
I only say this because I'm in a project of similar situation to yours, but I also have and worked on a project that did things the right way.
So your perspective could be distorted because you've never worked on an Angular project that did things the correct way.
I started using signals for Angular it's great, no more async pipe and much less rxjs.
No
Angular is beautiful.
If you find angular hard, you are learning it wrong. I teach angular to undergrad students and they start the project on third day themselves.
Also I don't get how react fans say jsx/tsx is more close to native html. On the other hand any valid html will just work in angular without single change, in react you have to change 'class' to 'className' , write weird style that too with object syntax, weird tags. Everything in react is just bunch of workarounds. Condition and loops in react are weird as hell, with all those idiotic ternary operators and foreach callbacks. In angular everything feels natural, it's too beautiful.
If you find angular reactive forms hard, just create a data object and bind it's fields to form components. Its too simple.
Angular fill a template system, that's why html work out of the box. JSX is javascript + html, so is more like js with powers. In js/ts you have already reserved the keyword class, so you can't use it in the html. And yeah, they're too many ways to make React ugly lol.
It's this satire? No offense but people think 100% the opposite in special the "everything feels natural"
@@neociber24 Maybe Angular fans just want to suffer, is the only conclusion i can find.
@@neociber24 What's not natural in angular?
@@cipherxen2 It's mostly because Angular is not as straight forward as others frameworks, the idiomatic way of doing things in Angular is more complex.
For example fetching a JSON and render the content, angular require a service, RxJS, maybe importing modules, in React that's a single component using the native fetch.
I am not saying you can't do it in a single component in Angular, because you can, but it's not the idiomatic way people do it.
me, sharing my hate in the comments, despite not being an Angular fan
I appreciate it! ✌️
This reminds me a bit of the comparisons of programming languages.
There are clowns out there who think that Python, for example, is superior to all other languages because the comparison of a "Hello World" example is 10 times smaller than in other programming languages.
Since the hype was so great to simply write something like "print('Hello World')" instead of first preparing a whole class with an entry point called "main()", Microsoft also decided to create the possibility for C#, Execute top-level commands. As far as I know it was a flop and they removed it.
I hope Angular stays true to its line and doesn't try to follow every new trend. If there's one thing I've learned in my many years of development as a software developer, it's that the people who get upset that a language or framework has been completely overloaded are the same people who used to be in favor of building in all the features because other technologies have it too.
Haha - Java is doing something similar these days by introducing flexible main methods and anonymous main classes to the language. However, they are doing this JUST for learning purposes, probably mainly to make it easier for students.
The reality is that people are always attracted by simplicity. In software development, like in most other fields the barrier of entry gets lower every year (for various reasons) so you'll get a decrease in quality of dev resources and resulted output.
Languages and tools still have to compete to gain popularity, because you'll die without a user base. Angular is also following this trend - they allow you to build without modules, they are trying to simplify reactivity via signals, and, more recently they are proposing updates to their templating system.
Also, who's to say who is right or not, especially when there is no objective metric to measure what's a good or a bad language.
React is king
React is awesome, but React devs are overwhelmingly average. With all the advantages React has, they still tend to produce spaghetti code with unnecessary useEffect everywhere.
@@mfpears i'm a React developer and i totally agree with you.
@@oscarljimenez5717 me too
React is just glorified PHP.😂
I'm not sure if this is a pro or a con 😅 Honestly, it could be both...
no hope for analgular🙂
I fear that's the case as well :( too bad - it had so much effort put into it.
Maybe but it will still be used developed and maintained because it is too big to fail now. So many companies depend on it, if they keep innovating and pushing things forward it might actually succeed
Angular is bs ... I will never understand these people who make framework like this .. module , core modules , components, decorators , providers etc etc ... Wtf!!!!!!!
Why alllllllll the goddamn complexity why Why why ?! , It's better to use vanilla js !
DUDE ! seriously, get a grip please
- you cannot just create a pull on your channel, with your audience
and present this as any type of an evidence 🤣🤣🤣
The only thing that this pull tells is that - in YOUR audience there
are more people that do not use Angular... yeah 'big surprise'...
Come on, you must understand at least on some level, that if this pull was conducted
on a channel that focuses on Angular the results would be - wait for it - in favor of Angular...
Your decision to even show such pull in the video made the whole video a lot less credible...
BTW I do work with Angular primarily but I have also worked with React,
Vue and Svelte enough so that I can make an actual comparison
and choose what works best for me.
That's the thing though... If you check my past videos you'll see that this is not a React focus channel either. The few videos I have on React are actually not performing very well, and they have a lower view count than the other ones.
Most of my content is on newer tech and frameworks outside React / Angular, with most engagement and views coming from Solid / Svelte and Qwik related content. So, overall, I believe that my audience is rather unbiased on the React vs Angular topic. I bet that if I'll do a pool on React, the results will be quite similar.
@@awesome-coding ah, ok, sorry then for my wrong assumptions... It's just seeing that option in the pull "No, I till hate it" I mean... why would someone hate Angular... what has Angular done to anyone ;) I don't use React but I don't hate it... I just feel indifferent about it...