Hacker News Reader

Comment by JoeNr76 | Hacker News Reader

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

View on HN

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.

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.

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.

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

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.

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

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.

Reply on news.ycombinator.com