Skip to content

I just finished Angular’s introductory guide. Here are my thoughts.

Here are my thoughts on Angular after I complete the guide provided at https://angular.io/. This is my third attempt sitting down and trying it out.

I’m not a big fan.

But hang with me here, I’m not setting out to just gripe about Angular. I want to process through the things that I find just aren’t my preference and try to articulate why. And I want to give an honest evaluation about what I think does work. If I am overly critical, comment below and point me to some good resources or examples! I’m open to see why Angular has become a modestly successful framework.

And I haven’t written a comparison of JavaScript frameworks, really. I need to participate in the obligatory topic since I’m trying to contribute to the JavaScript literature ?

So here are some of my (yes, admittedly off the cuff and very initial and probably pretty disordered) thoughts…

Angular.io feels tiring to create new things

I have said many times before, and I will repeat this as a major drawback with Angular: there is so much ceremony with creating anything in Angular. I have jokingly compared it to signing a mortgage when I want a new component.

If I understand correctly, to get a new Angular component you need to:

  • Add it as a declaration in NgModule by importing and adding it to the declarations array
  • Create a css, html, and ts file for the component
  • Create a class for the component that implements OnInit
  • Decorate the class and point the class to the correct selector, templateUrl, and styleUrls

Compare that to Vue.js:

  • Create a component.vue file with template, script, and style tags
  • Import the component into the file of the parent component you want to use, and add it to the components tag in that parent’s config object

Or React.js:

  • Import the component that extends React.Component (or a simple function depending on if it’s a SFC) in the component you want to use it
  • Use JSX to call the component in the render function

In the guide there were many places where it instructed you to “use the generator” to generate component files, which was handy and seemed to cut down the amount of boilerplate that needed to be typed out.

But it does seem that when you get to using things like generators as a routine part of creating things, I feel like something’s too heavy. The sheer amount of code that seems to be near carbon copies was surprising.

On the other hand, it appears that no matter where you are in the angular app, you can call a module once it is registered. So this seems to be a step up from Vue, where you need to call out whenever you’re going to use a component.

Files are more spread out

It seems these are the critical parts of an Angular app:

  • main.ts – In charge of bootstrapping the app
  • app.module.ts – In charge of organizing larger “units” of the app. Here is where you import your Angular things, declare components, provide services, and bootstrap to a particular tag
  • app.component.ts – Appears to handle displaying the app root. The same thing is seen in Vue and React, but it has its own css and html files
  • Component folder – Holds ts, css, and html files. I feel very mixed about this separation, but I understand that this is

Maybe this is just my preference from being used to seeing CSS-in-JS and Vue Single File Components, but I’m not a huge fan of all this separation. While doing the guide, I was overwhelmed by the number of folders and files, and the guide wasn’t making anything particularly complicated. I had so many files open so quickly.

Having services as a part of the framework is nice

I liked the fact that services are a part of the framework. I also like that the services can be injected when they need to be.

I also like how you can create your own modules, and they feel very close to the MVC style of organizing data in models and collections. And this is made easier by utilizing Typescript.

At the end of the day it’s pleasing to say collection.get(id).

Having a router as part of the framework is nice

Often people will say that “(vue/react) isn’t a framework because it only is in charge of the view.” Meaning that it only handles the V part of something like MVC.

This is true. React has admitted that it only handles the view, and Vue is named… Vue.

And this is true in particular with Angular when we talk about routing. It’s included (well, you still need to import it.) And It even has a form builder that abstracts a lot of the work forms usually take, so Angular does a bunch more than Vue or React.

But I’m still feeling a bit mixed about this. Having vue-router or react-router as optional is a great. Being able to have finer control over forms may be desirable. I’m just not sure that for something to be called a framework it really needs to have it’s hands in everything.

I like observables… but not that much

Angular uses observables, which is a cool way to handle data. The Http module from Angular returns an observable by default. You can do some cool things that you can’t do with promises, like cancelling a request. The mind shift between a constant stream and a resolving promise might help solve a lot of problems.

It appears to be a bit heavy handed though. From those who are deep into Angular and have used observables regularly, I often hear about confusion and frustration with them.

I think I would need to work with them more extensively to say more than that. But my hunch is that observables solve a problem, just not the problems that most web apps have.

It’s out of my system now

This is my very unplanned thoughts on Angular: a comparison that’s very opinionated and is subject to change.

I would love to hear from you about what you think Angular’s strengths and weaknesses are. If you are an Angular dev, please don’t hesitate to set me straight.

Leave a Reply

Your email address will not be published. Required fields are marked *