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