Web developer tool secrets that shouldn’t be secrets | Hacker News Reader

Web developer tool secrets that shouldn’t be secrets

christianheilmann.com

428 pointstybulewicz104 comments

This is more of a "hacker" tip than something for web developers but "Show Page Source" will show you the full raw HTML for any page. Be careful where you use it though as it is illegal in some states.

I was fascinated, but I cannot find any sources that say viewing the source is illegal. Reusing it as your own, yes if not licensed for that.

Viewing it? No. You’re viewing the rendered source code when you load the page?

https://www.techdirt.com/articles/20071017/092927.shtml

I think it was meant as a joke reference to a recent news piece where a state agency website had raw personal data in the source code, and 'view source' would show sensitive data (teacher data - names, social security numbers, etc).

https://arstechnica.com/tech-policy/2021/10/missouri-gov-cal... is probably what was being referenced.

I live in Missouri, in the deep Red Ozark Mountains in the SW part of it and I shared an article on that on FB in a local group.

Our Governor really blew it on this one. Folks here will generally stand by their GOP Party and for the most part they never talk about Parson here but this really pissed them off.

I was surprised by the comments and the number of them. They are pissed about the incompetence of those who built the website and quite a bit more so that Parson would try to charge the journalist with a crime for finding it.

We're all just shaking our heads over that.

FYI the P in GOP already stands for Party.

I LOLd out loud when I saw it

lol... yeah that was a typo. I make those sometimes to see if anyone will notice.

Isn't it a little strange that these red-staters don't even know their own name?

The lowercase "party" in my mind removes the redundancy as a class description for the collection of all political parties rather than as part of an abbreviated name for the one in question.

Unlike the "P" which stands for Preproccessor, in PHP.

Edit: whoops, they are both capitalized. Too bad I wrote with an ink pen.

Joke but kinda real as some US state put sensitive info into HTML and is attempting to prosecute someone for finding it.

got to find revenue for prisons

Very annoyingly it doesn't show you the full HTML for the page you're viewing. It does a new HTTP request (I think without cookies at least in Firefox) and shows that. This means you need to use inspect element if you have dynamically generated HTML either from JS or non-idempotent server sides.

Annoyingly most browsers do this. One of the first things we implemented in Orion browser was to use the source you already have.

Yes officer this comment right here!

Aiding and abetting.

What, is that a major thing?

Constructive possession.

"Overrides allow you to store local copies of remote scripts and override them when the page loads. This is great if you have, for example, a slow build process for your whole application and you want to try something out. It is also a great tool to replace annoying scripts from third party web sites without having to use a browser extension."

Overrides are useful not just for "developers". Why is this option hidden away in "Developer Tools".

The biggest "secret" not mentioned here is keyboard navigation. It is incredibly cumbersome to operate "Developer Tools" on a small form factor computer without a mouse.

Here is one solution: In Chrome's, F12 to open Developer Tools, then Ctrl-P then type ">".

Then can scroll all available commands using Up/Down or start typing and use autocomplete to search for commands. Whether this is faster and more effective than pointing+clicking/tapping on tiny screen areas, ticking/unticking tiny check boxes and scrolling around in tiny menus is a question for the reader. Talk amongst yourselves.

For example, to navigate to Overrides, the key sequence is F12,Ctrl-P,">","des",Enter

Author here.

This all applies to Edge, too. I am also a huge keyboard fan and user and the command menu is incredibly useful. As to bringing Overrides to the main browser interface and not only to developer tools, I'd love to do some more research on that. We are not seeing much use of overrides at all and they are a pretty niche use case. That said, I see far too many people and companies resorting to browser extensions where a snippet or override could do the trick. I guess one of the issues is that they are limited to the user/machine right now and you can't share them in a team.

That said, we have some ideas in the making to bring command menu functionality to the browser URL bar. We'll see how this goes down with non-developer end users. As a interesting fact , which I did mention in the talk, we had a real issue with people accidently hitting F12 and getting developer tools without wanting them and we're still getting daily feedback that people are utterly confused as to what happens to their browser when they open.

"As to bringing the Overrides to the main browser interface and not only to developer tools, I'd love to do some more research on that."

To a curious user who is not a "developer", "Developer Tools" is just more browser options. What tech companies want to everyone to forget is that any person who has no interest in working as a "developer" for a "tech" company can use the exact same software including all of its features as so-called "developers". Whether they choose to do that is their business and their choice, not the tech company's. I know this topic has come up before on HN, many years ago, that using names like "Developer Tools" just drives people away who are not interested in being labeled "developers". Even "Web Development Tools" would be better.

Chromebooks, where the browser is supposed to be seen as the OS (even though it isn't), are another example. There is an artificial classification of people into the categories "user" or "developer" (no such thing as "power users" or anyone who would care to understand how the computer works but not care to invade people's privacy for money). "Developer mode"? Seriously? Making a computer with storage space deliberately scant enough that the buyer is compelled to use "cloud storage", so the tech company can collect more data. Meanwhile "smartphones", a much smaller form factor, sold by the same company have over 10x the storage. Shameful and manipulative.

By operating under the artificial distinction of "developer" vs. "user", then all the stuff that users really should know about, but that the tech company hopes they won't know about, can be communicated under the assumption that the only people who would read it are "developers". Thus, zero effort needs to be made to try to tell "users" how this stuff really works. This arguably makes for more naive, carefree users and makes it easier for the tech company to collect data and serve advertising. And we know that is not what "users" prefer.

"That said, I have seen far too many people and companies resorting to browser extensions where a snippet or override would do the trick."

Right. Extensions, unless self-authored, usually require surrendering control to third parties. Tech companies like that. It is common on HN to see some extension author telling us how many inquiries they get from people looking to (secretly) buy their extensions as a means to get access to access to (unknowing) users. Using extensions, it is less likely that a user will learn anything whereas they would definitely learn from writing snippets and editing their own copies of others' scripts to use as overrides.

Eh, you can't reconcile 'nobody reads all that text on dialog boxes' with 'using names like "Developer Tools" just drives people away who are not interested in being labeled "developers"'. I seriously doubt people care all that much about what menu labels say, as long as they are roughly descriptive. What next, making some menu items pink because women are shown to be less likely to press on them? This way lays madness.

You have a good point about not needing to explain how all that stuff works, because developers are expected to seek out and read documentation and tutorials.

Making tools more accessible in that sense necessarily makes them less powerful, and there is too much dumbing down going on as it is...

Is it possible by now, to assign custom shortcuts in chrome or edge dev tools? Then you could be even faster for your regular commands with keyboard navigation.

It was discussed endlessly in chrome and I stopped following.

I ended up tweaking dev tools by hand (you can just open dev tools for chrome dev tools) - but stopped doing so, because of breaking update changes.

Author here: Yes it is in Edge DevTools, you can read up on how to here: https://docs.microsoft.com/en-us/microsoft-edge/devtools-gui...

I very much would advise against hacking the tools yourself, for the reasons you stated, but isn't it awesome that you even can do that?

Ctrl-Shift-P brings the command palette up without the ">".

Here's a really obscure one which I've never heard anyone mention, except the first time I heard about it:

In the JS console:

$0

is a reference to the currently-highlighted element in the DOM Inspector (at least this is the case in Firefox, Chrome and Edge, haven't tried others).

Very handy for quickly evaluating or operating on an element you're looking at :)

You'll see that in the Elements panel, it actually puts a grey " == $0" after the selected element to point you towards this feature.

Also, $1 is the previously selected element, $2 is the one before that, etc.

Author here. There are even more. $0 is only the current one, but you also have $1 to $4 as a history of the last ones/ I like that $_ is a reference to the last result of what you did in the console. I documented most here: https://docs.microsoft.com/en-us/microsoft-edge/devtools-gui...

Nice, that's great to know! Thanks for capturing them on that page. BTW I've followed you on Twitter for years. Always lots of neat tips and interesting topics -- thanks for that! :)

In a similar vein you can right click on any logged value that's pretty printed in color and save it to a global variable to play around with. (console.log("foo", foo) works with this, console.log("foo"+foo) doesn't)

If you’re using React the same applies in the dev tools component tree - $r is the currently highlighted component.

not mentioned in the article, but my favorite console trick is

  monitorEvents(elt)

https://twitter.com/htmx_org/status/1455242575363723265

hugely helpful when debugging event-driven systems like htmx or hyperscript

And unmonitorEvents(elt) to turn it off again. Monitoring every event is pretty noisy, so you can choose what to monitor with a second parameter: https://briangrinstead.com/blog/chrome-developer-tools-monit...

It would be nice if this made live expressions or something instead of filling up the console.

$() and $$() are handy but very annoyingly the first is overridden by any website that installs jQuery globally. IIRC in chrome you then use x$()? I always have to look it up.

Yes this is what I wanted to add.

$() is obviously inspired by jquery itself, but it has a slightly different semantics than jquery, so ironically jquery can override it.

I am not sure what x$ is.

However, what was not in the article, you can also you $x("/something") for xpath. That can be useful, because for some queries, xpath is easier than CSS selectors, and it is actually far more powerful (except that nobody really knows xpath nowadays).

The $x thing is actually script around `document.evaluate(xpath, document.evaluate, null, XPathResult.ANY_TYPE, null)`, but good luck remembering how to use that stuff... I can never write doc.evaluate on the first try

Not specific to developer tools, but definitely handy for using console.log etc: in JS, an expression can be any comma-separated set of expressions. Every sub-expression is evaluated, the last sub-expression’s value produces the value of the full expression. So for example:

    const add = (a, b) => (
      a + b
    );

produces the same return value as:

    const add = (a, b) => (
      console.log('adding', { a, b }),
      a + b
    );

The log call will be evaluated, producing the desired side effect, its return value (`undefined`) is ignored, and otherwise add behaves the same as before.

This can save 100s of paper cuts where you might otherwise rewrite a function or some other expression into a block of statements—in the arrow function case requiring curly braces and a return statement.

Caveats:

- sometimes you need to wrap the expression in parentheses to avoid syntax errors

- it does not work with debugger statements, which have no expression equivalent

> in JS, an expression can be any comma-separated set of expressions. Every sub-expression is evaluated, the last sub-expression’s value produces the value of the full expression.

This will work in C too. The keyword here is the "comma operator": https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

console.trace() looks nice, except it doesn't work for async functions (i.e., functions that call each other through an event loop), which is how many function calls happen to be coded in practice.

It doesn’t work for callback-based async (including native Promises, but some libraries like Bluebird can help). But it does work for suspending async functions (native async/await, generators)! This also applies to Error#stack and debugger call stacks.

I’m actively moving some projects I inherited from Promise APIs to async/await for this reason.

What is the difference between promises and native async/await? From the perspective of coding them they seem to be exactly the same.

It preserves the call stack as soon as you use ‘await’ instead of ‘[promise].then’?

Native async/await functions use generator functions under the hood, which are an implementation of coroutines. Like all fully-fledged coroutine implementations, generators can suspend execution while preserving the stack by yielding control (hence the `yield` keyword). This requires interpreter (e.g. V8) support.

Desuguared Promise.then can't suspend the stack like that as a normal JS thread must run to completion and cannot yield to the scheduler; instead every call to `.then` pushes the new closure onto the event/microtask queue.

The difference is that an async function suspends on await, and continues to be active in the call stack until it returns. It doesn’t preserve the stack so much as continues to be on the stack. A Promise-returning function returns the Promise value synchronously and then/catch/etc continue from a new stack where they’re resolved.

it'd be nice if there's an async-trace feature, where you get a (ascii?) visualization of the graph of async calls, if given a promise.

It'd have to be able to reach deep into the core of the vm to find out where the promise was created (which might be lost if that info wasn't recorded i suppose), so may not be possible.

> Many things heralded as the best thing since sliced bread in presentations and video tutorials are hardly every opened, let alone used.

This reminds me of something I heard once... that the first half of Portal (the video game) is basically a giant playable tutorial, and that a lot of video games start off with a tutorial disguised as gameplay, and that this is actually pretty pleasant.

The world's gotten pretty good at crafting tutorials disguised as gameplay. Could we do this with dev tools? Has anyone tried to make "VSCode: the game"?

Maybe "tip of the day" popups could be restructured as minigames?

Possible hurdles I can think of off the top of my head:

- a fancy tutorial probably runs into exactly what the author mentions on the next few lines: that adding more documentation doesn't fix things, because most people don't go to the documentation.

- In a game it's very easy to tune the tutorial to what you'll later encounter. A dev tool tutorial... every dev's needs are different. I imagine you'd have to structure it as a tutorial for "core functionality", plus separate tutorials for each extension.

- In the game context, I'm expecting to do certain actions repetitively. This has the side-effect of refining those skills. In a dev context, repetition is often considered a smell (though, I'd argue even in dev work we pick up a lot of little katas without thinking about it).

- Harping on repetition some more... what about the debugging tools that I only need to use once in a blue moon?

Games as teaching tools is definitely an interesting topic.

You might get a kick out of https://vim-adventures.com/ or https://cssgridgarden.com/ or http://www.flexboxdefense.com/

These are just off the top of my head - would love to see other examples.

https://deadlockempire.github.io/ is a good example, focused on multithreading.

Has anyone ever written a set of documentation solely by asking questions on StackExchange? I mean make an outline of exactly how you would do written docs, but pose each one of the sections in the outline as questions. You could have another user designed to be an expert for this app answer the questions.

I'm not trying to game SO for points. I'm trying to head off the fact that nobody reads docs, but will head straight to a web search.

"I'm trying to head off the fact that nobody reads docs, but will head straight to a web search. "

On average I would say, this is because the average SO answer about some API call, is usually way better, than the average doc.

> I'm trying to head off the fact that nobody reads docs, but will head straight to a web search.

Is that why everyone loves SO? I've found it so hard to get questions answered on there. Most answers I find are just regurgitations of documentation, which is just annoying when you are asking about an obscure edge case.

I can't speak for everyone, but...sometimes it's easier to ask a question in a search bar than heading off to the docs and navigating their menus in order to find where in the docs you need to be looking. Maybe SO links come up first, maybe the actual docs do. However, with the back-n-forth exchanges, it is sometimes easier to grok an SO link than dryly written docs. The first example jumping to mind is AWS related questions.

The search bar is more convenient, and sometimes the docs are hard to find. That said, I find a lot of docs are quite easy to read, and often have to take the second step of omitting SO or otherwise restricting the search to docs and kicking myself.

Some documentation is wonderful. I try to use documentation quality as an important consideration when choosing software.

The AWS docs have big issues, but they are similar to the big issues with SO - it's so easy to find old documentation. Also, they are horribly organized.

The web search should ideally show the relevant section of the docs as the first hit.

Actually, it often does for me.

Good search is hard, and adding search to your docs, especially with some fuzziness like synonyms and common typos, is not trivial, unless you defer it to web search.

"Has anyone tried to make "VSCode: the game"?"

No, but something along that line. It is actually very hard, to do so in a consistent way, that is fun and useful.

I learned vim back in college using this: https://vim-adventures.com

https://developer.chrome.com/docs/devtools/console/utilities...

That's pretty great

That is a terrific link, thank you!

Is there any way to "narrow" the Elements tab to displaying only a portion of the HTML? For instance to narrow to the "div#content" element such that said element appears as the root of the Elements tab, decluttering the view from the parts of the page irrelevant to what one is working on.

I've been looking for something like this for ages, clicked on the link with enthusiasm thinking it would be a general guide. Whilst the article is I retesting I'm still looking for that cross browser article.

Great article. I might be a bit late to the scene, but to add to the first section, there are also `console.time`, `console.timeLog`, and `console.timeEnd`. Very handy!

Here’s one: in chrome dev tools, hidden behind two menu clicks, you can enable additional tabs including “media”. This is, afaik, the only way to get error messages from video decoding

So this is basically a technical PR blog post promoting Windows Edge?

Never used it, but it looks pretty much like chrome dev tools, which might be, because they just copied it, when they forked chrome/webkit?

Well, why not copy what works, but is there anything edge dev tools are now doing better than chrome?

(there seems to be a connection possible to VS code, is that useful?)

Author here.

No, this isn't "a technical PR blog post promoting Windows Edge". It is, as explained in the first sentence, a write-up of a presentation I've given at an event. It is on my personal blog that I've maintained since 2006 and very much my own message.

> This is a talk that I’ve given at CityJS this September. I am a principal product manager for developer tools in Microsoft Edge and these are things I encountered during working on the tools, documenting them and going through user feedback.

Microsoft Edge is a browser based on Chromium and we joined the project quite some time ago, fixing hundreds of bugs, making the developer tools themeable, localisable and accessible to assistive technology. All of these changes have been submitted back to the Chromium core, so that Chrome, Brave and all the other browsers based on the same open source project also benefited from that. We work closely with the Chrome team and share a lot of ideas and plans for the future of the Chromium platform.

We differentiate in the UX of the developer tools, much like all Chromium based browsers differentiate in the interface for the end user.

I spent about 10 hours on the presentation and this morning about 3 hours turning the slides into this blog post. If my goal were to promote Edge, I could have done a much simpler, shorter and to the point post.

If you read the article, you might realise the things we're adding exclusively to the Edge devtools based on user feedback and demands, the focus mode and in-context explanations being one of the efforts, and the deep integration with VS code being another one.

As to whether these things are useful, I think I pretty clearly explained that this is exactly what we'd like people to tell us. Which is why there are several ways to contact the team and provide feedback.

"No, this isn't "a technical PR blog post promoting Windows Edge". It is, as explained in the first sentence, a write-up of a presentation I've given at an event. It is on my personal blog that I've maintained since 2006 and very much my own message."

I am pretty sure, private blog posts promoting your day jobs work, are beneficial to your career as well (and I can imagine it is encuraged). And the language used, "We are open to your feedback and many of the recent changes to the tools are direct results from demands from outside developers" sounds definitely official.

"I spent about 10 hours on the presentation and this morning about 3 hours turning the slides into this blog post. If my goal were to promote Edge, I could have done a much simpler, shorter and to the point post."

And I don't think so, because many people still have a bias against edge, who would have just skipped reading it, if it would be plainly stated, edge only. So burying the promotion inside some general useful tips, combined with what awesome plans you might have for edge dev tools - worked apparently quite well for promotion, but not for clarity.

Basically, what I am missing, was a paragraph like this:

"Microsoft Edge is a browser based on Chromium and we joined the project quite some time ago, fixing hundreds of bugs, making the developer tools themeable, localisable and accessible to assistive technology. All of these changes have been submitted back to the Chromium core, so that Chrome, Brave and all the other browsers based on the same open source project also benefited from that. We work closely with the Chrome team and share a lot of ideas and plans for the future of the Chromium platform."

And more importantly: to differentiate what of your "secrets" work everywhere. And what works only with edge. A normal technical blog post would have covered this, as they are usually neutral.

You are not neutral (and you do not have to be), but just tell me, why edge is superior and what does it do better. But maybe do so clearly.

"If you read the article, you might realise the things we're adding exclusively to the Edge devtools based on user feedback and demands, the focus mode and in-context explanations being one of the efforts, and the deep integration with VS code being another one."

So I did read most of the article, but this is my criticism. Finding out what of your features were edge only, was very hard - as it was not plainly stated. And if you read the comments here, that kind of confirms it. Lots of confusion and general web dev tips mixed with edge only stuff. That limits its usefulness.

I updated the article with a preamble and flagged up on each heading which browser supports what.

Thank you. That adds a lot of value in my opinion.

They didn't "copy" the Chromium dev tools, they are the Chromium dev tools. Edge is a Chromium browser, after all.

Well, they do not really advertise that fact and the codebase is not exactly the same, it seems.

The mentioned vs code connection - and it seems, I cannot just edit edge dev tools with edge, something I can do in chrome.

I am curious why you can edit Edge dev tools with Edge. There is literally a part of the article where I show that this is possible with a screenshot showing it on my Mac.

"I cannot just edit edge dev tools with edge,"

I could not "just" edit it like I am used to from chrome - but apparently had to activate a experimental setting. Which you did explain in a video. Not text. I read text.

I still want to understand the issue. The Sources tool is the same in Chrome and in Edge. And if you undock the devtools and you press CMD+Shift+I (or CTRL+I) on either Chrome or Edge you get a second DevTools instance to debug the first one. If you use a workspace, you edit files externally in either Edge or Chrome as they are the same thing. There is no difference in either of these use cases. What use case are you finding where it is different? I'm really confused.

"And if you undock the devtools and you press CMD+Shift+I (or CTRL+I) on either Chrome or Edge you get a second DevTools instance to debug the first one. "

Not for me on a vanilla edge instance. Pressing Ctrl + Shift + I closes the dev tools completly, no matter where the focus is. (on Win 10, german localisation, Edge 95.0.1020.40)

But it works like you describe (and how I know it) on a vanilla chrome dev instance.

So is there maybe some hidden setting, one needs to activate first?

Isn't the point of this article to highlight specific tools? A lot of technical PR blog posts do well on HN. Not as many as technical PR blog people wish they would, but still - if the post contains interesting information, that's what matters. Here's a past explanation about this, in case it's helpful: https://news.ycombinator.com/item?id=20186280, which was an answer to https://news.ycombinator.com/item?id=20186246 ("Is it acceptable to have unmarked advertisements on HN?").

There's also this guideline:

"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."

https://news.ycombinator.com/newsguidelines.html

In general I do enjoy technical PR blog posts and also in this one I found interesting bits.

What disturbed me was, that the title said "web developer tools secrets", while in the text it is specifically microsoft edges web developer tools.

This style of language I do not like so much. There is too much agenda in it, in my taste. As this seem to imply, there are only one web dev tools - the ones that comes bundled with your windows OS. (Microsoft does have a history)

Now it seems, the edge dev tools are allmost identical to chrome dev tools, so I might have assumed more ill intent, than what was actually there, as most web devs use one or the other.

But it is still not clear to me, what of the posts information apply only to edge for example. What to chrome. And what would also work in firefox. All of them have web dev tools.

As far as my understanding goes (which may not be very far at all), the common base seems to be Chromium. When I want to debug an HTML source (like the one in the article), VSCodium offers me Chrome or Edge as the base browser (none of which I have installed). I wonder why Brave isn't in there, since it's also Chromium-based.

Oh, I think I understand now. You mean when you use the debugger in Visual Studio Code the target browser dropdown only shows Edge or Chrome and not Brave?

That is weird and I wonder if it has something to do that brave hasn't got the CDP methods turned on that allows other software to remotely control it.

In essence, the debugger spawns a new instance of the browser and controls it remotely from VS Code, much like automated test tools do. It would be interesting to hear from Brave if there is interest in showing up there, too.

Yes, that's what I meant. And thank you for the explanation.

Author here: The first sentence explains this.

This isn't a "Here is what browser developer tools in each browser are like".

If you look for news on each of them, check out the post of my colleague Patrick, which does an awesome job covering news in all of them:

https://www.smashingmagazine.com/2021/09/devtools-cross-brow...

Oops, seems my last sentence was badly worded. With “in there” I meant the set of browsers offered by VSCodium, not your article. Your article is fine and informative, except that the title makes it seem more general than it actually is.

The first section ("Console is much more than `log()`!") applies to Firefox and Safari as well.

Reply on news.ycombinator.com