Angular v16

https://blog.angular.io/angular-v16-is-here-4d7a28ec680d?gi=59158dd70516

by Alex3917 • 3 years ago

165 249 3 years ago

blog.angular.io

andix15• 3 years ago

Important new features. But in my opinion too little, too late. To me it feels like Angular is slowly dying. No idea though, why so many companies still use it for new projects.

Bilal_io• 3 years ago

To me it feels like Angular is slowly dying. No idea though, why so many companies still use it for new projects.

These seem like two contradictory statements.

I use Angular at work and I love it. And the sentiment is similar among my peers.

andix15• 3 years ago

It’s not really contradicting. I think Angular and it’s ecosystem is falling behind compared to their alternatives.

Do you also work with other frameworks? And why do you prefer Angular?

koito172• 3 years ago

No idea though, why so many companies still use it for new projects.

If I had to guess, it has a mature ecosystem, it is still actively developed, and it has already been "battle tested" by various companies. Angular is a "boring" choice, and some people prefer to stick with boring solutions than exciting, new solutions.

To me it feels like Angular is slowly dying

See https://2022.stateofjs.com/en-US/libraries/front-end-framewo... and select "Usage". If you want to trust the results of this survey, Angular is the second most used front-end framework. Unfortuantely there are no statistics for 2023 yet.

andix15• 3 years ago

But also the framework with the highest „used it > would not use it again“ votes :)

threatofrain2• 3 years ago

https://npmtrends.com/@angular/core-vs-react

willio58• 3 years ago

I agree. To answer your question it's really just companies sticking with what they know. Just like how a huge portion of the internet is still built on PHP.

Check out this chart (click rankings in the top right): https://2022.stateofjs.com/en-US/libraries/front-end-framewo...

You'll notice when sorting by Retention that Angular is falling off hard, but by Usage and Awareness it's been steady for years at the top.

Retention: would use again / (would use again + would not use again)

Usage: (would use again + would not use again) / total

Awareness: (total - never heard) / total

By those metrics, the number of people wanting to keep using Angular has been falling for years. But they are forced to by some external control.

andix15• 3 years ago

The number of people wanting to keep using Angular has been falling for years. But they are forced to by some external control.

Exactly my experience. I often ask why angular was chosen for the task, and usually the answer is: because the architect put it on the slides, and because we hire angular developers.

thuuuomas• 3 years ago

Agreed. Stewardship of the angular ecosystem is lacking. Versioning across first-party @angular packages isn’t consistent. Some @angular packages are in permanent beta for unknown reasons. Anything besides the latest release is abandonware.

andix15• 3 years ago

And a lot of community libraries don’t work for new releases. Often they seem to need an update to work with the current angular version. React usually doesn’t have that problem. And because of their much smaller focus they only have major releases every 18 months or so.

jmkni• 3 years ago

I know Angular isn't 'cool' on HN, but damn I'm excited about this! Signals in particular.

Well done to the Angular team.

pwb253• 3 years ago

I don't get why, Angular is really nice and has so much included and is well documented and no need for reflux and redux libraries that might do or not do what you need

Illniyar• 3 years ago

I don't know about others but the move from AngularJS(v1) to Angular burned that bridge for me.

Developers have long memories. And the fact google keeps burning good will with other shutdowns isn't contributing.

Besides that Angular is also a heavy framework (gives a lot, but requires you to do things in a very specific way) where hacker news crowd has usually a preference for unintrusive frameworks and ones that give a lot of freedom and leeway.

Jochim2• 3 years ago

I worked a bit with AngularJS. My, definitely over-exaggerated, feelings are that it was a hideous abomination. It's been long enough that I can only remember how awful it was to have to register everything with the right strings. A lot of negative sentiment towards modern Angular is probably a holdover from that.

Modern Angular on the other hand just seem full of pointless boilerplate. From a personal perspective, the way it's typically structured just feels verbose and clunky compared to React.

rk062• 3 years ago

Look at this way, angular 16 is now introducing signals, vite support and improving standalone components.

Now, let’s compare to Vue, Vue has Standalone components, vite support, signals since v3. And fine grained reactivity since v0.

So, one must ask if here things are so good, why stick with angular and wait for everything to stabilise when you can jump ship to Vue now?

Similar argument can be made for react, though I admit hat Angular to react transition won’t be as easy.

And this is in context of newer advancements only. When you take a step back and look, you will see many cases where certain angular issues are only in angular. While rest of the js frameworks are converging

xupybd3• 3 years ago

How do you find the upgrade path. It's been a long time since I was working with Angular 2. I felt a little fear at the pace of improvements. It seemed that for a long lived application I'd be forever spending time upgrading the framework. Is that what it's like or are the upgrades reasonably easy?

orbz• 3 years ago

They're actually surprisingly good at making the update process as painless as possible: https://update.angular.io/?v=15.0-16.0

knallfrosch4• 3 years ago

I feel like there's a real major upgrade every 3 years, which is reasonable given the pace of web development itself. The "Ivy" renderer was a big one, but it was introduced in 9 and you had until 12 to transition. Still, these were like 5% of what you had to do from AngularJS to Angular2+.

Now 14 to 15 is a bit more work again, but they have introduced an upgrade guide like this: https://update.angular.io/?v=14.0-15.0

throw_m239339• 3 years ago

My React V1 app still works with the latest React version. That's why I don't like Angular.

steve_adams_865• 3 years ago

They’re different things, though. React has a lot less going on. If you want something with a stable API for the tasks React is suited to, it doesn’t make sense to throw Angular at that job.

vekker2• 3 years ago

Angular has been pretty stable since the v4 release. I recently did an upgrade of a large enterprise app from v8 tot v15... Jumping 7 major releases, no problem with the migration tool.

matsemann• 3 years ago

That's only the rendering, though. If you used other libraries (that's already included in angular) you wouldn't be able to say the same. For instance if you use routing in react, you've probably have had to rewrite your app 6 times by now.

rr8082• 3 years ago

Damn, we're still trying to get off angularjs.

_boffin_2• 3 years ago

damn... i'm sorry. sooo so sorry.

mkrishnan8• 3 years ago

angualrjs is a good framework btw for decent business use cases.

rr8082• 3 years ago

Yes it works great. Its just another victim of the relentless frontend upgrade cycle.

throwaway2990• 3 years ago

Angular is good for businesses which are your competitor so you have an advantage over them.

whalesalad• 3 years ago

Im ashamed to admit this but I’ve spent a notable percentage of my time in therapy discussing angular and recovering from PTSD.

nawgz3• 3 years ago

I think the top issue in React-land these days is definitely that reactivity is not provided as a built-in. I agree that lots of libraries have achieved pretty decent DX in that regard, because the hooks API is actually very powerful and reusable, but I wish the React team wanted this for us all.

Congrats to Angular team for delivering what sounds like a pretty thorough reactivity implementation. I think their opinionated and provided-by-Angular strategies make it a tempting option more and more over time, even though I enjoy my React stack.

bitL9• 3 years ago

How many apps actually benefit from reactivity, i.e. 1,000 people can post to a feed realtime and the app fetches data from 200 other backend services? I believe for vast majority apps, a basic HTML/JS/CSS is all one needs. It's fairly trivial to make your own SPA in ES7.

geraldwhen• 3 years ago

Try having 15 committers in the same codebase. It won’t scale.

nawgz3• 3 years ago

If you don't know the use-case for reactivity and are going to advocate for "vast majority apps" being authored in "HTML/JS/CSS", I don't really understand why you're debating me.

Frontends - that are clearly more complex than the ones you use - are state machines managing asynchronously-accessible state stored in external services. Due to the nature of how many resources an application might use, it quickly becomes cumbersome to map out that state machine manually, and it is more beneficial to just write declarative display logic that will automatically execute when the necessary preconditions are present and a change has occurred within the state management.

Now, mind you, nothing I've said really involves reactivity yet; and, even worse, most solutions - especially your custom SPA - will rerender the entire tree of objects relying on each changed resource in order to accomplish what I listed.

The beauty of reactivity is that you as a developer simply write modular code - whether it's state or view, the more modular the better - and then your system ensures changes to the underlying state tree flush updates to the view modules attached exactly to the parts of the state tree what changed. It's optimal performance by default, you run the least amount of your own code each time a change happens.

Of course, it brings its own challenges and issues, but it really means that your general answer to "how can I scale this UI" is just "write it in smaller chunks", and that scales pretty dang finely across a team.

Unlike a hand-rolled ball of JS. Come on folks, it's 2023, put your tired arguments away.

liminal• 3 years ago

I guess SolidJS should be very flattered! Signals seem very inspired by it. Overall I'm excited by these changes. Rxjs is great in many ways, but it's always been a bit awkward in Angular (e.g. Components hide that Inputs are Observables, so you can't just pipe between them).

laurels-marts• 3 years ago

I think Signals existed before Solid and is not unique to Solid.

NayamAmarshe• 3 years ago

Thank you for the updates, Angular. I don't like working with you at all but your updates kinda assure me that at least I'm not working on legacy software.

mrcino• 3 years ago

Jesus Christ, another version?

Let people learn previous features as having a feeling that your framework is constantly delivering new stuff and that you need to constantly catch up with them is increasing FOMO and is making people unsecure...

seattle_spring• 3 years ago

Would you have made the same comment if they went by minor versions instead, and this was v1.16.0?

mablopoule3• 3 years ago

Honestly, except maybe for the phasing out of Ivy, updating angular tend to be a non-issue.

(And yes, also the shitstorm that was AngularJS to Angular (4+), but that was a long time ago now.)

mupuff1234• 3 years ago

Am I the only who finds RxJS to be really unintuitive?

I never had any issues in the past with futures/promises libraries, but for some reason I can never remember how to use RxJS.

throw12346512342• 3 years ago

I feel like most of the RxJS functionality doesn't have a real use case. At the end of the day, you are doing an async call, something axios handles just fine. I did a bunch of presentations on RxJS, so I understand it fairly well, but I have never used it past basic API calls "irl".

codethief• 3 years ago

I feel like most of the RxJS functionality doesn't have a real use case.

I disagree. I have implemented several use cases using RxJS which would have otherwise been significantly more difficult to solve. (Think timing parallel sequences of animations und other UX effects etc.)

88913527• 3 years ago

The biggest benefit, which I haven't found much of a practical need for, is you can continue to emit 1...n times, whereas a Promise only resolves once. Since it's an indeterminate number of times, you need to subscribe and unsubscribe to prevent memory leaks, so it just adds more overhead. Use a Promise if you only need to resolve once.

JenrHywy3• 3 years ago

If you get on board with it fully in Angular, rxjs + async pipes can make things pretty clean.

andix15• 3 years ago

Yes, RxJS is extremely hard to use. I developed on a lot of different technologies, but RxJS is one of the things I never seem to get a hang of.

It’s not just the syntax (so (many (brackets)) and => lambdas), but it’s also really hard to create a mental model for what’s happening.

I know that react hooks are not a replacement for Rx, but really often you can program similar functionality with hooks and it’s just 10 times easier to read.

mediumdeviation• 3 years ago

RxJS, more specifically its primitive Observables, fills a different space from Promises. For simple cases where only one value is emitted Promise probably works better and is more intuitive, but there are certain things that Promises cannot model - specifically when there is a stream of events over time. RxJS is more complicated because it needs to model more complex things. I do think Angular made a big mistake overusing it in places where Promises would have worked perfectly fine, but when you do need it it does work pretty well.

pcthrowaway• 3 years ago

I do think Angular made a big mistake overusing it in places where Promises would have worked perfectly fine, but when you do need it it does work pretty well.

Was it really a mistake or were they just using it before native promises were widely supported?

mattigames2• 3 years ago

RxJS really needs a better debugging experience, I would love some visual representation (like a graph?) of all the events and how they relate to each other (who is waiting what, what has been waited, what was canceled by whom, etc). I tried a few plugins and browser extensions that supposedly do that but they all crashed, in their defence it was probably because it was a huge monolithic app.

andix15• 3 years ago

Fixing something too complex by adding additional complexity? :)

archarios• 3 years ago

I haven't used rxjs specifically a whole lot but I am a fan of the general declarative pipeline style that it promotes. A different JS library that I've used extensively that promotes a similar style but for more general purposes is Ramda. It is a very different approach to programming than is common so I understand not finding it easy to grasp. In my experience, the benefit is generally that there is less clutter in your code and the dataflow that is happening is a lot more explicit which helps me build a mental model of what is happening a lot more quickly.

ChatGPT is actually pretty good at exploring these different styles btw. It is pretty good at taking one code example and implementing it in different ways when prompted.

riku_iki2• 3 years ago

you still can use promises if you want?

xupybd3• 3 years ago

I'm not sure if you have spent much time in a functional language but I found this helped me understand what is going on with a Promise and an Observable. They're all Monads. Just like List and Map or the optional Monad.

When I first started learning that sort of thing it made no sense at all. But now it's just a design pattern that allows you to organize things. Having that understanding helps abstract away some of the mechanisms in the observable.

It helped me at least. YMMV

nine_k• 3 years ago

Indeed! The concept of Monad is simple and very useful; once you learn it, you start seeing it everywhere.

JS Promises are not completely monadic though, because a Promise that resolves into a Promise is always effectively auto-flattened into a single Promise. But most of the time other monadic properties of Promises can be used despite this.

miiiiiike5• 3 years ago

Unintuitive? Yes.

If by unintuitive you mean “Can I look at it without training and know what’s going on.” But the problems they solve are also unintuitive. Only, those issues can be buried under a tangle of nested callbacks that look correct, intuitively.

Once you take the time to really (and I mean really) understand RxJS it’s incredible. Write your own Observables. Write your own operators. Learn what the built in operators are really doing (subscriptions, etc) reimplement them yourself.

JohnCurran2• 3 years ago

First: This is not an attack on you

I have such an issue with this response because it just seems like “you’re holding it wrong” a la the iPhone “scandal” where apple attempted to blame an engineering flaw on its users

I would imagine most people’s use case (mine certainly is) for RxJS boils down to “call a JSON API and receive a response”. That shouldn’t be a hard problem

Imagine if someone complained about the complexity of Git and the answer was to “write your own DVCS”

The entire point of abstractions is that I don’t need to understand what’s going on underneath them

peebeebee• 3 years ago

I worked for 4 years intensively with RXJS. I love the concept, but it quickly becomes a mess in readability when trying to merge different data sources.

nvahalik• 3 years ago

I've seen components rewritten using observables to be sometimes a full 1/4 of the original size.

The biggest thing for me is the realization of the "source of truth". With observables, if they are set up correctly, you can see the exact bits of information that some resultant stream are dependent upon. Operations then can have a single action because all of those sources can be muxed together rather than having several calls throughout a component to doSomeAction().

bonestamp2• 3 years ago

Yes, and that's part of why they're adding signals.

Frotag• 3 years ago

My goto example for RxJS are event handlers. Heres an example that implements drag-and-drop (for which the vanillajs / d3js versions aren't nearly as pretty)

It basically translates to

1. Wait for a mousedown event

2. Start listening for mousemove events

2a. On each mousemove event, do something

2b. When a mouseup event occurs, stop listening for mousemoves and return to 1.

    import { fromEvent } from 'rxjs';
    import { exhaustMap, takeUntil, tap } from 'rxjs/operators';

    const el = document.querySelector('body');
    const mousedown$ = fromEvent<MouseEvent>(el, 'mousedown');
    const mousemove$ = fromEvent<MouseEvent>(document, 'mousemove');
    const mouseup$ = fromEvent<MouseEvent>(document, 'mouseup');

    mousedown$.pipe(
      exhaustMap(mousedownEvent => mousemove$.pipe(takeUntil(mouseup$))),
      tap(mousemoveEvent => {
        console.log('mousemove')
      })
    ).subscribe();

https://stackblitz.com/edit/drag-and-drop-rx-rvdkzv?file=ind...

---

More specifically I've found RxJS makes simple one-off calls (eg API fetches) ceremoniously painful (do I need to unsubscribe? do I get the value sync-ly or async?), but anything that involves multiple values (eg websockets, polling, event handlers) gets much cleaner.

My biggest complaint with RxJS is probably the dev experience though. It makes call stacks / the debugger useless so you have to get comfortable with console.log's everywhere. Which is one of the reasons I avoid chaining observables and filter()s in general.

tcfhgj4• 3 years ago

Hmm I agree with call stacks, but the debugger is doing fine

iansinnott2• 3 years ago

RxJS _used to be_ more intuitive, IMO. Around version 5 or so the API changed to use `.pipe` instead of simply chaining operators. Also, some functions were renamed to be (unintentionally, one assumes) more opaque. Such as `flatMapLatest` -> `switchMap`.

Anyhow, there's definitely a learning curve but what it provides is very powerful. It's unfortunate, IMO, that the API has become less approachable over the years.

steve_adams_865• 3 years ago

Although I see how chaining might feel more intuitive, pipeable operators allow for a lot more intuitive and readable composition, making it so you can create reusable and easily tested operators, or even sets of them.

It’s great for what it’s designed for, but you’re not wrong either. Composition can be hard to manage and navigate where a chainable API can be easy to follow and interpret by simply reading the flow.

I think RxJS is actually amazing and I like the path they chose, but I see why it isn’t more widely adopted too. It isn’t nearly as intuitive as it maybe could be.

Tade03• 3 years ago

Same.

I've found that this is one of those things that half of the developers never learn to use properly and is therefore a net negative.

In Angular specifically it offers a spectrum of footguns, my favourite by far being passing an observable as an input.

Will the component re-render when the observable emits? Who knows? It depends on more than one factor.

Interesting things also happen when it's a cold observable, it errors out or just completes.

Overall it's quite the circus and I've been in teams where most of the developers had only a surface understanding of what was going on.

That in and of itself is actually not a showstopper until someone decides to create their own component library.

commitpizza2• 3 years ago

The problem with RxJS is that it feels like Node did in the beginning. It's hard as eff to figure out where the system goes, what happens when, in what order etc.

knallfrosch4• 3 years ago

What's concerning is that when people use Observables, 90% of the time you need to break out of them again.

Subscribe, (value) => currentValue = value, do some calculation, onDestroy unsubscribe..

I don't know whether people really solve complex problems or whether they just appear complex when you use RxJS.

Klaster_13• 3 years ago

Have you tried `async` pipe and `takeUntilDestroyed`? I only ever `subscribe` if I need to trigger side effects, like setting a form validator based or a value (probably can be replaced by async validators) or modify DOM outside of the app root.

easton• 3 years ago

Hopefully ngcc being dead makes build/CI times go down. It's real bad :(

(Also, hopefully in the next release or two their esbuild based builder is good enough to use for everything. these 30 second+ reload times when almost nothing changed are the worst.)

virtualwhys• 3 years ago

30+ second incremental build times? How big is your app?

Presumably you haven't implemented lazy loaded routes?

mkrishnan8• 3 years ago

this v16 is quite interesting due to signal. you'd like it.

AbuAssar5• 3 years ago

I wish Angular had a good meta framework like next

saila• 3 years ago

I haven't used it, but there's at least one active Angular meta framework: https://analogjs.org

AbuAssar5• 3 years ago

yea looks promising but still very young

Tade03• 3 years ago

Nest is the closest thing to that, but only in spirit:

https://nestjs.com/

_boffin_2• 3 years ago

I really really love nestjs. After working with Spring in Java land for a few years, just just makes so much sense.

bitL9• 3 years ago

Isn't it easier just to learn ES7, use async/await whenever possible, learn how to do div display=none/block, read some CSS tutorials and forget about learning any JS framework?

duxup3• 3 years ago

For a page with a couple forms sure.

For an application with state and such, maybe not.

bitL9• 3 years ago

It's easy to make your own SPA using div display: none/block, so is routing. Global store is also pretty easy to do including update events. Async/await makes backend calls super simple, one could still use promises for a few more advanced cases as well, or even go full Saga pattern. Why is a framework needed these days?

NERD_ALERT2• 3 years ago

React is an industry standard tool. If you want to have relevant frontend skills you should know React.

bitL9• 3 years ago

Tell that to authors of angular, svelte, nuxt etc. They are all obviously missing something.

rafark2• 3 years ago

I don’t like this suggestion. I mean, it’s a good, solid suggestion. But I don’t like everyone using the same thing. A market dominated by a single entity means less competition which means less innovation.

If we didn’t have competition we’d all still be using jquery.

pjmlp3• 3 years ago

Relevant frontend skills is what the browser supports, that will stay the same regardless of ASP.NET, Spring, Rails, PHP, express....

mablopoule3• 3 years ago

As a long-time Angular user I had the exact same feeling, and was glad when I finally could switch job to one with a React and Next.js stack.

Which is when I truly discovered the state of the React ecosystem, and noped the f*ck out of it. Design systems that recreates the <strong> tag but with a React component, the abomination that is CSS-in-JS and "typed CSS", mixed with some of absolutely brilliant libraries with well-thought out APIs, mixed with "best practice" du jour made by clueless frontend devs rehashing arguments in a truly blind-leading-the-blind fashion.

And I do like React, and might probably use it again, but it has the downside of being the defacto choice for new devs, which creates a huge spread in the ecosystem quality that other "second languages" ecosystems such as Rust or Elixir won't tend to have.

(I know that I'm mixing a framework with a language, my point also stand for the whole JS/node ecosystem, just doubly so when you focus on the React side of the NPM ecosystem.)

rafark2• 3 years ago

https://cdnmetv.metv.com/z50xp-1619719725-16226-list_items-n...

andix15• 3 years ago

Learn a a frontend framework first, and once you know all their tricks you can go back to vanilla js.

jon-wood• 3 years ago

Sure, why not? I assume you’re volunteering to rewrite however many billions of lines of Angular are in the wild in that manner.

bitL9• 3 years ago

If it makes my app simpler, sure. It often does.

_the_inflator• 3 years ago

Angular is a fantastic framework. Congratulations to the team and hopefully see you again next year latest, Angular team.

AbuAssar5• 3 years ago

next major release is after 6 months, so still in 2023

ShaneMcGowan2• 3 years ago

Very interesting seeing Angular getting many of the features that EmberJS has had for a while such.

AbuAssar5• 3 years ago

such as what?

ShaneMcGowan2• 3 years ago

Computed properties, Stand alone components, “signals” already exist in Ember in some form to prevent constant recomputing of getters, route data being available in components directly

madethemcry• 3 years ago

First standalone components to get rid of modules and now signals. There is quite some innovation happening in Angular while being a really mature framework.

I enjoy Angular as much as I love React, Vue or Svelte. It's always about picking the right tool. And when thinking of Angular it's that batteries-included framework that is godsend for big enterprises where any decision given by the outside is something you don't have to battle for.

Often I describe Angular as a hidden champion. It's loved and trusted by enterprises while they are not really talking about it. Plus they hide all the package downloads behind their own npm caching servers like Nexus or Artifcactory.

On the other side there are tons of individual engineers working with React or Vue (for good reasons) and writing blog post after blog post. Maybe that's one reason why folks think Angular is dying? I don't see any signs of that though.

paulddraper5• 3 years ago

In my experience people that hate Angular don't understand why they hate Angular.

Like, if you like Svelte, that's great. You will probably like Angular too.

riku_iki2• 3 years ago

I like Angular, but approach of doing the same thing in 3 different ways (promises, rx and now signals) make codebase more complicated and adds additional brain load.

warent• 3 years ago

Their own website renders the Angular "template" as a string with no syntax highlighting.

The framework is extremely overengineered requiring multiple files for "hello world"

It introduces a lot of unnecessary complexity for projects of any size

It uses invalid HTML, with attribute syntax including brackets and parentheses

Sadly It's just not a good framework

Zanfa3• 3 years ago

In my experience people that hate Angular don't understand why they hate Angular.

One of my major annoyances is the templating language. Completely unnecessary and over complicated, compared to JSX. Just another weird syntax to learn with its own arbitrary limitations and quirks.

I think it’s a good indicator of the overengineering surrounding Angular overall.

jbergens• 3 years ago

I can just note that our Angular code seems to be much harder to maintain than our React code.

The React ecosystem also improves faster (yes, sometimes a bit too fast).

snemvalts3• 3 years ago

The entire library is so spread out, with so many half-assed features.

When I wrote Angular I spent 2 weeks on getting something similar to `props.children` working. <ng-content> didn't work if the elements were dynamic. Outlet system was way too verbose.

The 2 way databinding is anachronistic and belongs in 2010.

The i18n system they shipped with is awful. No way to have translations in code, only in template. This breaks down very fast when building generic components.

The DI relies on https://www.npmjs.com/package/reflect-metadata, which makes the builder an opaque black box unlike a webpack configuration.

Because of the opaque CLI I've spent 2 weeks figuring out why every third dev build resulted in a 150 line long tsc stacktrace, and it turned out to be angular's 1.x types package. Would have been so much easier with a webpack configuration.

nikeee• 3 years ago

Having mutability/2-way-databinding makes angular hardly benefit from using TypeScript. State is just so much pain and it is hard to make impossible states not representable in the types.

Angular requires a lot of extra steps to get the templates properly type-checked (and you even need an editor plugin for that). I can't even name which non-standard entries in the tsconfig are necessary to have all templates checked entirely.

Most people use the cli to generate new components. Where in other frameworks, you just create a new file, maybe use a snippet and call it a day, the cli yields a test, scss, html and the actual component code as separate files.

Having worked with angular and react for 5 years in parallel, I'm pretty certain that I'd never touch angular again. The DX is so complicated in comparison. Despite forcing you to use TypeScript, angular is the framework that benefits the least of it.

ttfkam2• 3 years ago

A 3MB JavaScript runtime blob right out of the gate? ("Only" 275KB needed just to first render, like that's laudable on its own.)

Other frameworks have already loaded dependent REST/GraphQL data before Angular has even initialized.

Take someone on a mobile device and put them at the edge of cell signal range either because they're out an about or stuck in the bowels of a building with thick walls. Suddenly 275KB-3MB matters a lot more and the user is staring at a blank screen for 10+ secs.

Then there's the boilerplate, all the metadata you need to add to each component that has nothing to do with your problem domain.

And then there's runtime speed compared to alternatives.

While I'm truly happy to see Angular incorporate signals, now devs need to learn when to use signals rather than rxjs. I know now that it's the difference between needing async or not, but if you go down one path, it's a PITA to tear it down and rewrite for the new path.

THAT's why I don't like Angular, though I'd happily choose Angular over React and Vue, both of which are a prone to reducing codebases to big balls of mud due to their "flexibility".

ttfkam2• 3 years ago

How about the extra 30 seconds to couple minutes for CI/CD to make a production build for static deployment? V16 added the ability to put esbuild/Vite into the mix, but it still builds WAAAAAAAAY too slow compared to modern alternatives, especially if you're on v15-.

ng serve for development is a pig too. Save-reload cycle is far from instant.

phil294• 3 years ago

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

politelemon2• 3 years ago

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.

neamar• 3 years ago

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

spyke1124• 3 years ago

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

Alex3917• 3 years ago

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.

tcfhgj4• 3 years ago

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

epolanski2• 3 years ago

I just don't like Angular at all.

Every version essentially breaks the previous one.

90% of the information online is outdated or incorrect. By the time you start a project on Angular X, Angular X+2 is out which makes many things complicated, some deprecated.

It's true that it provides a robust set of defaults and libraries but those are generally an overkill for most projects.

On top of that there's a higher compilation complexity in Angular which I have seen every single Angular project struggle at some point.

spyke1124• 3 years ago

The Angular team has this nifty little update tool[0] that helps us through running migrations and preparing the code base for upgrades.

[0] https://update.angular.io/

1thrasher• 3 years ago

Every version essentially breaks the previous one.

This is simply not true. It might have been true in the early Angular v2 days, but since v6 or so, updates are relatively trivial.

https://update.angular.io has your back extremely well. The trick is to ensure whatever third party libs you're using have also been updated, otherwise you're application may break.

ggorlen• 3 years ago

I don't see any signs of that though.

Even if we take it for granted that package downloads are hidden, how should we account for the ~40% drop in new questions in the Angular tag on Stack Overflow since its peak in 2018?

https://insights.stackoverflow.com/trends?tags=angular%2Crea...

In the Stack Overflow developer survey last year, Angular was 52% loved versus 68% for React and 63% for Vue. Can we find a way to dismiss this as well?

https://survey.stackoverflow.co/2022/#section-most-loved-dre...

On the freelancing platform Codementor, based on rough sampling, there have been about 338 Angular requests in the past year versus 2098 for React (6x).

Sure, Angular won't die outright because the enterprises that have adopted it will need ongoing support, but this seems like a weak metric for growth. For enterprises selecting a tech stack now, choosing Angular chops the hiring pool by a significant factor. I don't see evidence of advantages Angular offers overcoming that.

On the other hand, React has gained new life through frameworks like Next.js and maintained relevance. React's popularity is not just individual engineers making a disproportionate amount of noise on blogs. React hooks are the most established unit of construction for making components at this point across web, mobile, desktop and command line. That won't last forever, but there are too many signs of Angular trending out and React trending upward to dismiss.

n0us• 3 years ago

Required inputs
Since we introduced Angular in 2016 it has not been possible to get a compile-time error if you don’t specify a value for a specific input. The change adds zero overhead at runtime since the Angular compiler performs the check at build time. Developers kept asking for this feature over the years and we got a strong indication that this will be very handy!
In v16 now you can mark an input as required

Amazing to finally see this land, awesome release

valcron1000• 3 years ago

Signals are a step in the wrong direction. They provide extremely little value over RxJS Observables (ex. avoids glitches when you have diamond-shaped dependencies), but you sacrifice so much in return, like control over async operations.

The API looks like it wants to attract React devs, and I fear that it won't accomplish that but instead it will drive away the remaining Angular devs. In no time we'll see SO spammed with questions using `computed(async () => ...` or race conditions when using `effect`.

jamra2• 3 years ago

Removing the diamond shaped update chain is pretty huge. It also removes a lot of the entry cost to getting into Angular. RxJs is steep.

cuddlecake• 3 years ago

In no time we'll see SO spammed with questions using `computed(async () => ...` or race conditions when using `effect`.

As opposed to the very few questions about rxjs, where people understand everything perfectly.

falafel• 3 years ago

I like Angular and I think it's still a solid choice for new apps in an enterprise setting, and signals are a welcome addition that solve real problems, but I don't understand the hype. Signals are as old as JavaScript if not older. The diamond problem and sync propagation are not new problems. We've come full circle. Old problems become new problems but with the same solutions. What did we gain with all of these iterations if we landed back on what was essentially the Knockout model of 2010?

I'm reminded of papers such as "Deprecating the Observer Pattern (2010) [1]" which documented solutions to these problems a long time ago.

[1] https://www.semanticscholar.org/paper/Deprecating-the-Observ...

baq3• 3 years ago

I guess every large ecosystem has to rediscover certain facts… same thing with yaml and xml on the sysadmin excuse me devops side, nosql getting transactions and scans… everywhere you look there’s a bunch of people who like doing more than reading, and also doing gets rewarded much more than reading. The outcome is inevitable. Can’t wait for the next cycle, really curios what we’ll rediscover next.

redonkulus• 3 years ago

Essentially it’s because new developers cycle in every decade and do not have all the context of the previous generation of developers.

miiiiiike5• 3 years ago

Angular v16 is the opening sentence of an apology letter addressed to the Angular Community.

jeremycarter2• 3 years ago

Excuse me? How so?

miiiiiike5• 3 years ago

It’s moving the project in a direction that many devs are happy with. Non-destructive hydration when using SSR/Universal is a big deal.

solatic• 3 years ago

Does Angular have a future?

  1. Google is the main corporate sponsor
  2. Google is funding both Angular development and Flutter development
  3. The Flutter team keeps throwing serious effort behind their web deployment target. It's not at 100% yet, but they're getting there.
  4. Google internally saw returns from migrating cross-platform UIs to Flutter
  5. Google is well-known for being trigger-happy on cancelling projects

Pure speculation, but what are the odds that Google starts to transition off Angular, thus killing Angular? And therefore, why should people start new projects on Angular?

mkrishnan8• 3 years ago

Every project in google uses angular. Probably the most commonly used tech inside Google is Angular. So rest assured that Angular will be there forever. On the other hand I doubt flutter's future, mainly due to its reliance on Dart, Dart was extremely hated inside Google few years ago. There was even AngularDart at some point.

strongpigeon3• 3 years ago

The entire Google Ads frontend is written in AngularDart. Dart should be around for a while.

mhoad• 3 years ago

Dart itself has also made a huge amount of progress in the last 2-3 years and are days away from probably their most significant upgrade ever.

Dart is at this stage actually a damned good language. Miles in front of TypeScript for example.

Simple example here looking at Mixins (a fairly basic pattern to describe any kind of a “is-a” rather than a “has-a” relationship in OOP).

Here’s TypeScript

https://media.infosec.exchange/infosecmediaeu/media_attachme...

Here’s Dart

https://media.infosec.exchange/infosecmediaeu/media_attachme...

When Dart finally gets around to releasing their updated web and JS interop support later this year it is almost certainly about to become my new default there too.

dwaite3• 3 years ago

AFAIK Flutter still isn't a web development technology - the browser becomes a drawing surface for uncomfortable UX flutterisms.

IMHO - Flutter is the spiritual successor to Adobe Air, just as Dart is the spiritual successor to EcmaScript 4 (two ES4 mentions in one day!)

mkrishnan8• 3 years ago

correct.

amir734jj• 3 years ago

Angular + Nest.js = Awesomeness! developer's dream

paws2• 3 years ago

Anyone else run into an Angular 15 styling nightmare when upgrading to the latest Material Design (MDC) release?

I attempted to use the migration tool [0] for upgrading an in-house LOB app, but unlike previous upgrades client hated the resulting UI - understandable b/c of major styling regressions everywhere - so downgraded back to 14.

Angular 14 LTS support ends in November [1] and as best as I can tell, if we want to stay on a supported Angular release we're forced into a lot of custom styling work users simply don't care about.

If there's some way to stay on the "legacy" [2][3] components on Angular 15 or 16, would appreciate any links/hints. Cheers

[0] https://material.angular.io/guide/mdc-migration#2-run-the-mi...

[1] https://angular.io/guide/releases#actively-supported-version...

[2] https://material.angular.io/guide/mdc-migration#form-field

[3] https://material.angular.io/guide/mdc-migration#library-wide...

"These changes generally improve spec-compliance and accessibility." Maybe that's great for some folks, but the client liked the UI exactly as it was.

Klaster_13• 3 years ago

I maintain two Angular applications which leverage Angular Material and where dependencies are usually kept up to date.

The first one is my tiny pet project - https://github.com/Klaster1/timer-5 - that I use daily. Updating to MDC components was straightforward and style changes did not cause much trouble.

The second one is a moderately-sized enterprise app I work on as an employee. Every single component update introduces visual regressions the team had to coordinates the fixes for with the UI designer. We split the workload by similar component types, largest pain points being buttons and form controls. Total estimates are in 30-50 hours range, we plan to chip at the task bit by bit until Angular Material 17 arrives, where the legacy component are to be removed.

On a side note, migrating to Ivy-enabled dependencies was on even larger time scale as dependencies had their own breaking changes we spent a ton of effort on, especially Chart.js 2->3 and ag-grid 26->29.

thethirdteacup• 3 years ago

It is not well documented in the Angular Material documentation, but Angular Material 15 moved the "legacy" CSS to a new file.

This means that, depending on whether CSS or SCSS is used, the legacy theme has to be added to keep using the legacy components without styling issues.

The legacy Angular Material components might be removed in a later version, though.

[0] https://stackoverflow.com/questions/75101022/angular-materia...

[1] https://developapa.com/angular-material-legacy-styles/

dwaite3• 3 years ago

I eventually ran out of time for my toy application and just left it with styling regressions. I didn't understand the advice I used to get styling before, and the migration instructions left a big gap in understanding around what styling was expected to hang off of.

ior4uiofrjnev• 3 years ago

the client liked the UI exactly as it was.

That's nice, but how will we keep the tech treadmill spinning, and tech workers employed, with that kind of attidue?!

paws2• 3 years ago

Thank you @thethirdteacup - that looks helpful.

Because you were downvoted I can't reply directly so doing it here instead.

webprofusion• 3 years ago

The example includes: `effect(() => console.log('Name changed:', this.firstName()));`

But the text says "We also declare an effect, which callback will execute every time we change the value of any of the signals it reads — in this case fullName"

Surely fullName is not involved at all?

vulcanash999• 3 years ago

I agree, it probably should have been `effect(() => console.log('Name changed:', this.fullName()));`

That makes more sense given the context.

JenrHywy3• 3 years ago

It looks like they've updated the example to use fullName

ioseph• 3 years ago

I've slowly come to enjoy Angular, although the templating definitely feels clunky coming from React.

My biggest gripe is the lack of nice component libraries: Material just looks hideous, NgPrime has ads in the documentation and generally not well supported.

JenrHywy3• 3 years ago

We've found PrimeNg to be pretty good. Not perfect, but for the price we're paying ($0) it saves us an incredible amount of work.

activitypea2• 3 years ago

What do you enjoy about it?

revskill• 3 years ago

HTML templating is not productive as you might think.

In reality, you want control on every code you write. You can't put a variable in the HTML , which forced you to put those elsewhere, which hurts productivity.

machiaweliczny• 3 years ago

Ok, so they finally admitted that MobX is the best and they will implement it. Took em while to get humble and start stealing from smarter folks.

jeremycarter2• 3 years ago

Are you completely ignorant? What nonsense.

Tade03• 3 years ago

I have to say v14 was already interesting with its introduction of typed forms, but this brings improvements I didn't even expect.

For better or worse I've been largely stuck with Angular since 2017 (and completely since 2020), and it's not my framework of choice in private projects, so it's all the more exciting to see it catch up at least in some respects.

The other day I was wondering if Google still has the technical chops to introduce a new, modern framework to replace Angular, but perhaps that won't be necessary anytime soon.

commitpizza2• 3 years ago

As an Angular dev (not by choice) that kind of dislike RxJS I welcome this change. A lot. This will make the code so much easier to read and write.

Good work Angular team!

activitypea2• 3 years ago

I don't think I understand signals. What's reactive about them? I have to wrap every primitive in a custom object and I have to call setters for every primitive and I also have to define a function for computing derived values. None of this is reactive, these are just React hooks with 3x noisier code. The examples in the page imply you don't have to write dependency arrays. These were never a painpoint for me, but per their RFC:

It is possible to, optionally, specify an equality comparator function. If the equality function determines that 2 values are equal, and if not equal, writable signal implementation will block update of signal’s value and skip change propagation. The default equality function compares primitive values (numbers, strings, etc) using === semantics but treats objects and arrays as “always unequal”.

So just like React, optimization is opt-in, but worse -- React transitioned from `shouldComponentUpdate` to dependency arrays for a reason. Hell, Python devs learned this lesson 15 years ago with the transition from comparison functions to `key` lambdas.

What am I missing?

Sidenote: the second sentence from that quote made my head spin. I've read it three times and still not sure if it's a mistake

cout4• 3 years ago

I think I also don't understand signals. I expected something like signals/slots but this is something different. I read the example a few times to see if I was missing something, but I don't understand how this idiom fits into the larger picture of writing a component. What problem does it solve?

shoelessone• 3 years ago

There is a lot of discussion here about how Angular is a good choice for larger enterprise applications, but as somebody with more of a "backend" set of experiences, it seems to me that Angular might be a better choice for smaller teams as well?

My struggle is that when I want to build even a simple frontend with React, if it's been a while since I've done any frontend work I find myself having to re-learn what the current set of libraries / tools / frameworks I should be using with React is. For example, if I want a three page simple website, how do I handle routing, is it still `react-router-dom`?

Angular v16

Related Stories