Working with Extjs, GeoExt and OpenLayers, I more and more tend to run into problems which do not result in direct javascript errors (in either IE, FF or similar). It could be features not working, unexpected behaviour and so on.
My usual strategy is to strip down code to a minimum hoping to discover where the problem arises - Firebug and the IE debug tool are usually great companions. Google and various forums are always a big help – IF a similar problem has been documented by another user and IF the problem has been formulated in a way so that I find it.
But when it comes to using larger frameworks such as Extjs and OpenLayers, I find it very difficult when my debugging leads me inside the frameworks world of mysterious methods.
Asking questions here and in other forums can give fantastic results, but sometimes I cannot point to what the problem actually is – only the result I see on the screen. Using multiple frameworks it could be interference between them, unexpected behaviour when using exactly those frameworks and generally just complicating the debugging.
What do you recommend I do in these situations? What do you normally do – I would love to pick up a trick or two :)
I feel your pain. I use YUI a lot and sometimes errors get sucked into a bottomless pit of YUI code that doesn't generate an error per se but also doesn't do what I think it should.
In cases where I'm lucky enough that an error is thrown inside foreign code I look at Firebug's call stack and start debugging at the first place up the chain where I find my own code.
In the case of the bottomless pit swallowing errors then I resort to setting breakpoints in my code at suspicious places and single-step my way through.
Firebug is very, very useful here since it allows you to dynamically set breakpoints and conditional breakpoints. In both cases above I never reduce my problem to a minimum because the bug may be due to the complexity. Also, setting breakpoints is much easier.
About the only time I reduce my problems to a minimum is when I need to post it here or at comp.lang.javascript.
Now, if the bug only appears in IE I usually give up for the day, go home and come back tomorrow. It is a surprisingly effective strategy until my boss decides that we need to push the code to live TONIGHT (in which case I just cry inside).
Related
I could be wrong, but I believe the gist of breakpoints is to pause the state of an application, and review it's previous/current state, and cycle through each "breakpoint", to identify holes, bugs, and irregularities.
I was never taught to use this, and I believe I fall into a much more primitive, yet common, approach of debugging. Console.logs. Console.logs everywhere.
To me, a "breakpoint" is the equivalent of placing a console.log at the location where a "breakpoint" should occur, to understand the state of a particular object/class/etc.
Something tells me however, this is far from ideal, and I am lacking what appears to be a very valuable skill in debugging. Everyone that I know who is a talented developer, professor, and manager seem to heavily lean on breakpoints, yet from googling I can't find any solid explanations on how to use them to a degree superior than simple console logs.
This question is hoping to get the answer on how to differentiate the "console logger" mentality from what appears to be a more advanced form of debugging: breakpoints.
P.S. I tagged javascript and ajax as this is what I use, and my question is primarily geared towards these two categories, however I am confident this applies to all languages, and a general culture of optimal debugging.
There seem to be a number of differences (beyond performance of course) between both browsers when using Javascript. I am not even sure those are bugs or indeed different evaluations. In my applications (large, complex IDEs) I noticed here and there that Chrome is doing things different:
Array::indexOf and sorting appears different (hard to isolate for me)
scripts dealing with blur and focus seem to be different
a number of other minor issues with CSS
some other issues I can't remember of right now. The point of this post is to figure out what's different, nothing else :-)
I am also not really sure that the Chrome differences are really my faults and so I was wondering there things to know about Chrome vs FF when it comes to Javascript. My test-units do run all fine except in Chrome...
I did search a lot but I couldn't find any recommendation, guide or simple cheat list; possibly some folks here know better :-)
(ff/chrome version doesn't seem to matter)
thanks!
This is a very large question as each are built on different frameworks and therefore support functions differently, especially once you start going back a few versions.
But here is a simple page that lets you dig into the differences of each.
http://caniuse.com/#compare=firefox+42,chrome+47 (change versions to whichever you want)
This is a small portion and you can already see there are too many differences for anyone here to list.
In addition to canIuse, there's also kangax's compatibility tables. However your question appears to be geared more towards an under-the-hood implementation comparison, I can't help you there. Anything not in the spec (or marked as implementation-defined) is fair game: for instance object property order is not guaranteed but both seem to maintain insertion order when iterating via for...in.
Asking the right question (yep, the one held too stupid to be uttered) has it's own challenges. Since having started to flirt with d3.js, I seem to have no shortage of these. Here's one which, though for me quite pressing, I've already been warned may be too subjective.
Sometimes a DOM structure conflicts with what is expected: certain elements are perhaps siblings rather than children (perhaps the result of some filter function), or appear to be missing entirely (say an element which for some reason is being ignored).
In these cases, the DOM inspector can, though not necessarily misleading, be a frustration, and we are left to troubleshoot using the console and logs.
Sometimes, however, the console itself seems of little help. I'm thinking of those instances where you're confronted with a series of brackets, perhaps a hint at data, but -frustratingly- a series of error messages when trying to access it.
I see plenty incidental wildfire, but wonder is there a more or less comprehensive guide somewhere to the interpretation of cryptic console output, covering topics such as:
How the various object types are represented
What approach serves best to interrogate each
How to interpret various configurations of empty, square, curly and other brackets
Strategies for penetrating deeper regions of the DOM tree
Slights of hand to improve console representation and readability
Interpretation pitfalls to be aware of
Glad of any good leads..
Thanks
one really grat start is to follow these tutorials and introduction on d3.js:
http://alignedleft.com/tutorials/d3
in particular this section explains arrays and how they work:
http://alignedleft.com/tutorials/d3/data-types
I think this should be really helpful if you're just starting with d3
Something that may help for some of the cases you've mentioned for D3 specifically is the DOM inspector that vida.io (tutorial here) provides. In general, there's no answer to your questions however -- all depends on the particular library you're using, browser, versions, etc.
As an alternative to command line usage (e.g. console.log()) maybe the interactive web inspector would be more helpful to you. Details for Safari or Chrome. Although I find it less useful, there's also Firebug if you prefer Firefox.
My pages seem to be reacting slow.
There is a lot of JavaScript (jQuery) code on the page. How can I narrow it down? What is taking so long?
The YSlow add-on is the best solution to know why your website is slow.
There are many issues which could be the reason for slowness.
Combining many jQuery to one could help you increasing your performance.
Also you can put the script at the bottom of your page and CSS at top.
If you use Firefox, you can install Firebug and use the profiler.
You can read more about it in Understanding Firebug profiler output, and there is a tutorial in Firebug Tutorial – Logging, Profiling and CommandLine (Part I).
If you use Internet Explorer, you can use dynaTrace Ajax edition.
Read more about it in A Step-by-Step Guide to dynaTrace Ajax Edition, available today for public download .
There's also a built-in profiler in Google Chrome that you can play around with.
Both these solutions will help you narrow down what JavaScript function calls are the most costly, and with repeated profilings you will be able to see the effect your changes has.
Using tools like these will not only make you a better programmer (if you take the lessons to heart, and avoid the same mistakes they point out in the future), they will also give you a new appreciation of what happens in your code, since you will get a behind-the-scenes glimpse you haven't seen before ;)
Also, if you don't know YSlow, like Wazzy is talking about - get to know it... maybe your problem isn't even slow JavaScript code :)
Using the tiny Diggit/Blog feature of StackOverflow described here:
I would like to post the following Google tech talk video I have just saw and that I found quite interesting.
I have always had problems understanding javascript "nature".
Here, the JavaScript good parts are described by Douglas Crockford
I hope you find this link useful.
Now the question part:
What are your complaints about javascript?
Do you use an IDE for javascript editting?
Do you think this video helps to understand the "good parts"?
JavaScript: the bad parts.
The biggest mistake is late error detection. JavaScript will happily let you access a non-existant object member, or pass the wrong number of arguments to a function, and fill the gap with ‘undefined’ objects, which, unless you deliberately check for them (which is impractical to keep doing everywhere), will cause an exception or generate an unexpected value later on. Possibly much later on, resulting in subtle and difficult-to-debug errors appearing nowhere near the actual problem code. These conditions should have generated exceptions, except that JS didn't originally have exceptions to raise. ‘undefined’ was a quick and dirty hack we're now stuck with.
Undeclared variables defaulting to global scope. This is almost never what you want and can cause subtle and difficult-to-debug errors when two functions both forget ‘var’ and start diddling the same global.
The model of constructor functions is weird even for a prototype-based-OO language and confuses even experienced users. Forgetting ‘new’ can result in subtle and difficult-to-debug errors. Whilst you can make a passable class/instance system out of it, there's no standard, and most of the class systems proposed in the early tutorials that people are still using are both desperately inadequate, and obfuscate what JavaScript is actually doing.
Lack of bound methods. It's utterly unintuitive that accessing “object.method” when calling it makes a magic connection to ‘object’ in ‘this’, but passing “object.method” as a reference loses the connection; no other language works this way. When this happens, ‘this’ is set to an unexpected value, but it's not ‘undefined’ or something else that would raise an exception. Instead, all the property access ends up on ‘window’, causing subtle and difficult-to-debug errors later.
There is no integer type. Number looks like one but breaks down in various ways (eg. n+1==n for high enough n). Any time a NaN or Infinity sneaks in (quite unexpectedly if you think you are dealing with integers) you won't find out immediately; instead there will be subtle and difficult-to-debug errors down the line.
There is no associative array type. Object looks like one but breaks down under various unexpected keys. Arrays aren't pure lists. Any time you ever use ‘for...in’, you have probably fallen into a trap, and will experience... yes, subtle and difficult-to-debug errors.
Generally poor string handling, for a scripting language at least. String.split(, limit) and String.replace() don't do what you might think, causing... you know. The results of toString() are generally poor and not useful for debugging. Meanwhile we are stuck with a load of rubbish Netscape thought might be useful, like String.prototype.blink(), and the perpetually broken escape(). Yay.
And then there's all the browser differences (IE is still missing a lot of essential methods on the basic objects), and the DOM...
And finally, even when an exception does occur, it is hidden away from view, so the author won't even realise something is wrong. The result is that most sites are chock full of errors; turn on full JavaScript error reporting in IE and the result is unusable.
It scares me to think a new generation of programmers are learning this tosh as a first language. What's worse, most of the tutorial material they're learning from (“My fiRST AEWsome R0LL0VERZ!”) invariably encourages the worst possible practice. ‘javascript:’ URLs, ‘eval()’ for everything, browser-specific DOM access... oy.
The hard part about javascript, in my opinion, is:
Cross browser development/debugging issues
Cross browser dom/model issues (event bubbling, etc...)
Lack of "classes" (subjective)
Lack of good solid debugging support in browsers
Firebug helps a lot for FireFox, but I have not found anything that good for IE - and the mere fact that one has to is difficult.
On the bright side, if you build a script from the ground up and understand each step, it can be really enjoyable and powerful.
alt text http://oreilly.com/catalog/covers/9780596517748_cat.gif Javascript the Good Parts is a pretty decent book too.
For Javascript Firefox+Firebug and Notepad++ are my IDE. jQuery (and assorted plugins) is my Framework. My biggest complaint about Javascript is IE6
My biggest complaint while using JavaScript are the DOM bindings, but those are not really the fault of JavaScript so much as each browser implementing it their own way. Along those lines, IE is the worst offender.
In terms of pure JavaScript issues, I still don't fully grok prototyping in a way that allows me to use its full power; but that's less a complaint than my own personal failing. As a language I like JavaScript a lot, and any complaints I have on it are overshadowed by its interactions with the DOM.
I use Firefox + Firebug intensively for my main coding and debugging. There are debuggers in Opera and Safari that I use if either browser is having particular issues. Heaven help me when I need to debug IE.
I code in whatever text editor is available and has syntax highlighting. I tend to use the YUI framework, but that's just because I know it the best; I hope to someday learn more about other frameworks and decide which would be best for personal projects.
While I haven't seen the video, I just read "The Good Parts" this week. If the video is anything like the book, it'll be very helpful. The book itself is great because it's concise and informative. It goes into a level of language discussion that one doesn't see often enough when Googling for information, that gives one a better comprehension of the language as a whole.
I really like prototyping, it feels much more powerful than normal classes.