What coding conventions that help jQuery and Firebug work together? - javascript

I'm fairly new to both tools and need to go hardcore with both as I manage, monitor, and tweak a new site's design process. What sort of strategies should I ask be implemented that sets a good solid foundation for debugging, testing, and logging?
[to the degree that back-end stuff can play a role - it's .net mvc
thx

I would use Firebug to see how things are working with a few Firebug Add-ons.
I would use YSlow to check that you aren't downloading too much and it will make suggestions if you aren't minifying and gzipping your javascript.
I would also use FireQuery as that highlights jQuery very nicely in Firebug. I use it quite a lot these days to see what it should be firing.
Firebug doesn't rewrite XHRequests anymore but there is a bug in the latest Firefox/Firebug where if can block long running XHR calls. Details here

First off make sure you've read Firebug's docs. Some of the commands work cross-brower with other tools as well.
A simple search query will show you all available extensions for Firebug. As some people mentioned - some of them are really helpful.
Also it's important not to limit yourself to just a single tool since you will most likely be developing for multiple browsers. So make sure you take a look at webkits developer tools (Safari, Chrome) as well. Here's a good article which sums up the most popular development/debug tools.
You might want to research how jQuery/jQuery plugins are structured/organized so you have general idea how to organise your own JavaScript/jQuery code. It all depends how JavaScript heavy is your application. If jQuery just provides some visual enhancements and few Ajaxified pages here and there, don't bother. From other hand if it's very JavaScript heavy (as in a lot more site logic on client-side then on backend) I would suggest Prototype over jQuery, but it's just my opinion.
You could consider using automatic tools to build your JavaScript if you have a lot of code.
For example:
Sprockets
Juicer
On production server you want to end up with as few JavaScript files as possible and make sure to compress em.
If you're interested in more links to articles/tools for javascript heavy applications, drop a comment. I'm just trying to stay on topic at the moment.

I would just give a small warning using FireBug's network monitor and AJAX together. When enabled, it rewrites some HTTP headers and breaks stuff badly (well it used too, not sure anymore).
So if anything goes ape. Check that network monitoring is disabled.

I will also add for tools FireCookie, as it goes very well with $.cookie.
When I am debugging jQuery code I am using the NET panel a lot in Firebug for all ajax requests. Very helpful to see what are you sending and what are you receiving.
Also I use a lot the comand line, to test snippets of code.
You cannot do without the console. It will be very helpful. Example:
$.get( 'url.php', {},
function(data){
$.each(data, function(x){
console.log( x ); // will log each x object to see what it contains
});
}, 'json'
);

I also suggest you install FireUnit addon. It helps you work with QUnit unit tests. Of course that is if you are planning to write unit tests but in most cases that's the very good idea.

As much as you might love Firebug, Safari's developer tools are also quite powerful, and worth checking out. It's all I use when I dev.
Worth mentioning that Safari's javascript engine is still faster than FFX's, while Chrome reigns supreme. They're playing catch-up though, so this really isn't worth caring about.

Related

Debugging and checking what variables are equal to in production

So I've been coding for a while now in school, and I'm having my first introduction into a real working code base at my new job. When it comes to debugging, like if I want to find out what a certain variable is equal to, I'll often just console.log() things out and hope that something useful comes out of it.
It seems really inefficient considering how many moving parts there are in the code. Most of the time, it works eventually, but it feels so barbaric just editing the code over and over and looking at the browser's console until something useful comes out, and it feels like there has to be a better way to debug in a production environment. I am specifically using Ember.JS, but this question would apply to any framework like React or Angular or Node.
There are many tools out there to debug JS, the most "basic" being the debugger in your browser. Some tools go further also, for example VSCode has a slew of extensions that open and control the browsers debugger.
Chrome: https://developers.google.com/web/tools/chrome-devtools/javascript/
Firefox: https://developer.mozilla.org/en-US/docs/Tools/Debugger
Edge: https://learn.microsoft.com/en-us/microsoft-edge/devtools-guide/debugger
Safari also has one in the develop menu but there is no site describing it in detail - it is located in the sources pane
If you use VS Code, you can run Node apps in debug mode then select Node.js.

Developing FIrebug like web application for CSS things

I am developing a web application for web designing. One part of it includes changing CSS styles on the run and saving the same back to server.
I see that, first part of my motive is implemented there in firebug, where I can view CSS style rules applied to a particular HTML element and can change them to view the effect.
An earlier question at SO lead to me firebug lite source code https://getfirebug.com/firebug-lite-debug.js , which is far less confusing than full version of firebug.
My question was that, is there any way I can get documentation of the firebug/firebug lite code which can speed things up for me.
After some googling I found out that there is Firebug API
http://getfirebug.com/developer/api/firebug1.6/
But don't know how much useful it is for me.
Any alternative way to do this is also welcome.
Firebug uses a BSD-style license, which pretty much means you can use their code in your application without too many restrictions:
http://en.wikipedia.org/wiki/BSD_licenses#Proprietary_software_licenses_compatibility
I would suggest you contact the developers of Firebug directly. I'm sure they would be interested in providing assistance with what you are trying to accomplish.
In my opinion, the ability to sync changes to a file or server is the one thing that's missing from this powerful tool, and I'm interested to see what the final result looks like.
Check out the Backfire project, which "allows you to save CSS changes made with Firebug, Webkit Developer Toolbar or any other clientside debugging tool." The project page says that it was developed to be able to support various backends. The Backfire source code is available under an MIT license.
Submitting a possible answer to my own question.
Found following which gives a small amount of information about Firebug internals.
https://developer.mozilla.org/en/Firebug_internals

Best ways to develop painlessly in Javascript on a local machine

I'm pretty new to workign with Javascript.
In most languages you can run the code quickly locally on your machine. From what I've seen, in JS you generally only use it via the browser, and so I've been uploading my code an viewing its effects in the browser. This has proven very tiresome. Also, if I mak one error, it seems like my JS/JQuery will just do NOTHING, instead of giving me a useful error, message, which is making it painfully slow to code in.
IS there some way to run JS locally to see that it is working as I go? And then only upload it to the web when I'm mostly done? What ways are there for me to do this? What ways aer there for me to unit test the Javascript locally? Say I have some JAML that should render as <p>HI</p>, how do I run this locally in a unit test?
Thanks for the help,
Alex
EDIT:
Thanks for all the great suggestions. I'll have to take a bit of time and go through them to see which ones best help me in my situation.
Since you're using jQuery, I assume that you actually want to manipulate the various elements on your page. So depending on your specific development enviroment, uploading it each time is probably the way to go anyway. If you can set up a dev enviroment on your local machine (not always possible) then go with that.
As an actual answer to your question, I suggest using Chrome's developer tools, it doesn't just have the console, but an element inspector, and a resource tracker (resource tracker is invaluable when working with JSON and AJAX, since invalid json will fail silently)
As far as I know, the firebug plugin for firefox (dont use it myself) has a similar feature set, so if you're more comfortable with that go with it.
Just remember, as a developer, your development (and debuggin) enviroment is just as important as the code that you are writing.
EDIT: Noticed that you mentioned unit testing. There are several unit testing frameworks out there for JS including one that integrates with firebug called FireUnit. Do a quick google search to find more if you want.
You don't need to upload the JS file to a server to test it. Just write an html and declare the js binding
<script
src="js/yourJSFile.js"
type="text/javascript"></script>
Edit the JS file in your favorite editor and then refresh the page to test it.
For unit testing the best option is Selenium. It allows you to record an interaction with the browser and then play it back.
You can use Firebug with Firefox to debug JS, and Google Chrome has a debugger built-in (use the Tools -> Developer Tools menu).
You can run Javascript from the local file on your machine in your browser, so you can skip the uploading step.
Also, I'd recommend using Firefox/Firebug combo for developing Javascript as it will be very handy, especially for the part you mentioned about not seeing what's going wrong with your code.
Even if you upload your javascript it gets downloaded back to you as soon as you visit the webpage that invoques it. Its run client side always. So stick to local and use firebug as the others have said. Google`s developer tool is quite nice too.
In the browser if you open the developer tools, follow the following steps:
1) Navigate to sources
2) Under sources, click snippet and open run.js
3) You can use run.js to write as much code as you want and run it locally only to see if your code is working or not (it will give you output on the console)
4) Also you can get used to some keyboard shortcuts to make it faster for you.
5) For small javascript codes, you can navigate to console and run your code there
If you want to do unit testing with Javascript there are extension of Firebug that can help you with that. I haven't try any of them, so I can't really tell you which one are worth considering, but you can easily find them if you search for the keyword "Firebug unit testing" on Google.
What seems to be comming on top is FireUnit. You can find some information about how it works here.
Consider Spider Monkey, which is a javascript engine separate from a browser. If what you are developing does not involve rendering to a webpage or can be separated from the rendering code (good practice!), then this could be useful.
I prefer Chrome to Firefox and I just found Web Server for Chrome.
It's just a Google App that quickly sets up a web server for you and will be set up anywhere you are logged into Chrome. It only allows file access to your current devices, or if you specify, other devices only on the current LAN.
You just point it to the directory with your index.html file and type http://127.0.0.1:8887 in your browser.
Additionally to the answers given you can use Jasmine for automated testing.
A tutorial that seems to help get started with automated testing on Jasmine is provided by Evan Hahn.
I used it and for me it works like a charm. Especially if test driven development is what you are going for!

What steps do you take with VS 2008 to reduce development time with Javascript?

I am seeking your stories on how you have streamlined your client side development with Visual Studio. In particular, it seems that I need to build my site too often in order for changes to pushed down to IE effectively. What shortcuts or tools like FireBug, etc. do you use for your client side development? Do you avoid Visual Studio for debugging your client side apps all together?
We are developing the application which is building almost everything on javascript side, all the controls, webservice call (thru Ajax enabled javascript), grids and all kind of stuff.
We have created framework which includes ExtJs, and JQuery. It makes life easy to initialize and define all the controls in jQuery and make get data using webservice. We can use only ExtJs, however Jquery reduce the number of lines we need to define and set the controls. And of course its very light weight as javascript files are like <25-20 kb which needs to use this frameworks.
I've used the steps outlined by ScottGu here to get a better JS intellisense for VS 2008.
(As it is pointed out here, this patch is intended for all JavaScript files, not just jQuery.)
I use the vsdoc files to get intellisense working for jQuery.
lately, I had to work in a VS2005 + IE6 only environment. I've quickly got used to having Firefox for debugging with the tools I subjectively deemed essential: Firebug, PageSpeed, FireQuery.
I tried Aptana. (As of yet however, I didn't invest much time in getting to know it - you may find it familiar if you are equipped with some Eclipse knowledge, though...)
After all is well and done, I check pages in IE and use the built-in profiler in IE8 if there is some IE specific perf issue.
I use the "empty vsdoc" workaround when VS intellisense gives up.
At home, I use VS 2010 RC - and at all places I keep the API references of JS frameworks bookmarked and within reach, just in case.
Place Javascript code in separate JS files.
You might want to consider turning your related sets of functionality into a ScriptControl.
When you work on some JS file and want to avoid the time of rebuilding the whole project, do not make it an embedded scriptresource from the start. Package it in the assembly when it is stable enough.
If you are in doubt whether you get the latest version of your JS file, disable the browser cache. (It can be done from FireBug, or in the IE dev tools.)
Disclaimer: this list is really subjective and probably not complete at all.

Is debugging complex HTML/CSS/JavaScript pages feasible?

Consider a complex rich internet application with lots of user interaction. I'm thinking of extensive drag-drop support, server-side user input validation, custom drawn UI controls such as an Outlook-like calendar, real-time UI feedback, etc... Would such an application be debuggable? I mean, can you easily step through the source code, place breakpoints, view the contents of variables, see the current call stack, use a profiler to pinpoint performance issues, etc...
Yes, why wouldn't it be?
Complexity just means more code to dig through, but tools like console.trace() from Firebug makes that easier.
Yes, it would be debug-able.
If you're using IE8 to test your site, you could use the Developer Tools to inspect individual HTML elements and change their CSS on the fly. There's also the ability to break into Javascript from the same interface.
If you're using Firefox, Firebug has almost identical abilities with a different interface.
Safari also has developer tools installed by default, you just have to go through the hoops of enabling them.
When you are designing your application, design it with debugability and testability in mind. Make sure that individual parts are independently testable, you have enough test data, you have appropriate debug/probe points in your program logic, etc. Essentially if the complexity is properly managed, debugability won't be an issue at all.
If your job depended on it, you would find a way! :)
Seriously... a passenger jet has literally millions of parts and yet there are regular routine maintenance checks and if it breaks down it gets fixed. It's a very rare piece of software that approaches that much complexity.
Web app front ends tend to be relatively simple. Essentially you're just pushing some text from the server to the browser and making it pretty; and you're using various parts of the in-browser display as controls, some of which initiate some more text conversations with the server. There are lots of little things that can go wrong, of course, but much of the hardship is simply getting the browser (all of them!) to Do What You Mean.
The only truly difficult problems are those that are intermittent and/or timing sensitive. Those can be a bear to reproduce and trace. That calls for in-depth logical analysis of your source code and/or some specialized testing methods.

Categories

Resources