Some background:
I having part in developing a huge, extremely dynamic and customizable Angular 1 web application.
Since it so huge and dynamic, there are tons of watchers out there - 4K in single view, at least.
As may be expected, the application is suffering from major performance problems. This huge amount of watchers make application loading and general response times to be very long.
As one possible solution, I was considering to upgrade several of "heavy" components to Angular2 - so these parts could live in ng2 framework and use ng2 change tracking - which is much faster.
While reading migration documentation, I noticed this paragraph:
When we downgrade an Angular 2 component and then use it from Angular 1, the component's inputs will be watched using Angular 1 change detection.
At this point I want to get advice, just to make sure I'm taking right decisions:
Since I not going to convert the whole application at once, but to convert incrementally (directive by directive), which direction I should take in order to benefit ng2 performance improvements (e.g. ng2 change tracking):
a. Should I migrate "bottom-up", e.g. top level components will
remain ng1; while lower level will be converted to ng2, or
b.
Migrate "from up to the bottom"
Personally I prefer first option (sounds to me less risky), but in case the shell will remine ng1 while its content will be converted to ng2 - isn't that means (according to documentation) that I will be forced to use ng1 change tracking mechanics inside ng2 components? Or I get it wrong?
From your experience, which migration direction proves itself better?
Thanks
So I'm a bit late to the party here. The ngUpgrade stuff by the Angular team is absolutely fantastic and a viable solution, however I think it'll create more work that perhaps it may be worth (depending on the size of your application).
What I'd shoot for would be a modular process of upgrading a single module at a time rather than components/services at a time. i.e. assuming your 1.x app is broken up into modules you can begin rewriting the first module for example a "dashboard" module or "inbox" module. I went through this process before and we rewrote the homepage of our application, and once the user needed to hit another page that was the "legacy code", the url had /v1/ in to show that they'd actually gone to another application. This way we technically had two applications but ran them completely separate.
If you're still looking at concepts etc to upgrade, I've been working on an Angular 1.x to Angular 2 migration guide which may help you on your way :)
Related
My task is migrate incrementally from AngularJS to Vue3. The idea is to start using Vue components in some places, rotes, server requests.
Is someone has success story using Vue3 components/routing in AngularJS project?
I've spent few days trying make it work, but in internet there is no example about it. Only Vue2/AngularIO, Vue3/AngularIO, Vue2/AngularJS, etc.
Not sure what more information I need to provide.
Thanks in advance!
I think one good way to achieve such a complex migration would be to borrow some principles from the microfrontend architecture principle.
Just divide your application in big components, that you would like to convert one by one.
Take a big component of your application, rewrite it in VueJS, and make it communicate to the rest of your application using custom events.
That will allow you to work incrementally, without using any additional component or library to make the transition.
Just be sure to define clearly the boundaries between your different components, and don't try to apply this approach to very small components (as there will be some overhead involved by adding this event communication).
I am trying to figure out if we can move our Angular 1 application to Angular 2. We have a sufficient amount of code to warrant using ng-upgrade as opposed to starting from scratch.
Our current application is pushing the performance limits of what Angular 1 is capable of. Hopefully Angular 2 will bring us some performance benefits.
My question is how much of an impact on performance our migration path will have (i.e. running Angular 1 alongside Angular 2 as per ng-upgrade guidelines)? Will it have a noticeable impact or will it not be noticeable in practice? My main concern during this period is run time speed as opposed to memory usage or load time.
Not sure if this thread is still relevant, I'll try to add some further notes. Currently we are at Angular 6, and the upgrade behavior has gotten a lot better.
For anyone having performance issues or thinking there might be issues I recommend have a look at the downgradeModule (https://angular.io/api/upgrade/static/downgradeModule#differences-with-upgrademodule)
You basically can either Upgrade the Angular 1 part or downgrade the Angular 2 part. On a first view they might seem similar but the behave fundamental differently. For anyone concerned with performance I definitely recommend the latter approach. This way you will have the improved performance for your new Angular 2 code and the old code runs at nearly the same/if not the same speed.
Even for fairly large applications it is a breeze and you very rarely have any performance problems.
You should know that there are two ways to bootstrap a Hybrid App:
UpgradeModule - bootstraps both the AngularJS (v1) and Angular (v6) frameworks in the Angular zone
DowngradeModule - bootstraps AngularJS outside of the Angular zone and keeps the two change detection systems separate.
I have tried both ways. And I recommend using DowngradeModule - it's better for performance and memory leaks.
I am currently in similar shoes and the only thing I know is that the digest cycles of A1 and A2 trigger each other. This makes me think that during upgrade, things will be slower... I will update you if I find anything different in coming months.
https://angular.io/docs/ts/latest/guide/upgrade.html#!#change-detection
Everything that happens in the application runs inside the Angular 2 zone. This is true whether the event originated in Angular 1 or Angular 2 code. The zone triggers Angular 2 change detection after every event.
The UpgradeModule will invoke the Angular 1 $rootScope.$apply() after every turn of the Angular zone. This also triggers Angular 1 change detection after every event.
We have an app/website using Angular 1.5. It'll take time to convert everything to Angular 2 and it isn't a priority as what we have currently work.
I was thinking it could be interesting for new components/directive/services to write them in Angular 2, to avoid having to eventually convert them later on, as well as to start learning the new syntax.
But is it really a good idea to ship something containing Angular 1.5 and 2 with ngUpgrade? The memory footprint should end up being bigger, but are there other drawbacks?
The following article http://blog.thoughtram.io/angular/2015/10/24/upgrading-apps-to-angular-2-using-ngupgrade.html by Pascal Precht mentions: Keep in mind that the goal of this [upgrade] phase is to stay in it as little as possible, since running both frameworks on the same website is surely not ideal. but that doesn't tell us much.
Does anyone have feedbacks with a "real" (ie not tiny or proof of concept) partial update using ngUpgrade?
We have a large commercial product (banking web-application) and we use a hybrid application on production.
We migrate services and components from AngularJS 1.5 to Angular 6, and it will take at least a half year.
A few tips:
To avoid all issues with $digest and performance I recommend using DowngradeModule - it bootstraps AngularJS outside of the Angular zone and keeps the two change detection systems separate.
The first hybrid app used UpgradeModule and we had a lot of problems, - this approach is not for large applications.
Use similar code before bootstrapModule(AppModule)
import { enableProdMode } from '#angular/core';
if (IS_PRODUCTION) {
enableProdMode();
}
If you have any questions - you are welcome.
My team was considering using angular js for web app UI development. But knowing at a high level how single page apps work, I had a question as to, how feasible it is to use angular js framework, for a large web application. this would have at least 200 screens, each screen containing an average of 30 UI controls like text boxes, calendar controls, drop downs etc.
The user will be accessing the web app on desktop or laptop and will be using the application in the browser throughout an 8 hour day, without ever closing the browser.
Given above usage, would angular js, memory usage / performance be issue?
are there web apps with huge and complex UI, built using angular js, that are in production and used everyday?
You can have not just 200 but 1000's of screens - this number does not matter as long as you address the core and fundamental questions below. They all boil down to memory and performance.
At a given point of time how many $watches will be active.
At a given point of time how many listeners are created.
At a given point of time what is the complexity of DOM i.e. the number of DOM elements and thee nesting/depth.
At a given point of time how many Javascript modules (services, controllers etc.) will be loaded in the memory. Even though these things are singletons they consume memory.
For each such screen how much memory will be consumed (if you use jqueryUI etc. your memory increases quite rapidly than pure angular + html components)
This brings to what you can do to control the above factors which if not watched will make your application sink/crash.
1) How do you break the run-time complexities of your "big" application ? You can now think of "Routers" or dialogs. Each of your screen will come-and-go i.e. you will never display 200 screens the same time.
2) Make sure when the screen is gone there is no "leftover". Don't use jQuery - if you do make sure you clean this on $scope.$destroy.
3) Multitudes of directives:- Directives are powerful but don't over use it - try not to deep nest too many of them. templateUrl is "tempting" but sometimes in-lining a template is the best choice. Use build tools that will inline the templates.
4) Load modules on demand using requireJS. This will force you to modularize your application and think hard about concatention strategy (combining JS files). Will force you to write independent modules.
5) Browser caching your assets and a good cache busting mechanism. Grunt based plugins are to your rescue. Minify your assets.
6) Compresss the assets for efficient network utilization and faster transmission.
7) Keep your app encapsulated in Angular. Don't create any global objects. Chances are that they have access to some closure or are referring to some things within angular $scope and $scopes are now still hanging on or are in difficult trajectory to be able to get Garbage Collected.
8) Use one-time-bind or bind-once model binding as much as possible.
9) Splash screen is an excellent weapon - us it. Helps you load some stuff upfront while the user watches smooth/jazzy picture/picture :)
Regarding 8 hours a day constant use
Unless there is a leak of the following kind you should be fine:-
1) Listeners leaking i.e. hanging around.
2) DOM leaks. Detached DOM issue.
3) Size of Javascript objects. Javascript objects coded in a certain way creates repeated instances of function.
(I am developing AngularJS app - with more than 450 screen - MDI like app. The app is not yet in production. The above points are coming from my burnouts in the functionality we have developed so far.)
I've worked on multiple projects that are extremely large single-page applications in Angular and Ember.JS at companies like McKesson an Netflix.
I can tell you for a fact that it's completely "feasible" to build "huge, complex" applications with frameworks such as Angular. In fact, I believe Angular is uniquely well suited to this because of it's modular structure.
One thing to consider when creating your Angular application is whether or not every user will benefit from all "200 pages" of your application. That is to say, is it necessary to have all 200 views be part of the same single page application? Or should you break it into a few single page applications with views that share concerns.
A few tips:
Watch out for name collisions in the IOC container: If you create enough services and controllers, even if you break them into separate modules, it's very easy to create two services with the same name. This may or may not result in an outright error. What happens when you register two "fooService" services? The last one wins.
If you decide to break your app into more than one single page app, you have to be sure you have solid boundaries of functionality between the two. They're not going to be able to share state easily other than with something like cookies or local storage.
If you decide to keep everything in one single page app, you're going to want to keenly watch your initial download time. Always check to see how long it takes to start your app "cold" over a slow-ish connection. If the entire app is in one bundle, depending on how you structure things (are you going to use AMD?) then you might see a long initial load time.
AVOID rendering HTML on your server. I can't stress this enough. Let Angular do that work for you. The only rendering your server should be doing is rendering JSON to be returned from some RESTful service.
Flush out your JS build process early on. Look into Node-based tools like Grunt, Gulp, and Broccoli for linting/concatenating/minifying your JS files. Checkout Karma for running unit tests, and look into Istanbul for code coverage. Protractor is a great tool as well, but I recommend strong unit tests in Karma over integration tests with Protractor just because Web Driver based tests tend to be brittle.
Other than that, I think you'll find a single page app written in any modern framework to be extremely snappy after the initial load is done. In fact, it will make any "old" PHP/ASP.Net style app that renders the entire page at the server seem slow as dirt in comparison. This is because you'll only be loading data and the occasional .html file over HTTP.
Do you prefer...
1- Write the whole application, then set up routing/url rewriting
2- Set up routing as you go
3- Write most of the application, set up routing then maintain the routing
4- Set up the routing then write the application
5- Write the main routes first, then maintain them as development goes
I see advantages / drawbacks in all of these approach. I tend to write a big part of the application and then set up routing once I'm sure that the structure will not evolve and I really know what will happen next, feature wise.
Since I try to be as agile as possible it's hard to have all the features when I start, so (4) is not really possible.
What do you usually do? What's the general best practice?
I personally would start with it early on, as adding it in later is a bit problematic, as you don't want to have to change any of your links on actual pages from myPage.aspx?mykey=myvalue to /mykey/myvalue/myPage.aspx, as it isn't an automatic or easy process.
Additionally re-writing/routing is something that if done later, would require a full regression run of a site, just to validate that you did catch all of those examples. Therefore doing it as you go, will keep it much more simple.
In the apps I've developed in ASP.NET MVC, I've set up routing after I've implemented the section of code that it deals with.
The reason for this is once I see how the query strings deal with the GET, I can see what and how I'd like to rewrite (or route) the URL.
Without routing, how do you link from page to page? I find that I need routing to get anything going at all. I tend to think a little up front about what my resources are that will be the basis of urls -- but after that little bit, I do routing right before I implement the feature (route -> view -> template -> enough model to support the view).
I work in Django, BTW.