My app is a big stack of workaround stuff that might break anytime. Because that is how angular work. Some stuff work in a context and doesn't in an other. Nobody's know why ! They have so much issue on Github that they need a bot to close them after a while. They hope the bug disappear by himself ?
I've been working with Angular2+ for 3 years and I haven't met any bug.
Know the concepts, apply them and you'll have an easy trip.
Translation: It's a framework that does less.
Give me a break, this isn't true for any code in existence.
There is software that's incredibly solid.
I have personally witnessed companies take guys who have been slapping together "apps" in jQuery / .NET for the past 10 years and tell them "it's time to make the stack modern" and "we're going with Angular because we're a Microsoft house".
Things go very bad very quickly.
If you don't take the time to understand the Architecture behind scalable modern web applications you're going to have a bad time.
Anyone can slap together a quick and dirty app with Angular or React - not everyone can scale one correctly with thought given to the architecture behind these applications.
Neither of those is Angular-specific. In fact, of those you mentioned jQuery is the library with the unusual, idiosyncratic concepts.
I don't think Angular is a bad choice across the board, but you need to weigh this heavily when deciding to use it.
Is ms invested in Angular?
It's a Google project, isn't it? Is it first-party in dot.net? I though that was Blazor?
Microsoft also supported Angular early on as it was one of the largest early adopters driving folks to Typescript.
Before Angular, those developers would probably have chosen Knockout.js instead.
Yet I agree, a lot of things in my project is wrong and maybe blaming the framework for the mess is too easy. But I really do not enjoy working with Angular. Also, learning to use RxJS was a painful experience full of frustration.
I have a backendService that use the httpClient; it's a wrapper that automate stuff to make API request. I guess it's pretty common. I have a provider for APP_INITIALIZER. It can use the HttpClient but not the backendService. The backendService work everywhere else of course.
Join us, you’ll enjoy the ride!
Did you try to actually upgrade the react version? Lots and lots of breaking changes in that time, some really major ones along the way. Especially when upgrading react also forced one to change router etc.
An Angular 2+ app built in 2016 (when Angular 2 came out) wouldn't build anymore.
An Angular 1 app didn't even need a build step, so that would probably still work fine.
In 2016 React was on version 14. Are you telling me that from version 14 to 16.12 React has had ZERO breaking changes? Because they definitely haven't. That ecosystem has also changed recommended patterns countless times. They just choose to leave a lot of the old implementation options around if they can while Angular as a frameworks tends to be more opinionated.
Same goes for any library or framework across major versions...
Nobody claimed that stuff which has been built and never touched again stops working.
> In 2016 React was on version 14. Are you telling me that from version 14 to 16.12 React has had ZERO breaking changes?
No, I'm not saying that. If they had zero breaking changes, I would have said exactly that, it would be remarkable.
Nevertheless, there have been very few breaking changes in that timeframe[1] and they are highly unlikely to affect if you're doing ordinary stuff.
[1] https://github.com/facebook/react/blob/master/CHANGELOG.md
> Because they definitely haven't. That ecosystem has also changed recommended patterns countless times.
You can just ignore the "ecosystem". You don't need it. React pretty much only does one thing. It doesn't impose an architecture on you. If you want to go all-in on the ecosystem, maybe it's as bad or worse than Angular. That's besides my point.
> Same goes for any library or framework across major versions...
No it doesn't. Some or even most people working with Javascript are completely out of touch with software engineering practices outside of the web bubble. Breaking changes are supposed to be avoided at great cost. Of course there's no real incentive for that if you're a random person pushing something to npm, or if you're Google and your business model is selling users instead of software.
So no, I didn't enjoy the ride, at all.
Well-managed react is incomparable in power. Try to make a library like react-three-fiber using Angular, in less than 500lines of code.
Unfounded opinion.
> Try to make a library like react-three-fiber using Angular, in less than 500lines of code.
react-three-fiber is much bigger than 500 lines of code.
And no, the initial implementation which was just as powerful (but lacked typescript typing) was mostly 2 files of 250 lines of code each. Look it up.
I am waiting for the angular or vue counterparts. And also the angular and vue equivalents of react native.
Based on personal usage of React, it's no easier than angular or any JS based framework like Vue (which in my view more sensible than react). You add state management, templates, router and 1000's of npm packages to do anything simple and react soon becomes an unmaintainable nightmare with emany vulnerabilities if you do not upgrade. An app is not just simple react but many of the npm packages (although it's true in general for JavaScript eco-system which is by default is insecure and maintenance nightmare unless there is an extra amount of work done to secure it).
Angular at least provide a decent complete single framework to work with and a unified documentation, there are issues with it, but react is same when you need any reasonable size app from it.
React gives you an easy start with false sense that it's easy, than becomes just too convoluted and complicated with the addition of different components as soon as app starts growing. Maintaining and upgrading apps based on react is very difficult as one version to another it introduces breaking changes. Angular had similar thing from angularjs to angular 2, but slowly they made it much better but letting compiler do more work.
Ivy tree shaking compiler will give a fight to upcoming compiler framework like svelte and keep the size smaller and may be in some cases much smaller than react app bundles, will wait for the benchmarks and size comparisons.
I am still waiting for a simpler way of developing web apps, elm looked very nice, but it is still far from ready for use in the same way as Angular or react yet.
It feels cleaner and more solid.
I mean I hear what you're saying, but Angular is an opinionated framework whereas React is not, and many people end up reinventing the wheel (or an application framework) in the process. There is value in being opinionated.
Yes there is value in being opinionated, but it is less risky to decorrelate the opinion from the foundation. There are opinionated frameworks built on top of react and it is very nice like this. But react itself should not be opinionated.
The team that eventually took it over and grew around it recognized it had some problems scaling and being used for large applications. They knew they couldn’t just change angular 1 to be what it needs to be, so they made a big switch. They put in patterns that benefit large apps, typescript, observables, the choice of two way binding or one way binding, better DI system.
Everyone says react isn’t opinionated, and for developing an enterprise app that just sounds like a nightmare.
ng update is ridiculously easy, and the automatic code rewriting is generally sensible and easy to follow. When there are breaking changes, Angular takes care of the modifications for you. Generally I've felt like those changes resulted in a better expressed codebase (eg RxJS syntax improved massively from 5 to 6, lazy loaded routes are expressed with arrow functions now, etc).
I assumed the React community was also migrating versions with codemods, but maybe React does not introduce any breaking changes?
This is, at the very best, very debatable.
In my experience, it's the very opposite. Angular gives you very solid foundations as it's a proper framework that ships everything you need to build scalable apps. So you start from something small, and as you grow you know you can do so without rethinking the foundations of the app, as they are provided by the framework, which is Google guys, which means most likely people with a lot more experience than the average front end dev.
On the contrary, react leaves basic choices (the bricks you mentioned) to the user. While freedom can be good, it also implies that errors will be made, so you are a lot more likely to build on shaky foundations.
Choice to pick the best of breed solution to each smaller problem within the context of building an enterprise grade web application is at the heart of React. I get to look at all published routers and choose the one with the most intuitive API to me: I get to look at bundle sizes, and consider trade-offs.
Instead of spending all my time analyzing different open source packages for every single thing you do, you just have access to a first class supported solution.
IMO, lots of the react ecosystem is built on engineers trying to show off. They get fancy coming up with a solution, writing a unique library, and there’s no reason for this. Everyone likes to think their code is unique and special and great, but it’s not. We don’t need to reinvent the wheel all the time. So many of these apps are going to need to be rewritten in a couple years because of how poorly architected they are. That’s not a problem of react, but it’s a problem of react devs who take a small view library then build a framework on top of it.
I wouldn't characterize my time in React spent "all day comparing open source packages" -- if that's what you think web application development on React looks like on a day-to-day basis, you haven't done much on it.
To be clear, I do not intend to speak negatively about Angular. Some people love the provided structure. It's also not for some other people. This is okay. Different things make different developers happy. I wasn't generally describing all people's sentiment: that would be insane, both frameworks have huge backing. If you'd like to understand more about how some people view the framework as inflexible, and you're open to that perspective, I'm glad to shine some light on it.
A lot of comments state angular is inflexible and opinionated, but come from people who haven’t used the framework. They think your forced to do a lot of things where angular gives you choice.
I haven’t done much react development, but my significant other has and multiple members of my team have as well, and I’ve heard them discuss how when you need to find a package to pull in it’s a decision that involves searching and weighing the pros and cons much more then for angular.
I don’t hate react at all and totally understand its pros and how I think it’s a net positive on the web development landscape. It’s more that this site is extremely react focused and biased, and the US dev community is also that way. So angular gets called out as being something stupid to use that’s cumbersome, slow and big, but that’s just simply not the case. Example of angular app being smaller and faster then comparable react: https://www.freecodecamp.org/news/a-real-world-comparison-of.... I know these comparisons are silly so I’m not putting much thought into it, just one anecdote.
Both are great libraries/frameworks with great ecosystem of developers, we all need to stop flaming each other and see the progress each community is making. It’s not a winner take all type deal, there’s plenty of room for both.
This has been solved by create-react-app. I'm working on a 10K+ LOC app now, and the only significant dependencies that aren't part of create-react-app or its docs are d3 and date-fns, which don't belong in a framework anyway.
This is just a bad idea: https://angular.io/guide/template-syntax Without writing the tooling to debug it, to this day there is not said tooling.
https://juristr.com/blog/2019/09/debugging-angular-ivy-conso...
You don't actually have to do that. React just turns your data into DOM elements, most of the time it's a simple transformation.
Otherwise, how you architect your application is up to you. You don't need to overcomplicate things by following the latest trends, you don't need a ton of dependencies to do simple things. You don't need templates at all.
Angular is complicated by default. It makes design decisions for you that you probably wouldn't have made, and then sometimes it reverts those decisions, making you clean up the mess. React code very rarely breaks.
> Ivy tree shaking compiler will give a fight to upcoming compiler framework like svelte and keep the size smaller and may be in some cases much smaller than react app bundles, will wait for the benchmarks and size comparisons.
Angular bundles are huge by default, it has a long way to go. Tree shaking already works with React, you just need to set your build up that way. Also, don't assume that a compiler will make your build smaller, it may well inline a lot of stuff and end up larger.
Unless it's doing unsafe or nonstandard stuff in the first place, like idk, cross-domain requests or weird stuff with iframes or whatever it was Google tried to do when it added an extension that tried to do preloading and stuff like that.
By all means, upvote criticism that is properly argued and backed up with evidence. But upvoting these kinds of comments is the equivalent of posting anti-vaccination memes on Facebook.