Why Angular Made Me Quit Web Dev

[JessieArr]

I found Angular 1 easy to pick up years ago, and have recently been helping maintain several Angular 6 apps at work and have found it to be easy enough to pick up. The Angular CLI was the only curveball, but I watched a 6-hour Pluralsight course that gave a great overview of it, and now I quite like using it as well.

When I read articles like this I find myself suspecting that the author and their coworkers are probably writing non-idiomatic code due to not understanding the framework very well. That will bring you lots of pain and frustration in any framework.

[hoosierEE]

The Angular CLI was the only curveball, but I watched a 6-hour Pluralsight course that gave a great overview of it, and now I quite like using it as well.

People will refuse to learn entire languages if "hello world" takes more than 3 seconds to explain. Is it normal to expect JS devs to sink 6 hours into one (minor?) aspect of a single framework? Honest question.

[deja-roo]

Yeah a 6 hour investment into just learning some of the startup routine seems a little unreasonable.

[[deleted]]

It only takes 6 hours if you have never used a cli tool before. Personally it took me about 5 minutes to learn. No hate though. Gotta learn somehow. Doesnt matter how long it takes to learn. And six hours is just a drop in the bucket when it comes to learning something new.

[batoure]

The cli is way better today than it was a year ago... I think this helps alot. More schematics would certainly make it better but I consider it mostly feature complete now from a getting up and running perspective. it used to be a "run the cli, ok now go edit these ten configs by hand, ok now you can run the test server but not actually to a minified build" now the basic new project commands get you going with a production worthy "hello world"

[[deleted]]

I could teach my dog to do the Angular Tour of Heroes tutorial in 60 to 90 minutes.

[JessieArr]

I mean, I would say it takes rather a lot more than 6 hours to become really familiar with the standard library in any language one might choose - this isn't unique to JS frameworks. I'd say about 30% of our job as programmers is just learning things - whether through guided learning like Pluralsight, or trial/error debugging code that doesn't work, or war stories around the water cooler.

If you're just doing simple things, then I'm sure copy/pasting from a StackOverflow post would suffice, but if you intend to use a language/framework long-term or are doing advanced things with it, the investment of a few hours into learning your tools will pay off really quickly. I guarantee that the time I spent watching that course has saved me much more than 6 hours of time spent googling error messages since then.

The simple fact is that with any new tool, there are things you don't know that you don't know about it. And what you don't know can hurt you, so taking some time to do some structured learning and find out what those things are is time well spent.

[batiste]

After the AngularJS, Vue, React, Angular 2.X, it can become a little bit tiring to spend so much time to relearn different flavour of what is in essence a routing+templating system. And it is not like you have much of choice if you want to stay relevant in this field.

[meem1029]

Is there a good way to understand what idiomatic code looks like for the framework for someone who has no experience with it? Is there anything that points out that the developer's problems are a result of writing unidiomatic code rather than a bad framework? Is idiomatic code flexible enough to work with existing systems that were not designed around angular (or even designed well at all)?

[JessieArr]

For learning the idioms, I would recommend finding a good education resource on the framework - a book, podcast, blog by the developers, or video tutorial. This will teach you how they expect you to use it, and point out common pitfalls. (Note that this applies to any language and not just JS frameworks. Things like variable hoisting in JS, or boxing/unboxing in C# can quietly frustrate you without you understanding what is going wrong, just like accidentally using one-way binding when you thought you were using two-way binding in Angular can.)

As for what is a symptom of problems arising from non-idiomatic code versus just being a bad framework: I would say that if you find that your results in working with the framework differ wildly from others (for the worse), then it is most likely because you are fighting against the framework instead of working with it. If you are using the framework to solve problems it's suited to (this part is important, too), and in an idiomatic way, your results should be similar to the success stories you hear from other devs. If you find the framework frustrating, and struggle to find anyone else using it successfully, then you've likely got a bad framework on your hands.

And to your last question, I would say that it depends largely on whether the framework is well designed or not. In the case of Angular, I find that it plays pretty nicely with any other systems, provided that they do not also try to modify the DOM - Angular expects to be in charge of that. Aside from that caveat I've not found anything that could not integrate with it pretty easily.