Angular 10 Now Available(blog.angular.io)
blog.angular.io
Angular 10 Now Available
https://blog.angular.io/version-10-of-angular-now-available-78960babd41
10 comments
I'm a frontend developer working on angular for two years. Initially I thought this could be actually better than other frameworks, since it forces you to use typescript and has a standard, easy and clear way to do forms. But seems like that for everything else, angular and it's community like to hug a more-complex-than-it-should-be approach. No single file components. No straightforward export of a component to be used from a third party app. Http requests are even exposed as observables in the official docs. Don't really know how so many companies use this.
Having used Angular for years, I share the same experience. Everything is hulking complex and opaque. Compare it to React, which is simple enough in principle that you can actually understand whats going on to push your code to browser.
Angular is the J2EE/Plan9 web framework. They just keep layering on complexity when they find use cases that don't work. Instead of ratcheting down to give you more control, you get even less. The cycle repeats. Its way more than a web framework now. The templates you write are barely related to HTML and JS, an order of magnitude more divorced from reality than JSX
Angular is the J2EE/Plan9 web framework. They just keep layering on complexity when they find use cases that don't work. Instead of ratcheting down to give you more control, you get even less. The cycle repeats. Its way more than a web framework now. The templates you write are barely related to HTML and JS, an order of magnitude more divorced from reality than JSX
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.
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.
I’ve been using it for 4 years now, and I wish it would die. I don’t understand how it could possibly have come about intentionally.
It's a solution looking for a problem. The reasoning behind IoC containers was the ability to deploy binaries and at the same time be able to simply configure them with manifests without having to recompile the binaries or rerun unit tests.
There is absolutely no reason to use an IoC container with a dynamic language. None, even when one is using Typescript.
This is an "ideological" framework where the "ideology" is forced at all cost, surprising since Angular creator was a Java consultant for Adobe and then Google.
Changing a little script takes zero effort.
There is absolutely no reason to use an IoC container with a dynamic language. None, even when one is using Typescript.
This is an "ideological" framework where the "ideology" is forced at all cost, surprising since Angular creator was a Java consultant for Adobe and then Google.
Changing a little script takes zero effort.
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 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.
> easy and clear way to do forms.
I see this "aNguLaR ReACTivE fORmS" meme all the time. I don't understand the claim or the hype. Vue or React or another framework are all reactive and declarative. HTML inputs can be bound to the component state. After recently trying to use Angular Forms all I got from it was "Wow, they really have over-engineered simple data binding haven't they?".
I see this "aNguLaR ReACTivE fORmS" meme all the time. I don't understand the claim or the hype. Vue or React or another framework are all reactive and declarative. HTML inputs can be bound to the component state. After recently trying to use Angular Forms all I got from it was "Wow, they really have over-engineered simple data binding haven't they?".
Angular's form builder is the only framework-given option that gives you a isolated object while keeping you in power over how the template should be rendered. You also have in the same ecosystem the ControlValueAccessor interface which makes it really easy to adapt custom form components to be used by the form groups you create.
In react there's no built in solution; in vue you need to polute the scope of your component with form details no one wants. God forbid you if you want to do something less basic like a async validation
In react there's no built in solution; in vue you need to polute the scope of your component with form details no one wants. God forbid you if you want to do something less basic like a async validation
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.
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.
I've been developing web apps with Angular since AngularJS (v. 1) and I love it.
Thanks to the developers and the community for keeping it up to date and for the continuous improvements!
Thanks to the developers and the community for keeping it up to date and for the continuous improvements!