Hacker News new | comments | show | ask | jobs | submit login

Webkit dev tools timeline in frame mode is bar none the most useful tool for tracking down performance issues. Looks like it's on your roadmap but it's far, far more useful in tracking down actual perf issues in large codebases than any other tool in any developer tools toolbox because it's cross-cutting and bottlenecks tend to be a combination of factors and the frame-sizing lets you find what's on the critical path when it's on the critical path. I use it 10 times for every one use of all other perf profiling tools (I consider network/pageload to be a different set of problems).

I don't see it on the roadmap but the firefox console is SO terrible at printing objects. In most apps I work on I'm shipping around 2kB+ JSON objects and the current console is absolutely worthless for these.

Related, but I think there's room for improvement in object printing in general. I find myself not really caring about most fields in an object but I'd like a couple fields printed inline before expansion. I like that the firebug console prints a few fields with the option to expand objects but would like to have control over which fields those are. FWIW, my preferred pretty printer is node's.

I find CSS errors/warnings to be absolutely useless in both the firefox dev tools and opera's. Pretty much any modern site is using vendor prefixes and the result is hundreds or thousands of errors which makes the console fall over.

Due to the above, I've been taking the approach of trying dev tools out again every time Aurora updates and then going back to using firebug and chromium after 15 minutes or so. I completely missed the jsterm addon despite following you on a couple channels. It looks reasonable so I'll be giving it a go today.

When you're doing your network cascade panel, please set it up to load HAR files. You can get HARs from a variety of sources but there isn't (yet) a convenient way to view them locally.

For the debugger, I don't know of an equivalent of webkit's source view cmd+o / cmd+shift+o, which are extremely useful. The cmd+p filtering is decent but most of the time I do actually know what file and function I'm looking for. I also use the reformat button and break on caught/uncaught exceptions on a regular basis. Actually, now that I think about it, I use every single function except for the editing functionality on the chromium sources panel at least once a week.

For the style editor, the side list of stylesheets isn't mousewheel scrollable on my machine (I'm on Aurora).

I find dock right to be the most useful attached view for chrome tools. Screens (and particularly laptop screens) are wider than they are tall and dock right takes advantage of that.

Edit: For a larger feature, I would very much like the ability to edit code when the browser hits an exception and then continue execution using the new code. I've only seen this in smalltalk demos so I assume it's difficult but being able to flip a variable to tweak an if statement when stepping through the debugger saves the effort of getting back into the correct state from pageload.




Agreed on the console not displaying objects well. I find that to be especially true with DOM nodes.

FF:

  >>> document.getElementsByTagName('div')
  (pocs:({}), pocs0:({}), pocs1:({}), pocs2:({}), cst:({}), mngb:({}), ... )
Firebug:

  >>> document.getElementsByTagName('div')
  HTMLCollection[div#pocs, div#pocs0, div#pocs1, div#pocs2, div#cst, div#mngb, ... ]
Chromium:

  >>> document.getElementsByTagName('div')
  [<div id=​"pocs" style=​"display:​ none;​ position:​ absolute;​">​…​</div>​, 
  <div id=​"pocs0">​…​</div>​, 
  <div id=​"pocs1">​…​</div>​, 
  <div id=​"pocs2">​Press Enter to search.​</div>​,
  <div id=​"cst" style=​"display:​none">​</div>​, 
  <div id=​"mngb">​…​</div>, ... ]

(edit: formatting)

-----


I think a general pattern is that the console should be smarter about the specific stuff people do in a console, in the browser. Every kind of DOM node should have specific representations appropriate for that DOM node, not just what falls out of some generic printer. There are array-like objects that get printed out funnily because they aren't real arrays – but {0: x, 1: y} is no more clear about the actual nature of the object than [x, y].

Why people won't code vendor prefixes into CSS tools I don't know; the obvious thing is for Firefox to ignore everything but "-moz-*" – and even then, to warn selectively (i.e., if there are old versions of Firefox that require a prefix, even if the new version doesn't, don't warn about it). Or hell, crowdsource the whole thing, when you encounter something invalid fall back on a community edited document about what is valid in other browsers, or represents a common and acceptable CSS hack. There's often good information in the CSS warnings, but there's too much useless information to find it. I'm annoyed things like LESS and SASS don't treat vendor prefixes specially either.

-----




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: