In one of my Rails apps I have added a local jQuery library, but I have noticed a 404 in the console.
Should one be concerned about any future bugs due to not having the "jquery map" in my app files?
Problem: GET localhost:3000/assets/jquery-latest.min.map 404 (Not Found) Error
Thanks for any feedback in advance!
This is called a source-map file. You shoudn't worry about it, it is only loaded because the developer console of your browser is open and it attempts to automatically download the corresponding source map because jQuery provides one.
As you probably already noticed, you are using the compressed/minified version of jQuery and its code code is unreadable by a human. Source-map files allows the browser to run the minified version of the script but to also download the uncompressed version and a map file that links the two together. This way, when you are debugging your code the browser will present you the full source code of jQuery including the comments.
This may not be super useful alone with jQuery unless you develop jQuery, but if you compressed all of your Javascript files this is a neat feature: instead of having a crash in a function g(y,s,w,f), your browser would download the original source and tell you the error is in doSomething(element, width, height, otherThing) and basically act work like if the code was never compressed.
Related
Final Update
For most practical purposes, this question is obsolete as both firefox and chrome have native support for avif through the standard picture html tag with a source marked as type="image/avif". See https://reachlightspeed.com/blog/using-the-new-high-performance-avif-image-format-on-the-web-today/ . Fire fox still likes to hang and often forces a control F5 to bypass caches and requires sending the correct content type from the server. Hopefully will be fixed soon.
Here is the commit where I got avif support working: https://github.com/quackack/quackack-comics/commit/f1a98ed1f40b6a22584d61bc338bd91df3232fa5#diff-e25b0950ce48f4e928f98e0a6fbb694c . Note that it contains many unrelated changes and in fact avif is barely mentioned, only as a content type and a file extension.
Original Question
I am trying to change a website where I host web comics from using jpegs to the newer avif image format. It is much smaller and seems to be the new image format with the most widespread support. Unfortunately, web browsers don't properly support the new format yet. So I was planning to use this package: https://github.com/Kagami/avif.js to allow my comics to be rendered. Some basic tests showed that AVIF would give the same quality as jpeg for less than half the space.
Unfortunately, after more than 5 hours of time spent on this, I am unable to get this to work with my react framework. You can see my website at the time of writing at 'https://github.com/quackack/quackack-comics/tree/cda4c3893d8477192c4ff3aa78d00096b7621ff7'.
I tried using npm install to install avif.js and then added
require("avif.js").register("/avif-sw.js");
to index.js . But I get error
Failed to register/update a ServiceWorker for scope ‘http://localhost:3000/’: Bad Content-Type of ‘text/html’ received for script ‘http://localhost:3000/avif-sw.js’. Must be a JavaScript MIME type
And avif files are still not able to load. I think the requests are getting rerouted to index.html instead of the javascript package. It seems like the appropriate thing to do is something like
import * as avif from 'avif.js';
avif.register('avif.js/avif-sw.js');
But this fails too with the same error, as do many other similar variations.
At this point I am inclined to wait for proper browser support for avif, as I don't get enough traffic to worry about data costs anyway. If this could easily be fixed, then I would love to have the improvements from avif. I just want smaller file sizes and widespread browser support.
Update
Okay, I found that I could get this to work if I changed from the default react bundler (which I believe to be webpack) to Parcel. Then it does work exactly as you expect... until I try to deploy the project.
There is an issue where I cannot load the service worker when i try to deploy my single page webapp to AWS as a single page web app. There it makes a request to my url with avif-sw.js where there is not actually a js file. I believe the issue is closely related to https://github.com/parcel-bundler/parcel/issues/670
So the first key is to use Parcel to build your web app. But Parcel still does something wrong with deployment it seems. I will continue to investigate this in a few days.
Here is the almost working version using parcel: https://github.com/quackack/quackack-comics/tree/parcel
Update 2
My earlier update was incorrect. I only thought it was working because of a cached service worker. My final solution is in the answer below.
It doesn't seem to be a problem now. Simply convert your images to avif with tools like https://avif.io/ and use them as the image source or background source via typical CSS. As Chrome and Firefox now support it (even though users still have to enable it on Firefox), everything goes well. Even works on mobile now! :)
Okay, I finally got it working. Unfortunately, mobile devices don't seem to be able to handle the large file sizes so I had to keep using jpeg anyway. It worked on my laptop though.
Here is the commit that got everything to work: https://github.com/quackack/quackack-comics/commit/75e75307e688f0e515b4bbc9eb22eef290d2c209
What I had to do:
Switch to Parcel.
Copy the contents of the avif.js library into source before building. I used the command:
copyfiles -f node_modules/avif.js/*.js .
Put this specifically into reg.js:
require("avif.js").register("./avif-sw.js");
navigator.serviceWorker.register("./avif-sw.js", undefined);
What the last two steps do is trick parcel into actually keeping a copy of "avif-sw.js" around that can actually be loaded as a service worker. Probably with a bit more tinkering you can get this to work without using parcel at all, just by copying local and then registering. No requires required. But I stopped investigating after I found this solution can't work on mobile.
This was exceptionally hard to debug because service workers are cached by the browser and I had to clear broswer data after every edit. It was also hard to debug because the source files are cached to so I had to delete my projects cache and build frequently too.
You might also want to use npm module "http-server-spa", or similar, to test how your built SPA will act when deployed.
Can someone please explain what the point is of source maps? Because as I see it, my concatenated and minified file gets loaded (talking about JavaScript), alongside 100+ modules. How is this not affecting performance when I'm loading twice the size as before?
The point of a source map is that you can run minified Javascript or transpiled Javascript (which is not particularly readable in a debugger by itself), but when you open the debugger, the source map is loaded by the debugger and it gives you a readable form of your source for debugging purposes. The source map is not loaded if the browser is not configured for source map debugging.
Source maps are also extremely useful if you are transpiling code from something like TypeScript or ES6 down to ES5 Javascript so you can see the actual code that you wrote originally in the debugger rather than only the transpiled and minified output.
The alternative before the days of source maps was to have separate versions of your site or options on your site that would load non-minified JS so that you could debug with normal symbols, but this of course isn't actually debugging the exact same code so even then, this could still leave you having to try to debug minified code.
You can read here about how source maps are enabled in the Chrome debugger. If you're watching what is downloaded by the browser, then make sure that you are using a browser that does not have source maps enabled when checking if they are downloaded.
Because you only load the sourcemap when you open the debugger.
Actual users, who don't open the debugger, still get the benefit of the minification.
A source map is a developer tool. It's practical to know the original source when an error occurs within minified source, so you can track down the source of the error.
Source maps are thus only loaded by debuggers, and will not be loaded by default. However, you should consider disabling source maps for production environments, because debug data usually shouldn't be on production environments: for performance and (more importantly) security reasons
What is the industry standard or professional process of finding out where the actual line number in the source code of your rendered page is happening?
I have used browser debug tools and it of course shows you the error, but the line number is not the same for the source code file that is being served up. I know that usually server side scripts are making the file longer than it really is and etc.
I usually just do a find for functions or code near the error and can eventually find it, but is there a better way?
The simplest way is to ensure that most of your JS is written in non-templated .js files, rather than inline <script> blocks in your templated html.
I develop with Visual Studio.net 2013, which will stop at breakpoints and break on server and client side errors.
If you aren't developing with a tool like VisualStudio that has a built in debugger with breakpoints, etc., the built in developer tools in Chrome and IE are awesome (IMHO). Since Javascript runs clientside, you'll need to debug it using the browser. If you don't like the built in developer tools, you can also try Fiddler and Firebug.
I'm trying to debug an AngularJS app in Chrome (with the Jetbrains extension) within Webstorm 8. It's working just fine, but the only naggy thing is that the actual file that has breakpoints in it doesn't get debugged, but a readonly copy that reads as the full url of the file is (see screenshot). It works, but I cannot edit the readonly file while moving from line to line.
edit: plus, the IDE usually shows an outdated version of my JS file and I have to manually refresh it to see the correct one.
The Webstorm Run/Debug config for Javascript is really straight forward, basically just the URL to the app.
Does anyone knows how to avoid this?
Cheers
The short answer is: you can't
The longer answer is, the computer is not running the code that you see on the screen, that's just what the debugger is showing you. The computer is actually running optimized, non-human-readable Javascript bytecode, which is created when you start your JS program, after syntax is checked, namespaces are created and memory is allocated for variables etc. You can't edit that bytecode by writing JS code directly, at least not with any debugger I know of (and I'm fairly certain you can't with Webstorm specifically; I use PHPStorm and its Javascript debugger).
Such problems usually mean that remote files are not correctly mapped to local ('remote URL' not correctly set for local files in Run configuration), so the debugger can't map the files being executed to your actual sources. I'm not sure what your application looks like... But, as Angular apps structure is more or less standard, I can suggest mapping the 'app' folder to 'http://localhost:9000' in javascript debug run configuration you are using to debug your angular code
I have a web page which includes insane amount of minified JS files. The web page works perfectly fine on my local network but throws some JS error on staging. There is an issue in JS and I wan't to debug it. When I load the JS in Firebug's script tag it appears in one long horizontal line. Is there a way out in Firebug that expands or beautifies the script for debugging? I know I can use jsbeautifier but they wont help me. I can not upload an expanded file to CDN, defeats the purpose of using CDN.
Points to be noted,
a) I can not control the box which serves JS, its on CDN, I mentioned it.
b) I can use beautifiers etc but would that help me in debugging the script in run time? IMHO, no
c) Being bound by NDA and other legal things I can not share the script but its a generic problem, you can encounter it with a minified jQuery
Beautify your script
Add the CDN host in /etc/hosts or your local DNS to resolve it to your own web server
Host the beautified version and everything that you need on said web server
Both Firefox and Chrome (versions as of this edit) support beautifying script with the {} button available in the inspector.
Just load the minified file and press the {} button at the bottom and it instantly beautifies, making breakpoints and other debugging possible. (True for Chrome too)
This is a common problem and the Chrome dev team have recently come up with an elegant solution, which they've called Source Maps - see http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/ for more info, I think you'll find it's exactly what you (and the rest of us) have been crying out for! :)
This is more a workaround, but it can help. The idea is that we will replace files coming from the server by files on your machine.
This will work with any browser.
It takes a bit of setup the first time (15 minutes maybe), but then it can be very convenient.
It can also helps testing your bug-fixes in a live/prod environment.
Get Fiddler (it's a web debugging proxy), install it, run it.
http://www.fiddler2.com/fiddler2/
(Restart browser after install to get the Fiddler extension)
If you debug an HTTPS website, check this first:
http://www.fiddler2.com/Fiddler/help/httpsdecryption.asp
From now on, you should see in Fiddler ("Web Sessions" pane on the left) all downloads made by your browser, including JS files.
If not, check this : Fiddler not displaying sessions
Find the file you want to debug in the list (Ctrl+F works)
Click on the file. Then either:
get the file content from the inspectors pane (textView tab), beautify it, save to a file on your local computer
or have access to a file which contains the source code (ex: from your source control)
Go to AutoResponder tab (top left pane).
Select "Enable automatic responses" checkbox.
Select "Unmatched requests passthrough" checkbox.
Drag your file from left pane to right pane (prefills rule editor at the bottom)
Set the other field with the path of your local file
Click the Save button
Reload the page and enjoy your debugging session.
Fiddler can do many more things, but this use-case answers the initial question.
Consider a Change!
Firefox w/ Firebug was my favorite JavaScript debugging method for almost a year, but I've recently moved to Google-Chrome's Developer-Tools which is far more superior.
Chrome supports an On-The-Fly (built-in feature) beautification of JavaScript resources
Once beautified, you are free to debug the JavaScript resource file, as it was "natively" downloaded beautified from the web-server. Breaking-points are set by clicking the line number.
One of the most extremely powerful feature,
Is once You've Stopped In A Breaking-point, You Are Free To Execute Commands (using console) In The Same Scope You ARE In The Breaking-point. In Firefox you can't do that.
Its so easy to debug (even anonymous functions), You'll never be back to Firefox.
Try It!
Pretty-print your JavaScript. Google this and you'll find multiple on-line JS beautifiers.
I happen to use http://jsbeautifier.org/ myself and it works fine, but search for others and use one that suits your needs.
Caveat: You still won't be able to get meaningful local variable names (which are usually renamed by a minifier). If the code was compiled by the Closure Compiler, then you absoutely won't get any useful information back at all, even when beutified, because then all variables and functions and properties are mangled (not only local ones).
Now, if your problem is with debugging code that comes from outside (e.g. a CDN), obviously that code would be minified, and you can't save your beautified version back there. In this case, you can replace the tags that load code from a CDN with a url pointing to your local version, then you can beautify the code (downloaded from the CDN) into your own server and you can then debug with FireBug.
Now, if you don't even control the HTML that contains those tags (e.g. they reside on a outside server), then unfortunately there is no way for you to do what you want without physically downloading the entire site to your own server. Even if you downloaded the entire site (with all the files), it may not work since the site may be driven by a back-end processing language or accesses a back-end database. In such case you'll also need to simulate all those data. It can be done, however -- you just have to go through a lot of pain. My recommendation is to save a version of the web page and run it on your own server, serving beautified code from your own server to debug.
Placing breakpoints on JavaScript makes debugging much easier, but if your code has already made it to production then it's probably been minified. How can you debug minified code? Helpfully, some of the browsers have an option to un-minify your JavaScript.
In Chrome and Safari, simply select the 'Scripts' tab, find the relevant file and then press the "{ }" (pretty print) icon located in the bottom panel.
In Internet Explorer, click the tool icon by the script selection drop down to find the option to format the JavaScript.
Opera will automatically prettify minified JavaScript. Source