You are likely already familiar with basic breakpoints, either from using JS developer tools or a previous language.
It is one of the most useful tools in a developer’s toolkit. While in code view (sources tab in Chrome) you can add a
breakpoint by clicking the line count, which leaves a marker (the breakpoint). As I explained earlier, this default type
of breakpoint pauses the JavaScript and allows you to see the current state, including the values of the variables. There
are a few other types of breakpoints and not all debuggers can deal with all types of breakpoints, which can be useful
in different situations.
• DOM breakpoints: These let you pause the code for changes such as modification of an
attribute or removal of an element. In Chrome this can be found by right-clicking a DOM none
and selecting one of the options listed under Break on….
• Exceptions: Quite often you will have code that is set up to throw an exception but rather
than handling it in the code, you will want to debug it properly and figure out what caused the
exception. Instead of having breakpoints on every exception, which soon gets annoying, you
can set the debugger to pause on either all exceptions or just uncaught exceptions. In Chrome
this is accessed by clicking the pause button that has a hexagonal background. The color
changes dependent on which mode it is set to.
• Events: Breakpoints can be set for when an event gets triggered, such as click or mousemove,
which can be very useful for making sure events are triggered where they should be and that
they do as expected. In Chrome, these are available from the sources panel under the Event
Listener Breakpoints heading.
• Conditional breakpoints: These are the same as the default breakpoint except that you
can set conditions on which the breakpoint pauses, which work the same way as if you
put a breakpoint within an if statement. These are, in my opinion, the most useful kind of
breakpoint because you can use them to only pause the code when the results are not what
you would expect them to be. To place a conditional breakpoint, right-click the line count and
Timeline
So far we have discussed functionality in debuggers that allow you to fix code and make sure it is working as you
would expect it to. Sometimes however, getting the code to work is the easy bit—making it fast is often far harder. We
are still on the subject of debuggers but now rather than inspecting to make sure each part of the code is working, we
instead need to record the entire process so that we can spot patterns in performance (looking at the overall running
of the code rather than each inpidual function/line). This is a subject that could easily fill an entire book, so I will
go over the basics and it should give you a good starting point for figuring out how to understand and improve the
performance.
In Chrome, the tool that we use to measure performance of the code is the timeline. I should note that the
network pane is also related, as it lets us see which resources are causing a delay. But I’m going to focus on the
running of the code rather than the resources, because it is more likely that you have experience with resources
(on a normal website) than with performance testing of the code (crucial for the more creative of web apps).
To start using the timeline, you need to record the running of the code by clicking the circle button. As soon as it
starts recording you will notice that some graphs are created. There are (at the time of writing) three aspects that are
recorded: Events, Frames, and Memory; all these are recorded simultaneously but can only be viewed separately by
selecting them. At the basic level, these features give you a good way to test the speed of parts of your code because it
breaks down the code like a stack, showing you each function call. This is a fairly easy way to find bottlenecks, but it JavaScript的创造力英文文献和中文翻译(2):http://www.youerw.com/fanyi/lunwen_39266.html