Hacker News Reader

Comment by Jenk | Hacker News Reader

I have been a developer for 20 (e: I've just realised it's actually just over 25 years..) or so years now. I've attempted to "learn" Angular multiple times. I just can't do it. I get mental fatigue within an hour of picking up Angular CLI, or even just watching/reading tutorials. It speaks a foreign language to me.

And I've got years of React, Vue, vanilla-JS as well as Java, Kotlin, Scala, PHP, Smalltalk, Go, Rust, .NET (and the various flavours that comes in) under my belt. If I put some effort into it I could probably regurgiate some Cobol, RTF, and other now-forgotten stuff, too.

But Angular? I just .. can't.

View on HN

Are you really talking about angular or is it more about rxjs/observables ?

Because the former is really hard to imagine with what you claim to be proficient in.

The reactive stuff from rxjs is another story though, few people I know really worked with any of the reactive libraries before and mostly everyone I know struggled with the concepts at first, no matter which language they were using them in

I'm absolutely fine with rx* and observables. I was an early (but very minimal) contributor to many of the rx* family of libraries, even. I basically adore the pattern.

But I didn't even get that far with it. I don't think I could even accurately describe what an angular component is.

Angular CLI is definitely the biggest cause of my confusions.

This really isn't a fair statement to make because Angular without RxJS and Observables is nothing. The core http library is based on observables. If you forego observables, you're using very little of what makes Angular useful.

IMO using Observables instead of Promises for most API-type HTTP calls causes more harm than good. i.e. if you pipe the observable into an async pipe in more than one place, it does more than one HTTP call. I find in Angular code having my services that do HTTP calls return Promises via .toPromise() is much cleaner, and enables async/await and try/catch. Also with Observables, you have to remember to unsubscribe if you manually subscribe to the call, implement OnDestroy, etc. No need to worry about that with Promises.

Observables are great for other things though, like debouncing input, timers, @Outputs, etc. where there might be more than one result produced. They're awkward compared to Promises for single-result futures.

Yeah, Angular uses RX Observables so terribly and its HTTP module in particular for using Observables as "heavy weight Promises" does so much injustice for the entire ecosystem. People using Angular treat Observable subscribe() like it is just a bad non-conforming Promise then() in nearly every project including examples baked into Angular's own awful documentation and many "Production" libraries out there. Those bad habits are just so entirely persistent across the ecosystem that you just about have to assume every dependency is a memory leak (including Angular team's own CDK and Material libraries!).

I've made PRs to things to push them to use .toPromise() at least when they want Promises.

I was angry for days when I finally discovered where they buried AsyncPipe in the documentation (letting the template language automatically manage subscribe/unsubscribe rather than all bad habits of every component for themself and all the boiler plate for OnDestroy). Something like that should have been the default in the template binding language, not hidden away in a closet in the basement of the documentation. But they buried it because they never really committed to RxJS in the first place (such a huge dependency to half ass) and would have to teach things like shareReplay and hot versus cold Observables if they were to recommend AsyncPipe more strongly and/or make it the default it deserves to be (if they were actually committed to RxJS/Observables).

(React's been on a multi-year journey to towards Suspense/Concurrency and waiting for some updates together before scheduling them/Scheduling some DOM updates on requestAnimationFrame versus others more immediately that Angular could have done it so easily with a couple RxJS operators at template binding time if it had been intelligently designed with good defaults! It's amazing how hard they have instead worked to sabotage everything about the RxJS ecosystem in Angular.)

There's too many leaky boat escape hatches from RxJS and the few core libraries that make use of RxJS make use of it so poorly as either heavy-weight Promises or heavy-weight Node Classic Event Emitters (and bleeding Subjects/BehaviorSubjects everywhere across API boundaries which are their own violations of RxJS best practices). As an RxJS fan going into Angular it just makes me weep.

Thats true to a degree, but the distinction makes sense to me because angular is not the only project using reactive concepts.

RxJS is just one of the implementations [1] and people that haven't grokked it would struggle with other project utilizing it as well - even if its a React frontend, Go backend etc. (and as others have pointed out: angular should not be considered a poster-child of reactive programming. they made it work somehow, but its really easy to get memory leaks even if you're just copy-pasting code from the official angular docs)

- [1] http://reactivex.io/languages.html

One of my projects for work is RxJava and I’ll never touch anything Rx again. I don’t see any benefit it brings outside of making your project and control flow convoluted.

That's unfortunate because reactive programming shines when you have continuous data flows and want to run pipelines against them; whether that's clicks, websocket events, queue items, etc.

I work with rxjs and its a breeze to work with. My data flow got only complicated after introducing redux-observable.

  document.addEventListener("something", event => { /* blah */ });

is no different.

Nor are Java streams or .NET linq.

Java streams don’t infest your project. They also don’t throw away the error system of the language. They are also leagues more maintainable than a reactive project.

Ignoring the maintenance issues, reactive applications do not yield better performance on realistic I/O-bound workloads: https://julien.ponge.org/blog/publication-performance-and-co...

So all you end up with is less maintainable code and more developer headache.

I feel the same way. I just get stuck on trying to understand what actual problem Angular is trying to solve. Like, ok, it's a framework but... a framework for what? Webapps? Javascript is a "framework" for webapps, too.

When I first saw jQuery, I could understand the appeal, but Angular just seems like a lot of extra code for the sake of having extra code. (Like Spring...)

Angular is a framework for single-page applications, based on components with templates. If a property of a component changes, the rendering is automatically updated by the framework. This is supposed to free you from direct DOM manipulation and let you focus on the business logic.

Angular is somewhat similar to React and other SPA-frameworks, but Angular takes more of a kitchen-sink approach and provide its own dependency injection framework, URL routing, HTTP client abstractions and so on.

In comparison jQuery is just a library, it doesn't really care how you structure your application. jQuery makes it a lot easier to manipulate the DOM, but something like Angular is supposed to free you from having to manually touch the DOM in the first place.

And JavaScript is a programming language, but you probably already know that.

> JavaScript is a programming language

Ok, fair enough - JavaScript + DOM is a "framework" for creating webapps.

Yeah you can say that - the browser environment with DOM and other Wep API's is a framework for client-side apps. Single-page application frameworks like Angular, React etc. are frameworks on top of this, which provide higer-level abstractions and tools. Whether you need these higher level abstractions depend on your use case.

If you have lots of in-page DOM mutation in response to user interaction or data from the server, a SPA framework might simplify things. For a site like HN with very little in-page DOM mutation it probably isn't worth the complexity.

So you could certainly write your own component framework, state propagator, router, module framework, build engine, and more. But you'll probably find that, at the end of it all, you have a SPA framework you can share with us. If you're just doing simple web pages maybe you don't need all that, but some types of applications do.

I don't understand how can you not get Angular if you have .NET (assuming C#) "under your belt".

Not OP but feel the same way as OP... I can use Angular just fine, it just feels like I'm working around the Angular part trying to get down to the actual stuff I'm trying to program. Whenever I do use it, I spend most of the time thinking, "I could do this a lot faster in Javascript without Angular adding extra steps along the way..."

Why do you think that is?

Honestly I'm not sure if there even is a big reason.

The terminology doesn't feel right - I feel like I need to constantly remind myself what some of the terms mean compared to what I am used to, which I find occupies a tremendous amount of my cognitive capacity.

"The tutorials are shit" doesn't help. They really suffer from the problem of the author expects the reader(s) to know what it is they are being taught ahead of time. "Tutorial 1: how to make a component. Step 1: Run `ng component <name>`. Now you have a component." type deal. Now I'm left to my own devices to find out what a component really is, etc.

Another part is that it just isn't very exciting. I was/am more excited when using react or vue.

I've been maintaining angular apps (albeit lightly) for nearly 2 years at my current role, but even here react is being introduced to replace it.

I tried to pick it up 5 years ago or so and my main barrier was that any tutorial, even the official Google ones, was long obsolete and their examples would fail out the gate ... but I guess that's to be expected of frameworks in tech.

Reply on news.ycombinator.com