Well I had lots of scripts so what I did is that I combined all of them into one script file, which contains files like Jquery library too.
But now the problem is that it has stopped working, I don't know why did this happen.
What I did is that I took every script copied and pasted it and then I gave some space under it by pressing enter a few times and then I used to paste other script, I was told this was the method to combine scripts but now the scripts don't work.
Here is the link to combined scripts http://files.cryoffalcon.com/bloghuts/uncompressed/BlogHuts%20UNCOMPRESSED.js
And the link to a live example is http://bloghutsbeta.blogspot.com/
ANSWER/SOLUTION:
Earlier I was using an older version of Jquery I think 1.5 now I changed it to latest 1.7 and that was the reason that everything stopped working. It had nothing to do with combination. I am using all scripts combined and everything is working fine But why is older version better than New that is a new question for me
First, I'd suggest you move the jquery library links out to the main page. Have one file for all of your javascript, and include the other stuff on separate lines.
Whether or not you do that, though, your problem is almost certainly some sort of unclosed bracket or semicolon missing or something similar. Javascript often reacts to stuf like that by throwing its hands up in the air and giving up. The way to fix it is to go through your file and pick a function that is not currently working, but that is easy to test for functionality. Then comment out everything else, and test to see if the function works. If not, fix the function until it does work. Then, one piece at a time, uncomment each of the other blocks, again testing to see if the initial function works. If uncommenting a block causes the thing to stop working, then that's the block that you need to fix. Depending on how long your blocks are, you may need to do this in tiers
First, don't do that with jQuery, ever. You're almost always better off pointing your script src to a public CDN somewhere.
Second, what you're trying to do is very brittle, and probably not worth troubleshooting. If you have that many JS files, you really need to use a module library (I like require.js) to give your project some structure and make it more manageable. Most libraries like this will include some sort of utility to combine and minifi your scripts safely.
This will take some work on your part to get things setup, but it should prove well worth it in the long run!
Related
Does anyone tried to play with async: true for js includes in Rails? I mean it works great but just if you are not using jQuery. If you do, then you could face some strange effects like "$" is not defined and etc. There is plenty of articles how to avoid that, but all of them seems to be done with no Rails in mind. For example, this one: http://www.yterium.net/jQl-an-asynchronous-jQuery-Loader
Seems like I have to move jQuery from applicaction.js - means out from being putted into one big file with other JS I have.
Just wonder is there some "rails-way" of loading js asynchronously since Google is strongly recommended to do that (it is affected a page load speed a lot, and as a result - your Page Rank)?
This is a browser issue, not a Rails issue. In short, you can't do this on most browsers. This will cause a dependency error, which is what the error points to. One solution is to add the dependency in a file with all the dependent code.
However, this problem has been solved in ES6, using JavaScript imports. There is a guide on how to implement these imports in another answer here. See How do I include a JavaScript file in another JavaScript file? for that info.
Problem I'm trying to solve:
I have multiple bundled JS files: head.js, footer.js, some-other-page.js
If I had these all in a single file I could easily check for dead code and strip it
I'd like to be able to still strip the site-wide dead code from each smaller bundle.
Willing to re-work my build to do this. Any ideas?
A good way to check about dead-code is by having unit-tests to your project and then check the code coverage and see which part was never used. For more about code coverage you can see: https://www.jetbrains.com/webstorm/help/monitoring-code-coverage-for-javascript.html
This will maybe need re-work of your code as well if you are not using unit-tests but it is a very good way to analyse your code for code coverage and see that some parts are never used (hence remove them from your code)
Also for code that it is not yours (e.g. for jQuery) you can use a grunt build to remove the functions/methods that you are not using. A very interesting article of how to do that is this: http://developer.telerik.com/featured/trimming-jquery-grunt . For example if you are not using the ajax from jQuery you can simply do this: grunt custom:-ajax. Known libraries has this functionality so you can build it on the go.
Well,
Good Idea but for understanding purpose it's good to keep it seperate but if you want to combine then use switch
My problem is quite generic: I know that I have a JavaScript issue somewhere. Now I don't know how to start searching where the problem could be. Usually I use the Firefox built-in or the Firebug Debugger. I know how to use it in general. But what I don't know is where to start. Where should I set breakpoints? I often have this kind of problem.
As an example which is my current problem: I have a page with an unordered list. Every second list item is empty for some reason. I can see that the page gets loaded with proper list items. But then some JavaScript seems to add those empty items. It's a Yii application that inserts some JavaScript directly into the HTML but let the browser also load jquery.js, bootstrap.js and yii.js. I haven't added any own JavaScript.
Now, as I said, I don't know where to start to find the problem. It might be that I have done something wrong with some configuration. But it could also be bug. I just want to figure it out somehow.
With my current issue, the best would be to have a breakpoint on a function like onInsertEmptyListItemToCounfuseDeveloper() ...
I don't want a solution to my current issue. I'd like to know in general, where and how to start finding JavaScript related problems. Especially, with third-party JS. With some applications (CMS, shops,...) there are sometimes a lot of JS files. This makes it more worser.
I hope this question is answerable and you can provide some experiences.
Not speaking 'bout the CMS right now, but in general my method is
1) If you did not add any of your onw scripts, just 3rd party, delete them all of your project e.g.
You've added jquery.js, bootstrap.js, yii.js so you remove them and then you test if all works fine, if so, add first one, for me it would've been jquery.js, test again, if no bug visible add second and so on. In this case you'll see in which file is some bug or sort of unexpected behaviour.
2) Here is the worst part, in the found file you should find the problem part. So, download the full version, not production, open it in editor, and start searching... The good news are that you don't have to look through all file, just find the event listeners in your devtolls or firebug and follow them.
All of this is just my experience , so if someone know better methods, I would like to hear 'em too.
It would depend on the code. Generally, if I have a function that is suspicious, I put breakpoints or console.log() at the beginning and end of the function and see if both are executed. Then I follow the logic down to figure out which piece is broken. It really depends on the code though.
I did find a very interesting tool for identify unused css definitions in a web project.
http://www.sitepoint.com/dustmeselectors/
Are there similar tools also for javascript projects?
P.S.
I know there is no program for deterministically finding unused code. But I am looking for a report to identify possible unused code. Then the last decision will always be your own.
Problem is there is no way to be really sure. Suppose the following:
The initial HTML site is practically empty. There is a lot of JS code though, which seems to be unused.
OnLoad, a function is called which launches an AJAX query to the server. The server returns a lot of HTML code, which is the body of the site. This body contains lots of JavaScript functions.
The initial body is replaced with the body received via AJAX. Suddenly, all code is used.
Static analysis utilities are therefore useless. I do not know whether there exists a browser extension that marks all JS usage from a running browser though.
You can try using tombstones to safely locate and remove dead code from your JavaScript.
https://blog.bugsnag.com/javascript-refactoring-with-bugsnag-and-tombstones/
In order to find the unused assets, to remove manually, you can use deadfile library:
https://m-izadmehr.github.io/deadfile/
It can simply find unused files, in any JS project.
Without any config, it supports ES6, JSX, and Vue files:
The one that comes to mind most quickly is Javascript LINT (http://www.javascriptlint.com/) and JSLint (http://www.jslint.com/).
Beware though: the latter hurts your feelings.
I have noticed that the place of scripts is not irrelevant, if script refers to some div below, it may not work, not sure about rules perhaps my messy code assign some other value later. So I am asking general guide-lines to design the structure in Javascript code. What is the order for example to the parts such as CSS, Divs and Scripts?
My personal bias is that good code should be easy to read from the bottom to the top. So, for example, a browser could have browse() script at the bottom to start browsing and the rest junkies that it uses to to top in logical order, so after browse() its above script should be something that the browse() uses. Field values should be defined at the top, I think things like CSS and divs -- rude analogy I know. But if user's browser is slow, the script may not execute at all and the code seems to be non-working. Dilemma between practicability and readability.
Please, define terms, such as top-to-bottom coding and bottom-to-top coding, and show the structure.
In head, put CSS, then scripts in order of usage and in body Divs.
Example if you use jQuery and have a .js file that uses jQuery code, it's adviced to import the jQuery files before your .js
Personally I try to avoid putting scripts in the body and rarely face such issues as scripts not finding divs below.
Usually I try and place scripts that manipulate DOM on the bottom of the page, it solves the problem of not finding the DOM elements before a page is fully loaded.
However, libraries (such as jQuery) should go in <head>.
You can consider the entirety of the page, JavaScript, CSS, and HTML, as a combination "top to bottom" generic program, where later code can reference earlier code. Because when the page loads, it simply starts "executing" or interpreting "code" as it sees it. Most of the time, that "code" is simply definitions (like JS vars or functions), and placement of elements (like DIVs).
However, if you have JS that actually runs during load, that is code, that is outside of a function definition, then it's going to only "see" things that exist before the code is executed. So, in that sense, the whole thing is simply one long program, with the HTML as a meta-language building a DOM as the HTML is interpreted by the browser.
Obviously there are techniques to run code at certain points, like page load, etc., and that's where the libraries like JQuery come in to to expose those event points and make them easy to use.
But fundamentally, it's a top down script, like pretty much anything else.
I try not to have excessive script block ins my code at all. I call all external scripts in the head or just before body close in the case of some api inclusion (addthis for example). All inline scripting goes in a single block at the just before the close of the body tag as well.
RequireJS - Outsourcing Script Loading
I have found RequireJS particularly useful for JavaScript application development. In my case I'm dealing with tens of JavaScript files (modules) but I'm sure it will come in handy in other cases as well.
The library handles a lot of boring stuff for you. All you need to do is to set up some files (main.js, build options), state module dependencies and you are good to go. It includes a build system so you can easily get a debug or production build (minified) done.
On Application Structure
I like to code "top-down". The idea is that higher levels of an application should be really loosely defined. You shouldn't see actual algorithms used for solving some specific problems there. The highest level should be just about wiring parts of an app together. The lower levels solve more specific problems till you get to concrete implementations.
This is a fairly standard, layered approach to application development. You probably won't need something like this for casual scripting. It's still a good idea to apply in practice as it helps you to compose your scripts better. You can use the idea on closure level even to make the code easier to read.
On Functions
It might help to read "function" as "to" (Logo concept :) ). I think a well-written function reads like a recipe (to "drawLine" you must do this and that using these parameters...).
I know this might not be exactly pertinent to the question but I thought it might be a fun idea to mention. Perhaps it will help you to see functions differently and help you to structure your JavaScript code that way.
On Elements Not Ready
Considering elements not ready and script loading... you might be better off defining your code at a "document ready" handler. This is fairly standard thing to do.
If you use RequireJS or a similar library you probably don't have to worry about this. They handle this particular issue for you.
The style sheets go first and scripts go later. The reason for this is scripts are "blocking", meaning that while the browser is downloading JavaScript, it will not download anything else - not style sheets, nor images.
Browsers will only download so many resources at one time, and will block all other loads until this number of resources free up. IE8 actually will download quite a few at a time, as many as 18 or more. Firefox and Safari will download 6 at a time, but IE6&7 will only download one script or two non-scripts at one time. The thing to keep in mind is these resources are not free, and scripts are different.
A good rule of thumb is to put your style sheets in the head and your JavaScript at the very bottom of the body. Of course JS libraries give you some sort of "on DOM ready" to attach to. You can use this, and most devs do, but there are side effects:
IE occasionally barfs on the DOM-loaded hack. Rare, but it's happened to me.
Your page will be frozen until your scripts load if they are in the head. If you have too many scripts, that can make your page look slow and non-responsive.
If your JavaScript is all at the end of the page, you'll never need to worry if stuff is loaded or a DOM node is available. And the page will be rendered and styled while your JavaScript is loading and calculating.
Finally, keep your resources to an absolute minimum. If you have more than two scripts and two style sheets, your page is not as fast as it could be. Images too - make full use of image sprites. There should only be a handful of images unless you are dealing with thumbnails or something like that.
K-I-S-S is my dogma. When my code does not work, it starts usually to work when I kill non-intrinsic code.
Some good things are covered in replies such as mwilcox and prodigitalson.
No unnecessary pictures and no excessive script blocks. Actually, some people seems to have working-JS-code of over 500 000 lines, example with Gmail.
I have no idea how they do it but it hints to be critical about the replies here! Further replies could cover how to design massive JS code like of the size 100 000 lines, for the time being.
Exceptions
libraries and analytics scripts are an exeption and go to the beginning (if needed at all). Due to this kind of messy things, you may see why the term structure become confusing. But to craft some sort of structure, it would look something like:
CSS
Divs
scripts at the end