Disclaimer: I'm on the Chrome team and specifically focus on the Inspector/DevTools
Majd and I have talked a lot about tooling and the Chrome DevTools in particular. He ends up tweeting me a few requests or bugs a day that I'm routing to the engineering team. I love it.
Majd's writeup here is incredible. I hope to find a way to augment our existing documentation with this very thorough roundup. He's done a similar thing before ( http://jtaby.com/2011/05/31/google-chrome-why-i-hate-it-and-... ) and the Chrome team filed and fixed 33 bugs as a result. For the new article in particular, I expect us to iterate and improve based on the excellent feedback provided here.
I would add that CSS Selector Profiling is mostly in the DevTools so you can see how insignificant of a cost it is (in 99% of cases). But focusing on your network waterfall will pay performance dividends a few orders of magnitude bigger than optimizing selectors. :) That said, Majd knows what he's talking about quite well.
Hi, one of the reason I still use Firebug is we have a multi-line enabled script editor, not just multi-line support (http://code.google.com/p/chromium/issues/detail?id=35487), and the script is retained after page refresh, no up arrow needed.
I hope Chrome will have this feature in the future.
Hi!
The author suggests to use chrome canary.
I so want to use Chrome Canary on Ubuntu. Are there any plans to support it on ubuntu? Is there an alternative?
That said, it used to be actual dailies, but updates have been very spotty the last 4 months or so. I'm not sure why. When it was updated ~daily, it would sometimes break so it's not for everyone. I run it as my main browser and I've had to downgrade once. Now that it's updated less frequently it's been more stable (obviously).
I would have added this info in my original comment, but I was posting from the phone. Adding it to your sources is as simple as:
Heh. That's just building in the aliases that originated in Prototype.js, which offered $ as gEBId sugar and $$ as one for querySelectorAll. Opera actually decided to go with $ as querySelectorAll, a la jQuery, which IMO makes a bit more sense.
This is one of the ways that Prototype.js had a huge effect.
This is a great resource and I'm glad Majd wrote it. However, this is really the kind of content that should be coming out of Google itself.
Google is in an interesting position. Of all of the major Silicon Valley tech companies, I think Google is the one most seen as the "web" company, and yet they've staked a lot of their future on Android. Android, instead of making the web a first-class citizen, has in fact set the mobile web back by years. While they should have worked to bring all of the strengths of the web to mobile devices, they decided to play the app game on Apple's terms and, IMO, have lost.
Surely someone at Google realizes that killing the open web also kills the company's cash cow--search and related advertising--but based on their behavior it doesn't seem like it.
My hope is that the Android wakes up and decides to make the web a priority again. In league with the Chrome team (some of the smartest people I've ever met), they could do wonders to make developing for the mobile web a joy instead of the disaster that it currently is. Google needs focus, and it needs its focus to be on the mobile web. Having great, unified documentation about building sophisticated web apps that competes with Apple's Developer Centers is a good start to doing so.
It's true- I've spent a lot of time developing HTML5-based apps (i.e. in a webview) and am already surprised at how much worse the Android web engine is than the iOS one. Google should be all over this (and with the release of Chrome of Android, perhaps they finally are) but it baffles me that it took this long. Meanwhile, it took Mozilla to create Boot To Gecko, a true web OS.
The Chrome beta on ICS is great, but it's only accessible to <4% of all android devices. ICS has been out for months, and the providers are completely dragging their feet on it.
Chrome Beta needs to be backported to at least 2.3
AFAIK it also doesn't make any difference to apps that use webviews. I mean, it's just as well- if you changed the underlying engine without notifying devs insanity would ensue. But it would be good to be able to set a flag that says "use the decent engine".
"ICS has been out for months, and the providers are completely dragging their feet on it."
Can anyone explain why this is such a problem? Does Android not have a proper hardware abstraction layer or driver model that would allow OS updates immediately, as long as these layers remained compatible and a build existed for your processor family?
Windows has supported disparate hardware configurations for many, many years. Yet, generally, you can run out and buy the new version and install it. Why can't Android do this (albeit with a version for each processor)?
Many providers have customized the OS for the look and feel along with adding their custom apps and settings including locking out tethering. One of the big advantages of 3.0 was it was suppose to provide an easier way to separate out the look and feel out of the OS so the providers didn't need to create a custom OS. This make pushing out updates very difficult.
For example, I worked on an app to be included with the device by the OEM. The OEM had roll a custom OS and kernel to handle their hardware and replace/update the mail and calender app because they are very tied to Google by default. We needed hooks into the the mail and calendar app in ways that are not supported by Google so the OEM also had to add those hooks for us. At this point, we were deep into unsupported territory by Google, but supported by the OEM. These things change unexpectedly with minor OS updates from Google which make them brittle to maintain. An update to a newer OS would be a hell of a lot of work.
All that said, if we could have based off of 3.0 instead of 2.3, many of these issues would not exist because of some abstraction layers added just for this purpose. I expect 4.0 to make that even nicer.
For one thing, last I looked, Chrome Beta requires the GL_OES_egl_image extension for off-thread texture upload, and had support for the ICS-only SurfaceTexture (although judging by the WebKit source that's ifdef'd out). GL_OES_egl_image support is very spotty on pre-ICS devices.
You seem to expect different things than the GP (and me).
A browser without decent SNI support, with broken XPATH support and really various shortcomings was outdated when it came out - and neglected afterwards.
There's some revisionist history. When the iPhone was released, mobile apps were supposed to be HTML5 webapps. Developers cried for local apps. Apple responded to demand.
The truth is likely somewhere in between. Apple probably anticipated the demand for native apps. But they weren't ready, business-wise if not technically, to build the SDK and App Store in 2007, so they held off on it for a year.
Sometimes it's useful to pretend that what you were going to do all along was merely a concession to outside demand.
Steve Jobs said in the intro of the phone that the apps were "just the internet" or some such. Personally, when I heard that I just ignored the iPhone.
The steve jobs bio documents how he was deadset against native apps, even after the iphone was released. Even apple has to listen to its customers / developers every now and then. The myth that apple's moves are all part of a big plan is just that.
This is worth getting your head around just for the console.
<this post is partially for those of you who are, like me, relatively new to javascript. If you're one of the demigods that works at twitter/facebook, go ahead and ignore this>
I've been transitioning all of my projects from python cgi scripts (yuck), to shtml files, javascript clients, and APIs that run on node.js.
For somebody like me, that has been writing python+cgi for the last 5 years, diving into javascript was daunting. Terrifying even.
Console made this a lot, lot, lot easier. In javascript, you can call
console.log("thing")
and it will print it out to the console (again, this is obvious if you're done any JS development, I'm sure).
But that isn't all...
Suppose that I'm working with an object called map_pins. In the javascript console, I can just type:
map_pins;
and it will print out the object for me in a tree that I can traverse by clicking the little sideways triangles.
Very, very nice.
I can also interact with my javascript functions from the console. If I have a function called update_bounds(), I can force it to fire from the console by just typing:
update_bounds()
This is really, really nice. Before I discovered this, my javacsript was full of alert("I made it to this without crashing");
It was awful.
If you're learning JS and OP's article looks over your head, at least take the console away from it.
Also, don't forget the step through debugger. It's such a time saver to be able to set a couple of break points and then when they are hit you can hover your mouse over different variables and see a tool tip that shows the contents of that variable.
A great post for beginners. Also, beware of the fact that console.log() doesn't always print out the value of the object at the time it is logged; it can print out the value of the object at some time after the fact, leading you to believe there is a bug in your code when there is in fact none.
It's worth to note that this concept has a name - Read-Eval Print Loop, or REPL, and is present in several good languages. It changes the way people think about programming, making it much more interactive. If one didn't encounter this concept before, it's worth to take a look at it.
Thanks for the comment. Was there anything specific you could point me to that you felt was above your head? I'd love to do a follow-up with more introductory material.
"Modern Web Development" does not mean "Works in Webkit", and it does a disservice to future/novice developers to reinforce that notion. What's dominant now was not in the not-too-distant past, and may not be in the not-too-distant future.
You misunderstand. This was how modern web applications are written. I know very few people who write modern web apps but do not use Chrome for it. The reason is that Webkit has the best tools. Cross-browser independence isn't the point, since when I'm developing I'm using only one set of tools.
When Mozilla ships better developer tools than Chrome, I'm sure there will be posts just like this one. The fact that developers prefer Chrome is not a failing of developers; it's a failing of Mozilla to provide compelling tools.
I don't know much, but I don't understand Mozilla's effort to reimplement firebug natively. Right now their solution seems unusable and far beyond firebug.
Mozilla is just in an unfortunate situation, where Firebug's ground-breaking functionality was duplicated as a first-party feature of other browsers. So now as Chrome Inspector continues to add more and more deep functionality, Firebug is hampered both by being third party code and subsisting on Firefox's addon API.
I acknowledge WebKit's monopoly on the mobile landscape today, I make no claim whether it's a good thing or a bad thing, that argument would distract from the reality that if you want to make a mobile web app work well, you need to build it on webkit and debug it on webkit
I'm not sure if docking to the right is really the best default; it really depends on your setup. On big, wide displays it's indeed a good way to do it. On small displays (notebooks) docking on the bottom is better. If you have multiple displays, detaching and moving the detached window to the other display works best. I think it's a good idea to assume the worst (tiny display) and dock to the bottom; the browser will remember your setting anyway so it's not like you'll need to do this all the time.
How many netbooks have anything other than a 16:9 display (even the MB Air 11")? Vertical pixels are precious in landscape mode. Dock to the side is far more efficient with current reality of displays.
Let's put aside any frustration that 16x9 is even usable much less desirable for any office work.
I don't know, I definitely prefer scrolling vertically (in both panels) on my MBA 11" to horizontally scrolling every time I need to read a line in its entirety. 680px wide just isn't enough for the inspector. That said, 1366x768 is certainly not on optimal resolution for development, period!
I agree with this sentiment. There's a certain width in pixels you need before things start to degrade. Most sites are already designed for a vertical scrollbar and almost never for a horizontal one, so even if docking to the right is a better use of screen real estate, if you can't get a comfortable thousand horizontal pixels it's not worth it.
A mild concern of mine with the "Google, if you’re listening" annotations. It's worth remembering that Chromium's an open-source project. If you really want something, send a patch.
You actually bring up a good point, the webkit inspector right now is tied to the webkit project, and the barrier to contribution is prohibitively high. I've suggested to Paul Irish separating the two projects and making them more independent, though I'm not sure what the feasibility of that is.
I can either try to submit a patch and likely fail, or blog about it. Last time I complained to Google about Chrome, they filed 33 bugs and fixed many of them. The point here is to be an agent of change, not an agent of patches :)
Well, discussion is fine too and not every web developer is in a position to knock out some detailed C++.
But this is still a valid point in the sense that Chromium is run much more in the spirit of an open-source project than other large-scale commercial open source efforts. External patches do make their way into Chromium.
I'm probably not the only one, but I have no idea where the separation between Chromium and Chrome actually is. Can anyone enlighten me as to where the separation really is? Is Chrome a fork of Chromium, is Chromium an upstream? I know they actively work together in a lot of ways but how exactly?
Aside from the obvious - branding and stability - It's mainly the commercial stuff (MP3, PDF, Flash) which can't be distributed under Chromium's license.
It can be useful to engage open source projects of this size on other grounds - I can't speak for Chromium, but with many significant projects, a patch with some code is less than useful if there's been no discussion around it.
The custom scroll bar might look sorta cool, but it's completely unusable on Chrome. The scroll tracker disappears and it's basically impossible to find. I've ended up restarting at the top of the page just to be able to scroll properly.
Dunno if you've had that fix go live yet, but it's still unusable. The actual little scroll tracker (what's the name for that thing?) isn't discernible from the background. When you scroll up and down, the bar turns white and the cursor is white. I'd send a ss, but I don't see anyone else complaining so it's probably a me problem. Might be because I'm on Linux.
So the reason is because I have a black background color on body. When I said it's fixed, I just realized it's only fixed on Chrome Canary. It looks different on Chrome 18, and it looks different than that in Safari. Welcome to the Web. I'll try to fix it again after work.
Well, that's what you get when you hamstring yourself to developing in a daily build of your browser.
Don't get me wrong, I do the same thing, but you have to admit there is a certain dry humor in the fact that you recommended as a best practice to develop exclusively in a cutting edge build of a standards-based browser, only to find that your website is broken in every browser except your development one.
This is a really nice inventory of the latest Chrome Developer Tools. I also really like the recent Settings additions of "emulate touch events" and "Override device metrics" for mobile web development.
Wonderful, can't wait for part 2. One question: I don't seem to have the same file navigation for my javascript files as mentioned in this article. There is no "tabbed" browsing, nor an icon with two folders at right angles. Chrome is up to date.
I was just on the Chrome Dev hangout watching some of the latest mobile devtools features demo'd. These are also really neat - ability to set resolution, simulate user agent, simulate touch events, and dock devtools to the right (so you don't have problems with it becoming too narrow when making the browser thin).
Google Chrome Canary dev tools is definitely worth it despite the bugs you see more often when using Canary. It has been vastly improved over the last years.
I remember when Firebug was the standard tool for web debugging, now, chrome (specially canary) is the de facto standard for me.
One thing that I use often: when execution hits breakpoint, you can switch to the Console tab and modify local variables, and run any code in the context of the current function.
Also, files in the Scripts can be edited by double clicking.
One suggestion: Revise your list of browsers with inspectors to indicate what they are. The newcomer will look at that and think they need to download a tool called "Safari Stable".
It most likely should be something like "Safari (stable build)", and similar for the others.
Majd and I have talked a lot about tooling and the Chrome DevTools in particular. He ends up tweeting me a few requests or bugs a day that I'm routing to the engineering team. I love it.
Majd's writeup here is incredible. I hope to find a way to augment our existing documentation with this very thorough roundup. He's done a similar thing before ( http://jtaby.com/2011/05/31/google-chrome-why-i-hate-it-and-... ) and the Chrome team filed and fixed 33 bugs as a result. For the new article in particular, I expect us to iterate and improve based on the excellent feedback provided here.
I would add that CSS Selector Profiling is mostly in the DevTools so you can see how insignificant of a cost it is (in 99% of cases). But focusing on your network waterfall will pay performance dividends a few orders of magnitude bigger than optimizing selectors. :) That said, Majd knows what he's talking about quite well.