Grails 2 resources and yui3 script loader - javascript

I would like to use yui3 with a grails 2 web application but the new way that grails 2 handles resources is starting to annoy me.
yui3 seems to have the path right when is loads the js files, i.e. ../static/js/yui3/node-menunav/node-menunav-min.js but all I get is 404 errors when it tries to load dependencies.
How do I bypass the resources plugin for js or should I turn of the resources plugin altogether, as it seems a lot of work for not much gain.
And yes I know there is a plugin but it's just JavaScript and doesn't need a plugin and I'm trying to keep the plugin usage to a minimum.

Either comment the line above in your BuildConfig.groovy:
runtime ":resources:1.1.5"
Or include your js in your ApplicationResources.groovy.

Related

Find all loaded files in website to create ApplicationCache manifest

I'm trying to figure out a way to automatically generate an ApplicationCache manifest file from all the HTML,CSS,JavaScript and images files used by our website.
We need this because we need to support offline usage of the website. More precisely, offline usage of an ArcGIS API for JavaScript webapp.
We are not using service workers instead of the ApplicationCache because supporting iOS is a critical requirement and service workers are not supported at all on iOS, on any browser.
The idea is that I'll manually call a function after the site is fully loaded that will dynamically create the text to be used for the new manifest. Then manually copy/paste it in the manifest file. So it's something I would only do when something in the site changes and the manifest file needs to be updated.
This tool, ManifestR, is very close: http://westciv.com/tools/manifestR/
but has two issues with it:
1- It does not handle image file URLs found in CSS files properly. For instance if it finds url(../images/myimage.png) it will add the relative link ../images/myimage.png directly in the manifest file instead of adding the non-relative link like www.mysite.com/images/myimage.png.
2- It does not list any of the scripts loaded through dojo.require (AMD modules).
I'm thinking of using similar code to fix these issues and compile the list of files. I already see how to fix #1, but can't figure out how to fix #2.
So, using JavaScript, how can I find the list of all script URLs used by the website, not just those loaded trough tags (found in window.scripts object), but those loaded using AMD modules as well?
Basically I want to compile the same list that Chrome is showing me for the website in the Sources pane.
Ex:
I'm thinking that if this isn't available anywhere, maybe I could create a proxy function to dojo.require that keeps tracks of all files loaded through AMD.
But I wanted to ask here first, maybe I missed a tool of script that already does this? Or maybe my plan isn't good?
Thanks
I've never used ApplicationCache for an ArcGIS API for JavaScript app, but I would recommend that you first serve up a custom Dojo build of your application in order to bundle your code into one or more build layers. If you configure your Dojo build properly (no small feat) you should know the exact scripts that will be required.
Also, I'd suspect that once you figure out how to get the list of scripts, you may have special considerations in order to get the Dojo AMD loader to be able to use the cached files. See: dojo and the offline application cache
Good luck.

Does not Angular 2's reliance on so many javascript file hamper/affect its performance?

I have worked with Angular 1.x and now starting with Angular 2. Now I am overwhelmed to see the number of js scripts that we have to add to our index.html just to get started.
I mean even if I exclude angular's (and its components') own js files, there are "systemjs", "es6-shim", "reflect-metadata", "rxjs", "zone.js".
And I keep on hearing that Angular 2 is 2 to 3 times faster than Angular 1.
I have used AngularJS 1.x and also ReactJS and no where I have seen this much dependency on other scripts.
What I don't understand is this - Don't all these script files make the browsers slow? Don't they create extra load on the JS Engine of the browser?
And are we assuming that we are only targeting the latest of browsers when we are developing in angular 2 ?
Will anyone please explain?
EDIT:
I would like to understand the performance effect by lots of JavaScript files.
Can you refuse/reject the fact that Angular 2 needs a lot more JS files to start working than Angular 1?
Well having more file to load may increase the first time loading the page, and memory consumption at start (not necesseraly in then end) obviously.
But once you passed that, this is pretty much unrelated to performance.
Furthermore by using libraries that have been specially developped and optimized for their purpose, angular developers don't have to rewrite their own part of code which would probably less optimized/ morebuggy than existing and widely used ones.
Let's take a simple example : underscorejs or lodash. By including it to your browser you will probably add some time loading, but by using the functionnality that the provide, your code will be probably faster because there is a lot of trick about javascript & performance when it comes to what those libraries are used for.
And it's not because you load those libraries that you will get their full code executed on each javascript loops, same goes for angularJS2 and all his libraries.
The most annoying thing about this could be the need, not only to learn angularJS2, but some of the others components to get things rights about how to code properly with angularJS2, increasing the learning curve so.
Among the file you showed : es6-shim is to make angularJS2 compatible for no-es6 browser, you had the same when using angularJS 1.x on IE8, nothing new for this one.
The Angular team is working on a build tool (partially included already in RC) that resolves all kind of stuff before the application is delivered to the browser
script inlining
CSS inlining
CSS rewrite for ViewEncapsulation.Emulated (default)
HTML inlining
lazy loading of components depending on routes configuration
replace declarative bindings by generated code
...
During development an Angular applications has to make dozens to hundreds of HTTP requests to get all resources. After the build step these are minimized to the absolutely necessary.

Are there any reasons NOT to use angular-loader?

I've worked with Angular for a little bit, but I keep managing to learn something new - today, I installed the angular-seed project in order to give my development a little kick in the pants. I ran into the index-async file and learned about the angular-loader - which I hadn't used before.
I found this question, as well: What is angular-loader.js for?
It looks as though the index-async file is using a script loader in addition to the angular module loader, which makes sense. However, I've never used this method before. (In my company, we've used RequireJS to load angular modules before, and so I can understand why something like this would be easier and less cumbersome.) Yet, it also seems that I could use the loader without a third-party script loader - I could just include all of my app files, in any order, before the loader is called, without having to worry about the dependencies.
In short - when should I use angular-loader? More importantly, is there any reason NOT to use it all the time?
Well, you don't have to use it if you don't need it.
From the Angular Docs, you use it:
If you are loading multiple script files containing Angular modules, you can load them asynchronously and in any order as long as you load this file first. Often the contents of this file are copy&pasted into the index.html to avoid even the initial request to angular-loader.min.js. See angular-seed for an example of usage.
The reason behind is to optimize the loading time on the client-side - only load the currently needed module for the user, particularly if you have a reasonably huge app.

Loading jQuery / CSS inline when needed or always via external?

I like keeping myself busy building modular web-applications, but don't want to spend time where I can save some..
For example I'm building a news module that should be easily implemented over multiple sites, because the same web-application is used.
However not all websites will need a news module. Is it better/easier/faster to create an inline stylesheet/javascript file built into the module itself, than to create a big external stylesheet/javascript with all the libraries? Even though the file for the news module is not needed on all other webpages?
It seems to be much easier to create an inline library in the module itself. So that this only gets loaded when needed, and saves load time and bandwidth on the other pages.
The other thing is that I like writing 'plug-and-play' modules. Say I move a file across the file server into the module folder, and the application will take care of the rest. With inline sheets, I dont have to add new lines to the header/footer etc.
What is the best solution for this? When also taking into account that I rather spend 10 minutes moving a file and it works, than to spend 1 hour appending external libraries just because its more of a 'good practice'?
If you re building web applications, are you using the MVC patern? Do you separate your concerns? (your Templates/Views, your Models, and your logic(Controllers))
If you follow MVC, it makes easier maintaining and customizing your app.
To answer to your exact question, what you need is RequireJS. This way you have only one place to declare your requirements, and RequireJS will handle the rest.. Load order and more..
Quoting from the requirejs website:
Over time, if you start to create more modular code that needs to be
reused in a few places, the module format for RequireJS makes it easy
to write encapsulated code that can be loaded on the fly.
Inline is never a solid way to maintain CSS. Take care to separate the description of your layout from your views. You can easily include the file in the same directory as the module so it should not be an issue.
Or if you want just to load "on fly" some script you can use jQuery.getScript , http://api.jquery.com/jQuery.getScript/ . Otherwise you should follow George's way.

Organizing Javascript w/ jQuery

I am tinkering around with jQuery and am finding it very useful and almost exciting.
As of now, I am referencing the jQuery script via Google's CDN and I store plugins I use locally in a static/scripts directory.
Naturally, each page has its own individual implementation of components that are required for the features it currently offers. I.E. the main page has the Twitter plugin whereas the login page has form validation logic and password strength metering. However, certain components (navigation bar) for example use the same script across multiple pages.
Admittedly so, I am not a fan of putting javascript code in the header of a page, but I rather prefer to have it in an external file (for caching, re-usability, and optimization purposes).
My question is, what is the preferred route for organizing the external files. I wanted to try and keep it to one javascript file for the entire site to reduce IO requests. However, I am not sure how to implement document ready functions on a conditional per page bases.
$(document).ready(function () { ... }
Is there some way to reference a page by some method (preferably id based and not a url conditional).
Thank you in advance for your time!
You should try REQUIRE JS.
This will allow you to load only those plugins the pages where you need them, and unload them again if they are not needed anymore.
Then again, it might be overkill. It really depends on the size of your project.
Paul Irish:
http://paulirish.com/2009/markup-based-unobtrusive-comprehensive-dom-ready-execution/
This will allow you to block your scripts by body class/ID and execute them automatically.
First you might want to use YUI Compressor or some other JS compressing tool. Then perhaps creating a resource file (resx) for your JavaScript is the way to go. Then just reference the resource within your code. This is the approach Telerik took for their RadControl ASP.NET AJAX control framework.

Categories

Resources