Comment by phil294 | Hacker News Reader

Comment by phil294 | Hacker News Reader

Parent Full thread

Angular is as little innovative for web frameworks as Firefox-ESR is for browsers. It merely keeps copying features from other frameworks - just many years later. It is a chronically outdated framework that always struggles to keep up with its competitors. It would be ok if those were deliberate design decisions, but if the features get copied some day anyway, what is the point? Why not do it the right way from the start?

For example, this update brings us computed properties, an essential feature for any complex performant web application that was made popular by Vue.js 10 years ago [1]. And now in 2023 we get it in Angular, essentially a confirmation by its devs that its lack had always been a design error.

I also cannot understand the "mature" argument. For example, it took five years for documentation on the integral `<ng-content>` to arrive [2]. This is something I'd expect from the side project of a lone programmer, not an enterprise-level framework.

The only upsides of Angular are its "batteries included" approach and the (debatable) default of RXJS, while the downsides are plenty (see other comments).

[1] https://github.com/vuejs/vue/tree/218557cdec830a629252f4a9e2... [2] https://github.com/angular/angular/issues/17983

What's the point? If you copy after there is some proof that the features work in practice, you are less likely to implement something that's going to make everything worse instead of better.

Frameworks are experimenting with thousands of new features which might improve something, but this doesn't mean that they do in the end.

People rely on Angular, this makes it important that everything is thought through. I don't want to become proof of concept tester for new features

> The only upsides of Angular are its "batteries included" approach

This basically trumps everything else though. Angular is likely going to have by far the lowest TCO for any projects with a 10+ year lifespan.

Like, sure, you need to watch 20 hours of Udemy videos to understand how to build an app, but that two weeks of work upfront is going to save you millions of dollars and multiple years of stress eating coffee pastries every morning.

Knockout.js, released in 2010, introduced computed properties to the web (slightly before Vue I think)

Not quite, its webcomponent implementation is ahead of React's, which is still pretty poor. Its PWA integration has been among the simplest and most seamless I've seen. It's easy to cherry pick examples either way.

Computed properties has always been a possibility in Angular, you'd just create a getter[0] based on multiple different values, works like a charm. This new way is probably faster, but I've honestly never had any issues with the other approach.

[0] https://www.typescripttutorial.net/typescript-tutorial/types...

Will the getter result be cached? If not, it's not a computed property.

According to what definition?

Isn't that just semantics? Whatever name you give the feature "lazily computed and cached values in the context of web frameworks", previously Angular didn't have them (built in) and now they do.

Angular did have it, it is called RxJS.

According to the "definition" on the Vue documentation page for computed properties: https://vuejs.org/guide/essentials/computed.html#computed-ca...

That describe what a computed properly is in the context of Vue.

Are you aware what comment tree you are in? This whole thing started because GP wrote this:

> For example, this update brings us computed properties, an essential feature for any complex performant web application that was made popular by Vue.js 10 years ago [1].

So obviously the relevant definition is "what the feature does in Vue". What is your issue here?

I’d expect that it’s not cached. But then I would go ahead and call that memoization.

The concept is actually slightly different. With memoization you store a map from inputs to outputs. A computed property doesn't necessarily do this, it just caches the result of the last computation.

The important part is that a computed property tracks its dependencies and is automatically re-calculated ONLY when necessary. If it behaves differently, it's not equivalent to the concept of a computed property in Vue.

The problem I had with getters in a fairly complex application (WYSIWYG editor) was handling mouse events, in particular onMouseMove - change detection was triggered on every such event, and the application was very slow. EDIT: It was slow because there were many getters based on other getters etc and everything was recalculated on each event.

I don’t think a computed property would behave any better. It sounds like your event handling should have been decoupled from change detection and only applied changes when necessary. This would probably be a problem in any framework.

This is an issue with zone.js + getters, I changed the key components to OnPush change detection.

Reply on news.ycombinator.com