4 ms·

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

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

llimos 6y ago
@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?
- mgechev 6y ago
  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.

llimos 6y ago

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

mgechev 6y ago
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.