Hacker News Reader

Comment by gitgud | Hacker News Reader

The only thing I like about Angular is the dependency injection of services. Having "services" managed for you and just picking and choosing what you want is pretty nice.

What I don't like is the verbosity and boilerplate... here's 2 examples:

- Routing boilerplate is convoluted and time consuming. I think Nuxt.js has a much nicer implementation of SPA routing, where the filesystem is used to map the routes.

- Angular modules are verbose, redundant and don't even truely encapsulate dependencies anyway. You can easily create implicit dependencies by relying on services instantiated in higher level modules.... which is bad

I love using Typescript though!

View on HN

Another benefit in my mind is that Angular is "batteries included" - you get everything you need in a single library, e.g. routing is a big one.

From what I understand of React, you need to pick and chose the libraries (and versions of those libraries!) to use for your app, and then keep the versions of all the different libraries up-to-date and in sync with each other. Sounds like a maintenance nightmare.

It has probably been improved since I last tried it but this is one of the reasons I picked Angular over React. Having a router, HTTP client, forms, i18n, etc. out of the box compared to having to find/evaluate/integrate/maintain the various libraries that build on React to get the same functionality was a great benefit.

The other reason is the first class TypeScript and RxJS support.

Then again, that is what might lead to the boilerplate. I've been out of Angular for a while, but was kind of following along around the release of v2, where they went through about four routers, I think. GP mentions mapping routes to the file system, but then how are you going to accommodate a route pointing to a modal inside another route, identified by its hash? By having one blessed implementation, they also feel forced to support every potential use case.

> you need to pick and chose the libraries

I've seen people tout this as a benefit for certain ecosystems for years and years and years, and I think it's a big bag of crap. Maybe if you are ultra talented and ultra disciplined, it's possible to stay on the ball and make things work when you are gluing together disparate pieces and shaving an untold herd of yaks.

But for mere mortals, having sensible defaults and pieces that were designed and built together is wildly more productive.

I was more amenable to the libraries-not-frameworks argument a decade or two ago, when release cycles were once or twice a year, libraries were mostly independent, and granularity was much coarser. Now it's just too goddamn much work to keep things sane. I do not have time to dedicate a day a week to troubleshooting why updating package X has pulled a new dependency on library Y, which is incompatible with library Z.

> then keep the versions of all the different libraries up-to-date and in sync with each other

Not really, since by design React doesn't care. You can use a years-old version of React Router without any problems.

The great thing is nowadays you can use Typescript for React or Vue very easily :-)

Reply on news.ycombinator.com