
Hacking Mountain Lion: Bringing the old Web Inspector back - bound008
http://thomasst.ch/webinspector/
======
tambourine_man
You can't create new style rules with the new inspector.

It's also buggy and skow to the point of being unusable.

Who ever thought that was ready for release must be out of his mind.

Also, if you chose "use webkit inspector" you're no longer able to view
source.

I'm left with no alternative. Chrome is hideous on OS X and I hate that
omnibar that Safari now shares. I'm using Safari for browsing and chrome for
developing but it's a terrible experience.

~~~
DeepDuh
May I ask what's so bad about Chrome on OSX?

~~~
gurkendoktor
Answering because I also think it's hideous: the tool bar style and color are
different from the rest of the OS. The new icon is way flatter than anything
else in the dock (save the new Messages icon, maybe; see [1]). Even though I
found a nice-looking skin on my one Mac, there doesn't seem to be any way to
find out the theme's name and install it on my other Mac. The right-click menu
is different than in all other web views on the system (at least in the German
localization). The built-in dictionary lookup support (what is triple tap
nowadays) is getting there, but still worse than Safari in my experience.

[1] <http://maururu.net/2011/old-chrome-icons/>

~~~
tambourine_man
Yes, that's mostly it. Ugly toolbar and address bar, can't use built-in
dictionary, slightly worse text rendering, etc.

Oh yes, and if you want to grab the window, you have exactly 11px for that.
Try it after lot's of coffee.

I find Chrome beautiful on Windows. In full screen, it's a natural fit, one of
the best Windows apps. But on the Mac, it annoys me and hurts my eyes.

And I know it's old fashion, but if you are among the 0.5% of the population
that can actually distinguish a URL from a search query, you are out of luck.

PS: if you do find out the theme's name please post it here, thanks.

~~~
nnnnni
The thing that I hate about these "omnibars" is that I _used_ to be able to
type a URL into the search box and get information about it directly _without
going there_. It now takes two steps (google.com, enter URL).

~~~
graeme
I type something like "amazon.com q" then quickly erase the q and let instant
search change the results.

I just now realized that I _should_ be typing "!g amazon.com", because I have
duckduckgoog installed. (google search with DDG shortcodes)

------
bdash
By replacing your system frameworks with those from a WebKit nightly you're
going to see trouble with OS X software updates, system-wide instability due
to running bleeding-edge code, and a test environment which isn't
representative of what your users will see.

If for some reason you need to use the frameworks from a WebKit nightly with
your application, use DYLD_FRAMEWORK_PATH to point your app at the WebKit
nightly's frameworks. This has the same benefit without any of the downsides
mentioned above.

------
owyn
The new inspector is totally unusable. It doesn't seem to solve any of the
normal workflows that you run into doing front end dev work. Like inspecting
source, looking at the console, looking at network traffic, request/response
headers and contents, etc. The console lags unbearably. Even printing an
object, it gives you a nice view of the contents but opening it might take 10
seconds. The list goes on. Fortunately I don't have to debug much js at the
moment but I switch to Chrome when I need to. Very glad to be able to switch
back now with just WebKit because I do prefer it as a browser.

------
JacksonGariety
A couple reasons not to do this:

1\. Your frameworks are out of sync with the the rest of the system, could
cause problems updating.

2\. You're now running super-buggy development WebKit. The code you're using
was written a few hours ago, remember that.

3\. The old WebKit inspector doesn't have retina support. If you've got a rMBP
and care about how it looks, don't do this.

4\. The article gives no information on how to go "back" after you've done it.

~~~
jarek-foksa
It's developement version, but I wouldn't call it super-buggy. WebKit project
has strict development process, each commit is rigourously reviewed and tested
before merging.

You will likely run into problems if you enable experimental flags though.

~~~
bdash
While the WebKit project has a strict review process and a substantial amount
of regression testing, code reviews can't catch all issues and WebKit doesn't
have complete test coverage for all aspects of web technology. Changes can,
and often do, introduces regressions from subtle rendering errors to all-out
crashes.

These sorts of temporary issues aren't that a big deal if it's in a separate
application that you use only for testing, but they're a darn sight more
painful when you replace your system WebKit frameworks and they start
impacting things like your email client or the system installer stack.

------
anemitz
Repost of <http://news.ycombinator.com/item?id=4440198>

I didn't think reposts were possible?

~~~
anemitz
downvote, really?

------
jarek-foksa
Replacing WebKit, WebCore and JavaScriptCore frameworks is a bit risky because
many system components depend on them. I would replace only inspector files
(mostly JavaScript) instead as described in <https://gist.github.com/3898054>

------
philfreo
I love how you can't even see POST data in the new inspector

------
danso
Wow, I had no idea the Safari Inspector was so bad. Because I've stopped using
Safari at all..it's performance even on my brand new MBP is atrocious...maybe
it's because of how the loading bar painfully crawls across the browser,
accentuating the load times. Or maybe it's just the crashing.

I'm glad I didn't try the inspector...it would've driven me crazy but I
wouldn't have guessed that they just killed the inspector

------
89a
Want the old Activity Viewer back so much

