Circling Back to Angular for Another Look

After spending some time on MongoDB University to learn the basics of the MongoDB NoSQL database, then how to connect to one from Node.js code, I think I have enough of a basic understanding to tackle simple projects. It also completes my basic exposure to the entire “MEAN Stack” for bulding web applications: MongoDB, Express.js, Angular, and Node.js. Emphasis, however, on the “basic”. Going through a bunch of tutorials isn’t the same as being to put tools to work. I went through Angular some months ago, but there were too many unfamiliar topics for me to absorb everything the first time around. But I’ve learned a lot since then. I had a HTML refresher where I learned about semantic HTML, followed by learning more CSS I never learned (or never absorbed) before, and then enough JavaScript courses that the language is actually starting to make sense. I felt missing this knowledge earlier prevented me from usefully deploy Angular.

Part of the problem was that Angular is a big package which is highly prescriptive or “opinionated” on how each part would work with the others. This has advantages for a beginner because I don’t have to think about evaluating and picking from multiple alternatives, but it has the disadvantage that a beginner has to learn it all. With so many tightly integrated components, as my learning started falling behind, my understanding also started to fall apart.

Would I be better off learning another platform now? I contemplated learning React, which has a lot of coverage on Codecademy. I haven’t taken any of those courses yet, but I’ve read React is more modular than Angular. For some components we can start with something simple while we learn why we might want to substitute with more complex and powerful alternatives later. Further on this scale of flexibility is Vue.js, which advertised itself as something tailored for incremental development. It’s not just we can substitute components in Vue.js, we can go without them entirely if the project doesn’t use it.

As tempting as it might be to go after something new and shiny, I feel I will get a lot more out of Angular if I take another look. Or at least, have a better understanding of its tradeoffs before I go after something new and shiny. Reading my notes from earlier, I can tell I already understand some problems better than I used to. Example: Angular’s Tour of Heroes tutorial introduced me to the RxJS library which is Angular’s opinion on asynchronous JavaScript. Initially, I had no idea what I was looking at. But as the tutorial went on, I started seeing its benefits. Now, with my latest JavaScript courses, I understand RxJS was a solution to make asynchronous JavaScript things like Promises easier to work with. Unfortunately, it was a solution that predated official JavaScript adoption of async/await. So RxJS “Observable” mechanism doesn’t quite line up with async/await. This might be one example where Angular’s architecture holds it back: it is tied to pre-async/await RxJS and other platforms (React/Vue/etc.) may have an easier time adapting async/await. Is that important? That I don’t know yet, but at least I’m starting to understand more of the picture.

Before I dive back into Angular again, I have one more hole I thought I should fill: it uses TypeScript to tame some of the wildness of JavaScript. And now with a better understanding of JavaScript, I think I can get a lot more out of TypeScript.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s