7 ms·

I've recently had to use Angular for some time after using React for years. It's.. been unpleasant. A few of my pain points. - Observables. I'm actually okay w

• renke1 6y ago
  I wholeheartedly agree with basically everything you said. Reactive Forms are really great in general, but not being strongly typed is really a shame. I am aware though that it's not easy to actually make it strongly typed for various reasons. For a component-based framework, it's way too tedious in Angular to actually create components. Too often I create big components because I can't bring myself to split it into smaller components. In React it is so natural to create components you can do it even while you develop a feature (without it being overhead). I hardly do that in Angular because it's just too much work.
  • geewee 6y ago
    Yes I think the Reactive Forms work really well for the most part, and the type-safety is such a shame. I agree 100% with the big components. I can literally feel myself thinking "I should split this up.. but it's so much work" - where there's just much less friction doing that in React.
• strombofulous 6y ago
  Out of curiosity how long have you used angular for? I usually have similar thoughts when first picking up a new framework before working with it for a few months to figure out how it's "supposed" to be used. (I have not used angular myself)
  • foepys 6y ago
    Their observations especially on Observables is very spot-on. We have quite a few "makeObservable(input)" in our code to make @Inputs observable. That the framework doesn't do it automatically is a bit of a let down. Same about Reactive Forms. Patching each @Output and @Input through a component by hand is also pretty annoying, especially if they change relatively often. A custom input field for a reactive form gets quite large due to all the in- and outputs.
    • geewee 6y ago
      Is there a good implementation of makeObservable() somewhere? I haven't been able to find one that seemed to work elegantly. Patching @Output and @Input is supremely painful - I really wish there was some sort of shorthand for that.
      • foepys 6y ago
        I cannot share the code we use directly but we use Object.defineProperty and override the getter and setter for it, tunneling the new setted value through a behavior subject that gets returned. The getter returns the value by synchronous access to the subject. Inputs into makeObservable are the component class (this) and the requested property name (generics with keyof).
        • geewee 6y ago
          Oh that's a clever way of doing it. Thanks!
  • renke1 6y ago
    Not parent, but I am using Angular for like 3 years now, I apparently have not yet figured it out. I am still baffled how hard it is to figure how to something is supposed to be used (and when do I am often shocked how it can be considered the right way…). It does not help that there a countless of Angular resources (blogs, Stack Overflow answers/questions) with low quality.
• stupidcar 6y ago
  They are finally making reactive forms strongly typed, at least[1]. On the Observables point, the Ngrx folks have created the @ngrx/component[2] and @ngrx/component-state projects[3] to try to build true reactivity into the component model. It's a shame this effort is happening outside of the main project, but it's something. [1] https://angular.io/guide/roadmap#better-developer-ergonomics-with-strict-typing-for-angularforms https://angular.io/guide/roadmap#better-developer-ergonomics... [2] https://ngrx.io/guide/component https://ngrx.io/guide/component [3] https://ngrx.io/guide/component-store https://ngrx.io/guide/component-store
• davedx 6y ago
  Yeah, typing in angular is kind of weird. Think Angular 9 was when templates got real type checking, but reading the documents it's still not clear to me what's enabled by default. Whereas with my react projects, if I use TypeScript and use the right file extensions, then everything is type checked, end of story. I also didn't like using observables with Angular to fetch/send data to API's. Not everything is an event stream, why can't we use the right tool for the job?
  • mgechev 6y ago
    Angular team member here. Strict type checking is often reported as confusing for folks getting started with Angular and web development. That's why by default our type checking is not the strictest we support. To make sure advanced developers have better compile-time type checking and editor support, we introduced strict mode. When you create a new workspace the CLI asks you if you want to get it enabled. In the future, incrementally, we'll be enabling strict settings for everyone.
    • davedx 6y ago
      Thanks for commenting! It still seems strange to me, if you start a new Angular project then you know you're writing TypeScript, no ifs or buts - and that means if you write some code that doesn't compile, you'll have to fix it before it runs. I don't understand why that's seen as different in the template layer? Great that it's there at all though, last time I developed with Angular templates didn't have type checking at all, and it kind of hurt.
      • mgechev 6y ago
        Sorry for the miscommunication. I meant type checking in general, not in Angular templates in particular. To get the same strictness as in TypeScript, you can enable `strictTemplates` in tsconfig.json. Here's our guide which goes into more details https://angular.io/guide/template-typecheck https://angular.io/guide/template-typecheck.
  • dmm 6y ago
• llimos 6y ago
  My biggest problem with it is it's basically a new JS-like language written on top of JS. You just don't write idiomatic JS (or even TS) in Angular. In templates is the biggest example - where you can use some JS constructs but not others, and have to learn a new set of directives instead of using if/for/while etc. But also things like modules being an empty class that's only there so you have somewhere to put your annotations. Not to mention needing to bundle a compiler, unless you use AOC, and the debugging is a nightmare (or at least used to be, I don't know if they've fixed it recently.) When your stacktrace is full of zone.js calls that are doing weird things because they monkey-patched Promise, you get the feeling that it's just not Javascript. Some might say that JSX in React is similarly not JS. I respectfully disagree. The syntactic sugar is so light you could easily translate it yourself, by hand. Try doing that with Angular code! And the trouble is that, as a new language that you have to learn, it is significantly inferior to JS/TS. So yes, give me React any day, where I can use real Javascript and not have to feel like the framework is fighting the language it's written in.
  • mgechev 6y ago
    Angular team member here. >In templates is the biggest example - where you can use some JS constructs but not others, and have to learn a new set of directives instead of using if/for/while etc. Templates, just like JSX have their own trade-offs. They are statically analyzable, so relatively easy to optimize by our tooling. Having HTML templates allows us to generate efficient JavaScript instructions for rendering and change detection. This has almost zero overhead on runtime and lets us perform change detection as fast as possible (we know exactly what has changed in the view). >Not to mention needing to bundle a compiler, unless you use AOC You don't need to bundle a compiler in Angular. The compilation happens at build time. After that we perform a lot of optimizations (having JavaScript instructions instead of HTML templates allows us to tree-shake more efficiently). >debugging is a nightmare Browsers hide the part of the stack trace that's coming from node modules, others let you blackbox non relevant scripts. To ensure smoother debugging experience for folks, we've been also working on providing better debugging guides and development tooling. We'll be rolling this out in 2021. >And the trouble is that, as a new language that you have to learn, it is significantly inferior to JS/TS. So yes, give me React any day, where I can use real Javascript and not have to feel like the framework is fighting the language it's written in. As I said above, it's all about trade offs. JSX is very expressive, but sets its own limitations. It locks you to a specific paradigm for incremental computations, which is not necessarily the most performant one. Templates are less expressive. At the same time, they are easy to optimize ahead of time. Neither of both is JavaScript, as described by ECMA-262. Comparing templates and JSX is definitely an interesting topic that's hard to cover in a comment on HN :)
• spyke112 6y ago
  Regarding observables, specifically the ones from HttpClient, i always just do a .toPromise(), and use async/await. My rule of thumb is that if i expect a stream of events use observables, but if it's a one of call, like a http request really is, then i use promises. If i need to memoize the data from the request, i do it in a service, and call through that.
  • modernlearner 6y ago
    Just ran into this when building a component to display and filter data. It was starting to turn into a monster when trying to use Rx.js and in the end, the code was simpler to understand with multiple for loops and forEach and map/filter calls. I ended up with a service that doesn't rely on observables.
    • nobleach 6y ago
      Not to mention, easier to test. I had a branch of my code where I had finally figured out how to reliably test the stream/observable variant, but it was just an ugly mess.
• mgechev 6y ago
  Angular team member :) "Inputs as observables" is probably the most discussed feature request on our issue tracker. I agree that there are strong arguments for going in this direction, but we generally try to keep `@angular/core` agnostic in this sense and not couple it to RxJS (EventEmitter is the only dependent abstraction right now). There are different reasons for that, but I'd say the two main arguments are: out of order component loading and ergonomics. There are a lot of developers who are comfortable with RxJS and enjoy how expressive it is. Simultaneously, we have a less vocal majority of either beginners or people who oppose such expressive APIs. Both of these groups use Angular, and we need to keep the framework ergonomic for them. That's why we have community libraries such as `ngrx`, which we consider as reactive extensions of @angular/core. >- The reactive forms has been untyped for years. It feels weird to ship with a forms module that seems to work pretty well, heavily invest on typescript, and then the forms are simply `any` - I mean what the hell? We developed reactive forms when TypeScript was still not as powerful as it is today. For the past years, however, the language evolved and it has very strict and expressive type system. We really want to make reactive forms much more struct :) Our team has been looking actively into that, but it's not trivial to fix the problem without introducing breaking changes in the public API surface. That's something on our radar, and we've been doing a lot of exploration, but given the adoption of Angular, we want to be careful and land it without breaking the ecosystem. In the meantime, we have community modules that provide much stricter forms implementation. Regarding fragments and the input/output model, we haven't received much of your feedback, but that's something I'll bring up to the team.
  • miohtama 6y ago
    Nice to see Angular authors here! As an another question, what are generally the legacy features holding you back you would want to change if you could do again everything with modern TypeScript, CSS and tooling?
    • mgechev 6y ago
      What's tricky to make forms stricter are proper typings for dynamically added form controls. We don't know what their types are since developers can add them at runtime. It's not impossible to make forms stricter, it's just a matter of planning how to make it in the least breaking way. Definitely from a very high priority for us.
• Griever 6y ago
  To address your point about the lack of fragments: It's not as clean as React's implementation, but you can set a component to "ViewEncapsulation.None" to help address this. Within a components template though, I frequently use <ng-container> to execute async pipes, or to perform simple conditional logic without adding unnecessary divs.
• JamesSwift 6y ago
  For so little experience, you've actually hit pretty much the same list as me (with a couple years experience). I don't agree so much with the last bullet point but otherwise spot on.
  • geewee 6y ago
    I'm glad that it isn't all just rookie mistakes and I'm not "getting" it :) I'm intrigued about you not agreeing with the last part though. You don't think it's painful to manually reroute inputs/outputs to child-components?
    • JamesSwift 6y ago
      Yeah, I don't find myself doing it as much as I felt like I did in react aka prop-drilling. React has context API and state to deal with it, angular you would probably use a service or dependency injection.