3 ms·

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

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

by ng12 7y ago

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.