>...but I HATE rxjs and the complexity of it. And the whole thing on top of rxjs, ngrx. You can't just simply take one value and compare it, no you have to use pipes and rxjs.
We're working on making RxJS optional. In v17.3 `@angular/core` no longer has a dependency on RxJS. In the long-term we'll enable a path forward without RxJS for other core modules as well.
That said, we're providing an interop package that enables even better RxJS support for people who make the decision to use it.
Edit: in v17.3 we have a minimal dependency on RxJS in ApplicationRef and NgZone, but in practice, it's unlikely that you'd need to use these APIs. In the following versions, we'll remove these dependencies and introduce interop APIs as well.
Hey everyone, I'm working on this at Google and would be happy to answer your questions :)
The tldr; is that we see a lot of similar requirements from developers across Angular and Wiz, so we're looking for opportunities to reuse work. Good example is the Angular Signals library that's now used in all the YouTube Mobile Web. In a similar way, Angular is bringing more fine-grained code loading that Wiz offers.
Over time, we'll continue focusing on what's best for developers and incorporating the best from Wiz in Angular, and vice versa. At the end we can end up with one framework, or continue to coexist.
In the next couple of weeks we'll follow up with a blog post that explains our plan in more details.
tbh - killing of basic html Gmail was the last straw that pushed me to other mail provider... I usually use imap but once in a blue moon I need to access mailbox via browser and regular Gmail client is just abysmal...
Could be interesting/useful, but none of these seem to have any impact on the sites like Youtube which loads tens of megabytes of resources, and every interaction takes a second or so to happen.
> The tldr; is that we see a lot of similar requirements from developers across Angular and Wiz, so we're looking for opportunities to reuse work. Good example is the Angular Signals library that's now used in all the YouTube Mobile Web. In a similar way, Angular is bringing more fine-grained code loading that Wiz offers.
It sounds no different from Svelte borrowing concepts from SolidJS, or Vue borrowing ideas from Svelte, from you said — if it is just adding some features that Wiz has, it doesn't sound like merging? Why put a shocking title that Angular is merging with Wiz, when Wiz has no name recognition in the outer dev community — like we don't know what that means?
Hey, im working with angular for almost 5 years now.. What changes should we -developers - expect in the developer experience. In other words how we work with angular. Are you aiming for the "drop-in" replacement same as with ivy back then? Or new standards are comming with this? Thx!
At this point, we are not anticipating to have to develop a new rendering engine at this point, so it should be a more incremental effort than Ivy.
As an Angular developer you could expect new features and developer experience improvements. Also over time you’d see more of Angular used in popular consumer Google products.
>our bundle size hasn't moved or increased slightly
Please make sure you are using the latest version of our compiler and runtime. Many developers observed significant improvements after the v9 release. Here's just one [example](https://news.ycombinator.com/item?id=22260864).
>Every ngconf there's talk of the magical 2kb hello-world
Currently, it's absolutely doable to get very small bundle size (<7-8KB) for a hello-world application. This, however, relies on private APIs. We haven't made them public yet, because not many folks are building hello world apps, but in the future we'll be exploring how to reduce the footprints of the framework even further for smaller apps.
>We're currently at 2mb main/vendor after spending A LOT of time optimising and making everything lazy
It is shocking for me that you're spending that much effort on optimizing your app, but you can't get your bundle below 2MB. I'm spending large chunk of my time looking into apps and thinking how to make them smaller & faster. I'll be more than happy to connect and brainstorm the same for your case. Please reach out to me on my hackernews username @google.com
>Every year I install the VSC Language Service plugin and have to disable it the same day due to it continuously crashing and killing the editor so it seems we'll never get to benefit from that.
Sorry to hear you had such an experience with the language service. If it keeps crashing, definitely report the problem here https://github.com/angular/angular/issues. We'll be very thankful if you share reproduction steps.
>Then I see a continuous stream of core developers leaving the Angular project due to toxic behaviour from Igor and it feels hopeless and depressing.
Folks leave and and others join. I can't comment on my co-workers experiences, but after 2 years working on Angular I haven't experienced any of the behavior you're referring to.
>The one saving grace is that the entire ecosystem is written in TypeScript and it's nice seeing everything typed to perfection.
Oh, I wish everything was that perfectly typed :). This is something the team and the community is constantly working on, but we still have a long way to go until we reach perfection.
FWIW, I recently left a project with quite a lot of Angular (2+) code (not massive project but good chunk of code for three developers), and mostly it was a real pleasure as most of the stuff was strictly typed.
One extra reason that smoothed the experience was that our Spring Java/Kotlin endpoints have corresponding client typescript API (and data structures) generated automatically by custom tool http://github.com/evidentSolutions/apina
i.e. Having defined endpoint controller with methods, you have automatically Angular service that has the same methods with the similar types. (One may need to define some custom datatype de/serialization but not much)
If I had to say two things that I would like to get improved:
1) better typing related to Reactive Forms and Angular Material (e.g. IIRC Material dynamic table definitions were declared in a way that it lost IDE navigation and static analysis)
2) Faster compiling times, but we got this to be good enough for hot-reloading which matters most.
RxJS Observables with Push ChangeDetection was heavily used.
Personally just thanks for your contribution to make web developing more enjoyable!
I will just chime in to say that we love Angular on our team. We love the opinionated, batteries-included philosophy of angular, and it does keep getting better over time. We don't want to have to make the decisions that are required for React applications. For teams of 3+, I think Angular is the better choice most of the time. It is easy for us to make well maintained, fast applications across platforms. I think you've made reasonable choices over time. Thanks for your work.
If you care about javascript bundle size you have to avoid everything that comes from google (besides angular core & common of course). Material, animations, cdk, ... everything is just horrendously over engineered and nothing optimized for size. E.g. just look a sourcecode for material checkbox! https://github.com/angular/components/blob/master/src/materi...
Don't get me wrong, I like those bundles - and I like my frameworks over engineered. They take care of edge cases. And if I'd write a CMS I'd be all over those packages. But if your constraint is bundle size, you have to avoid them.
Yes, I've worked with Jeff and I'm familiar with the post. In fact, Jeff was the one who first invited me to apply for a role at Google after our collaboration on the Angular mobile toolkit and it was great working with him :)
It's not easy to share such a personal story publicly. I'm sorry he had such experience and I'm not saying he does not have the right to be upset. He knows the best what he went through and how he feels.
I'm just saying that it's not correct to generalize and gave myself as an example for someone who can't relate to his experience.
Toxic and abusive people are not toxic and abusive with every single person. You might have not had the same experience, but pointing that out does not really help. The linked article cited many people who suffered the same, so it is an important thing for anyone who might want to be involved in Angular development to know.
Very positive response! It sounds like you don’t think there is any truth to what he is saying. That seems interesting given that he is not the only one saying it.
There's no way for me to know what happened without being part of the team back then. What I'm certain is that he had a bad experience which impacted him negatively and I'm sorry he had to go through this.
The only thing I'm saying is that it is not correct to generalize, giving myself as an example for someone who haven't experienced anything similar.
> It sounds like you don’t think there is any truth to what he is saying
I've no idea how you reached that conclusion given that the comment you're replying to says
>> I'm sorry he had such experience and I'm not saying he does not have the right to be upset. He knows the best what he went through and how he feels.
It’s very quite simple - Mgchev is careful to validate only Jeff’s feelings, and absolutely nothing else about what he says.
Indeed he goes on to make this clear: “The only thing I'm saying is that it is not correct to generalize”
This invalidates everything about Jeff’s piece except for his feelings, since the entire piece is an argument that there is a systematic problem with the team that other people have experienced too. There are tweets and quotes to support this.
Jeff does generalize, and he does reference other people who had similar experiences. Jeff’s entire reason for writing the piece is to generalize. He doesn’t say ‘I’m sure this is just me’. He argues quite the opposite.
If it is ‘not correct to generalize’ - as Mgechev says, then Jeff must be wrong about there being a problem with the team, therefore Mgechev does not believe Jeff.
Mgechev also says they “can't relate to his experience”. They also make no reference to (or validate) any of the other people who apparently had similar experiences or views of the team.
It’s pretty reasonable to conclude that Mgechev doesn’t think there is a problem with the team and wants to convey that to us.
Generalization literally means to apply the point to all involved. So no, it's quite appropriate for mgechev so reject generalization if the point doesn't apply to them. And that in no way a rejection of the facts presented. The same way that the generalization "apples are red" can be rejected by the presence of green apples without denying the existence of the red apples.
> Mgechev is telling us not to draw a conclusion from Jeff’s piece.
You're really going to pull out a dictionary on me, then blatantly ignore the emphasized word in your chosen definition that is exactly the word that makes my statement true?
Not sure why you're linking me your own posts, which I have read. You're determined to assert things that nobody but you said, which I guess is fine, but I don't think this conversation is constructive or useful. I would suggest you take a hard look at your behavior, though. But that's up to you.
The author brings his own toxicity by a) trying to milk his relationship with the angular team (he hated working with so much!) on twitter and b) making inappropriate and confusing jokes about an unpleasant topic (would he be allowed at that summit despite being a conaultant?). Igor and him just seem to be a really bad mix.
This could be true if it wasn't for many, many other former members of the Angular team confirming it's a problem. There's a very long list of core team members who quit.
This seems like a good example of productive discussion! While this won't necessarily solve the original poster's problems in of itself, it does give actionable steps on how to address them!
As for anyone interested in real world comparisons of many of the popular frameworks (though not necessarily the most bleeding edge versions), feel free to have a look here: https://github.com/gothinkster/realworld
> Currently, it's absolutely doable to get very small bundle size (<7-8KB) for a hello-world application. This, however, relies on private APIs. We haven't made them public yet, because not many folks are building hello world apps, but in the future we'll be exploring how to reduce the footprints of the framework even further for smaller apps.
This answer doesn't quite cut it. Every project starts out as an "hello world" type application. How do you audit the cost of each additional package if you didn't even start out with a "small bundle size" from the beginning?
I believe you guys have made great strides and I appreciate your efforts immensely. I wish you the best of luck, I hope you're able to actually address the large size of deployment in a meaningful fashion.
>Every year I install the VSC Language Service plugin and have to disable it the same day due to it continuously crashing and killing the editor so it seems we'll never get to benefit from that.
I've heard my partner swear at least a couple of times a week over this since we've started working from home due to corona.
"Inputs as observables" is probably the most discussed feature request on our issue tracker. I agree that there are strong arguments for going in this direction, but we generally try to keep `@angular/core` agnostic in this sense and not couple it to RxJS (EventEmitter is the only dependent abstraction right now). There are different reasons for that, but I'd say the two main arguments are: out of order component loading and ergonomics.
There are a lot of developers who are comfortable with RxJS and enjoy how expressive it is. Simultaneously, we have a less vocal majority of either beginners or people who oppose such expressive APIs. Both of these groups use Angular, and we need to keep the framework ergonomic for them.
That's why we have community libraries such as `ngrx`, which we consider as reactive extensions of @angular/core.
>- The reactive forms has been untyped for years. It feels weird to ship with a forms module that seems to work pretty well, heavily invest on typescript, and then the forms are simply `any` - I mean what the hell?
We developed reactive forms when TypeScript was still not as powerful as it is today. For the past years, however, the language evolved and it has very strict and expressive type system.
We really want to make reactive forms much more struct :) Our team has been looking actively into that, but it's not trivial to fix the problem without introducing breaking changes in the public API surface. That's something on our radar, and we've been doing a lot of exploration, but given the adoption of Angular, we want to be careful and land it without breaking the ecosystem.
In the meantime, we have community modules that provide much stricter forms implementation.
Regarding fragments and the input/output model, we haven't received much of your feedback, but that's something I'll bring up to the team.
Re: inputs as observables: Yeah I've followed the Github issues and while I get the arguments, it still seems weird that the value prop of Angular seems to be "batteries included", that the batteries then disagree with eachother.
I totally get that you have two camps of people using the framework, but right now it feels like the state Angular is in, leaves both camps satisfied. The people who like RxJs can't utilize it fully, and the people who don't still have to deal with it.
Re: forms:
It makes sense that the forms are hard to type without breaking stuff. Stuff being third-party is probably one of the reasons the React eco-system has been able to move faster, but also with more breakage. That's probably just a consequence of the different ways to govern the project.
Re: fragments/host elements:
There's a two year old issue here with 200 or so upvotes: https://github.com/angular/angular/issues/18877
I'll admit that this is probably not the biggest issue - I've only encountered it because I wanted to have sub-components within tables and that can mess up the formatting.
Re: input/output model:
It probably makes sense that you haven't heard too much about it. It's probably not something you'd necessarily think about if you just developed angular and haven't tried other composition models.
Thank you for the insights. Wouldnt it be possible to add an @AsyncInput decorator, without ever touching the ng/core?
Same could be done for @AsyncOutput, with observables instead of event-emitters.
Nice to see Angular authors here! As an another question, what are generally the legacy features holding you back you would want to change if you could do again everything with modern TypeScript, CSS and tooling?
What's tricky to make forms stricter are proper typings for dynamically added form controls. We don't know what their types are since developers can add them at runtime.
It's not impossible to make forms stricter, it's just a matter of planning how to make it in the least breaking way. Definitely from a very high priority for us.
Inputs should really handle observables - Perhaps with a separate syntax or something. You can't really use Angular without learning rxjs, and once you have the fact that component outputs use them, but inputs don't sticks out like a sore thumb.
>In templates is the biggest example - where you can use some JS constructs but not others, and have to learn a new set of directives instead of using if/for/while etc.
Templates, just like JSX have their own trade-offs. They are statically analyzable, so relatively easy to optimize by our tooling. Having HTML templates allows us to generate efficient JavaScript instructions for rendering and change detection.
This has almost zero overhead on runtime and lets us perform change detection as fast as possible (we know exactly what has changed in the view).
>Not to mention needing to bundle a compiler, unless you use AOC
You don't need to bundle a compiler in Angular. The compilation happens at build time. After that we perform a lot of optimizations (having JavaScript instructions instead of HTML templates allows us to tree-shake more efficiently).
>debugging is a nightmare
Browsers hide the part of the stack trace that's coming from node modules, others let you blackbox non relevant scripts. To ensure smoother debugging experience for folks, we've been also working on providing better debugging guides and development tooling. We'll be rolling this out in 2021.
>And the trouble is that, as a new language that you have to learn, it is significantly inferior to JS/TS. So yes, give me React any day, where I can use real Javascript and not have to feel like the framework is fighting the language it's written in.
As I said above, it's all about trade offs. JSX is very expressive, but sets its own limitations. It locks you to a specific paradigm for incremental computations, which is not necessarily the most performant one. Templates are less expressive. At the same time, they are easy to optimize ahead of time. Neither of both is JavaScript, as described by ECMA-262.
Comparing templates and JSX is definitely an interesting topic that's hard to cover in a comment on HN :)
@mgechev Thank you, I appreciate you replying to someone who's clearly not the biggest fan :)
My main point isn't so much the individual difficulties like debugging, yes you can build something on top to fix it. It's that these are symptoms of not respecting the idioms of the language the framework is built in. This leads to everything working fine if you do it exactly by the book, but when you start deviating slightly from the standard Angular way of doing things, the cracks start to appear.
This wouldn't happen if it was written to work with the language rather than against it. There's no good reason why me setting my own setTimeout() without going through Angular's should break things, but it does (and Angular reports my app as 'unstable'). If I have a getter method on my component that gets called thousands of times a second by Angular to see if something changed, it's another symptom that the framework wasn't written to fit neatly together with the language.
The fact that you can add yet more code and tooling to handle these issues as they come up does not alter the fundamental problem.
I'm really interested to know how many JS or DOM builtins Angular modifies, wraps, edits the prototype, or replaces in order to work. I know it modifies Promise, I think setTimeout too, and probably also DOMElement. @mgechev, would you have that information?
In my experience there are two different ways to go about creating an abstraction layer for others to use: a) you respect the language/standards/idioms and just add new building-blocks to the pile, or b) you use the language as a mere "target environment" and build your own, self-contained walled-garden on top of that environment. This is a conscious choice, and each of these approaches has tradeoffs and costs. I wrote a blog post about it, actually: https://www.brandonsmith.ninja/blog/libraries-not-frameworks
I personally tend to agree with you, but I think there are use-cases where the Angular philosophy can be the right decision. The key differentiators for me are a) does this walled garden provide real benefits over the more open model? b) does the organization backing this project have the resources to re-implement and maintain standard library functionality, build/editing tooling, debuggers, documentation, etc? There is a very high cost to going this route, because so many things move in-house. In Angular's case, backed by Google, the answer to question b is probably yes. The answer to question a is less clear. It sounds like there are performance advantages, and certainly there's a cohesive dev experience. For some companies, this tradeoff may be worth it. Personally I wouldn't want to use Angular, but I respect their decisions for what they are.
Aside: I wrote that blog post after being faced with a framework that's very similar to Angular, except it's backed by a very small team unaffiliated with a major tech company and is barely being maintained at this point. That's pretty much the worst-case scenario; with a more open "library" you'd have a much easier time coping with a loss of official support. But Angular is unlikely to ever find itself in that kind of situation.
> AngularJS (v1) found itself in exactly that situation!
Sort of. Angular 2 came out in 2016, and Angular 1 will continue to get long-term support through 2021. That's a pretty generous window, and there's also a clear and well-documented migration path. Overall it's a dramatically better situation than the one I found myself dealing with.
Of course! I love chatting about incremental computations and approaches in different frameworks :)
You're getting warnings at devmode (i.e. during ng serve) that you've modified a binding after it was checked. This is not related to the way we trigger change detection. The simplest example is:
@Component({
template: '{{ foo }}'
})
class AppComponent {
_foo = 0;
get foo() {
return this._foo++;
}
}
This is clearly unstable because every time we get the value of foo, we also increment _foo. What Angular does in devmode is to ensure developers are not hitting this issue.
This is not related to setTimeout and the APIs we patch with zone.js. The check just safeguards us to not get into such cyclic binding scenarios. We'll be working on better explaining the error and the message in future releases.
DOMElement is untouched, we only patch APIs so that we can plug into the microtask queue and trigger change detection when it's empty to ensure consistency between the model and the view.
In fact, one of the projects high on our priority list is to make Zone.js optional and provide alternative, ergonomic APIs to trigger the change detection and specify local component state. I am saying ergonomic APIs because this is already possible, just not ideal since we have to specify a noop zone when bootstrapping the app. Optional, because many developers love the current behavior and we want to keep it available.
And just, let me spent one more paragraph in explaining how the change detection works. Just want to show why is it that fast and with such a low memory overhead.
Each component has a template that we translate to JavaScript instructions. For example:
<span>{{ foo }}</span>
We will translate to something like (I'm writing the comment from my phone, some instruction names could be different in the CLI output):
if (mode & creation) {
renderElement('span');
interpolation(ctx.foo);
} else if (mode & update) {
interpolation(ctx.foo);
}
That's a leaf component, but we can imagine how it works in more complicated hierarchies.
So when we trigger change detection we just invoke the template functions for the components in update mode. We update only the bindings that have changed, without allocating any additional data structures to do that.
Whether the framework is written to fit the language is mostly a subjective opinion.
Angular doesn't go against the standard anywhere and does not introduce extra syntax on top of TypeScript. It also doesn't add new semantic to already existing constructs.
In fact, to keep compliant is from a high priority to us. We constantly interact with different standardization bodies and keep up to date with standards.
Yes, the basic template update mechanism is fine, and it does seem to be fast. I was talking more about the change detection, how it knows that foo has changed in the first place, particularly if it is a nested object or a getter that leads to one. I have had cases where Angular calls the getter constantly (proved by console.log).
I agree that there isn't another obvious way to figure out something changed, but that's the point - since JavaScript doesn't have a way to notify on changed properties, for the framework to make that the paradigm is an interesting choice. So it's great news that you're moving away from that and from zone.js.
This is where React's setState is much easier to reason about. I call a function, I know that I told React that something changed, so the update isn't a surprise. While setting a property does not usually cause anything to happen in Javascript, so I have trouble getting my head around how it works and what Angular is doing behind the scenes, and realizing that it must be polling, which isn't usually a good pattern.
> In fact, to keep compliant is from a high priority to us. We constantly interact with different standardization bodies and keep up to date with standards.
Which is definitely a good thing, but also an indication that it's not actually Javascript, just something that tries to be compatible with Javascript.
Anyway, thank you very much for responding! I also understand that Angular has a lot of history to work with and you're doing a good job with the paradigms you have.
Hm, so if you get modifications thousands of times a second, then ... something is wrong. I'm tempted to say you're "holding it wrong". Meaning that on one hand you do something that goes against how it ought to be, but also Angular despite all its mighty compiler/optimizer/typing magic doesn't stop you from doing this and doesn't help you to fix this.
Also, I don't think they're moving away from zone.js. They are simply providing an alternative for the more minimalistic minded folks, who like to put their own stack together.
> While setting a property does not usually cause anything to happen in Javascript, so I have trouble getting my head around how it works and what Angular is doing behind the scenes, and realizing that it must be polling, which isn't usually a good pattern.
... um. It's a bit ironic that you say that Angular is going against JS, but maybe you forgot about the wonders of Object.defineProperty which allows the unflinching true hackers to virtually override assignment operation itself!
But Angular doesn't work that way, saner heads prevailed apparently. Hence the use of TS annotations, like the @Input property, which basically wraps the field to trigger change detection. And zone.js, which ... well, basically it does work that way. (It simply replaces global objects with a wrapped version. It wraps timers and I/O, as in click, type, touch, fetch, and websocket events, and who knows what.) So no polling, but yes monkey patching.
Strict type checking is often reported as confusing for folks getting started with Angular and web development. That's why by default our type checking is not the strictest we support.
To make sure advanced developers have better compile-time type checking and editor support, we introduced strict mode. When you create a new workspace the CLI asks you if you want to get it enabled.
In the future, incrementally, we'll be enabling strict settings for everyone.
It still seems strange to me, if you start a new Angular project then you know you're writing TypeScript, no ifs or buts - and that means if you write some code that doesn't compile, you'll have to fix it before it runs. I don't understand why that's seen as different in the template layer?
Great that it's there at all though, last time I developed with Angular templates didn't have type checking at all, and it kind of hurt.
Sorry for the miscommunication. I meant type checking in general, not in Angular templates in particular.
To get the same strictness as in TypeScript, you can enable `strictTemplates` in tsconfig.json. Here's our guide which goes into more details https://angular.io/guide/template-typecheck.
> Developers in these environments usually do not take part in these surveys.
Angular team member here. These are our observations as well. Based on metrics we collect (opt in telemetry, website traffic, language service downloads, etc), there are over 1.7m developers using Angular.
I'd say that many of them are in the enterprise, but there are also a lot of startups that bet on Angular. This is mostly due to the integrated stack where folks need to make fewer decisions and get smooth updates across versions.
Stability is another factor. We validate every commit pushed to the Angular repo with 2600+ projects inside of Google. If any of their tests break we rollout automated migrations or rethink the implementation.
Just a heads up. Angular does not use virtual DOM to reduce memory overhead. At build time, in Angular we've been generating instructions for efficient rendering and change detection since the early versions of the framework.
Angular team member here. I'm curious what's the source of your data that Angular is a distant third?
I understand there are a lot of data points to consider. In terms of usage, based on our metrics this is incorrect, but of course, that highly depends on your dataset that's why I'm curious.
Not a distant third in terms of usage, but how simple it is to use. I'd think Vue is probably the distant third in how much it's used, but it's impossible to truly know these things.
As for my judgement of modern Angular as complex, there's a few things I'd like to point out:
- separation of CSS, JS, and templating into separate files. This makes it harder for the mind to keep everything in place rather than just scrolling
- defining routes in a global file but also in modules.
- providers, services, modules, etc
To be fair, Angular is so much more than React and Vue, which just parse templates and add some features. I feel like I'm not spouting a hot take, I feel like it's earned. If Angular wants to seem more approachable, the team has a way to go.
