When building a jQuery plugin, do you think it's bad practice to embed the source of another plugin or library that it depends on?
It seems to me that it's a better way to go than requiring users to do multiple <script src="..."> calls or compressing the multiple source files themselves.
I would stay away from embedded in most cases, especially if you're depending on another jQuery plugin. Some cases to consider:
What if I'm already using that plugin, a newer version, an older one?
At best you're adding the download weight twice, possibly a different version
At worst you're breaking my code :)
What if I'm trying to debug, is a bug in your plugin?, the other?, still yours because you included it?
Which author do I contact?
There are few upsides to this besides saving a few <script> tags, which should be cached on the client anyway...and in my case as well as many others (like SO) the scripts get compressed into one or a few requests.
Most jQuery plugins require dependencies to be added with their own <script> tags, in this case by not going with what most do serves more to confuse or complicate rather than save time. Personally, I'd stay away from the embedding, but to each their own.
Personally, as a potential plugin user, I'd prefer the multiple <script src='...'> way. First, it gives me more flexibility and control and second, if I already have some of the plugins in my own code, having them in your plugin as well means they'll be included twice.
Imagine what would happen if every plugin author included all dependencies in the source. What you think is convenient now will turn out to be a maintenance nightmare later.
Related
I am using a template on squarespace to build my website and use a lot of custom CSS.
All pages I analyze using GT Metrix get a rating of "C" for speed because of that one issue with defer parsing of script. If I'm using a template do I have any control over this? I would assume squarespace provides templates that are optimized so it must be something I've added.
If it helps this is the js that, if deferred, could save 900Kib:
https://assets.squarespace.com/universal/scripts-compressed/common-4dd8f80a39abb8e9e5ab9-min.en-US.js
The "common js" file as it is often referred to by Squarespace developers is not something you can easily control.
It requires you to be using a "Squarespace 7" template (not Squarespace 7.1). Then you must A) enable developer mode (and accept the ramifications of that) and B) remove {squarespace-headers} in the JSON-T and break it down into its various components (because that one line includes dozens of various Squarespace-specific scripts, etc.) and then C) manage the loading of those scripts from then on, updating as necessary if Squarespace updates the platform, script locations, etc. (and they don't announce such changes).
If you're willing and able to do that, you can add defer and have full control over the loading of your site. But it is a large undertaking initially and will need to be maintained going forward.
Regarding "I would assume squarespace provides templates that are optimized so it must be something I've added.": That's a reasonable assumption, but incorrect. Among experienced Squarespace developers, Squarespace is known to not be well optimized according to, for example, Google's PageSpeed Insights. I've not used GT Metrix, but it sounds like your experience is similar. This has been an issue with Squarespace for over 5 years. It's unclear if "7.1" will make drastic improvements on this front in the short term.
GT Metrix has a good guide of how to defer your parsing here.
Basically you just want to rewrite your javascript file to have less javascript in it, either by A) removing unnecessary code, or B) deferring some if that can be loaded later, after page load. Ask yourself, how much of my javascript do I need just to load the page?
I don't use squarespace but this looks like an example of how to upload js files there.
So I have web app with multiple JS files (jQuery, jQuery, my own JS code and more). Say I have a page named index.html. What would be the best practice to include / preload my js files? I was thinking about creating a separate JS file that will do the preloading (include all the other scripts and call jQuery.noConflict()). What do you guys suggest? Is this possible? How would you implement it?
Thanks!
In general, combine your script files into one file (and minify or compress them, or even compile them, but note that this last item is not zero-impact, there are pain points). See notes here and here. Basically, one of the first guidelines you'll see for a good fast page load is "minimize HTTP requests." So you don't want six separate script tags where you could have one.
For popular scripts, though, you may benefit from using them from Google's CDN. Google is kind enough to host most popular JavaScript libraries on their CDN for free. The advantage here being not only that the CDN will be fairly fast, but that the target user's browser may well have a cached version of the script you want to use even though they've never been to your site before.
Check out RequireJS, a smart and robust script loader for JavaScript. It's designed to work well with jQuery and comes with an optimization tool to combine all of your scripts into one.
The best way is to minimize all the js files and combine them into one script. This will cause less work for the browser, as it doesn't have to make multiple requests to the server.
If you are going to load everything up at the same time, you could put it all into a single compressed file
I have been optimizing my website but the one problem that stands in my way is all the jQuery functions that I do not use. The only ones that I use are for a smooth page scroller. It just seems like such a waste of download time.
My question is: Is there any script or program that will remove the jQuery code that I do not need and leave the 1 or 2 functions that I do need.
There's no way to do this, especially since it's not that simple. For example .fadeIn() is one method, but it calls the whole animation section of jQuery to fade the element, but that's after your selector has accessed the traversal section including the Sizzle selector engine...that's how most frameworks are, it'd be very tricky to remove pieces because of so many dependencies inside the framework itself.
That being said, if you're delivering jQuery correctly, it's minified and gzipped, and you're only sending about 24kb to the client which they cache so it's just sent once, not every page load. Also, they may have already cached it from another site, the more people who point their site to the same CDN (the page you're viewing does) the more likely this is to happen.
Google has a CDN, details here, for example from there you can grab jQuery, or jQuery UI:
http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js
http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.0/jquery-ui.min.js
Previous versions of these as well
Also, Microsoft has a CDN, details here, you can fran jQuery and the validation library from it:
http://ajax.microsoft.com/ajax/jQuery/jquery-1.4.2.min.js
http://ajax.microsoft.com/ajax/jQuery.Validate/1.6/jQuery.Validate.js
Full list of validation files here
Note: these are the current versions as of the time of this answer, don't use these explicit links if you're finding this later, there may be more recent versions available.
Just reference the library from Google, chances are it will already be cached on the client...
<script type="text/javascript"
src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js">
</script>
This will also save you bandwidth. StackOverflow and many other sites do this.
some time ago, I was reading an article(a library built by some guy) about how his library can do
lazy loading of JS
resolve dependencies between JS
(typically encountered when trying
to "include" one js from another)
include files only once. thought
specified multiple times regardless
of how they are called (either
directly specifying it as file or
specifying it as one of the
dependencies)
I forgot to bookmark it, what a mistake. Can some one point me to something which can do the above. I know DOJO and YUI library have something like this, but I am looking for something which I can use with jQuery
I am probably looking for one more feature as well.
My site has asp.net user controls
(reusable server side code snippets)
which have some JS. Some of them get
fired right away, when the page is
loading which gives a bad user
experience. Yahoo performance
guidelines specify that JS should
be at the bottom of the page, but
this is not possible in my case as
this would require me to separate the
JS and the corresponding server side
control into different files and
maintenance would be difficult. I
definitely can put a jQuery
document.ready() in my user control
JS to make sure that it fires only
after the DOM has loaded, but I am
looking for a simpler solution.
Is there anyway that I could say "begin executing any JS only after DOM has loaded" in a global way than just writing "document.ready" within every user control ?
Microsoft Research proposed a new tool called DOLOTO. It can take care of rewriting & function splitting and enable the on-demand js loading possible.
From the site..
Doloto is a system that analyzes
application workloads and
automatically performs code splitting
of existing large Web 2.0
applications. After being processed by
Doloto, an application will initially
transfer only the portion of code
necessary for application
initialization. The rest of the
application's code is replaced by
short stubs -- their actual function
code is transferred lazily in the
background or, at the latest,
on-demand on first execution.
OK I guess I found the link
[>10 years ago; now they are all broken]
http://ajaxian.com/archives/usingjs-manage-javascript-dependencies
http://www.jondavis.net/techblog/post/2008/04/Javascript-Introducing-Using-%28js%29.aspx
I also found one more, for folks who are interested in lazy loading/dynamic js dependency resolution
http://jsload.net/
About the lazy-loading scripts thingy, most libraries just adds a <script> element inside the HTML pointing to the JS file to be "included" (assynchronously), while others like DOJO, fetches it's dependencies using a XMLHttpRequest and then eval's its contents, making it work synchronously.
I've used the YUI-Loader that is pretty much simple to use and you don't need the whole library to get it working. There are other libraries that gives you just this specific funcionality, but I think YUI's is the safe choice.
About your last question, I don't think there's something like that. You would have to do it yourself, but it would be similar to using document.ready.
i did in my framework a similar thing:
i created a include_js(file); that include the js file only if it isn't included reading and executing it with a synchronous ajax call.
Simply put that code in top of the page that needs dependencies and you're done!
This one should be easy, and I think I know the right answer, but here goes.
For compatibility reasons, should I leave the filename of jQuery as "jquery-1.3.2.min.js" or just rename it to jquery.js?
My guess is leave it as is to avoid conflicts in case another app uses a different version of jQuery. If they've renamed it to "jquery.js" and I do the same, I see potential version conflicts.
Am I wrong or way off base?
Jeff
It's a very good idea to have version-numbered JS (and CSS) files, because that lets you configure your web server to use a far-future Expires header on such files without running into caching problems. When the file gets updated, it gets a new version number, so the browser always fetches the new version, not the old cached one.
You should do this on your other JS and CSS files, too. You want this to be automated, not something you manage by hand. Your development work happens on unversioned files, and your versioning system creates versioned copies and works out the details of updating the references to the CSS and JS files in the HTML files to point to the versioned copies. This can be a bit of work, but well worth it when it comes to speeding up your site. It took me about a day to set my system up. The improvement wasn't subtle.
I would go with jquery-1.3.2.min.js because it's more specific and you can immediately tell if you're reviewing this site in months to come, as well as avoiding any filename confliction in the future.
You shouldn't have any issues with updating, if you're relying on something like an include/template file for the javascript.
In my opinion, its just a personal preference. If you have version in your file name, It helps you easily identify which one you are using with out actually opening the file. It also provides an indirect way of clients downloading the new version file (as it is never cached). If you don't use the ext, upgrading to newer version is easy in coding perspective, but takes the pain of force downloading the new file by all users.
Recommended way to use jQuery in app is using the google's hosting..
google.load("jquery", "1.3.2");
google.setOnLoadCallback(function() {
// Place init code here instead of $(document).ready()
});
Why and how to use jQuery hosted on google
I prefer to leave the version in the file name because there are times when you are changing versions and this is very helpful. At a glance I can see which version I am using on any given webpage.