19 ms·

Angular v16

165 points by Alex3917 3y ago

andix 3y 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 3y 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.
  - andix 3y 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?
    - wiseowise 3y ago
      > I think Angular and it’s ecosystem is falling behind compared to their alternatives. How so?
      - threatofrain 3y ago
        The rising tide lifts all boats. Except Angular. https://npmtrends.com/@angular/core-vs-react https://npmtrends.com/@angular/core-vs-react
        koito17 3y ago
        First of all, if you want to compare actual growth, you'll need a logarithmic scale. Second, if you add in alternatives like Vue.js, you'll realize React dwarfs both Angular and Vue.js, yet I don't see anyone on HN claiming "Vue is dying".
      - andix 3y ago
        My experience with libraries built by the community. Libraries for react have much higher quality than angular libraries. I usually fix the hard bugs in our team, and therefore read a lot of library code on GitHub. Usually react libraries impress me and angular libraries are often rather underwhelming. Highly subjective opinion though.
        Klaster_1 3y ago
        I don't have much experience outside of Angular ecosystem, but I share this sentiment too - the framework might be good, but the community size and quality also matter a lot. A similar example would be Sublime Text vs VSCode - I use the former, but VSCode has so much more vibrant community and everything supports VSCode by default, unlike ST where you are lucky to get a half-working prototype.
        andix 3y ago
        The framework is so complex, that a lot of details are not documented at all. And you see library authors struggle with that complexity.
    - tashoecraft 3y ago
      It seems the alternatives are trying to catch up to Angular. The entire react ecosystem's embrace of Next is proof that people want a framework and not "just a library" for a lot of their needs. I prefer Angular as I much prefer spending my time building rather than wading through open source bs finding what works, what plays nice together, what others are using. Version management is as simple as "ng update".
      - andix 3y ago
        People always say angular comes with „batteries included“, but honestly I don’t get it. If you take vite, vitest, react, react-router, react-hooks-forms, react-i18next and axios you have more or less all the angular features covered. You don’t have to „dig through bullshit“ to do that.
        whycombagator 3y ago
        Unless sarcasm, your comment actually explains the part you don’t get quite well. If you pick React for a project, how do you know to pick the other 6 dependencies you listed?
        AbuAssar 3y ago
        what about: reactive forms validation dependency injection animations pipes and directives i18n material components these all and more are built-in in angular
        jmisavage 3y ago
        Material components are a separate repo. They are not built-in.
        andix 3y ago
        Can’t reply anymore because of nesting: No, it’s not sarcasm, just install the listed dependencies and you are good to go. For forms and validation you can use the mentioned react-hooks-forms. MUCH easier compared to reactive forms. I never understood the benefit of angular dependency injection, because of its very limited singleton only approach. React-i18next is just so much better than all the i18n solutions for angular. If you want to be able to switch the language on the fly, you anyway need something like transloco for angular. Pipes are just functions for templates, no need with jsx. And directives can be replaced with composition. Much easier and powerful. Angular material is really dated, look&feel is from 10 years ago, check out the current material guide, and compare it to angular material. And it’s just way too hard to customize it, and it doesn’t come with a lot of features. And technically it’s not a part of angular. There are a few good commercial angular UI libraries though.
- koito17 3y 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-frameworks/ 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.
  - threatofrain 3y ago
    https://npmtrends.com/@angular/core-vs-react https://npmtrends.com/@angular/core-vs-react
  - andix 3y ago
    But also the framework with the highest „used it > would not use it again“ votes :)
    - pjmlp 3y ago
      Usually Angular tends to be used in projects where the developers have no say in what tech stack gets used anyway, other than switching jobs.
- willio58 3y 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-frameworks/ 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.
  - andix 3y 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 3y 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.
  - andix 3y 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 3y 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.
- pwb25 3y 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 3y 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.
  - Jochim 3y 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.
    - vekker 3y ago
      I hear this critique a lot, but what exactly is that pointless boilerplate? When I write a React application, I have to use a lot of React-flavored boilerplate too... useEffect, useState, useThis and useThat... What makes this so different from the Angular TS annotations and lifecycle hooks?
rr808 3y ago
Damn, we're still trying to get off angularjs.
- _boffin_ 3y ago
  damn... i'm sorry. sooo so sorry.
- mkrishnan 3y ago
  angualrjs is a good framework btw for decent business use cases.
  - rr808 3y ago
    Yes it works great. Its just another victim of the relentless frontend upgrade cycle.
  - throwaway2990 3y ago
    Angular is good for businesses which are your competitor so you have an advantage over them.
- deleted 3y ago
  [deleted]
- whalesalad 3y ago
  Im ashamed to admit this but I’ve spent a notable percentage of my time in therapy discussing angular and recovering from PTSD.
nawgz 3y 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.
- bitL 3y 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 3y ago
    Try having 15 committers in the same codebase. It won’t scale.
    - bitL 3y ago
      That might be true but React has the same issue with larger teams and everyone using a different part of it; the pace of development drops rapidly and apps become complex monsters for little reason.
  - nawgz 3y 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 3y 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 3y ago
  I think Signals existed before Solid and is not unique to Solid.
NayamAmarshe 3y 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 3y 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 3y ago
  Would you have made the same comment if they went by minor versions instead, and this was v1.16.0?
- mablopoule 3y 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 3y 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.
- throw1234651234 3y 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 3y 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.)
    - andix 3y ago
      Rx can be awesome for some complex problems. But I’m angular it’s everywhere and often makes things much more complex than they have to be.
      - whycombagator 3y ago
        Seeing as it’s often. Do you have a single example?
        throw1234651234 3y ago
        I am the guy who doesn't use it, but people used to recommend using it for "event-driven architecture on the front end" - clicking a button is an event, typing text is an event, hovering over something is an event, and there could be multiple subscribers. The example use-cases people give are really contrived. The functional crowd also pushed it. Again, to me it's another trend like Web Components that never really took of in the mainstream. Yes, people use Web Components and RxJS' full power, but it's not something to learn when you are looking for practical, widely applicable skills. If anyone still cares about this, here is a helpful site that you can understand without knowing anything about RxJS: https://rxmarbles.com/ https://rxmarbles.com/
deadeye 3y ago
[flagged]
- AbuAssar 3y ago
  how so?
  - webprofusion 3y ago
    https://knockoutjs.com/examples/helloWorld.html https://knockoutjs.com/examples/helloWorld.html Signals are very, very, similar to knockout observables. (Note that Knockout observables are very different to Rx/Reactive observables).
  - steve_adams_86 3y ago
    Though the idea of signals has been written about and used in computing for decades, knockout was the first frontend framework to implement them in a form we’d recognize as signals today. I think that’s why people are getting worked up about angular using signals. Claiming we’re circling back to knockout makes no sense though. Signals are sort of a primitive for modelling solutions; they aren’t the solution. The fastest tools for UI development are presently using signals to solve performance issues such as Solid, Qwik, or even Leptos which uses WASM and still outperforms React. React maintainers have said that signals could even be used in react eventually, though they don’t want it to be a surfaced tool that you have an API for. Instead it would be generated with a compile step. Regardless, we’re not headed back to knockout days and signals are not an archaic solution to a specific problem that we already have better tools for — there’s still plenty to revisit and explore to get better performance.
- pjmlp 3y ago
  Is that a surprise? We are also back to server side rendering from 25 years ago. Some of us never left SSR, though.
easton 3y 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 3y ago
  30+ second incremental build times? How big is your app? Presumably you haven't implemented lazy loaded routes?
mkrishnan 3y ago
this v16 is quite interesting due to signal. you'd like it.
AbuAssar 3y ago
I wish Angular had a good meta framework like next
- saila 3y ago
  I haven't used it, but there's at least one active Angular meta framework: https://analogjs.org https://analogjs.org
  - AbuAssar 3y ago
    yea looks promising but still very young
- Tade0 3y ago
  Nest is the closest thing to that, but only in spirit: https://nestjs.com/ https://nestjs.com/
  - _boffin_ 3y ago
    I really really love nestjs. After working with Spring in Java land for a few years, just just makes so much sense.
bitL 3y 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?
- duxup 3y ago
  For a page with a couple forms sure. For an application with state and such, maybe not.
  - bitL 3y 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?
    - pwb25 3y ago
      then everyone who joins your company gonna learn this home made framework?
      - bitL 3y ago
        There is no framework. Just simple JS calls and bindings to HTML with somebody defining REST or GraphQL backend. And some eye candy CSS. The point is that with ES7+ JS can be finally readable and not a spaghetti code monster so anyone can easily understand and extend any code.
        pwb25 3y ago
        good luck with that
        duxup 3y ago
        It really sounds like you don’t have any need for a framework and so of course it doesn’t seem like you need it.
_the_inflator 3y ago
Angular is a fantastic framework. Congratulations to the team and hopefully see you again next year latest, Angular team.
- AbuAssar 3y ago
  next major release is after 6 months, so still in 2023
ShaneMcGowan 3y ago
Very interesting seeing Angular getting many of the features that EmberJS has had for a while such.
- AbuAssar 3y ago
  such as what?
  - ShaneMcGowan 3y 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
    - Kerrick 3y ago
      I just wish Angular would copy Ember Data. I worked in Ember apps for eight years and I’ve been in Angular for the last year… it’s the biggest, most annoying missing piece.
      - steve_adams_86 3y ago
        What did Ember Data offer that isn’t available in the Angular ecosystem?
        idkwhoiam 3y ago
        Last time I worked on Ember app (many years ago) the selling point of Ember Data was seamless integration with JSON:API endpoints.
madethemcry 3y 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.
- paulddraper 3y 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.
  - ttfkam 3y 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".
n0us 3y 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 3y 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`.
- jamra 3y 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 3y 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 3y 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-Observer-Pattern-Maier-Rompf/d7341e40b11008965d60631953ad83e89aa40584 https://www.semanticscholar.org/paper/Deprecating-the-Observ...
- baq 3y 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 3y ago
  Essentially it’s because new developers cycle in every decade and do not have all the context of the previous generation of developers.
miiiiiike 3y ago
Angular v16 is the opening sentence of an apology letter addressed to the Angular Community.
- jeremycarter 3y ago
  Excuse me? How so?
  - miiiiiike 3y 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 3y 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?
- mkrishnan 3y 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.
  - strongpigeon 3y ago
    The entire Google Ads frontend is written in AngularDart. Dart should be around for a while.
    - pjmlp 3y ago
      Google Ads is the reason why Dart was still around when Flutter came to be in first place. After Dart's failure, Google Ads had just migrated from GWT into AngularDart, they weren't going to go through yet another rewrite, thus they rescued Dart from being fully rampeddown. It is also the reason why AngularDart stayed around, when the Angular team decided to adopt TypeScript.
      - strongpigeon 3y ago
        Correct. I do believe the Dart team is fully under the ads org as a result of that, or at least, was for a while.
amir734jj 3y ago
Angular + Nest.js = Awesomeness! developer's dream
paws 3y 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-migration-tool https://material.angular.io/guide/mdc-migration#2-run-the-mi... [1] https://angular.io/guide/releases#actively-supported-versions https://angular.io/guide/releases#actively-supported-version... [2] https://material.angular.io/guide/mdc-migration#form-field https://material.angular.io/guide/mdc-migration#form-field [3] https://material.angular.io/guide/mdc-migration#library-wide-changes 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.
- sieabahlpark 3y ago
  [dead]
- Klaster_1 3y 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 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.
webprofusion 3y 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 3y ago
  I agree, it probably should have been `effect(() => console.log('Name changed:', this.fullName()));` That makes more sense given the context.
  - JenrHywy 3y ago
    It looks like they've updated the example to use fullName
ioseph 3y 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.
- deleted 3y ago
  [deleted]
- JenrHywy 3y 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.
- activitypea 3y ago
  What do you enjoy about it?
revskill 3y 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 3y 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.
- jeremycarter 3y ago
  Are you completely ignorant? What nonsense.
Tade0 3y 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.
commitpizza 3y 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!
activitypea 3y 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
- cout 3y 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 3y 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`?

165 points by Alex3917 3y 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 3y 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.
- andix 3y 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?
  - wiseowise 3y ago
    > I think Angular and it’s ecosystem is falling behind compared to their alternatives. How so?
    - threatofrain 3y ago
      The rising tide lifts all boats. Except Angular. https://npmtrends.com/@angular/core-vs-react https://npmtrends.com/@angular/core-vs-react
      - koito17 3y ago
        First of all, if you want to compare actual growth, you'll need a logarithmic scale. Second, if you add in alternatives like Vue.js, you'll realize React dwarfs both Angular and Vue.js, yet I don't see anyone on HN claiming "Vue is dying".
    - andix 3y ago
      My experience with libraries built by the community. Libraries for react have much higher quality than angular libraries. I usually fix the hard bugs in our team, and therefore read a lot of library code on GitHub. Usually react libraries impress me and angular libraries are often rather underwhelming. Highly subjective opinion though.
      - Klaster_1 3y ago
        I don't have much experience outside of Angular ecosystem, but I share this sentiment too - the framework might be good, but the community size and quality also matter a lot. A similar example would be Sublime Text vs VSCode - I use the former, but VSCode has so much more vibrant community and everything supports VSCode by default, unlike ST where you are lucky to get a half-working prototype.
        andix 3y ago
        The framework is so complex, that a lot of details are not documented at all. And you see library authors struggle with that complexity.
  - tashoecraft 3y ago
    It seems the alternatives are trying to catch up to Angular. The entire react ecosystem's embrace of Next is proof that people want a framework and not "just a library" for a lot of their needs. I prefer Angular as I much prefer spending my time building rather than wading through open source bs finding what works, what plays nice together, what others are using. Version management is as simple as "ng update".
    - andix 3y ago
      People always say angular comes with „batteries included“, but honestly I don’t get it. If you take vite, vitest, react, react-router, react-hooks-forms, react-i18next and axios you have more or less all the angular features covered. You don’t have to „dig through bullshit“ to do that.
      - whycombagator 3y ago
        Unless sarcasm, your comment actually explains the part you don’t get quite well. If you pick React for a project, how do you know to pick the other 6 dependencies you listed?
      - AbuAssar 3y ago
        what about: reactive forms validation dependency injection animations pipes and directives i18n material components these all and more are built-in in angular
        jmisavage 3y ago
        Material components are a separate repo. They are not built-in.
      - andix 3y ago
        Can’t reply anymore because of nesting: No, it’s not sarcasm, just install the listed dependencies and you are good to go. For forms and validation you can use the mentioned react-hooks-forms. MUCH easier compared to reactive forms. I never understood the benefit of angular dependency injection, because of its very limited singleton only approach. React-i18next is just so much better than all the i18n solutions for angular. If you want to be able to switch the language on the fly, you anyway need something like transloco for angular. Pipes are just functions for templates, no need with jsx. And directives can be replaced with composition. Much easier and powerful. Angular material is really dated, look&feel is from 10 years ago, check out the current material guide, and compare it to angular material. And it’s just way too hard to customize it, and it doesn’t come with a lot of features. And technically it’s not a part of angular. There are a few good commercial angular UI libraries though.
koito17 3y 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-frameworks/ 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.
- threatofrain 3y ago
  https://npmtrends.com/@angular/core-vs-react https://npmtrends.com/@angular/core-vs-react
- andix 3y ago
  But also the framework with the highest „used it > would not use it again“ votes :)
  - pjmlp 3y ago
    Usually Angular tends to be used in projects where the developers have no say in what tech stack gets used anyway, other than switching jobs.
willio58 3y 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-frameworks/ 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.
- andix 3y 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 3y 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.
- andix 3y 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 3y 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.

pwb25 3y 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 3y 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.
- Jochim 3y 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.
  - vekker 3y ago
    I hear this critique a lot, but what exactly is that pointless boilerplate? When I write a React application, I have to use a lot of React-flavored boilerplate too... useEffect, useState, useThis and useThat... What makes this so different from the Angular TS annotations and lifecycle hooks?

rr808 3y ago

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

_boffin_ 3y ago
damn... i'm sorry. sooo so sorry.
mkrishnan 3y ago
angualrjs is a good framework btw for decent business use cases.
- rr808 3y ago
  Yes it works great. Its just another victim of the relentless frontend upgrade cycle.
- throwaway2990 3y ago
  Angular is good for businesses which are your competitor so you have an advantage over them.
deleted 3y ago
[deleted]
whalesalad 3y ago
Im ashamed to admit this but I’ve spent a notable percentage of my time in therapy discussing angular and recovering from PTSD.

nawgz 3y 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.

bitL 3y 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 3y ago
  Try having 15 committers in the same codebase. It won’t scale.
  - bitL 3y ago
    That might be true but React has the same issue with larger teams and everyone using a different part of it; the pace of development drops rapidly and apps become complex monsters for little reason.
- nawgz 3y 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 3y 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 3y ago
I think Signals existed before Solid and is not unique to Solid.

NayamAmarshe 3y 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 3y 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 3y ago
Would you have made the same comment if they went by minor versions instead, and this was v1.16.0?
mablopoule 3y 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 3y 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.

throw1234651234 3y 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 3y 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.)
  - andix 3y ago
    Rx can be awesome for some complex problems. But I’m angular it’s everywhere and often makes things much more complex than they have to be.
    - whycombagator 3y ago
      Seeing as it’s often. Do you have a single example?
      - throw1234651234 3y ago
        I am the guy who doesn't use it, but people used to recommend using it for "event-driven architecture on the front end" - clicking a button is an event, typing text is an event, hovering over something is an event, and there could be multiple subscribers. The example use-cases people give are really contrived. The functional crowd also pushed it. Again, to me it's another trend like Web Components that never really took of in the mainstream. Yes, people use Web Components and RxJS' full power, but it's not something to learn when you are looking for practical, widely applicable skills. If anyone still cares about this, here is a helpful site that you can understand without knowing anything about RxJS: https://rxmarbles.com/ https://rxmarbles.com/

deadeye 3y ago

[flagged]

AbuAssar 3y ago
how so?
- webprofusion 3y ago
  https://knockoutjs.com/examples/helloWorld.html https://knockoutjs.com/examples/helloWorld.html Signals are very, very, similar to knockout observables. (Note that Knockout observables are very different to Rx/Reactive observables).
- steve_adams_86 3y ago
  Though the idea of signals has been written about and used in computing for decades, knockout was the first frontend framework to implement them in a form we’d recognize as signals today. I think that’s why people are getting worked up about angular using signals. Claiming we’re circling back to knockout makes no sense though. Signals are sort of a primitive for modelling solutions; they aren’t the solution. The fastest tools for UI development are presently using signals to solve performance issues such as Solid, Qwik, or even Leptos which uses WASM and still outperforms React. React maintainers have said that signals could even be used in react eventually, though they don’t want it to be a surfaced tool that you have an API for. Instead it would be generated with a compile step. Regardless, we’re not headed back to knockout days and signals are not an archaic solution to a specific problem that we already have better tools for — there’s still plenty to revisit and explore to get better performance.
pjmlp 3y ago
Is that a surprise? We are also back to server side rendering from 25 years ago. Some of us never left SSR, though.

easton 3y 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 3y ago
30+ second incremental build times? How big is your app? Presumably you haven't implemented lazy loaded routes?

mkrishnan 3y ago

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

AbuAssar 3y ago

I wish Angular had a good meta framework like next

saila 3y ago
I haven't used it, but there's at least one active Angular meta framework: https://analogjs.org https://analogjs.org
- AbuAssar 3y ago
  yea looks promising but still very young
Tade0 3y ago
Nest is the closest thing to that, but only in spirit: https://nestjs.com/ https://nestjs.com/
- _boffin_ 3y ago
  I really really love nestjs. After working with Spring in Java land for a few years, just just makes so much sense.

bitL 3y 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?

duxup 3y ago
For a page with a couple forms sure. For an application with state and such, maybe not.
- bitL 3y 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?
  - pwb25 3y ago
    then everyone who joins your company gonna learn this home made framework?
    - bitL 3y ago
      There is no framework. Just simple JS calls and bindings to HTML with somebody defining REST or GraphQL backend. And some eye candy CSS. The point is that with ES7+ JS can be finally readable and not a spaghetti code monster so anyone can easily understand and extend any code.
      - pwb25 3y ago
        good luck with that
      - duxup 3y ago
        It really sounds like you don’t have any need for a framework and so of course it doesn’t seem like you need it.

_the_inflator 3y ago

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

AbuAssar 3y ago
next major release is after 6 months, so still in 2023

ShaneMcGowan 3y ago

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

AbuAssar 3y ago
such as what?
- ShaneMcGowan 3y 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
  - Kerrick 3y ago
    I just wish Angular would copy Ember Data. I worked in Ember apps for eight years and I’ve been in Angular for the last year… it’s the biggest, most annoying missing piece.
    - steve_adams_86 3y ago
      What did Ember Data offer that isn’t available in the Angular ecosystem?
      - idkwhoiam 3y ago
        Last time I worked on Ember app (many years ago) the selling point of Ember Data was seamless integration with JSON:API endpoints.

madethemcry 3y 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.

paulddraper 3y 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.
- ttfkam 3y 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".

n0us 3y 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 3y 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`.

jamra 3y 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 3y 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 3y 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-Observer-Pattern-Maier-Rompf/d7341e40b11008965d60631953ad83e89aa40584 https://www.semanticscholar.org/paper/Deprecating-the-Observ...

baq 3y 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 3y ago
Essentially it’s because new developers cycle in every decade and do not have all the context of the previous generation of developers.

miiiiiike 3y ago

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

jeremycarter 3y ago
Excuse me? How so?
- miiiiiike 3y 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 3y 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?

mkrishnan 3y 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.
- strongpigeon 3y ago
  The entire Google Ads frontend is written in AngularDart. Dart should be around for a while.
  - pjmlp 3y ago
    Google Ads is the reason why Dart was still around when Flutter came to be in first place. After Dart's failure, Google Ads had just migrated from GWT into AngularDart, they weren't going to go through yet another rewrite, thus they rescued Dart from being fully rampeddown. It is also the reason why AngularDart stayed around, when the Angular team decided to adopt TypeScript.
    - strongpigeon 3y ago
      Correct. I do believe the Dart team is fully under the ads org as a result of that, or at least, was for a while.

amir734jj 3y ago

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

paws 3y 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-migration-tool https://material.angular.io/guide/mdc-migration#2-run-the-mi... [1] https://angular.io/guide/releases#actively-supported-versions https://angular.io/guide/releases#actively-supported-version... [2] https://material.angular.io/guide/mdc-migration#form-field https://material.angular.io/guide/mdc-migration#form-field [3] https://material.angular.io/guide/mdc-migration#library-wide-changes 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.

sieabahlpark 3y ago
[dead]
Klaster_1 3y 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 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.

webprofusion 3y 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 3y ago
I agree, it probably should have been `effect(() => console.log('Name changed:', this.fullName()));` That makes more sense given the context.
- JenrHywy 3y ago
  It looks like they've updated the example to use fullName

ioseph 3y 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.

deleted 3y ago
[deleted]
JenrHywy 3y 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.
activitypea 3y ago
What do you enjoy about it?

revskill 3y 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 3y 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.

jeremycarter 3y ago
Are you completely ignorant? What nonsense.

Tade0 3y 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.

commitpizza 3y 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!

activitypea 3y 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

cout 3y 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 3y 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`?