6 ms·

I seldom see this opinion but I'm glad to read it. People complain about JSX on the React side but what on Earth am I reading when I see the templating language

• EMM_386 3y ago
  > the templating language that Angular came up with? ngIf, ngBlah The new templating syntax is simply @if () @else () ... it makes it much clearer to read in many cases. I never had a problem with *ngIf as long as you are controlling the visibility of one element. It became messy when you needed "else" statements in there.
• ecmascript 3y ago
  I didn't care so much about the syntax but rather the over reliance on the subscriber pattern that you have to have like a subscriber to even read something as fundamental as query params. And the funny thing is that is will fire once and then again when the query params is actually set. So you will have an empty fire for when they are not yet set for some strange reason, presumably from when the observer is created. The problem with Angular, especially as the app grows is that you will have many different subscribers that all listen on the same state changes, then fire them again so you will have code that just runs again and again and it's extremely hard to have a mental model on how the system work and what code runs when. The code also easily gets super slow because you run something, it affect state, then it triggers something else that triggers something else that just happen to affect the first state, whoops now you have a loop. Even if the loop resolves, it's pretty much inevitable to get a loop sometimes if the app is complex enough, at least in my experience working with several other devs.
  • tashoecraft 3y ago
    Sounds more like a misunderstanding of the framework and observables. The problem many faced with angular is they chose not to learn observables, then got angry. If you have different subscribers, all on the same state change, you may not have chosen to use ShareReplay, or filter, or bothered to use a tool like ngrx that has memoized selectors. The same problem you're complaining about is the same thing people in the react community are complaining about because they never bothered to understand useEffect, and now have massive cascading updates. There is a very good reason they chose to make everything a subscriber, and it helps avoid pitfalls, because it doesn't hide away the async nature of everything. Signals are just a simpler way to understand and use that same async nature.
    • ecmascript 3y ago
      Well perhaps, but I think it's so overly complex and verbose to the point that learning it and making sure that everyone working on the project is on the same level is hard or near to impossible. I really tried to learn RxJS, I used a lot of different methods like filter and what not but I still got into a huge amount of issues but honestly a lot of that was because angular was not really fit for the type of application we were trying to build. Especially as we relied heavily on query params for state. There were many strange behaviors of Angular Router that I ran into several times. It has some kind of own internal state and fires updates in an unexpected way. I remember sitting hours just to try to get the query params to update correctly and I was not the only one having these kinds of issues. Even if I agree useEffect is unnecessary complex, it's still far far away from being as complex as RxJS and Angular. I remember I was trying to add some pipe service or whatever it was called and it was near to impossible to achieve what I wanted to do which would be trivial in any other framework/vanilla JS (unfortunately I don't remember what it was). Then using third party stuff in Angular is a nightmare as well. You have to deep dive into how it's being built to make sure all the stuff is brought into the build step etc. The configuration is a nightmare if you want to do something special like making use of Angular Elements that's barely documented at all. I never got to use the Signals feature, because I left the company before it got introduced into Angular.
    • datavirtue 3y ago
• chuckadams 3y ago
  The template syntax of Angular isn't the problem most people have with it. It's the boilerplate, the forced OOP paradigm, having to work with observables even when they're not appropriate (thus having to understand "hot" vs "cold" observables), and up until recently, having to scatter each component across three different files. And to top it off, when the lack of expressivity is touted as a feature for taming complexity, that points to a development culture that doesn't sit well with me either.
  • tashoecraft 3y ago
    You have literally never had to scatter each component across three files. From the first release of Angular 2, you had "single file components", with template, styles and js all in one file.
    • cout 3y ago
      You could do that with angularjs 1.5 components too. But afaik it was/is not standard practice to embed html and css inside your js, because many (most?) editors treat html inside a string as a string instead of as html.
    • chuckadams 3y ago
      It does appear I was wrong about the "until recently" bit: Angular still doesn't have a single-file component format like Vue or Svelte. Of course you can stick templates in string literals (and IDEA will even treat them as angular templates). Just be prepared to escape your quotes I guess. The official tutorial still uses separate files, and the tooling defaults to them too. Honestly the real shame is that IDEs don't present a more integrated UI for separate files, and that on the other hand in my Vue apps I still have to argue over the order of script/template/style sections. I guess Angular at least avoids that second problem.
      • usui 3y ago
        Isn't dealing with bare string literals for HTML-like syntax a terrible developer experience?