Angular is a framework if you've hack you're way without following best practices you expose yourself to such things.

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.

Almost every problem I've seen with Angular involve people not knowing how to implement features correctly or using it for what it wasn't meant to be used for. You know, the same problems people have with all frameworks.

The problem is there's so much you need to know. Angular invented a custom feature with plenty of boilerplate for every task -- and if you want to do something that Angular doesn't explicitly support you'll end up fighting the framework very quickly.

Use things like Svelte. It's a framework that lets you hack. You don't need 'best practices'.

>It's a framework that lets you hack.

Translation: It's a framework that does less.

This isn't a bad thing if the things the framework does aren't terribly useful for what you want to accomplish.

why in the world would I want a framework that lets me hack?

"I've been working with Angular2+ for 3 years and I haven't met any bug."

Give me a break, this isn't true for any code in existence.

I work with GCC since 1996 and I never encountered a compiler bug. Whatever I wrote, the program always ran as it was supposed to run (even if it, more frequently than I'd like to admit, it didn't do what I wanted it to).

There is software that's incredibly solid.

I haven't met a bug related to the angular source code. I've obviously seen bugs in my projects

I've been doing Angular for 5+ years now. I think you might be using it wrong because I never experienced anything like that.

Angular has a lot of unique concepts that people find difficult to wrap their heads around. The Observable pattern, decorators, typescript, etc. When you throw things like NGRX and effective management of state / side-effects in the mix; things get exponentially more complex and difficult to scale.

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.

Agreed. "Unscalable" code is completely possible to write in Angular or React. Simply put, it's bad code that doesn't follow the paradigms of the framework it lives in, with all of the usual suspects (spaghetti code) sprinkled in.

I haven't done much with Angular 2+ (I use Vue now), but in my Angular 1 days, I've definitely seen a lot of Angular apps that were basically put together like a jQuery app. Massive controllers, lots of dom manipulation and logic in the controllers. My approach at the time was that controllers should be as small and simple as possible, with most business logic, data models, communication, etc extracted to services. The controller should just connect the various parts, nothing more. But when you're used to unstructured jQuery, the controller is an obvious place to just put everything.

> "we're going with Angular because we're a Microsoft house"

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?

The architecture concepts behind Angular are very .net-esque in a lot of ways. It's often an easier transition for folks used to MVC style projects with a heavy reliance on dependency injection to wrap their head around Angular than some other SPA options out there so the two get related in this way a lot.

Microsoft also supported Angular early on as it was one of the largest early adopters driving folks to Typescript.

Angular is the framework of choice for most Java/.NET shops, because it is basically JEE/Spring/WebForms/MVC, but in JavaScript, besides being written in TypeScript which is quite appealing.

Before Angular, those developers would probably have chosen Knockout.js instead.

Would you recommend any resources to learn how to effectively build a scalable modern web app? I haven't worked with Angular for about a year now, but I didn't use NGRX or similar alternative and I distinctly remember that managing state for the app got progressively harder as the app got more complex.

yeah I think what people are getting at here is that there's often a large investment to figure out how to use Angular2+ correctly (and even a lot of the concepts from Angular2 have been improved upon with new features in versions 6-8). A lot of times it's not "bugs" but if you're not in a place where you can spend 8 hours a day learning the framework in addition to building your app, you're going to have to choose one or the other -- and that's where frustrations set in. I'm gonna choose "build my app" every time.

I don't think Angular is a bad choice across the board, but you need to weigh this heavily when deciding to use it.

> Observable pattern, decorators, typescript

Neither of those is Angular-specific. In fact, of those you mentioned jQuery is the library with the unusual, idiosyncratic concepts.

They are not Angular-specific, but they are required to know. That undeniably increases the learning curve. And the Observable pattern is decoupled from Angular change detection, so spaghetti coders can find themselves in especially confusing situations. I say this as someone who loves RxJS and typescript.

I m pretty sur the 2500+ issues on github are not all people using Angular wrong.

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 agree with you 100% here. I have been working in Angular for a long time and feel like I have a pretty strong understanding on how it works. Like you, I will not build another app with Angular (or any framework for that matter). I don't think I encountered as many bugs as you have, but I have spent too much time trying to figure out how to do it the Angular way or the RxJS way. With modules, web components, promises, and async/await, I feel like you can now write very clean code with just JS. So, that is what I am going to do going forward.

If you can write the app you need with "modules, web components, promises, and async/await" then you never needed Angular to begin with. And that's a good thing, frameworks/libraries are never the answer to everything and are a decision to be weighed carefully.

Agreed. I think the increased support for modules and web components across major browsers in the past year has really given me the confidence that I can go without Angular/React/Vue and still have a well organized project. I still really miss the binding and routing of Angular. But, that is a small compromise.

Do you have any examples? I've been doing Angular2+ apps for years and have not experienced this.

I also not experienced these problems.

I had many, but here is the first I can remember correctly :

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.

Meanwhile, the web apps I wrote in 2014 in react still work flawlessly.

Join us, you’ll enjoy the ride!

On HN in general there is a disdain for anything other than react, probably more people of Facebook generation and admiration of it's technology like open graph, react and few other products.

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.

Maybe the disdain comes from the fact that people don’t like getting a whole house (like angular) built on shaky grounds, but prefer a clean basic foundation (like react) where they can lay whatever bricks they like on top (routing, data management).

It feels cleaner and more solid.

Your argument is flawed with a very opinionative starting point, which is that Angular wouldn't provide a solid foundation.

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.

They are not people with more experience you are appealing to authority. The cold hard truth is that Angular got it so wrong the first go around that they had to completely rewrite the framework. The very reason was that a lot of the early guys where just out of school and built a framework on theory. If you contrast this with React, guys in the trenched trying to build applications at scale for FB, they where built with totally different mindsets. The FB guys understood the render loops that has been a pattern in UI since the desktop days and has stuck around because it works. To this day two way data binding and template based logic are both a dumpster fire, that cause unmaintainable code and side effects that cause debugging to be more difficult.

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.

...well...on THIS day there is said tooling. In Angular 9.

This is the most comprehensive document I can find on debugging in 9 and I still do not see a way to set a breakpoint in say a loop declared in a template. I may be missing something as I have not worked on an Angular project in probably 6 months. But I don't see template debugging I see being able to get reference to a component and then manipulate said component via dev tools.

https://juristr.com/blog/2019/09/debugging-angular-ivy-conso...

The real difference between the two frameworks boils down to developer happiness. In Angular, all of the choices are made for you. For some, the lack of autonomy and agency when writing Angular applications makes those developers sad. It's hard to take pride and ownership in your work when 90% of everything has been decided for you, and if you try to eject from the "Angular" way of doing this, you end up just writing bad Angular code.

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.

This is the biggest “meme” about angular and it’s so unbelievable wrong. It shows that you haven’t used the framework if you think all the choices are made for you.

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.

Unlike most people, I've written both Angular and React extensively: I've shipped both Angular and React web applications in enterprise settings.

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.

I was mostly responding to this line “ It's hard to take pride and ownership in your work when 90% of everything has been decided for you,” Which in my kind is just a weird thing to say and seemed to imply a general statement.

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.

> it’s a problem of react devs who take a small view library then build a framework on top of it

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.

"Built on shaky grounds" needs a citation and additional explanation.

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.

The churn between angular versions, stemming from the limitations and inconsistencies of two way data bindings and others, are what I mean by «shaky grounds».

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.

There is so little churn between angular versions. Angular 1-2 was a big change and they should have renamed the framework. But you have to understand how angular 1 came into existence. It wasn’t planned to be used by everyone, it was just solving some problems experienced by a couple devs and it spread like wild fire.

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.

I'm not sure what churn you are talking about, unless you mean the Angular 1 - Angular 2+ split?

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?

> You add state management, templates, router and 1000's of npm packages to do anything simple...

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.

Although Ivy will bring nice improvements all around, you won't see the 12kb bundle sizes you are talking about in this initial release of Ivy. `renderComponent` is the key that will enable that down the road in some fashion (you can play with it now), but I appreciate the teams approach to easing the framework into major changes like that.

I joined a company that had two fairly simple internal web apps, one in Angular and the other one in React. Both had been written and maintained by a number of devs, each on the task for a few weeks or months. Both had several issues and blunders that needed to be fixed. However, while the Angular app had a very obvious, predictable structure, with issues confined inside single components or services, the react app was a totally obscure jam of javascript and html with more javascript and more html interspersed within, tons of redux boilerplate and properties passed down three or four levels of nested components. The stuff was such a wild spaghetti mess that editing a form in a foreground modal made the text in a background static page jump around when the number of characters in the form was even.

So no, I didn't enjoy the ride, at all.

Anecdotal evidence. This is just the result of bad practices. React is less opinionated than Angular I'll give you that, so I guess that subpar angular might be preferable to subpar react.

Well-managed react is incomparable in power. Try to make a library like react-three-fiber using Angular, in less than 500lines of code.

> Well-managed react is incomparable in power.

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.

Opinion founded on several examples such as the react-three-fiber one I just gave.

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.

Thank you, but I m done for the frontend shit for a while. I will be perfectly happy throwing JSON to other frontend dev.

Are you suggesting that angular apps written in 2014 would not still be working?

I don't think so, the point is that Angular breaks user code often, whereas React rarely does.

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.

lol it would work fine. I've had a joke app running Angular 2.0 in production for years. The code doesn't just expire and break. If you upgrade to Angular 8 in your package.json without running the upgrade schematics, yes it will break...because there were breaking changes.

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...

> I've had a joke app running Angular 2.0 in production for years. The code doesn't just expire and break.

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.

I wouldn't expect anything else to be honest; as long as the underlying JS / HTML does not change, anything written 10, 20 years ago should still work now. Browsers (= your application runtime) are pretty good with backwards compatibility, and not touching your application should not break things.

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.

One day, all Meteor.js apps went blank in production (you'd just get a blank screen) due to a change in Chrome, that required everyone to upgrade (albeit, a non-breaking change, so it was easy to accept). I had been building an enterprise application on top of Meteor. The outage caused a huge lack of confidence among my customers.

The Angular1 apps I wrote around that time are still running as well. The question is about maintaining them.

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.

i have a 2013 backbone and 2015 react still working in production.

What framework would you use to avoid those workarounds (or others in different parts of your app)?

I want to move away from the frontend job et do backend stuff. I really hope to stay away from javascript for a while.

I find it deeply ironic that, judging by the stories regularly posted and upvoted, Hacker News readers supposedly value science, rationalism, evidence-based thinking, etc. Yet the same people reliably upvote these kinds of toxic, detail-free, ungrammatical, emotional rants.

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.

Self-proclaimed skeptics are rarely skeptical about their skepticism.