EXTJS 6, Requires or Uses - Determine programatically
At work we are using EXT JS 6, I've been tasked with 'speeding it up'. I've already done several things and have achieved at least a 30% speed increase. However when loading a page/module/section (whatever you want to call it), Every single component underneath the first is loaded async.
This is causing a measurable delay of about 20 seconds on a page load.
I believe this is because when we migrated from EXT JS 4, we kept everything in our class definitions as a requires.
requires: [
'app.view.setup.thing.TabController',
'app.view.setup.thing.Panel',
'app.store.setup.combo.thingGroupIcons'
],
I've look at a lot of documentation and have come to the conclusion that we should be using 'uses' to define sections of the program that can load separately to the 'on-screen-first' stuff.
So for instance, the above would become something like:
requires: [
'app.view.setup.thing.Panel',
],
uses: [
'app.view.setup.thing.TabController',
'app.store.setup.combo.thingGroupIcons'
],
The program probably has a good 500 pages/sections to it. Probably has 3000~ files. So my question is (really two fold).
Question 1: How can I pragmatically determine if something in my 'requires' could/should be loaded using 'uses'
and
Question 2: Am I on the right track at all?
There's a very hostile community around EXT JS, so I'm asking this question on Stack where I hope people will be more helpful. I have spent seven hours so far today reading, and the below are some of the links that I think are actually helpful.
https://www.sencha.com/forum/archive/index.php/t-133191.html?s=8b90c637dd96fed53597cd029544d955
http://docs.sencha.com/extjs/6.0.0/classic/Ext.Class.html#cfg-requires
To determine which ones you can load via uses, you can only move everything from the "required" sections into the "uses" section, and check what's broken.
But with uses, you can only improve the loading time of the uncompiled version, not of the cmd compiled version, where all dependencies are in a single javascript file, and which should be the only version facing the customer.
Of course, you can always do the same as my boss did, and get some Highly Paid Consultants™ (from Sencha or a Sencha-approved outlet near you) to review your application. Their first result was exactly what I already told him: that there is no possibility to significantly improve the loading speed of our Cmd-compiled version further. They told us that we had only one option left - I should add an animated splash screen, which would cut down the loading time in half. It doesn't if you use a stop watch, of course, but the user does not have a stop watch when he starts the application...
Related
The last 9 months, I've been working on two big websites with PHP and Javascript without using any framework.
Every time I wanted to modify a page or fix a bug, I was spending:
10% of the time on finding the PHP file with the html content
20% of the time on locating the CSS and JavaScript files it is using
20% of the time on locating the PHP classes it's using and the functions and variables it's inheriting
20% of the time on locating all the scripts that are being called through ajax calls.
And only 30% percent of the time to actually fix the problem.
So, I wanted something that for every file that I want to modify within a project, after indexing all the aforementioned, it shows a list with all of these relationships on a diagram/flowchart along with the corresponding links to these files.
After a lot of Googling I couldn't find anything that directly solves this problem effectively. Right now, except for just opening all the includes inside the PHP file one by one, I am using Google Chrome's Inspector to quickly locate the includes from the Network tab or even add my whole Workspace in the Sources tab in order to apply CSS and JavaScript modifications directly from there. The problem with this, is that I don't have any options for locating any server-side code(PHP). Also I don't want to be dependent on any specific Web-Browser. Lastly, this solution doesn't provide me any graphical representation of the website's schema, something that's really important for understanding in seconds the whole structure of a webpage that you are going to modify for the first time.
I know that this question sounds a little off-topic but I couldn't find anything on the Web (maybe I didn't use the correct search keywords?) and I feel like it's something that a lot of developers struggle with sometimes so it could be really helpful if it's answered and stay visible. Even if I am missing the point due to luck of experience and there is a different approach to this kind of problems, I don't think I am the first one and It could be also good to be clarified for all the others out there.
I can't help you with the diagram part of your question but I understand that your problem is indexing.
You could use sublime which more or less work with all the operating systems and at the same time it's quite light. With it you will have indexing as you can see here.
Ok so I am in the process of building my first Javascript 'framework' or 'bootstrap' which will be implemented in combination with a single pre-processed CSS file. I am gathering my favorite content slider, smooth scroller, content slideshow, parallax elements & bg-img, sticky elements, among a few more cutting edge navigational & UI based scripts (cross-browser/platform/device/viewport compatibility and performance). My problem is when constructing my demo page with all combined elements in place loaded and active on the page... well many seeem to require a different version of Jquery to be called in order to function properly. I have managed to get them to work properly while testing by carefully reordering the jquery librarys as they are called in the of the page. Now here is my (2) part question:
How do I get all my JQuery to work properly without loading multiple versions of it (one for each script almost)
I have a sample in my portfolio which I would love to use as the example. http://www.nicholasabrams.com/ (non mobile device version). In the src for that URL you will see only (1) js and (1) css - including the jquery libraries which are ALSO included in the single .js in the begining of the file. Please don't flame me, as I am asking for help. The link above works fine now (with apple as a slight exception)... but I am just trying to eliminate any bad practices I have as I have just started as a web developer at my first large company. Thanks!!
PS: Would post a snippet but its quite a large js file as you would imagine but if you will, please inspect my src and let me know what you think because my sites first load decreased from 22 seconds to 4-7 seconds after doing the above I wish I could just include the latest version of JQuery!)
if I understand you correctly you are loading more than one jQuery library to the page (in different order)? That's a mistake - you shouldn't do that.
What you should do is make sure that the plugins you work with are compatible with the library you are working with. If they're not - wither find other plugins or fix the ones you have to support the jQuery language you are using.
You have a 2 megabyte hi-res background image, that is insane! I would scrap that and the swirl image, while it may look cool to you, it is distracting and may actually make people want to avoid your website. It makes it difficult to concentrate on the text in the middle of your screen. You don't want people to remember the swirling image, but rather your portfolio, right?
You also have 404's on the following:
http://www.nicholasabrams.com/ScrollSpy_files/result-light.css
http://www.nicholasabrams.com/example-images/testing_station.png
404's are bad for several reasons, they are a wasted resource as they slow the loading of your page, because it attempts to find something and does not find it, and, finally, they have a negative impact on your SEO, specifically Google PageRank docks you for any 404's.
Find a way to work with one version of jQuery, it will eventually bite you to have multiple versions of the library and it is a bandwidth killer to have your users load up a bunch of libraries, even if they are CDN'd.
We are have a site with a feed similar to pinterest and are planning to refactor the jquery soup into something more structured. The two most likely candidates are AngularJS and Backbone+Marionette. The site is user-generated and is mostly consumption-oriented (typical 90/9/1 rule) with the ability for users to like, bookmark, and comment on posts. From the feed we open a lightbox to see more detail about the post with comments, related posts, similar to pinterest.
We have used backbone sporadically and are familiar with the idea but put off by the boilerplate. I assume Marionette would help a lot with that but we're open to changing the direction more radically (eg Angular) if it will help in the long term.
The requirements:
Initial page must static for SEO reasons. It's important that the framework be able to start with existing content, preferable with little fight.
we would prefer to have the data needed for the lightbox loaded already in feed so that the transition can be faster. Some of the data is already there (title, description, photos, num likes/ num bookmarks,num comments) but there is additional data that would be loaded for the detail view - comments, similar posts, who likes this, etc.
Changes to the post that happen in the feed or detail lightbox should be reflected in the other with little work (eg, if I like it from the feed, I should see that like and new like count number if I go to the lightbox - or the opposite.)
We would like to migrate our mobile site (currently in Sencha Touch) to also use the same code base for the parts that are common so we can have closer feature parity between mobile and main site.
These requirements related to my concerns about Angular:
1) Will it be possible/problematic to have initial page loads be static while rending via the templates additional pages.
2) is it problematic to have multiple data-sources for different parts of page - eg the main post part comes from embedded json data and from "see more"s in the feed while the additional detail would come from a different ajax call.
3) While the two-way binding is cool - I'm concerned it might be a negative in our case because of the number of items being rendered. The number of elements that we need two-way binding is relatively small. Posts like:
https://stackoverflow.com/a/7654856/214545
Angular JS ng-repeat consumes more browser memory
concern me for our use-case. We can easily have hundreds of posts each with 1-2 dozen details. Can the two-way binding be "disabled" where I have fields/elements that I know won't change?
Is it normal/possible to unload elements outside of the view port to same memory? This is also connected to the mobile direction because memory is even more of a concern there.
Would AngularJS work/perform well in our use-case? Are there any tricks/tips that would help here?
There are different methods of "infinite scroll" or feed as you put it. The needs of the users and size of acceptable response payload will determine which one you choose.
You sacrifice usability where you meet performance it seems here.
1. Append assets
This method is your traditional append to bottom approach where if the user reaches the bottom of the current scroll height, another API call will be made to "stack on more" content. This has it's benefits as being the most effective solution to handle cross device caveats.
Disadvantages of this solution, as you have mentioned, come from large payloads flooding memory as user carelessly scrolls through content. There is no throttle.
<div infinite-scroll='getMore()' infinite-scroll-distance='0'>
<ul>
<li ng-repeate="item in items">
{{item}}
</li>
</ul>
</div>
var page = 1;
$scope.getMore() = function(){
$scope.items.push(API.returnData(i));
page++;
}
2. Append assets with a throttle
Here, we are suggesting that the user can continue to display more results in a feed that will infinitely append, but they must be throttle or "manually" invoke the call for more data. This becomes cumbersome relative to the size of the content being returned that the user will scroll through.
If there is a lot of content being retruned per payload, the user will have to click the "get more" button less. This is of course at a tradeoff of returning a larger payload.
<div>
<ul>
<li ng-repeate="item in items">
{{item}}
</li>
</ul>
</div>
<div ng-click='getMore()'>
Get More!
</div>
var page = 1;
$scope.getMore() = function(){
$scope.items.push(API.returnData(i));
page++;
}
3. Virtual Scroll
This is the last and most interesting way to infinite scroll. The idea is that you are only storing the rendered version of a range of results in browser memory. That is, complicated DOM manipulation is only acting on the current range specified in your configuration. This however has it's own pitfalls.
The biggest is cross device compatibility .
If your handheld device has a virtual scrolling window that reaches the width of the device --- it better be less then the total height of the page because you will never be able to scroll past this "feed" with its own scroll bar. You will be "stuck" mid page because your scroll will always be acting on the virtual scroll feed rather than the actual page containing the feed.
Next is reliability. If a user drags the scroll bar manually from a low index to one that is extremely high, you are forcing the broswer to run these directives very very quickly, which in testing, has caused my browser to crash. This could be fixed by hiding the scroll bar, but of course a user could invoke the same senario by scrolling very very quickly.
Here is the demo
The source
"Initial page must static for SEO reasons. It's important that the framework be able to start with existing content, preferable with little fight."
So what you are saying is that you want the page to be prerendered server side before it serves content? This approach worked well in the early thousands but most everyone is moving away from this and going towards the single page app style. There are good reasons:
The inital seed you send to the user acts as a bootstrap to fetch API data so your servers do WAY less work.
Lazy loading assets and asynchronous web service calls makes the percieved load time much faster than the traditional "render everything on the server first then spit it back out to the user approach."
Your SEO can be preserved by using a page pre-render / caching engine to sit in front of your web server to only respond to web crawlers with your "fully rendered version". This concept is explained well here.
we would prefer to have the data needed for the lightbox loaded already in feed so that the transition can be faster. Some of the data is already there (title, description, photos, num likes/ num bookmarks,num comments) but there is additional data that would be loaded for the detail view - comments, similar posts, who likes this, etc.
If your inital payload for feed does not contain children data points for each "feed id" and need to use an additional API request to load them in your lightbox --- you are doing it right. That's totally a legit usecase. You would be arguing 50-100ms for a single API call which is unpercievable latency to your end user. If you abosultely need to send the additional payload with your feed, you arent winning much.
Changes to the post that happen in the feed or detail lightbox should be reflected in the other with little work (eg, if I like it from the feed, I should see that like and new like count number if I go to the lightbox - or the opposite.)
You are mixing technologies here --- The like button is an API call to facebook. Whether those changes propogate to other instantiations of the facebook like button on the same page is up to how facebook handles it, I'm sure a quick google would help you out.
Data specific to YOUR website however --- there are a couple different use cases:
Say I change the title in my lightbox and also want the change to propogate to the feed its currently being displayed in. If your "save edit action" POST's to the server, the success callback could trigger updating the new value with a websocket. This change would propogate to not just your screen, but everyone elses screen.
You could also be talking about two-way data binding (AngularJS is great at this). With two way data-binding, your "model" or the data you get back from your webservice can be binded to muiltiple places in your view. This way, as you edit one part of the page that is sharing the same model, the other will update in real time along side it. This happens before any HTTP request so is a completely different use case.
We would like to migrate our mobile site (currently in Sencha Touch) to also use the same code base for the parts that are common so we can have closer feature parity between mobile and main site.
You should really take a look a modern responsive CSS frameworks like Bootstrap and Foundation. The point of using responsive web design is that you only have to build the site once to accomadate all the different screen sizes.
If you are talking about feature modularity, AngularJS takes the cake. The idea is that you can export your website components into modules that can be used for another project. This can include views as well. And if you built the views with a responsive framework, guess what --- you can use it anywhere now.
1) Will it be possible/problematic to have initial page loads be static while rending via the templates additional pages.
As discussed above, its really best to move away from these kind of approaches. If you absolutely need it, templating engines dont care about wether your payload was rendered serverside or client side. Links to partial pages will be just as accesible.
2) is it problematic to have multiple data-sources for different parts of page - eg the main post part comes from embedded json data and from "see more"s in the feed while the additional detail would come from a different ajax call.
Again, this is exactly what the industry is moving into. You will be saving in "percieved" and "actual" load time using an inital static bootstrap that fetches all of your external API data --- This will also make your development cycle much faster because you are separating concerns of completely independant peices. Your API shouldnt care about your view and your view shouldnt care about your API. The idea is that both your API and your front end code can become modular / reusable when you break them into smaller peices.
3) While the two-way binding is cool - I'm concerned it might be a negative in our case because of the number of items being rendered. The number of elements that we need two-way binding is relatively small.
I'm also going to combine this question with the comment you left below:
Thanks for the answer! Can you clarify - it seems that 1) and 2) just deal with how you would implement infinite scrolling, not the performance issues that might come from such an implementation. It seems that 3 addresses the problem in a way similar to recent versions of Sencha Touch, which could be a good solution
The performance issues you will run into are totally subjective. I tried to outline the performance considerations like throttling into the discussion because throttling can drastically reduce the amount of stress your server is taking and the work your users browser has to do with each new result set appended into the DOM.
Infinite scroll, after a while, will eat up your users browser memory. That much I can tell you is inevitible but only through testing will you be able to tell how much. In my experience I could tell you that a users browser can handle a great deal of abuse but again, how big your payload is for each result set and what directives you are running on all of your results are totally subjective. There are solutions that render only on a ranged data set in option three I described, but have their limitations as well.
API data coming back shouldn't be anymore than 1-2kbs in size, and should only take about 50-200ms to return a query. If you arent meeting those speeds, mabye it's time to re-evaluate your queries or cut down on the size of the result set coming back by using child ID's to query other endpoints for specifics.
The main thing that remains unanswered in Dan's answer is the initial page load. We're still not satisfied with the approach that we have to do it client side - it still seems to us that there is a risk for SEO and initial page load. We have a fair amount of SEO traffic and looking for more - these people are coming to our site with no cache and we have a few seconds to catch them.
There are a few options to handle angular on the server side - I'll try to collect some of them here:
https://github.com/ithkuil/angular-on-server
https://github.com/ithkuil/angular-on-server/wiki/Running-AngularJS-on-the-server-with-Node.js-and-jsdom
https://github.com/angular/angular.js/issues/2104
will add more as they come up.
What's the smallest lightbox plugin for jQuery (in terms of size)? Something close to Fancybox, but smaller :)
I wrote a low-level jQuery lightbox script called Nitelite: https://github.com/premasagar/nitelite (it's 1.4KB when minified and gzipped)
It is the kind of thing that can be either used on its own, or to build more feature-rich lightbox plugins.
It's been used in production on a couple of projects:
the BBC World Service widget (click a news article): http://www.bbc.co.uk/persian/services/2009/05/090512_pm_widget_conditions.shtml
the MiShorts widget (click a film thumbnail): http://www.mishorts.com/widget
It's open source, MIT license. Enjoy ;)
I have used this sometime ...
http://www.digitalia.be/software/slimbox2
It's only 4K .
As Yi Jiang already stated, the "smallest" depends completely on your specific needs, if you want everything that Fancybox does, I hardly doubt that there's a way around using that very plugin.
Still you could take a look at others and see whether they fit your needs, you should check out this list of lightbox scripts, many of which are smaller in size than Fancybox, but you'll still have to evaluate them and see if they fit your needs.
And last but not least you can always write your own one by reading a tutorial. That is, if you want to write your own one. But then again, if you have such specific needs you should know that nobody will come along and write some code for you for free.
My approach to these sort of problems is to find a script that meets my requirements then hack it mercilessly until it only contains what I need. Once that's achieved, I'll minify the script (leaving the compression of the script up to my server).
While we're on the subject, if you are looking for small scripts mainly to reduce the browser fetch time, then also ensure that your web server cache control headers and compression settings are set to good values. A nice writeup (regarding caching) can be found here. If you don't have a good caching policy defined, then it won't matter much whether the script is small if it is being downloaded from the server on every page view.
I would shy away from the PrettyPhoto plugin, which appears convenient. There is an advertisement on their demo which is suspicious (my site was redirected shortly after experimenting with it)
If you are looking for a lightbox, try to find one that has been updated to the latest query. Slimbox2 and fancy box have not been updated for modern css, using images to build the box, and neither have been updated for streamlining changes in the latest jquery.
I'm building a site that makes extensive use of FLIR to allow the use of non-websafe fonts. However, pageloads are an ugly process, as first the HTML text version of each field loads and then (a few hundred milliseconds later) it's replaced by its FLIR image counterpart.
Is there any way to avoid this sort of thing? I've got a client presentation in a few hours and I know it'll raise eyebrows. My situation is sort of related to this question which is in regards to sIFR, not FLIR. Any ideas?
Thanks,
Justin
Try putting the following rules into your stylesheet:
.flir-replaced{text-indent:-5000px;}
.flir-image{display:block;}
You may have to modify your other FLIR-related CSS rules to account for the fact that the generated images are now vertically aligned to the top of their respective parents.
It's been a while since I used FLIR, but I recall there was an internal caching method that would pull from cache on load instead of generate it each time.
http://docs.facelift.mawhorter.net/configuration:settings
Also, you can't have too many on the page at once. I found that between 6-10 were optimal for performance.
Are you on shared hosting? Is your css/js compressed? I found that the initial load was a little slow, but fairly quick after the images had been generated.