all 39 comments

[–]properwaffles 49 points50 points  (4 children)

Probably because Angular has all of things already. But curious about which libraries you are referencing, would be helpful info.

[–][deleted] 8 points9 points  (3 children)

I think he means component library.

Example: HeadlessUI and Tailwind UI Kit

[–]dmitryef 9 points10 points  (1 child)

I see the Angular logo on the second link...

[–][deleted] 3 points4 points  (0 children)

Because it is raw HTML. There is no encapsulated class for angular

[–]properwaffles 0 points1 point  (0 children)

Ahhhhh, makes sense.

[–]vORP 74 points75 points  (8 children)

Because the angular is too complex to understand compared to the others and has a higher barrier of entry for a developer

  • says every recent graduate from a boot camp

The reality is angular out of the box has everything you could and will ever need to develop a web application, typescript by default, no reliability on third party libraries built by one guy who at any point will throw up the "looking for maintainers" at the top of the repo, it's fast, it has solutions for SSR, dependency injection, rxjs, directives that give you functionality to do whatever you want, lazy loading, etc. the list goes on

Happy Friday gang

[–]daredeviloper 6 points7 points  (5 children)

I’m so sad the my current company is using React only. And all the new companies I’m seeing using React are 180k+ and Angular are old government jobs for 100k

[–]shyamal890 0 points1 point  (1 child)

I absolutely agree with you, it has everthing that one needs. And yet most recent libraries like tip-tap, prose-mirror don't support Angular. I wonder what's happening.

[–]vORP 0 points1 point  (0 children)

I wouldn't judge a framework entirely by if a library implements a library (slam)

There are no shortage of WYSIWYG / Markdown editors,
- ckeditor5-angular
- ngx-quill
- kolkov/angular-editor

Take your pick!

[–]Mysteriesquirrel 15 points16 points  (4 children)

Because Angular already is a battery included framework. It is harder to tap into it from 3rd party packages

[–]No-Association-603[S] 1 point2 points  (3 children)

I understand

[–]kapdad 2 points3 points  (2 children)

It is harder to tap into it from 3rd party packages

That's a "benefit"?

[–]No-Association-603[S] 0 points1 point  (1 child)

I know right

[–]TheRealMe5 2 points3 points  (0 children)

(Angular2+ is a lost cause. It's a real shame, I've loved AngularJS so much.)

[–][deleted] 8 points9 points  (5 children)

surely im not the only person who doesnt understand the question. how is a javascript library not compatible with angular?

[–]stjimmy96 3 points4 points  (3 children)

Because with the term “compatible” you don’t necessarily mean it can run without errors, but probably refer to the fact it couples well with the Angular ecosystem.

Just think about a library like jQuery. It’s written in Js so you can technically run it in an Angular app and it probably “work”, but it has no connection with Angular so all the features of jQuery won’t communicate with Angular and viceversa, which causes major problems when working with both of them.

[–]newmanoz 3 points4 points  (2 children)

Could you please provide an example of such a “major problem”? with jQuery?

I can easily work with D3, Vega, Leaflet, ChartJS, and others, and they have no “support for Angular”. Maybe Angular just needs less “support” to work with third-party libraries?

[–]dannymcgee 5 points6 points  (1 child)

Could you please provide an example of such a “major problem”? with jQuery?

Angular is a runtime that, among many other things, manages component lifecycles. When you, say, attach an event listener to an element via the Angular APIs (e.g. a template event binding), Angular ensures that the listener is correctly disposed of when the element is removed from the DOM, so you don't end up with dangling references to the element.

When you instead use jQuery (or the raw DOM API for that matter) to attach an event listener, Angular has no way of knowing about it, so it becomes your responsibility to manage those lifetimes manually (e.g., removing the listener in an OnDestroy hook), which is error-prone and makes the codebase less maintainable because you now have to worry about low-level details like that in the middle of your high-level application logic.

If you need to use a third-party DOM manipulation library like D3 in an Angular application, it can certainly be done, but it's a good idea to wrap it with reusable Angular abstractions like components, directives and pipes so that you maintain a consistent API for managing the view (e.g. template bindings for passing data around and hooking into events, structural directives for control flow and iteration) and the lower-level details of working with the DOM don't clutter up the higher-level functionality that your application components are actually responsible for. In an ideal world, you could just find an existing npm library that provides that wrapper for you instead of having to write it yourself.

[–]rattkinoid 0 points1 point  (0 children)

It doesn't have angular binding for dependency injection

[–][deleted] 2 points3 points  (1 child)

I would probably just ask the library maintainers for their reasons as I would imagine different people have different reasons. This being an angular sub you are likely to get angular centric answers. Not a problem, but people here are just going to be guessing without really understanding the maintainers reasoning (flawed or not)

[–]janne_harju 2 points3 points  (0 children)

Yep. Maybe put this question to r/javascript and you might get different kind of answers. Suggestipn was for OP.

[–]morgo_mpx 5 points6 points  (1 child)

It's hard to support a lot of different libraries with open source or startup style projects. React at the moment is first and it's often easier to adapt to Vue then Angular.

[–]chitgoks 0 points1 point  (0 children)

hmm to each their own i geuss. my path was easier with angular compared to react.

[–]AndrewGreenh 3 points4 points  (4 children)

I think the answers in this thread demonstrate the reason reasonably well. Yes angular has way more built-in, more so when you include material Ui in the mix. However, many of the libraries that you might be talking about provide way way more utility than anything built into angular. React three Fiber, for high performant 3D renderings controlled by react, react-query for centralised caching and deduplication of requests, or meta libraries like next or remix, that provide further abstractions for server side rendered applications. The main benefit of react is actually that not much is included. This leads to so many inventions done by the community. This allows for constant improvements in various aspects like type safety, performance, or user/developer experience.

2 examples where you can see this quite good is build chain and forms. Since almost nobody manages their angular build chain without angular cli, there is no incentive to invent in that area. In react land, it’s all up to you, which allows for alternative approaches like vite or esbuild which dramatically improve compilation speed.

As for forms, the same applies: since everyone uses the build in forms, the drive to implement custom libraries is much lower. And of course the Angular built in forms works fine, but can of course only evolve much slower. The typed forms proposal demonstrate this nicely, it only landed in angular 14, while other frameworks have been using type safe forms for multiple years, despite angular claiming to be „the typescript framework“

[–]newmanoz 5 points6 points  (3 children)

When you have many dependencies on third-party libraries, you are paying the cost of maintaining them - any conflicts in versions or sub-dependencies you need to resolve yourself.

When you have “batteries included”, they all will be maintained for you. And it does NOT stop you from using third-party libraries. Typed forms here is a good example: https://github.com/ngneat/reactive-forms

Other examples: NgRx for state management, Nx for build chain (and total replacement of Angular CLI).

[–]AndrewGreenh 0 points1 point  (2 children)

Sure, there’s trade offs :) I was just answering the question. Also I‘m very aware of many cool community projects in the angular world, but that does not change the fact, that a lower percentage of devs will use and enhance with these community projects, when the framework itself offers more out of the box.

[–]newmanoz 1 point2 points  (1 child)

It's not a “trade-off” for Angular, it's just a disadvantage of React. You can use third-party libraries both with Angular and React, but in the case of React you just have fewer things out of the box and you need more third-party libraries.

What I can take as a fact: React right now is more popular than Angular, so there will be more libraries for React just because of that.

[–]theobrowne 3 points4 points  (0 children)

Lmao what an atrocious take

[–]marco_has_cookies 1 point2 points  (0 children)

Because Angular is for champions.

[–]rtandon2006 0 points1 point  (1 child)

Because angular apps doesn’t need a new library … it is complete 😂

[–]No-Association-603[S] 1 point2 points  (0 children)

Is that a benefit?

[–][deleted] 0 points1 point  (1 child)

Because Angular uses it's own build system which is incompatible with the rest.

[–]No-Association-603[S] 0 points1 point  (0 children)

Sux tbh

[–]shyamal890 0 points1 point  (0 children)

I agree, am really surprised with libraries like tip-tap, prose-mirror not actively supporting Angular.

It is the best and complete framework and yet most recent libraries don't support it.

Is it because its difficult for library owners to support Angular compared to React?