5 ms·

I find it a little strange that you are pointing out comprehensive documentation on a module as proof of a problem with the framework... Lets talk about what y

I find it a little strange that you are pointing out comprehensive documentation on a module as proof of a problem with the framework... Lets talk about what you get with HttpClient: - Easy testing. Because its using the DI system, its very mockable. You can totally set this up with fetch or whatever behind a service but, well why? Its already done. - Robust type safety. Again you can set this up with fetch, but why? Its already done. - Integrated with rxjs/observables for data transformation, piping, and filtering. You can set this up with fetch but why? It's already done. - Discoverable API because of the deep framework integration and type intelligence. You can set this up with fetch buy why? It's already done. - HttpInterceptor is awesome for checking for things like auth tokens and such. You can set this up with fetch but why? It's already done. Not specific to HttpClient but: - AOT compiler means that unneeded code gets pruned keeping your bundles small. - AOT compiler means that you literally can't compile incorrect code (but it provides an escape hatch if you want to live your life that way) I can make this same argument for pretty much any module you throw at me. Like I said, Angular is _complete_. Is it the right fit for every situation? No! :) It's overkill for smaller projects but if you are building anything of sufficient complexity, you _will_ need all this stuff. The question is, do you want it to be something you had to roll yourself and didn't have time to document for your teammates or do you want something that did all the hard work for you and is ready for whatever you throw at it?

ng12 7y ago
I mean it's really not "already done" if you have to use all this boilerplate to get those features. > Robust type safety. Again you can set this up with fetch, but why? Its already done. Not sure what you mean here. Fetch has high-quality TypeScript bindings. For the rest it's mostly YAGNI. The boilerplate confuses new developers (try explaining what NgModule does to a junior dev just trying to build a simple page) and experienced developers know how to do this stuff themselves.
- vikingcaffiene 7y ago
  It's YAGNI until you do. Since we're busting out the acronyms a lot of what you are saying sounds like a case of NIH syndrome. :) I have trained junior devs on Angular and I think it's a fair criticism to say it's a steeper learning curve. They do fine tho and as an added bonus they get introduced to concepts like IoC and the like which sets them up for other languages. Experienced developers can set this stuff up its true. I have in fact. It's fun the first few times. Then you get annoyed and want to actually work on your problem domain. I'd much rather spend my time and brain power on that stuff. The apps that I've built that had an established pattern and all the infrastructure needed from go tended to age better and tolerate changes to business requirements. The ones where we rolled it all hodge podge needed more extensive refactoring later. I mean look: this really boils down to very different philosophies. You either go light and build as you go or go everything and the kitchen sink and deal with (what some would call) bloat. I think both have their pros and cons. No silver bullet and all that. You gotta look at the situation and make a call. The rest is just preference and gut instinct.
- paulddraper 7y ago
  > Fetch Angular uses an RxJS interface to XMLHttpRequest, which has a few advantages. For example, only relatively recently did fetch() (including polyfills) support cancellation. That said, there's absolutely nothing that requires you to use @angular/common/http. Angular created it because developers have to solve those problems over and over, but it's just a library under the Angular roof; you can use fetch() function instead.
marcus_holmes 7y ago
How come Vue doesn't need this stuff then?
- paulddraper 7y ago
  You need this stuff, but Vue use you will figure out their own individual patterns or reach for a different tool.
- avip 7y ago
  Possibly because vue does not have any builtin http capability... which is kind of the point GGP is trying to make up there. Angular is not overengineered, it's just feature-complete. vue is not "simple made easy", it just delegates lots of functionality to 3rd party, leaving the confused developer to read medium posts on the line of "axios vs. vue-resource". I prefer the vue way, but it's a subjective personal preference and should basically be ignored by others.
  - shantly 7y ago
    > Possibly because vue does not have any builtin http capability I mean, it does run in a web browser.

ng12 7y ago

I mean it's really not "already done" if you have to use all this boilerplate to get those features. > Robust type safety. Again you can set this up with fetch, but why? Its already done. Not sure what you mean here. Fetch has high-quality TypeScript bindings. For the rest it's mostly YAGNI. The boilerplate confuses new developers (try explaining what NgModule does to a junior dev just trying to build a simple page) and experienced developers know how to do this stuff themselves.

vikingcaffiene 7y ago
It's YAGNI until you do. Since we're busting out the acronyms a lot of what you are saying sounds like a case of NIH syndrome. :) I have trained junior devs on Angular and I think it's a fair criticism to say it's a steeper learning curve. They do fine tho and as an added bonus they get introduced to concepts like IoC and the like which sets them up for other languages. Experienced developers can set this stuff up its true. I have in fact. It's fun the first few times. Then you get annoyed and want to actually work on your problem domain. I'd much rather spend my time and brain power on that stuff. The apps that I've built that had an established pattern and all the infrastructure needed from go tended to age better and tolerate changes to business requirements. The ones where we rolled it all hodge podge needed more extensive refactoring later. I mean look: this really boils down to very different philosophies. You either go light and build as you go or go everything and the kitchen sink and deal with (what some would call) bloat. I think both have their pros and cons. No silver bullet and all that. You gotta look at the situation and make a call. The rest is just preference and gut instinct.
paulddraper 7y ago
> Fetch Angular uses an RxJS interface to XMLHttpRequest, which has a few advantages. For example, only relatively recently did fetch() (including polyfills) support cancellation. That said, there's absolutely nothing that requires you to use @angular/common/http. Angular created it because developers have to solve those problems over and over, but it's just a library under the Angular roof; you can use fetch() function instead.

marcus_holmes 7y ago

How come Vue doesn't need this stuff then?

paulddraper 7y ago
You need this stuff, but Vue use you will figure out their own individual patterns or reach for a different tool.
avip 7y ago
Possibly because vue does not have any builtin http capability... which is kind of the point GGP is trying to make up there. Angular is not overengineered, it's just feature-complete. vue is not "simple made easy", it just delegates lots of functionality to 3rd party, leaving the confused developer to read medium posts on the line of "axios vs. vue-resource". I prefer the vue way, but it's a subjective personal preference and should basically be ignored by others.
- shantly 7y ago
  > Possibly because vue does not have any builtin http capability I mean, it does run in a web browser.