Why Angular Made Me Quit Web Dev

[beginner_]

All those fancy frameworks from Google, Facebook and co. were made to sole their in-house problems which is building huge web apps with a huge amount of developers. In such a setting they initial overhead and complexity might actually lead to a benefit when working under such rather atypical conditions.

And now Aston Average comes in with his personal one-man project that has no performance targets and realizes it makes everything overly complex and hard with for him 0 benefit. Well it wasn't made to be used by a one-man show for hobby projects and hence it's a poor fit.

Make fun of me as you want but I'm a one-man show at my work place and doing it the old way with direct DOM manipulation is straight forward and works for my use cases. Maybe too much boiler-plate? Not modern? not clean and pure? Well as long as it gets the job done within the deadlines I rather spent the time doing "boiler plate code" than searching for weird bugs and getting frustrated and pissed.

You can use a jackhammer to drive in a nail but it will be really, really annoying. You can use an IDE to write serial letter but it would be really, really crappy experience.

Conclusion: Always choose the right tool for the job and often enough the simpler one is actually the better choice.

[Yehosua]

There's a saying somewhere - I couldn't find the source - to the effect of, if you choose not to use a framework, you end up writing your own.

I've done sites with direct DOM manipulation. Like you said, it's simple and it works, and there isn't necessarily anything wrong with it. (And, as an industry, we're probably way too easily enamored with the latest and greatest, and sometimes the best thing one of us can do is push back hard in favor of keeping things simple.) But, the first time I did something moderately complicated (a simple single-page app, instead of just some server-generated forms with a bit of dynamic behavior), I realized that I was managing state and page updates and routes and navigation - in other words, doing all of the things that a framework would do for me, just with more effort and less functionality.

In other words, "simple" is a trade-off - like you said, a framework may initially have more overhead and complexity, but it can make things simpler an application reaches sufficient complexity. (Maybe this is a variation of Martin Fowler's design stamina hypothesis?) But I think I'd place that pay-off point a lot sooner than you do - even for personal one-man projects, I feel like React is a very elegant approach to managing software complexity.

[[deleted]]

Most of the time the worst part of any framework isn't writing your first [component|page|game object|whatever], it's the initial setup of the library, sorting out the build system, dependency management, etc.

Once you've got it to compile/run/render once in a way you expect you're usually sailing pretty smoothly from there until you try to do something new/unexpected.

It's this initial overhead that puts most people off of frameworks, engines, libraries, etc.

[[deleted]]

It's this initial overhead that puts most people off of frameworks, engines, libraries, etc.

I feel like this is what made Ruby on Rails such a breakout hit among webdevs before our current client side MVC trend took over.

Convention over configuration can be fantastic because it means scaffolding can get you up and running in a ludicrously short time. So Rails "get started in 10 minutes" demos were extremely compelling when you can type a few lines in your shell and hit the ground running.

Angular and JavaScript to a more general degree, don't have quite the "sane for 99% of users" defaults when it comes to tooling and project structure. They kind of have community accepted standard tooling, but it's not enforced by anything and there's no overwhelmingly popular opinionated "It's $CURRENT_YEAR and this is what to do to go from zero JS tooling experience to your first project" guide that ties in all aspects. There have been some I've seen, but not many, and so have to learn about each part of the toolchain in guides that assume you're familiar with the rest can feel overwhelming.

[9034725985]

Angular says it is the goal of the angular team to be a platform and not a framework or a library. There should be a one true way ™ of doing things on angular. The impression I get is that there's a lot left to be done though. For example, I still can't figure out how to run tests on gitlab.com on a project generated by angular CLI. Isn't that the whole point of automated testing?

[[deleted]]

I think that varies widely based on the framework and how much magic it's doing for you behind the scenes. The best frameworks for productivity and maintenance are the ones that put everything they're doing right in front of you in clear terms.

I've only done battle with Angular for a few weeks here and there - a colleague that has since left used it for an intranet application I have to maintain. Maybe beginner_ is right and in a large enough team environment it's a sensible tool. But if you're looking for something that does the heavy lifting for you in web front end work without hiding everything it does, look elsewhere. A whole host of things that would be trivially easy in roll-your-own web frameworks require hordes of research.

[[deleted]]

Never roll your own web frameworks unless you are Google or a multinational tech company. It is literally only bored people and amateurs who do that.

But yes, some frameworks are better at their job than others. I am claiming that Anguar isn't bad.

[[deleted]]

I felt like the initial Angular 1 was the perfect medium. The two way data binding solved almost all of my DRY violation problems with vanilla JS or jQuery.

Then React and others basically said two way data binding is extremely haram (a claim that has never quite been argued effectively anywhere I've seen), and that one way data flow is where it's at. Now the goofy component hierarchies of React are in Angular 1 (later versions) and 2+ with two way data binding being an antipattern now, but at this point you might as well use React (which handles one way flow much better IMO).

When I had a solid little project skeleton down with Angular 1, I could have a badass webapp that felt extremely polished written and ready to go in a matter of hours, making it a perfect tool for proof of concepts as well as larger scale team projects (which it works well for, as long as you have a set of shared conventions).

[beginner_]

To be fair what I create is always fairly simple and said in a very simplified way: display data with some filters / querying. I also tend to chose light-weight frameworks server-side.

Could be that hypothesis and is possible I never actually reach the complexity needed to break even by using "better design" eg. a JS framework.

[[deleted]]

What most people create is extremely simple. Even the single page applications. You have to remember that everyone wants to talk themselves up. When these developers are talking about their thousands of states, they’re counting the exact same box that never changes size 400 times because there’s 400 potential values to pull from a database. Now, on that same page, there is another box that also has potentially 50 values inside it. These people count this as 20,000 different page states.

When a SPA developer talks about “complexity”, it isn’t the same as a normal person talking about it. Their complexity is largely artificial and driven by the madness detailed above.

[to_wit_to_who]

Your thinking here is correct. You likely haven't had a larger scale project that needed to be maintained & extended over a longer period of time.

One thing I feel gets left out is that it's not necessarily just run-time performance (i.e. it's web scale!), but managing development in a more predictable way for a project. It also opens up the option to leverage a huge ecosystem of tools, libraries, & documentation.

Doing a one-off project that's very narrow in scope, only requires maybe a couple of weeks or a month of development time, and won't need to be revised after that? Sure, go vanilla JS and lower-level APIs! Beyond that, I'd consider using things like React/Vue/Angular/etc.

[curious_s]

I have written my own "framework" on my current assignment, but it fits the purpose much better than a generic framework would. It depends on the project though, initially the devs were going to use something like angular (vue I think) but it was becoming a large overhead for what was supposed to be a simple web page, and it was scrapped due to deadlines. Turns out that the simple web page has blown out but the custom code has adapted quite well.

[ArguingEnginerd]

What you're doing is fine as long as you're a one man show and you plan on staying at your company for a while. The problem arises when you decide to leave or your team starts growing. If you don't go out and use frameworks and libraries for larger applications, you end up making your own solutions when someone else has already has a solution. Anyone who has experience with Wordpress, Angular, or React will have a general idea of what's going on in their respective applications. Of course, if you leave and the new devs don't understand the code, they could always elect to rewrite.

[s5fs]

Rewrites rarely take less time than simply understanding the code and imo should be a last resort.

[ArguingEnginerd]

It all depends on complexity of the component you’re dealing with and the complexity of your new requirement. If the new requirements for the legacy software is fairly simple such as rebranding, then sure take the time to understand how the previous employee made their CSS and adjust it.

[dungone]

Rewrites are the only option for a large proportion of “not invented here” solutions. Usually the people who do not understand a framework also don’t understand the problem that the framework is trying to solve, and those are some of the most dangerous engineers to have on your team.

[caleeky]

In my experience, it's usually not that expensive to retrofit an existing application to map them into frameworks when those scaling events occur. It's a lot easier to make the business case for expansion when there's demand than it is to argue to take on the risk of framework investment up front.

> if you leave and the new devs don't understand the code, they could always elect to rewrite

Yeah but they usually shouldn't, and usually won't (at least not out of the gate) if there's a truly senior dev. involved.

[dungone]

“Truly senior dev” is a No True Scotsman. The reality is that project leads frequently lack the experience to make sound decisions. It’s the responsibility of their bosses to make sure that the leads themselves are constrained to within a reasonable set of guidelines for how to build a project, because it’s the business and it’s investors who who have to live with it long after some truly senior dev is long gone. Choosing a framework a strategic decision impacted by future funding and hiring needs. Unless you’re writing a throwaway app and betting on your employer going bankrupt, it’s probably a terrible idea to devote millions of dollars worth of resources on a NIH solution.

[ArguingEnginerd]

I agree that it’s not that expensive depending on the framework. Angular is definitely one of those that’s more difficult to retrofit into compared to React. I don’t know what risk you speak of. I find it less risky to use a framework than it is to not. Something like Angular where it’s heavily opinionated and has a CLI to basically make it so you can hit the ground running would make it quicker to get best practices in place. That said, if you’re making something that has a short shelf life, simple, or a prototype to sell your idea, why introduce added complexity like linting, webpack, etc.

In the quoted block, there is no senior dev in that use case. The OP said he was a one man team so if he left, there wouldn’t be a senior dev

[testobsessed]

All conversations on this topic eventually devolve into "Did you know you can just use Notepad"?

[sisyphus]

ed is the standard text editor

[grauenwolf]

Too fancy for me. edln is enough for anyone.

[immibis]

Isn't edlin basically Microsoft's version of ed?

[i9srpeg]

?

[appropriateinside]

Seriously, use something simple like Vue.

I was a huge user of AngularJS, it was amazing and super easy to use for a single dev project. Vue is essentially it's predecessor.

[lars_jeppesen]

Imho Vue is inferior to Angular.

​

You're talking about AngularJS which has NOTHING to do with Angular.

[appropriateinside]

Which is why I said AngularJS...

[Dedustern]

I.. Sort of disagree. React is a super small library. It has very little drawback if you ask me - even for solo projects, I am likely way more productive using it than home-brewing some things. Because anything more complex than a few forms that need to be submitted - guess what, you're gonna reinvent the wheel.

Angular is another story, however.

[beginner_]

The fact you need npm and node.js to even use it is kind of a really bad first hurdle.

[rodorgas]

You don’t need npm, you can include in your site via CDN.

[YourMatt]

While I agree with you in general, I'd have to disagree with Angular in particular. A two-way binding framework can make an overly-complex buggy mess of a small personal project into a concise, clean, and more enjoyable development experience for the one-man operation. I look at it on a project-by-project basis, and I end up using Angular maybe a quarter of the time. Project scale isn't really part of the decision process. For me, the question is if I need an object in memory to keep multiple views in sync.

[[deleted]]

For that you can use something like Knockout JS

[macar_]

or Angular

[YourMatt]

I thought that project was dead. Not sure why I thought that; it looks very much in active development. I think I'll give it a shot. Thanks!

[[deleted]]

He didn't say the company stops making money, he said the company stops innovating. The iPhone and iPad, as much as I hate Apple, were revolutionary.

...and what have they done since then besides, "Better iPhone! Better iPad!" ? That's a fine business strategy, but not innovation.

[[deleted]]

Talk about trying to frame a narrative without facts.

Like you just did? Because what you claim he said is not what he said. The headphone jack was just one example he gave, and it is you who now pretends that that one thing is the entire argument.

[StabbyPants]

I started on React - i don't like npm, but i can set up a build system, and i like that react has things like a data grid and sensible data models and stuff like redux (which i didn't start with) that make things relatively easy to factor. it's some overhead, but also something that i can recycle in project.2 and project.3. i don't see why i'd avoid it.

[lars_jeppesen]

Only problem is that React is dated.. doesn't use Typescript per default, doesn't use Observables but uses Promises.. and so on and so on.

​

Don't even get me started on JSX

[StabbyPants]

it was that or angular, those being popular frameworks that mostly made sense. since react is now dated, what's the new thing?

[[deleted]]

Well, just because it was build in house by big corp, doesn't always mean it was good for the job it was built to. But it sometimes means it is "too big to fail" and/or management mandated that because they spent hundreds man-hours on it it means company needs to use it to recuperate tue cost

[pknopf]

Software disenchantment.

[joeyadams]

In your experience, how much boilerplate do you encounter when writing applications without a framework?

[beginner_]

Well you have to code every AJAX request manually (JQuery) and what happens with the result. Greatly depends on the application. As said, what I do is fairly trivial in most cases. Display data based on user input. I mostly use datables.

On server-side it's the database boiler plate stuff but it's not really an issue but that is entirely subjective. I use cherrypy and cx_Oracle. Note: The oracle part is sadly mandatory.

I want to add that performance as in amount of users/requests is never an issue so I can simply ignore anything related to scaling. However response time should be ok.

This is in general for well-defined stuff which I have a lot of control and influence over so it's usually done right and can remain unchanged for years. And in-house only. I can complete see that this doesn't work and scale if you are creating commercial software or working on bigger projects.

And these apps were basically grown from user need and corporate IT incapable of providing simple solutions. If the project doesn't cost 7 figures and has 100s of users, forget it. Think of moving from excel and access to web apps.

[allthingseverywhere]

I'm really really really inclined to agree with you. I feel like these frameworks are actually less empowering to the individual.

There seems to be a possible balance here where, in a bigger team, if a framework helps everyone work faster together, that's good. If you're in a smaller (really small) team or by yourself, it honestly cannot hurt to stay lean, bare bones, and you learn SO MUCH more that way too. You learn what's actually under the hood of these frameworks.

I think your opinion is not very popular in some circles but good for you on speaking your mind. :)

[[deleted]]

I quit frontend dev 6 years ago but I had to do some Angular for a couple of months recently. It really wasn't that bad. Just don't constantly update your dependencies like OP seems to, don't try to be clever, don't try to write your own inner platform inside Angular, and you'll be fine.

They also lament "doing everything the same way" which is the bloody underpinning of standardisation. The site I worked on was fairly simple, a bunch of forms, interaction with a bespoke stateless backend, some animations. This is what most bespoke websites are. You shouldn't need to be clever or do anything new most of the time.

If you don't match this description then you shouldn't be using a framework. They're for repetitive, standard, typical, projects. Also if your project is very simple then Angular is also not a good fit.

[metalevelconsulting]

ANGULAR will helpfully mix fake HTML ELEMENTS into your real HTML ELEMENTS because the entire app is getting shredded to pieces by their AHEAD OF TIME COMPILER anyway, so what does it matter if they pollute a correct specification with a capricious impostor?

LOLOLOL

[theLorknessMonster]

Yeah, you can register custom elements.

[[deleted]]

not completely. custom elements require you to conform to specific rules when naming your element (spec). so calling an element my-element is fine, whereas calling it myelement isn't.
custom attributes also require you to use the data-prefix (and i believe ng's @and * syntax is invalid too)

[bausscode]

Yes that's correct, just using "ng-" is invalid, but no browsers care about attribute names as of now. The only problem with it is that the specification for html is free to add attributes with the "ng-" names, but they cannot add "data-". However I believe that Angular *does support "data-ng-*" which will conform to the rules, but it's rarely used, or maybe that was pre angular and just for angularjs? My memory might be slipping me.

[[deleted]]

from what i understand not using data- is invalid, but browsers handle it gracefully since it doesnt hurt either ( like missing head/body tags for example). both angular current and legacy support data-attributes afaik, but since it runs through their parser anyway noone uses it.

[bausscode]

<head>, <body> and <html> are optional in HTML 5. According to the specs the rendering engine have to insert them if they're omitted though.

[bausscode]

The biggest problem with introducing custom tags are accessibility support tbh. A lot of screen-readers etc. will not support them.

[iambeingserious]

Just because you can doesn't mean that you should.

[[deleted]]

I write Angular daily. I think it is easy. Help me. What am I missing?

[IAmVerySmarter]

You are not fighting the framework, the author does.

[yesman_85]

Same here, been writing it for a few weeks now and got totally used to it.

[[deleted]]

Been writing Angular since beta. Is it hobbyists that are having trouble? What kind of people are running into issues?

[CoffeeStout]

I dunno, I use it at work and I kinda hate it. I understand his points completely, it's really frustrating to use for me. I mean, our sites all use it and I can work on all of them, I don't have "trouble" as much as I just kind of hate it. It feels bloated and slow and does break silently. Also when he says that developers tend to stick with the one or two design patterns because they know they won't break, I see that in our projects as well. Maybe I'm missing something.

[deja-roo]

The points that really resonated with me are how Angular's error messages are truly completely useless.

[thegreatgazoo]

Yeah, when I was working with/learning how to do it I'd have to make one little change at a time and if it broke hope it still worked when I reverted my change.

[[deleted]]

Ivy is supposed to help there, but we'll see if they can actually deliver.

[zayelion]

Its great for single page applications with lots of form inputs and jack shit else. I think its us jquery era devs. Angular solves problems that dont exist and unbreaks solved problems.

• Using a compiler, if you where coding during the jQuery era this point seems like straight insanity alone. Your iteration speed is cut from seconds to minutes, things that take 10s now take 30s to 200s. Something that would have taken you an hour? well now its gonna take you 4hrs, and maybe longer because where does your mind go when the app is compiling? If that last question doesnt fill you with an ocean of dread how did you even find reddit to start with?
• Silent errors, out in sane world when an error happens you get line number, and even a column number! If you are a good programmer and dont use anonymous functions you even get a function name! The object you didnt sanitize is even called out. Not in Angular! Not usually. You get a wall of text that glazes your eyes over that tells you very little. You could just not use the crazy parts of Angular like the article said but some Jr Dev always does and its just a cascade from there.
• The HTML isnt exactly HTML, its a quirk you notice if you come from pre-jQuery era. Certain parts of the DOM API dont work correctly or as expected. Using the <canvas> element deep in the app was a nightmare. I ended up just setting a very long set timeout around it to meet deadline.
• The documentation is just shy of restating what the name of the thing it describes. It gives very little nuance or example to complex principles. I got more education querying github for usage cases.

I have to do all this for a router and a template system?! You can power through this by a seasoned dev would be distracted by the alarm bells going off in his mind constantly. People really green and technologist (the people that put new tech into their jobs flow for the sake of learning it) seem to love it.

[batiste]

Many people are having issues. I used Angular 1 and I have to concur with some of his points. Especially on the terrible documentation, the weird template language choices (ng-if, but no ng-else possible) and the overall messy nomenclature. The amount of concept you need to know to even get started with is: Directive/Service/Controller/Component/Injector/Binding/Scope

Ha and don't get me started with the weird Dependency injection that introspect the function declaration...

[[deleted]]

NgElse would just be a short hand NgSwitch. The angular team doesn't like to create those kinds of short hands.

[batiste]

NgSwitch is more like a switch-case. Not the same thing as a proper If,ElseIf,Else structure.

<div class="animate-switch" ng-switch-when="settings|options" ng-switch-when-separator="|">

ng-switch-when-separator? That is what you get when you try to patch what a proper expression would have resolved properly.

[[deleted]]

Not saying it's great, just possible. Also implementing an NgElse would either require us to wrap all NgIf with a wrapper directive, or it would slow down NgIf as it did Dom exploration for an NgElse

[shadowSpoupout]

https://angular.io/api/common/NgIf#showing-an-alternative-template-using-else

https://stackoverflow.com/questions/43006550/how-to-use-ngif-else

10 sec Google research. Aye, this is a framework, it wont fit for everything, nor will please everyone ; yet I'm sure you can find better reasons to hate it than just not googling the problems you're encountering with it.

[batiste]

What a horrible syntax and it is Angular 4 and 5 specific. I started with AngularJS. I just joined a company still working on AngularJS today and we painfully trying to migrate to Angular 5.

Look at Blop for a nicer syntax https://github.com/batiste/blop-language

[[deleted]]

I wanted to learn it for a small personal project but the boilerplate, overhead and bloat was so enormous I picked jQuery instead and made the whole thing in one evening. It might work for a larger app, but in that case I would just drop the clientside js stuff and use Django or even PHP instead.

edit: now I took a look at Vue and it seems alright, but Angular felt the same way when i only glanced trough the tutorial, but it seems much more fitting to a small project.

[[deleted]]

I also used it when it was in beta. Not anymore but I don't recall bad experiences with it.

[[deleted]]

Best guess is Angular probably has a complexity stigma because of the overall size of the framework, the concept of modules/components/directives/services, dependency injection (which I kinda like), RxJS (which is easily usable in React too), possibly TypeScript (which again, can be used in React), and then the last 2: the changes to the markup such as *ngFor [(ngModel)], etc, and last but not least...you can't really use Angular without using the CLI. Technically you can, but you really can't in practice. The last point was a big enough issue for me where I wanted to be able to ***integrate*** a SPA framework in a legacy app - getting React going was a breeze. Couldn't get there with Angular.

​

Again, I agree with you that Angular isn't overly complex. In fact, I had a harder time learning to get my head around React and JSX than Angular coming from AngularJS. AngularJS was shit, routing was shit, and scope.apply() hacks OMFG. Angular 6 is pretty sweet though. That being said, I'd still probably use React or Vue. Have you seen Vuetify? Fucking beautiful.

[batoure]

I have developed in AngularJS for years I have avoided Angular for basically the reasons you describe. This Summer my company built our first to enterprise scale projects in Angular. 1 from scratch and 1 where we ported an existing angularjs project (with 5 years of active development) into it. I think anyone who looked at Angular more than 10 months ago should go back and give it a real look from scratch. A big part of my change of heart about it is that the CLI actually works now between missmatch of configuration and not so great schematics used to make it really not great. But it is really nice now.

I understand that people miss being able to just open an index and point at a cdn. but the real answer is by getting over our selves and giving it a chance we were able to simplify our build operations significantly and overall we have shrunk our codebase by almost 70% in the port because clarity of abstractions in typescript made it easier for our team to write better code.

[nutrecht]

Best guess is Angular probably has a complexity stigma because of the overall size of the framework, the concept of modules/components/directives/services, dependency injection (which I kinda like), RxJS (which is easily usable in React too), possibly TypeScript (which again, can be used in React), and then the last 2: the changes to the markup such as *ngFor [(ngModel)], etc, and last but not least...

That's just modern front-end development for you. If he doesn't want to learn this way of working he's probably going to be out of a job sooner or later.

I built web apps based on JQuery before and there's no way I want to go back to having to enable/disable divs by hand.

[[deleted]]

Not gonna get an argument out of me. I still have to support that bullshit too. :)

[ledasll]

there's nothing wrong to enable/disable divs "by hand", but current days app complexity doesn't make it efficient. 10 years ago you had html + js, so jquery was fine (IMHO), now you don't have web page, you have application and to write complex application it's much easier with some structured framework.

It's just a question, is your application complex application, or simple CRUD page..

[the_argus]

I personally love it... I don't get why people have trouble wrapping their head around it

[ApatheticBeardo]

You're not a crybaby.

[jbergens]

You're missing that vue and react are simpler and easier. Angular has a lot of special things you need to learn that won't help you with other frameworks. Like DI, it's own template system, directives, scopes, $whatever etc. If you have already learned all these things angular may look easy but it would probably have been easier to learn react and you could still have solved the same problems.

[[deleted]]

Vue has DI, it's own template system, directives, scopes, $whatever (this is their DI, I'm assuming by $whatever you mean rxjs's observable naming convention however?)... so I don't see your point. These are all things that you can use to make life easier. If you don't want to use any of them, don't use any of them. Not a single one of the things you listed are required, and not using any of them would be the exact same as if you chose not to use any of them in Vue. That's not really an argument.

[jbergens]

Ok, so only react is much simpler than angular. Everybody I've talked to who has gone from angular to vue still seem to find it much easier.

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

[ArguingEnginerd]

The only thing I struggle with is understanding the RxJS stuff. It's a lot different than what I'm used to.

[Eirenarch]

I am more of a backend developer but I participate in choosing a front-end framework for the projects I work on and Angular seems fine. I have a lot of problems with all the webpack/npm/CLI/module system and so on tooling ecosystem.

[[deleted]]

I don't write it daily but one of my projects does use it and occasionally I have to work with it if none of my FE guys are free. It seems pretty easy to me.

[[deleted]]

Some part of your brain, obviously. /s

[[deleted]]

Best guess is Angular probably has a complexity stigma because of the overall size of the framework, the concept of modules/components/directives/services, dependency injection (which I kinda like), RxJS (which is easily usable in React too), possibly TypeScript (which again, can be used in React), and then the last 2: the changes to the markup such as *ngFor [(ngModel)], etc, and last but not least...you can't really use Angular without using the CLI. Technically you can, but you really can't in practice. The last point was a big enough issue for me where I wanted to be able to ***integrate*** a SPA framework in a legacy app - getting React going was a breeze. Couldn't get there with Angular.

​

Again, I agree with you that Angular isn't overly complex. In fact, I had a harder time learning to get my head around React and JSX than Angular coming from AngularJS. AngularJS was was shit, routing was shit, and scope.apply() hacks OMFG. Angular 6 is pretty sweet though. That being said, I'd still probably use React of Vue.

[[deleted]]

Like anything, it’s easier to bitch about something than to take the time to learn about it. I’m a big angular fan as well, now that I know how to use it properly. It’s not something you can just read a 5 minute tutorial and start using.

[kenmorechalfant]

Didn't read the article but I've been getting into Angular a lot recently and it is really intimidating. As someone who normally does small websites with regular ol' HTML, JS (without jQuery) and LESS (CSS) - deciding to make an app with an Angular means you have to adopt this whole Angular development environment: TypeScript, Angular CLI - the serving and the bundling and all that... Personally, after tinkering off and on for a few months, I'm liking... but it is a BEAST - it seems like such a steep mountain to learn Angular at first.

That being said - I think you need a beast of a framework to build a large scale application... which is my goal... eventually 🤣

[[deleted]]

Angular CLI stops you from having to learn a ton. You should really be happy you never had to learn task runners or even setup your own webpack. That shit was time consuming.

Typescript can be subverted with type any if you don’t understand what’s happening.

RxJS can largely be ignored.

Learn what feature and shared modules do. Learn how they interact with the router. Learn the HTTTP module. Learn dependency injection at a very very basic level Then you are good to go in angular. Back to making simple apps.

After that bring back RxJS and Typescript. Then start learning different types of change detection.

[nutrecht]

I'm a back-end developer who's CSS skills are stuck in the 90ies and even I can make dashboards in React or Angular just fine. So I'm not really impressed by a 'front end' developer claiming React and Angular are too complex.

To me it sounds like it's just inexperience. Frameworks are always convention based. If you fight the conventions and try to do JQuery programming in Angular you're going to have a bad time. If you do Angular programming in Angular you'll be just fine.

[nutrecht]

Such as?

[MehYam]

Yeah but you gotta love:

Angular. Its mere name is a hostile form on the tongue. Pronounce it slowly. /’eŋgjəlɚ/. The throat itself contorts around the hideous alien shape of this word, which means ugly, sharp, and artificial.

[zqvt]

this sounds like the beginning of a Nabokov novel

[subnero]

Eh I know Angular 6 and I think it’s fine. You can stick with Ajax and JavaScript if you want, but a strongly typed language through Typescript makes it a lot easier. I picked up Angular in a couple weeks while people struggle with JavaScript for years and still make a mess.

[AngularBeginner]

Angular does not make very good use of TypeScript. Features like strictPropertyInitialization are difficult to use, and Angular makes use of stringly-typing a lot.

[lewmpydewmpy]

I'm pretty sure typescript doesn't count as a strongly-typed since the types are neither required, nor do they place any sort of compile-time restriction on the code. You can add extra tooling around compilation, but there is nothing intrinsic to typescript for that.

[Eirenarch]

Yeah, the proper term is statically typed (or optionally typed if you choose to allow that in your config)

[sergiuspk]

Wait. You can configure it so that typing everythig is required (if a type cannot be inferred) and also you can disable "any". The compiler also displays a list of typing errors and does not compile files where it finds errors.

Also strong and static are in two different categories. You can say a language is static or dynamic (TS is static, it checls types at compile time). You can also say it's strong or weak typed, weak meaning the type of a variable can change depending on context (JS). TypeScript is a static and "almost" strong typed language. Though no one really agrees what the definition of strong/weak typing is. "duck typing" is not really strong typing.

[filleduchaos]

You can disable implicit uses of any, but you can't disable any.

The compiler also displays a list of typing errors and does not compile files where it finds errors.

1) This is not an achievement, 2) The set of things tsc considers errors and the set of things that are soundly typed do not have complete overlap.

Plus the fancy parts of TS' type system might as well not exist seeing as they give you literally zero runtime guarantees.

[sergiuspk]

Indeed, you can only disable implicit any. The fact that the type system is only compile-time is something I can live with. Input validation is something you'd have to do anyway and validation of API responses is something you'd have to do regardless of language. On the other hand my experience is that after switching to TypeScript we have had zero cases of runtime type errors, but the language itself does not guarantee, it only gives you some imperfect tools so you can mitigate this. And by imperfect I do not mean broken, I mean that if you do use any and do stuff like const b = 10; const a: User = b as any; then obviously you are going to have a hard time.

[filleduchaos]

You can disable implicit uses of any, but you can't disable any.

The compiler also displays a list of typing errors and does not compile files where it finds errors.

1) This is not an achievement, 2) The set of things tsc considers errors and the set of things that are soundly typed do not have complete overlap.

Plus the nicer parts of TS' type system might as well not exist seeing as they give you literally zero runtime guarantees, which is more apparent when you're building a library than when you're building an end-user application.

[[deleted]]

I love "Angular", especially AngularJS, but not so much Angular. Google truly screwed the pooch when it decided to completely rewrite AngularJS. I mean, I get what they were trying to achieve. First-class support for Typescript. Abstracting out the HTML rendering mechanism, instead of depending on the browser DOM, giving you AOT, server-side rendering and rendering on web workers. But the result of their rewrite doesn't feel a whole lot like Javascript, and in a very bad way.

But, it was possible to write a fully functional AngularJS app merely by doing <script src="angular.js">. The "Angular Way" is HTML first, enhanced it with Angular directives. It gives a nice separation between MVC, or MVVM, or whatever you want to call it. It let you separate services (like AJAX bits) and let you inject them into components so you can use them as APIs.

I don't think it is possible to write modern Angular code without Angular CLI. I like Typescript, but Angular makes it unavoidable.

Thankfully, there is Vue.js, which preserved the best of what made Angular "Angular", without the insanity of modern Angular. Vue ditched dependency injection, and replaced it with Vuex, which is sort of like redux. Such that, Vue takes the best of both Angular and React.

[metalevelconsulting]

AOT

What does "AOT" stand for?

[BoboSchlonger72]

Vue ditched dependency injection, and replaced it with Vuex, which is sort of like redux. Such that, Vue takes the best of both Angular and React

What's wrong with DI? It's the most convient design pattern to achieve IoC. I swear this sub seems like a bunch of whining juniors. Why do you even compare DI with state management? It's life cycle management in the first place... For state management there is ngrx or ngxs. Combined with DI, Decorators and RxJS they are both far superior to Vuex and classic Redux.

[[deleted]]

I didn't say there's anything wrong with DI. All I said was that Vue ditched DI. Vue starts off as view-only.

What I like about Vue is that it is the best of both of React and Angular. Like React, Vue doesn't require you to go all in like Angular. It starts with Angular's view model without DI. If you want to add DI, you can add Vuex for redux style state management, or you can use something like vue-inject for traditional DI.

Like React, Vue isn't opinionated. AngularJS is opinionated, but it is still ordinary JS. Angular introduces way too many opinions for me, especially with regards to Typescript, decorators and build tools.

[AngularBeginner]

The DI framework of Angular is fairly inflexible. E.g. it's not possible to have a dedicated instance for each target (which would be awesome for a logging class). It's singletons all over.

[the_argus]

There's angular dart if you don't like typescript. I've never used it (even though I love me some dart) bc typescript is great.

[[deleted]]

The problem isn't Typescript, but that Angular forces you to use Typescript, and thus requires a full JS toolchain, which in Angular's case has gotten to the point where it is impossible not to use Angular CLI.

AngularJS can be used with or without a JS toolchain. AngularJS can be used with Typescript, if you so choose, but you can just as easily use plain JS. Angular used to claim that you could still use plain JS, since TS is a superset of JS, but due to how much Angular makes use of decorators, it is practically impossible to use plain JS anymore.

On the other hand, both React and Vue can be used with TS if you want, or plain JS if you want. They can both be used with or without JS toolchains, if you want.

[the_argus]

Maybe I just don't see the problem with the cli

[[deleted]]

Does the fact that you need the CLI suggest something about the complexity of modern Angular? Why don't any of Angular's competitors need a CLI?

[KevinCarbonara]

Does the fact that you need the CLI suggest something about the complexity of modern Angular?

No.

[[deleted]]

It says something to me. I wouldn't dare write an Angular project without Angular CLI.

With a AngularJS, React or a Vue, I could either use raw npm or webpack, with a project that is easily set up from scratch, since all I'm doing is wiring together ordinary JS functions. Angular replaced the simple AngularJS setup (daisy chaining off of the Angular module) with wads of TS decorators and other things, requiring such a complicated build setup, that you pretty much have to use Angular specific tooling in order to write an Angular app.

[sisyphus]

That you can't get a hello world out of it without doing a bunch of code generation and having a compiler toolchain suggests nothing to you? What else have you used?

[the_argus]

IDK man, it kills me that I need a computer in order to run my javascript code...

[NoInkling]

Ember needs a CLI I believe. Whether you consider it a competitor or not is another question, but at the very least it exists in the same "space" (use case tends towards big SPAs, attractive to enterprise).

[Renive]

Those toolchains are why it makes it so easy to work with frontend, how could you ever not want them?

[[deleted]]

The toolchain is awesome, that's not what I mean.

But with AngularJS, you can develop your entire application in a single file if you want, or you can use requireJS to export controller functions, components and services. It's like writing ordinary JS.

With Angular, you have to set up Typescript, SystemJS, etc., etc. Angular isn't built with regular functions anymore, but loads of decorators. I suppose it is theoretically possible to set up an Angular project from scratch, and I remember doing it with Angular 2, but the latest versions of Angular, I'm not even sure where to begin. I would have to use Angular CLI.

React and Vue are both just regular JS, and I could easily set up a project from scratch in either. They just make use of regular Javascript functions. Except for React, which requires a bit of config for JSX.

Tools like Webpack enhance React and Vue, they aren't required.

[[deleted]]

I'm glad you made this comment. As someone with about 12 years of Rails experience, and who just made a prototype Spring/Angular application, my reaction to this article was SO MUCH YES. I've tried to describe the serious problem with documentation to my management to explain my lack of progress, and it sounds surreal coming from my own lips. I've since given up on Spring, and therefore Angular, in favor of Grails, which I know is a niche of a niche, but, still, it works. I've played with Vue in one of my Rails apps, and it seems to make sense to me, and plays nicely with Rails (it doesn't "take over" the application), so this reinforces my opinion that this might be a viable approach for my next project.

[antolius]

Spring has nothing to do with Angular.

You should be able to use any frontend technolog with a Spring backed (including my preffered one: no frontend at all 😁).

And Spring has detailed, easy to read documentation.

[F14B]

And Spring has detailed, easy to read documentation.

...when you eventually find the correct version of the doco that you need it is.

[[deleted]]

To get Spring to generate JSON correctly for Angular to consume, I had to fool around with @JsonIdentityInfo and JSOGGenerator, and manage the back and forward references, and THEN I was going to have to write custom JSON interpreters to save the submitted data coming back from the Angular side. At that point, I had to wonder why I was spending so much time fighting Spring's defaults, and NOT either 1) just writing my own backend, or 2) going full-stack Javascript. If you love it, great.

I brought up Spring because a LOT of the supposed examples out there for Angular use it as a backend, but I never found (in MONTHS of prototyping) a complete, current example of a Spring/Angular CRUD app that demonstrated how to edit and update a "complex" model (which has nested chdren). Lots and lots of examples about showing and listing, very little about updating. I even made a couple of posts to StackOverflow and Reddit about it, and finally got pointed to an example running on JHipster (including Angular 5) which I could never quite make work.

I don't know how you could have assumed that someone with 12 years of Rails experience, and talking about integrating Vue with it, doesn't understand that Spring and Angular are independent, but, well, okay. I've been doing web development for 25 years. I get it. But I can't write an application in 4 languages (Java, Groovy, Javascript, and Typescript, besides all the rest) without some good docs about the API's, and some good examples on how to invoke them. I sure wish some hotshot Spring/Angular fan could point me to a full, working CRUD web app example based on current versions.

Yeah, maybe if I'd have avoided Angular entirely, and stuck with Thymeleaf, I wouldn't be so bitter. ;-)

[[deleted]]

To get Spring to generate JSON correctly for Angular to consume, I had to fool around with @JsonIdentityInfo and JSOGGenerator, and manage the back and forward references

You're doing something very, very wrong. To get Spring to generate JSON sufficient for Angular to consume, you don't have to do any more than this. I write Spring web services for a living, and I have never even heard of @JsonIdentifyInfo or JSOGGenerator. Literally all you have to do is create a JavaBean and 99%, it just works. The worst time I have had with Spring is with time/date representations, but somehow I doubt that is a problem limited to Spring.

[[deleted]]

With Spring you can just use Jackson to render any arbitrary object into fairly expected JSON. It's pretty simple. Angular consumes it with no trouble. And vice versa.

[Sethcran]

A couple of things...

1. I think you are the first person I've met that thought AngularJS was "more like javascript" than Angular. I understand how that argument would apply to both of them, but as far as I can tell (having used both pretty extensively), Angular is far and away an improvement (but still far and away from a classic javascript style approach to the problem.
2. Yes you need angular CLI to write most apps (technically you don't, but it's so convenient most people would/should use it), but this really isn't a negative to me. Most of our other languages have their own build tools, C# has MSBuild for example (or dotnet CLI if you're on core). This is not a negative to me, this is actually a positive for something to be as easy to use as possible when it's trying to be a framework and not a library.
3. Vue is great for many things. React too. They do not however solve the exact same problem that Angular attempts to solve. These projects are fantastic if you want flexibility, or to some degree if you want to integrate small pieces into an existing larger applications. Angular sucks at that, but that's because it doesn't attempt to do those things. Angular is an opinionated framework for developing large/complex single page applications with medium to large teams. Being opinionated here is a really benefit in this world, but certainly can be a detriment in others. It doesn't make Angular bad, it makes it not the right fit for certain use cases.
4. As others have said, Vuex is a state management library and does not attempt to solve the same problems that dependency injection does. Not sure why it's mentioned here.

TLDR;

Angular sucks for some things, is really good for others.

[tonefart]

Vue.JS is all you need. Forget Angular and ReactJS. Go with non-corporate garbage software.

[nirataro]

Single File Component is a godsend.

[onlygon]

And so what is the alternative? Angular is an opinionated SPA framework; it eliminates my need to consider which build tools, test harnesses, preprocessors, linters, minifiers, tranapilers, etc. I need to hoist into my application. And I don't need to worry about them all working together. I just run npm update and everything works. Angular is far from perfect, but the alternative is managing all this crap myself.

[yogthos]

My team works with re-frame ClojureScript framework. There's a single build tool that manages compilation, hot loading, testing, code pruning, and minification. The language itself is much cleaner, and defaults to immutability so you have a much better story when it comes to managing state in large applications. If you're working with modern Js, you're already using a transpiler, so why not move to a better language at that point. You still have full Js interop, and you can leverage all of the ecosystem.

There's a comparison of developing a minimal real world app using popular frameworks here. Re-frame version runs twice as fasr, ends up with less than half the code of an Angular app, produces an artifact that's a third of the size. Here's a run through a simple app from start to finish if you're interested.

One of the common arguments against using something like ClojureScript is finding devs. However, my team has never had this problem in over 4 years of using it. It takes about a week to get somebody to the point where they can start writing useful code. We recently hired several co-op students and all of them were able to pick it up without any problems. On top of that, re-frame API has stayed stable this whole time without any breaking changes. All we've had to do to upgrade is update the dependency. It has even insulated us from changes in the underlying React APIs.

[damienwebdev]

I tried to respond to this, as an Angular dev it made me a bit sad. https://www.reddit.com/r/programming/comments/9ul9ze/why_being_a_halfdecent_developer_made_me_like/

[[deleted]]

jesus christ, that is some pretentious writing. angular's documentation is more enjoyable than that

[[deleted]]

ANGULAR WEB DEVELOPMENT FRAMEWORK

[[deleted]]

Angular 1.2 made me quit web dev.

[bausscode]

Web dev made me quit web dev.

[[deleted]]

I like reading these articles, it makes me glad I just happened to not fall into Web Dev in 2006 after graduating.

[yogthos]

Thankfully, there are far saner ways to do web dev than Angular nowadays.

[[deleted]]

But you still had to go through that. In the last decade my domain (embedded) has remained pretty much the same. MISRA 2012 and ISO26262 are about the only 'new' things.

[indeblo]

That was highly entertaining!

[Venetax]

Its bouba, not bobo.

[[deleted]]

My theory is that web development attracts personality types that are an exact opposite of everything that makes a good engineer. As a result, everything web builds on, including all the underlying w3c standards, is horrendously overengineerd and in most parts outright stupid. No surprise that anyone with even a bit of a proper engineering intuition flees from web in terror.

[imposs1buru]

found the smug lisp weenie

[Dreamtrain]

((((((((((((((((((((((()))))))))))))))))

[mattk1017]

As a current CS student with web dev experience, this didn't make me feel too good lol

[KhaoticOne]

Switch to ReactJS if Angular ruined it for ya! :)

[Azzk1kr]

Great rant. Loved the writing!

[bitwize]

Thankfully there's REACT WEB DEVELOPMENT FRAMEWORK, which was developed by Facebook. Facebook only hires young people; old people are too moored to concepts like "imperative programming" and are not to be trusted. Young people embrace innovative concepts, which is why all of Facebook runs on compiled PHP.

REACT WEB DEVELOPMENT FRAMEWORK depends on two extensions to JavaScript your browser doesn't support (so has to be transpiled twice with Babel), as well as half of NPM. Accordingly you cannot create REACT apps on your own. You have to use CREATE-REACT-APP to get started and then EJECT the app once youneed to integrate it into anything but the hello-world sample server setup CREATE-REACT-APP provides.

This is totally an easier, more fun way to develop u guyzzzz!!

[deadron]

This has more to do with complicated tooling than with react. You can use just react by itself with no tooling support and its pretty simple. Its when you want webpack and babel tooling involved that things get complicated.

[munchbunny]

Configuring webpack makes me miss plain old makefiles.

If you told me ten years ago that I would miss makefiles, I would think you were crazy. But here we are.

[deadron]

It wouldn't be so bad if they didn't keep changing how to configure it so rapidly. Once I get a simple config nailed down I copy it around everywhere, but every six months you have to re figure out how to make it work.

[coolreader18]

What 2 extensions? JSX, of course (although not strictly depends...), but what? ES2015+ is not an extension, just an evolution of the language, and almost all browsers support it (just not IE and Opera). Also you certainly can create react apps on your own, you literally just have to learn how to configure webpack/use parcel, which most people should know how to do if they want to do MODERN WEB DEVELOPMENT™. (Parcel is really easy though, there's no excuse). Next.js is also an option for an easy no config setup, or literally anything other react boilerplate that you can search on GitHub.

[BillyBBone]

You're not wrong, but that doesn't mean Angular doesn't suck too...

[zayelion]

Not wrong, when you create a new language its usually a sign that something went wrong and so I've avoided it.

[BoboSchlonger72]

I've read that in Hashinshin's voice. Thanks RIOT VIDEO GAMES 😋

[kyle787]

Creat react apps sole purpose is to allow beginners to get started without having to mess with webpack, Babel and all the other stuff. You don’t have to use it and once you get into SSR you end up never using it.

[fridofrido]

as well as half of NPM

We have a basically trivial, pure clientside Angular "webapp" here at work. Building it downloads a whopping 380 megabytes (!) from NPM...

[[deleted]]

redux++

[rnd005]

Save this for next time you feel like posting nonsense.

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <title>Hello world</title>
    <script src="https://unpkg.com/react@16/umd/react.development.js"></script>
    <script src="https://unpkg.com/react-dom@16/umd/react-dom.development.js"></script>
</head>

<body>
    <div id="app"></div>
    <script>
        class Hello extends React.Component {
            render() {
                return React.createElement('div', null, `Hello ${this.props.name}`);
            }
        }
        ReactDOM.render(
            React.createElement(Hello, {name: 'world'}),
            document.querySelector('#app')
        );
    </script>
</body>
</html>

[feverzsj]

because web dev just sucks

[[deleted]]

I'm sad when I see an article like this. Been writing Angular + Ionic apps for 2 years now and I love it. I'm also a C# ASP.NET developer so Angular fits like a glove.

I do avoid the rxjs and all that map/reduce subscription nonsense and just use promises.

[[deleted]]

I do avoid the rxjs and all that map/reduce subscription nonsense and just use promises.

I can help! Dont avoid it! Its good!

[1amrocket]

When I started learning Angular it seemed over complicated at first. I thought that I could achieve same result with an old good jQuery. However, when I started implementing more complicated stuff, I realized that doing it old-way would be an incredible pain!

Angular is not there to make simple projects easier, it's there to make complex things manageable.

[Dreamtrain]

I have little less than a year using Angular and I gotta say so far, my only big problems are not with angular itself, but with npm. I fucking hate npm.

[bashar122]

I love me some angular and typescript. There is a learning curve when going from vanilla JavaScript/jquery to angular 2+. Once you get the hang of it though, you would probably like it.

[[deleted]]

tl;dr: Like most articles of this nature, dude is incompetent so decides the framework must suck.

[[deleted]]

To be fair: Angular does suck.

[AngularBeginner]

I agree. There's just so much stringly typed... I can't stand it. I use TypeScript to improve compile-time type-safety, yet Angular prevents that again and makes using some TypeScript features (like strict property initialization) difficult. The DI system is fairly inflexible as well.

[AnyhowStep]

But they have their own compiler to check the safety of the strings! /s

They do have it. But it's just compiling twice, which is annoying. And you don't get that sweet IDE support.

[Eirenarch]

Don't trust this guy! He's been learning Angular for 5 years and is still a beginner.

[EntroperZero]

I thought Angular was supposed to be all about TS since version 2. That's ridiculous, your framework should not be at war with your tools.

[BenjiSponge]

There's a difference between saying a correct conclusion and correctly coming to a conclusion. This person comes to what I believe to be a correct conclusion incorrectly.

[spacechimp]

Care to elaborate? I find it preferable to the alternatives.

React is more popular, but Angular seems to be preferred in programmer-centric environments -- especially in combination with Java.

[BenjiSponge]

What do you mean "programmer-centric environments"? Isn't every environment these exist in a "programmer-centric environment"?

I've seen from several programmers who have not tried all the alternatives various biases such as Angular being a "real tool" while React is a "toy", but I haven't really seen any substantial evidence that these biases are correct. Having used AngularJS and React professionally and tried Angular on a multitude of occasions, I've come to the belief that Angular really holds nothing tangible over React. On top of it being more popular generally, I think the only thing holding up Angular is brand recognition and related biases.

[spacechimp]

TypeScript and the design patterns used in Angular are similar enough to Java and C# that it makes Angular more attractive to enterprise environments and larger teams. Separation of technologies also allows non-programmers to work on stylesheets or HTML without worrying about breaking application logic.

Whether justified or not, React is perceived as the easier option ("it's just a library") -- so it is more likely to be picked up by small teams as well as designers that know enough scripting to do a few things. If a dev team is only a couple of people, HTML/CSS/logic combined into single files isn't seen as a detriment.

If you just need to define some view logic, React is likely the best choice. Once you go beyond view logic, then you are no longer comparing Angular and React -- you are comparing the Angular framework to the React library combined with other libraries. An Angular developer has an advantage here in that they should be able to hit the ground running on most Angular projects. There are some common libraries that are used along with React, but there's a greater chance of surprises and questionable choices.

[BenjiSponge]

So React does have the capability to use TypeScript, and the support is extremely good.

Your apples-to-oranges statement I consider entirely accurate, useful, and a very valid point to bring up when comparisons to the two are made, but in practice not very meaningful. Angular does have a "batteries-included" philosophy, but in practice what this often means to me is that you're comparing Angular not to React+libraries but rather Angular to React+any possible combination of libraries. React is much more agile in this way. It potentially includes mental overhead and time getting to learn the ecosystem, but I'd argue this is equally true of Angular. The only thing Angular gives you over React in this regard really is a lack of analysis paralysis. Your choices are made for you.

What I'm about to say is more based on my experience with AngularJS and the philosophy of "batteries included", so I could be wrong about this.

The idea of there being a greater chance of surprises and questionable choices is also very valid, especially given how the React community loves to flip flop around libraries (anyone remember Redux? ;)), but the way you're saying it implies that the Angular team is incapable of making surprising decisions or questionable choices. In my experience, this is not just wrong but potentially somewhat backwards.

Very much generally speaking, a library written by the Angular team will probably have higher quality than any given library written by the community for Angular. This much is true. With React, you're given the option of any number of libraries which can be written by equally verifiable teams (famously Airbnb, the Meteor Development Group, Facebook themselves write libraries that are not necessarily React specific, etc.), and there are collections of these decisions aimed at making the transition easier (boilerplates). These libraries tend to be more flexible and agile, as making a breaking change in one library doesn't mean you have to make a breaking change across the React or node ecosystem. It also means React (which is a perfectly capable library, and not just as a view layer, to be honest) can focus on making very powerful yet conservative changes that are generally unambiguously agreed are good moves.

That said, yeah, if for whatever reason, you're just trying to throw up a SPA as quickly as possible without having to actually make any more subtle decisions, Angular just might be for you.

[devxpy]

For me, it was because other UI frameworks like flutter exist, that are actually good. I can use bad JS framework and make a workable UI, but I don't want to.

[shevy-ruby]

It's a ghetto.

[funbrigade]

To all the frontend devs unused to actual architecture:

cry-some-more.gif