I've been developing in Angular for a bit now and loving it. I do understand the performance implications of data binding and use the bind-once plugin and other means of minimizing watches, etc.
However, I'm wondering if, how, and when Angular applications will become significantly faster? By that I mean with all things being equal performance almost or on par with non-declarative frameworks.
Is this matter of browsers catching up to the declarative model?
Do any browser currently have any plans for that?
Is it a matter of EcmaScript 6 or beyond to eventually support native "watching" of variables. (Any hope?)
Or will that take too long and Angular itself needs to improve in some clever way (any plans from the Angular team?)
Of course eventually browsers and computers in general get faster but is there anything on the horizon for Angular performance?
The way I see it, regarding bindings / change listeners etc., there are 3 possible areas of optimization:
Tweaking special cases of scope watches / bindings:
This includes for example bindonce or the optimization of specific data structures, such as $watchGroups, which is like one watch for two or more properties (https://github.com/angular/angular.js/pull/7158). These are changes that basically anybody can implement and propose, but they don't have very high priority for the core team (although they are working on a bindonce like feature).
Improving the general change detection / application architecture
In angularjs 2.0, the scope change detection algorithm will be much faster than now (http://blog.angularjs.org/2014/03/angular-20.html). Another major improvement in the architcture I see would be batched DOM updates.
Browser features
Object.observe() is a standardized way to listen for changes in objects. It's currently not supported by all major browsers, so this can't be used yet.
The most promising area is currently (2) as the general architecture changes will incorporate or obsolete changes in (1). I think a public alpha of angular 2.0 will be available at the earliest at the end of the year.
You are asking a lot of what if/theory questions. Angular is as fast as you make it. Performance is directly tied to how you application was developed. I am woking on a project with 50+ controllers that had serious performance issues as we were dealing 100,000+ records in a table. We were able to get sorts and filters from multi second transactions down to 60ms just by being smart about our decisions. Bind once is only a piece of the puzzle with performance. You really need to look at your watches. The flame chart is a great tool for this. I wrote up a pro tip on Coderwall.com about it:
https://coderwall.com/p/nsanaa?i=1&p=1&q=author%3Abreck421&t%5B%5D=breck421
Also you need to be mindful and purposeful about your DOM manipulations (ng-repeat is slow).
Brian Ford just did a lightning talk about this topic:
https://github.com/breck421/brian-talks-about-angular-with-lots-of-data
Hope this helps,
Jordan
Related
I'm a project manager of a market place and I'm trying to find solution for my concerns. For two years a ago we decided to develop market place.
In front layer we decide to use angularjs and our team professional implement front layer using AngularJS. We add dependency injection for first time to angularjs 1.3 and solve google analytic crawling in SPA website.
But when google announce On July 1, 2018 AngularJS entered a 3 year Long Term Support period. As a project manager I have a big concern because We living in 2019 and after two years whats happen for our website ?
But my biggest question is how optimistic how long can we use Angularjs?
how much migration is necessary for this framework and
Is it possible that the sites written with Angularjs are not able to work after 2021?
Google announced:
All AngularJS applications that work now, will continue to work in the future. All published versions of AngularJS, on npm, bower, CDNs, etc will continue to be available.
For more information, see
Angular Blog - Stable AngularJS and Long Term Support
AngularJS Version Support Status
It’s out of date now, and new projects should absolutely not be built using it. This isn’t to say it was ever a particularly great choice. AngularJS came out of nowhere and became popular by default, rather than because it had particularly great design. It has a difficulty curve better suited to a great roller coaster than a decent framework, and a bunch of weird architectural and terminology choices. What the hell is a $scope, anyway? And what is a directive? What does transclusion actually mean? Meaningless terms that AngularJS has created. AngularJS does some things that are fundamentally wrong, such as creating invalid attributes on HTML markup. Even Google doesn’t use Angular for their own apps, like Gmail, and there’s a reason for that.
In fairness, AngularJS was always a poor choice. Its idiosyncratic code means that unlike other frameworks, it’s not good at implementing an agnostic, javascript solution. AngularJS code looks unfamiliar to anyone not super experienced with the weird intricacies of AngularJS itself.
Thankfully, this decision is well made for you – AngularJS is now quite thoroughly dead, and only legacy projects will continue to be using it. We should be grateful for what AngularJS has given us, and respect the position it held, but we should be just as pleased that it’s gone.1
The change is only about "support" and it means, no more bug fixes and no more improvements. Other than that, everything will be the same. Although, you should consider some disaster scenarios after LTS.
I saw some posts about running AngularJS and Angular side by side and I think it can be a good solution for your problem. Since you have enough time to migrate, your team can develop new features on Angular and you can also maintain your current AngularJS. Eventually you can get rid of AngularJS depending on your project size and development capacity.
Please check these scenarios.
Running AngularJS 1.6 in Angular 5 (side by side)
Running Angular and AngularJS frameworks side by side
For Angularjs support, you can find the previous discussion on this portal: angularjs 1.x support lifecycle and end-of-life
And the question regarding migration, in my personal opinion migration is a better option as the latest Angular version provides Boost in performance, Mobile-driven approach, code Maintainability & optimization, and most importantly Reduced development time and costs with better support.
And if asked about the migration approach, I would suggest a complete re-write that can be the most cost-effective strategy. If you’re a manager, put your team through Angular training (live, online, videos, books). Allocate time and budget for getting your developers up to speed with Angular as the learning curve is steep and prior experience with AngularJS is not overly helpful. Then your developers will write the new version of the app as per best practices recommended for Angular/TypeScript projects.
And finally, it’ll definitely pay off in the end. And, secondly, the newer versions of Angular won’t let you systems become outdated or irrelevant.
There is a team called XLTS.dev who are providing extended support for AngularJS beyond December 2021.
We have used Angular JS extensively in our company for enterprise projects, mobile applications and continue to use it. Google's decision to stop development of AngularJS and put it on a EOL will definitely make developers to panic. But 3 years to migrate away from it is a long time and you can plan accordingly.
If your plan is to migrate to Angular, then you can follow their official guide to upgrade using ngUpgrade. You can find numerous articles online that explain how they upgraded existing AngularJS apps to Angular.
If your plan is to consider migrating to a totally new framework, then this will involve some work. You should take a look Web Components spec. Your existing directives/components can be re-written, with less effort, as web components (shadow DOM) or custom components (without shadow DOM). There are libraries that help you write these generic components - supported on most browsers today - Stencil JS, lit element and a few others.
The advantage of using Stencil JS is that it provides tools to compile your web components to target different frameworks (Angular, React, Vue, Ember).
The latter solution seems feasible as it allows you to migrate directives one by one over a period of time, without having to re-write the whole application in one go. In the future you can also re-use your components in the framework of your choice.
As for your question about will it continue to work after 2021 - yes it will continue to work. The problems you might face might not really be of technical nature, but related to hiring resources to work on it or maintain it.
I am AngularJS developer and I do continue to use this framework for some of my projects. I am aware that in not too distant future this library will be completely outdated (as some of you can say it's the case now), however:
AngularJS ecosystem gives you still lots of choice/support (as framework is very mature)
my main libraries as ag-grid, highChart or others, help to build great apps out of the box with little time
I still do enjoy to work with this framework for it's simplicity and flexibility
If you should build brand new app I would recommend React or Vue (or other framework) especially if you do not have significant experience with Angularjs. However if Angularjs is not new for you, you need to go fast - just use your experience and go for Angular.
Taking into account what you wrote:
My main concern is after 3 years of support. Whether after the 3 year end of support, Angularjs sites can continue to work without problems
Angularjs apps won't just stop to work like that, from one day to another.
As your project requires long-term maintenance, needs to be built from scratch and will take lots of effort - Angularjs ecosystem is then probably not the best choice for you (I do insist "for you").
Let me start with the justification. A lot of companies that have now been using AngularJS for years are still using it, and don't have immediate plans to migrate to 4+. So there's marketability, plus the inevitable requirement of knowing both as an Angular developer.
My question is broad I know, but I am curious to hear from folks who have experience with both. Are they completely different, or will some of the knowledge transfer? For those who know both really well, what are the key differences that really stick out to you?
In comparison to Angular (2 and higher), AngularJS has several important limitations that affect the way applications can be built.
A single injector with string DI tokens and no built-in lazy loading.
Config/run phases and synchronous bootstrapping (the overview of configuration recipes).
Scope hierarchy for data binding and its consequences for application architecture - the concept of digests, performance impact, AngularJS-specific services ($timeout, $q, ...) instead of native counterparts, etc.
jQuery-influenced approaches for manual DOM manipulation.
Considerably different set and API of built-in services, directives and filters (pipes).
No support for nested applications (possible with a hack).
No view encapsulation and component styles.
No built-in component router.
No built-in translation/i18n.
No built-in support for workers and server side rendering.
No official CLI.
The development of AngularJS has been focused on providing upgrade strategies and common features since 1.5. In a lot of aspects Angular/TypeScript experience can serve as a source for best practices for modern AngularJS development.
AngularJS is generally more flexible in the ways how its injector and compiler work and allows for a plethora of neat hacks that have been rendered impractical or impossible in Angular.
There's a lot of smaller differences that AngularJS introduces which may be discarded if the goal is to intentionally limit development practices to the ones that allow to build TypeScript/ES6/ES.next AngularJS application that follows Angular guidelines and could be easily upgraded to Angular in future.
ng-metadata does its best to unify AngularJS coding practices with Angular but still requires a good understanding of the differences between two frameworks.
However, smaller differences make a big difference if a developer works on existing AngularJS project that heavily relies on them and uses legacy coding standards.
I have seen many articles regarding the changes in Angular2 . But I can't find much advantage in using Angular2. Can some one point out some new things that can be done using Angular2 which can't be done using the previous versions.
I know there are changes like $scope changed to this. I'm not asking for changes. I'm asking for new features that is in Angular2.
The TL;DR Version
Because ES6 is important to pick up, so no need for a custom dependency management system anymore. ES6 and Angular 1 together get ugly fast, as they together introduce a bajillion coding styles :(
Although the library is overall heavier, the architecture it uses (all component based) is a lot faster, lighter, and modular for a scalable application. See http://info.meteor.com/blog/comparing-performance-of-blaze-react-angular-meteor-and-angular-2-with-meteor
You receive (upcoming) Server Side Rendering, which enables fast initial load time and Search Engine Optimization (Yay!) See: https://github.com/angular/universal
You receive WebWorker friendliness, which makes your application able to "multi-task". See: https://github.com/angular/angular/blob/master/modules/angular2/docs/web_workers/web_workers.md
Shadow DOM is not fully inherited by Angular 2 yet, but I'm sure it will be. It has some support right now.
The whole concept of $scope is gone. You receive two way data binding with anything you put in your ES6/TypeScript class, but anything more you need to create a Observable or promise. Unfortunately, you can't just shove anything into the scope, digest, and WALAH! anymore.
And of course, all the cool stuff they mention on their website: https://angular.io/features.html
Hope that helps!
Support for different languages TypeScript, Dart, ES5, ES6.
Change detection is much more effective
Support for isomorphic applications where the same code can run on the server, the browser and a WebWorker in the browser
Moves more work to build time to reduce the time for the initial page load.
Simplified binding syntax
Improved DI
There are also lots of mostly smaller and tiny features that Angular2 doesn't (yet?) support which Angular 1.x does.
I've been playing around lately with Entity Framework, WCF RIA Services, and Silverlight 4. I'm impressed by how rapidly you can develop an application with these tools, and you get a lot "for free", such as the Silverlight UI automatically knowing about certain validations that are included as DataAnnotations on the EF model. However, it seems like in a large application it would be undesirable to have a dependency on EF pushed all the way through the entire application including the business logic and UI.
I know that you can use POCO / IPOCO with Entity Framework, and that is certainly an option for me. However, if you go that route, you lose some of the "automagic" stuff such as Silverlight being able to show model validations without any extra work.
How are people dealing with this? Do you give up some of the power and put interfaces in between the different layers in order to decouple the other layers from EF? Or do you give up on decoupling in order to allow for more rapid development? Is there some way to have my cake and eat it too that I'm not seeing?
My group is currently dealing with this exact issue. We came up with a decent compromise that everyone was happy with. Keep in mind that before it is all over with, projects become more complicated over time and maintainability is key. You also want to increase code reuse as much as possible so replacing your UI (or unit testing) is a minimized effort.
Given all this, we favored a well defined domain layer instead of pushing EF all the way through to the UI. This makes the model the heart of the application and doesn't force us to conform to the schema of our database. I know EF tries to abstract that away with its conceptual model, but we kept running into little gotchas that made it more and more difficult to rely on EF for the full stack. For instance, there really isn't a great place to put business logic with EF. We didn't want to put that stuff into Interceptors and we didn't want to put it in the UI. Sure, there might be a clever workaround for this, but we weren't liking the direction we were being pushed.
The compromise was to use EF but to keep it between the data store and the domain model. This way we still don't have to program against DataReaders, and we can leverage the benefits of self-tracking entities in the domain. We then expose basic WCF services (not RESTful) from our domain to our UIs.
To us, the extra validation work wasn't really THAT big a deal. Sure, our initial release takes a little more time, but the overall maintenance cycle doesn't take as long because we aren't finagling with the complexities of the framework.
I’m currently involved in the design of a prototype Silverlight 3 application used by call centre operators in an enterprise who take queries via phone and email. The intention of the prototype is to demonstrate how Silverlight can be used to improve the UX and overcome some of the hurdles of using ASP.NET webforms in a high latency environment. I won’t go into the details of the environment or the rationale of Silverlight 3 vs 2 or WPF, this question is about usability;
I’m looking for examples of good user interface design suitable for the above requirement that highlight some of the benefits of Silverlight. It’s a prototype so it can be a bit sexier than your usual enterprise app and have a few more bells and whistles than you’d usually get from user requirements. The goal is to both provide something functional and introduce the “wow” factor. Appreciate any resources or examples you can think of.
You've got a stateful client - one of the interesting things to do is leverage that state.
For example:
Task centric UI with multiple active tasks.
Each task represents a process/workflow that has begun, but not yet completed. Especially useful in scenarios where ther are interrupts.
Auto-save drafts to local isolated storage in case the app restarts, browser closes etc. Any partially filled forms can be restored when the app is re-launched.
The other thing is context... or preserving context of the task at hand. For example, if you want to do a lookup, you can popup a dialog, rather than navigate away from the current page.
Just some quick ideas...
Have you seen http://quince.infragistics.com? Although not specific to Silverlight it's full of proven UI methods - not Infragistics specific!
I find it very useful when designing forms and controls, maybe you will find some good suggestions there.
I like the way it encourages (forces) all your service calls to be asynchronous. From the UX point of view it means that your form is not locked up while performing a potentially laggy operation.
Animations are nice too. While they're often considered useless fluff, they can reduce the amount of surprise the user experiences when something suddenly changes. They can also be used to draw attention in a more subtle way that a messagebox in the face.