Angular v16
blog.angular.io
blog.angular.io
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.
Like, if you like Svelte, that's great. You will probably like Angular too.
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
It's my answer to what I can tell you agree is the most important question in software engineering - "What programming language has the shortest 'Hello World' program?"
Problem is, this doesn't lead me to solve any harder problems.
That's not even a criticism of the framework.
Is that a valid criticism?
Angular is for writing medium to heavy complexity applications. Sure, if you want to write hello world programs in it, then it is going to be complex.
This is a generic comment thrown about for all large frameworks.
> It introduces a lot of unnecessary complexity for projects of any size
This I agree.
> It uses invalid HTML, with attribute syntax including brackets and parentheses
True, but so does React and other frameworks. To me, it seems like this is a limitation of HTML rather than a transgression of Angular.
> Sadly It's just not a good framework
It is a good choice for a large organization, with team members changing and all sorts of other goodness.
> requiring multiple files for "hello world"
False (unless you're counting angular.json conf file for Angular CLI??)
> It uses invalid HTML, with attribute syntax including brackets and parentheses
And what, JSX is valid HTML????
FWIW Angular templates is completely valid HTML. (The only non-standard thing is that the attributes are case-sensitive.)
JSX makes so much more sense, making code the parent of the template, instead of keeping code and template as siblings.
I note that Vue and Svelte have the same issue, and yet I rarely hear this criticism of them.
Brackets and parens are valid in attribute names.
Section 13.1.2.3 of the HTML standard[0] states:
> Attribute names must consist of one or more characters other than controls, U+0020 SPACE, U+0022 ("), U+0027 ('), U+003E (>), U+002F (/), U+003D (=), and noncharacters.
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.
With Angular templates, there's an entire new language, with its own weird syntax ngIf/else, ngSwitchDefault, let-*, pipes and other components that get pulled in based on whether you forgot to set up correctly or not in modules far-far away somewhere in the codebase, brackets of different sorts having different functions and just a lot more stuff to remember. And if it doesn't work, you're gonna get a silent error most of the time with no easy way to set a breakpoint to investigate.
I also don't believe there's any real separation between the HTML templates and the Component class, just because they're written in separate files. They're just as tightly coupled as any regular React component, just harder to follow. I don't think I've ever seen an Angular component, where you could swap out the template, without making simultaneous changes to the Component to accommodate it, which should be possible if they were truly separate.
The React ecosystem also improves faster (yes, sometimes a bit too fast).
A big part of maintainability comes from the quality of code and/or existing experience with the two frameworks, not the frameworks itself.
I work at an Angular only shop, if we would write some React it would be probably harder to maintain for us than the Angular ones.
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.
Another thing is, that angular components always wrap their template into a block element (like a div) in the DOM. So if you do some refactoring and split up one big component, the result in the DOM is different and your CSS may not work anymore. If you are using flexbox or grid, it may even be impossible to split the component.
Usually if you run into problems like that, you should use templates.
Honestly, I'm not sure why `<ng-content>` exists vs templates. I'm sure there's a reason (verbosity?), but templates have way fewer caveats.
> Would have been so much easier with a webpack configuration
I agree. It's not hard at all to do a Webpack configuration of Angular. Just add the Angular plugin. (That's what the CLI does under the hood.) I wish they document it though.
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.
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".
ng serve for development is a pig too. Save-reload cycle is far from instant.
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
[0] https://www.typescripttutorial.net/typescript-tutorial/types...
> For example, this update brings us computed properties, an essential feature for any complex performant web application that was made popular by Vue.js 10 years ago [1].
So obviously the relevant definition is "what the feature does in Vue". What is your issue here?
The important part is that a computed property tracks its dependencies and is automatically re-calculated ONLY when necessary. If it behaves differently, it's not equivalent to the concept of a computed property in Vue.
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.
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
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.
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.
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.
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`.
As opposed to the very few questions about rxjs, where people understand everything perfectly.
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...
> 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
Well done to the Angular team.
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.
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.
* Angular classes just feel a lot more verbose/messy than the equivalent functional implementation in React.
* Perhaps it's just familiarity but I have a much easier time understanding what a functional React component is doing just by reading it from top to bottom.
* I have an irrational hatred for separate html template files.
* I'm also not a fan of templating via custom html attributes.
* Two way data binding is sometimes convenient but feels messy.
Pulling a random hello world comparison that starts from a base template from google:
React: 16 lines - 342 chars - 2 files changed. Angular 34 lines - 808 characters - 3 files changed, 4 if following common html template practice.
React
HelloWorld.js:
import React from 'react';
function HelloWorld() {
return (
<div>
<h1>Hello, World!</h1>
</div>
);
}
export default HelloWorld;
import React from 'react';
import ReactDOM from 'react-dom';
import HelloWorld from './HelloWorld';
ReactDOM.render(<HelloWorld />, document.getElementById('root'));
hello-world.component.ts
import { Component } from '@angular/core';
@Component({
selector: 'app-hello-world',
template: `
<div>
<h1>Hello, World!</h1>
</div>
`,
})
export class HelloWorldComponent {}
import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
import { AppComponent } from './app.component';
import { HelloWorldComponent } from './hello-world.component';
@NgModule({
declarations: [AppComponent, HelloWorldComponent],
imports: [BrowserModule],
providers: [],
bootstrap: [AppComponent],
})
export class AppModule {}
import { Component } from '@angular/core';
@Component({
selector: 'app-root',
template: `
<app-hello-world></app-hello-world>
`,
})
export class AppComponent {}Looking at you: $scope, '@' '='
Angular2+ on the other hand, just install the language service and it will enable type checks for stuff like *ngFor even in the template (HTML) files.
It will suggest person .name, and if you do person.namee (typo), it will show up as error immediately. That's not far off from TypeScript.
Angularjs did get better after 1.5 (when they added components and one-way binding), but IMO the model is still fundamentally broken. Vue fits my mental model much better and is much better documented; if I were to start a new project today, that's probably what I would reach for.
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
Vue has blacklisted reactivity, everything becomes reactive (and observed) by default and you can opt-out, while MobX features whitelisted reactivity and is much more fine-grained
Contrast with coarse grained reactivity I. E. angular, where it must dirty check all "reactive" objects to identify the changed object. As angular can't tell exactly which properties changed.
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
I don't think that's quite true anymore. As someone sarcastically remarked on Twitter [0], React has patched native events with synthetic events; has rolled out its own scheduler in order to achieve the suspense effect ("patched the event loop"), and is going to patch the native fetch for reasons that I am not clear about, but that are doubtless also suspense-related. With hooks, it introduced a syntax with a set of implicit conventions that, confusingly, still looks like javascript, but has significant differences from how javascript works ("the rules of hooks"). React provides its own way of lazy-loading modules; its new server-side renderer currently assumes that when React rehydrates, it takes control of the whole DOM tree; and the docs are now strongly recommending people to use full-fledged frameworks (Next, Remix) when starting new projects. React has long outgrown its "it's just a library" stage, sadly.
[0] - https://twitter.com/RogersKonnor/status/1618739256775815168
Messing with the console is such a no-go that I'm appalled it even passed the drawing board, making the "React isn't a framework, it's a library" argument even more bonkers than it already is.
This all makes me want to move on to web components; but of course now the project that I am a developer on is locked in React :-(
I never had any issues in the past with futures/promises libraries, but for some reason I can never remember how to use RxJS.
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.)
If anyone still cares about this, here is a helpful site that you can understand without knowing anything about RxJS: https://rxmarbles.com/
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.
Was it really a mistake or were they just using it before native promises were widely supported?
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.
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
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.
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.
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
https://shift.infinite.red/redux-observable-epics-vs-redux-s...
Parent comment said:
> But the problems they solve are also unintuitive.
Do you consider calling a JSON API unintuitive or complex? If not, then you may be using the wrong tool. If you need nothing else, you are perfectly fine using a promise.
If you need to await extra requests, transform them, and react to other events then you need RxJS. For a simple call, you do not.
> 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
Do you consider the following code hard to understand or are you are making requests in a more complex way?
``` this.network.get('<url>').subscribe(response => <do whatever you want here>) ```
Even if we agree to disagree that the above code snippet is hard to understand, you can just convert it to a promise:
``` const response = await lastValueFrom(this.network.get('<url>')) ```
http$
.pipe(
map(res => res['payload']),
catchError(err => {
console.log('caught mapping error and rethrowing', err);
return throwError(err);
}),
finalize(() => console.log("first finalize() block executed")),
catchError(err => {
console.log('caught rethrown error, providing fallback value');
return of([]);
}),
finalize(() => console.log("second finalize() block executed"))
)
.subscribe(
res => console.log('HTTP response', res),
err => console.log('HTTP Error', err),
() => console.log('HTTP request completed.')
);
Once you learn how RxJS works examples like the one anbove anre intuitive.
Angular 2’s most egregious crime is that their tutorials try to make it (and RxJS) seem “simple”. They aren’t. They’re powerful.
2) RxJS is not Git. It’s a library designed to be extended by users. To use RxJS you need to write code with it. Git is not exclusively a library and doesn’t require you to write you own extensions to use it day to day.
As a casual Git user you wouldn’t get much out of implementing a DVCS but you would benefit from learning to host your own repo instead of relying on GitHub.
If someone was struggling to use Git I’d tell them to learn the foundations, practice them, and then to host their own repos to continue learning.
The same basic track I recommended for RxJS.
A big moment for RxJS users is when they realize that they need an operator or observable that doesn’t exist. It’s really fun to write your own.
I am doing that all the time and all it takes, is withLatestFrom or combineLatest
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().
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();
---
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.
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.
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.
However, I found the API choices odd because in RxJS the `.pipe` operator is, itself, chained rather than being standalone. Using a standalone `pipe`, such as via Ramda or something home-grown worked just fine, so I found it very strange that they mixed the functional composition style with the object-chainable style.
> I see why it isn’t more widely adopted too
I agree that RxJS is amazing, which is why less adoption is unfortunate. So many projects would benefit from RxJS or something like it.
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.
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.
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.
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.
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...
That's nice, but how will we keep the tech treadmill spinning, and tech workers employed, with that kind of attidue?!
/s
Because you were downvoted I can't reply directly so doing it here instead.
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`?
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
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.
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.
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!)
(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.)
Presumably you haven't implemented lazy loaded routes?
Good work Angular team!
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?
That makes more sense given the context.
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.
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.
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.
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.
Maybe you can consider that on HN you are talking to people who spend their working lives answering the question of "how can I scale this UI" and think that reactivity is a good approach.
> why should however most apps bother jumping on this paradigm
I stated pretty clearly the benefits above - it has great performance in general due to minimal redraws, and those minimal redraws are accomplished "automatically" / via runtime construction so you don't even need to think about optimizing accesses, it's already the least possible.
More to the point, I don't see why we shouldn't laud Angular for delivering an opinionated reactivity implementation when their opinionated, batteries-included approach has enabled a lot of teams to hop in and build apps.
I also don't think you have any fucking clue what goes into UI development if you propose rolling your own SPA, so there's also that.
> 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
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.
These seem like two contradictory statements.
I use Angular at work and I love it. And the sentiment is similar among my peers.
Do you also work with other frameworks? And why do you prefer Angular?
How so?
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".
reactive forms
validation
dependency injection
animations
pipes and directives
i18n
material components
these all and more are built-in in angular
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.
Forget which solution is better, apparently there is a subset of users who choose Angular purely because they want features built in & not to go searching for additional dependencies.
Could you recommend one of these?
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.
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.
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.
For an application with state and such, maybe not.
Some uses benefit from a good framework.
If we didn’t have competition we’d all still be using jquery.
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.)
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...
(And yes, also the shitstorm that was AngularJS to Angular (4+), but that was a long time ago now.)