mgechev

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.

Performance always needs to be a priority for a team to hit satisfying metrics.

Wiz is designed to make it harder to get bad metrics if performance is not your top goal.

Yes, via Angular.

It introduced very fine-grained code loading on interaction and something the community refers to as resumability.

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.

Merging is the ultimate goal! Both teams are already working closely together on shared designs and specific implementations.

We’re going to share a blog post with more details in the next couple of days.

We’re building infrastructure for these products rather than the products themselves.

I’ll be happy to answer questions about Angular and our collaboration with Wiz :)

Fundamentally they are similar to Preact Signals, Solid Signals, Vue signals, etc.

We took some different trade-offs and listed the details here https://github.com/angular/angular/discussions/49683

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

Or Svelte works essentially the same way as Angular? :)

They are similar in a sense that both compile HTML to incremental DOM-like structure, but have their own differences.

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.

Angular team member here :)

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

  if (mode & creation) {
    renderElement('span');
    interpolation(ctx.foo);
  } else if (mode & update) {
    interpolation(ctx.foo);
  }

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.

Angular team member :)

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

Angular team member here.

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

Angular team member here.

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.

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.

Angular team member here. We're working on simplifying the Angular learning journey.

Generally, lots of the examples out there use very expressive APIs coming from RxJS. They could be very powerful, but at the same time may look convoluted to folks unfamiliar with the semantics.

I can recommend you checking out https://angular.io/start. We did a few iterations on the materials and tried to introduce the concepts from the framework gradually.

Something you could notice is that Angular encourages the best practices from the beginning, such as TypeScript, testability, etc. Based on my observations, this may make the learning journey a little steeper at first, but starting with (and learning) good practices is always worth it.

A common pattern is to separate the instantiation of an abstraction from the place you're using it. There are variety of ways to implement this in different technologies/frameworks.

The way Angular implements it is the way our team believes is the most scalable and expressive way. It has been tested in over 2k projects inside of Google and hundreds of thousands of external apps and seems to be working well.

At the same time, this is just a feature that the framework provides. Just like any other technology, you can pick what pieces of the entire system which works for you and ignore the rest. That's not part of the beginners journey and shouldn't be, especially for folks unfamiliar with the pros and cons of this approach.

The static HTML templates allow us to compile them to JavaScript instructions, similar to incremental DOM (iDOM).

This way Angular can perform an efficient change detection to reflect changes in the view.

Static versus dynamic has its own trade offs. It's well explored topic in theoretical computer science and popular literature. Static systems definitely can set some constraints, but at the same time open a lot of space for compile-time optimizations.

Hey, Angular team member here.

The decision to use Observables was made after an extensive discussion. You can follow the thread here https://github.com/angular/angular/issues/5876. If that's an interface that doesn't align with your expectations, you can use fetch and/or wrap it in a service to take advantage of the DI mechanism we provide. Another popular third-party solution is https://github.com/axios/axios.

There's a straightforward way to export components to be used by a third-party app directly via the Angular CLI. If you'd prefer to use a component outside of Angular, we have @angular/elements.

Hope this addresses some of the concerns you had.

This is true for Angular as well. To use the framework you don't need to understand everything it provides. In https://angular.io/start we're aiming to reduce the initial conceptual overhead.

We understand that we can work on simplifying the mental model of Angular. This is something we're working towards. We're careful with in process though because we want to provide a consistent, backwards compatible development experience.

Thank you! We're really excited to finally make Ivy generally available! ️