Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web developer tool secrets that shouldn’t be secrets

christianheilmann.com

Post reply on HN
Print view View original

41–50 of 108 posts

Re: Web developer tool secrets that shouldn’t be secrets

#41

Post by MonaroVXR »

steve_adams_86 wrote: post #10
yepthatsreality wrote: post #3

Open secrets aka secrets for people who can’t RTFM. Good tips! I would argue that the IDE is the connector of the editing + debugging experience. Otherwise there’s a reason they’re disconnected.

You might be surprised how limited some otherwise very competent people's understanding of dev tools is. Console being such a primary example probably isn't an accident; tons of people don't know what it's capable of. I suspect people don't RTFM because frankly there are so many Ms to R. It's overwhelming at times. Many carpenters can get by without learning little tricks here and there while still being excellent ca…

What's up with carpenters? I see a lot of references to it.

Re: Web developer tool secrets that shouldn’t be secrets

#42

Post by nine_k »

dylan604 wrote: post #14
NAR8789 wrote: post #9

> 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 go…

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 stra…

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.

Re: Web developer tool secrets that shouldn’t be secrets

#43

Post by jakear »

amatecha wrote: post #36

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.

Re: Web developer tool secrets that shouldn’t be secrets

#45

Post by eyelidlessness »

Aeolun wrote: post #35
eyelidlessness wrote: post #23

Earlier quoted context omitted.

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’?

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.

Re: Web developer tool secrets that shouldn’t be secrets

#46

Post by steve_adams_86 »

MonaroVXR wrote: post #41
steve_adams_86 wrote: post #10

Earlier quoted context omitted.

You might be surprised how limited some otherwise very competent people's understanding of dev tools is. Console being such a primary example probably isn't an accident; tons of people don't know what it's capable of. I suspect people don't RTFM because frankly there are so many Ms to R. It's overwhelming at times. Many carpenters can get by without learning little tricks here and there while still being excellent ca…

What's up with carpenters? I see a lot of references to it.

I personally like to find parallels between trades and crafts to help connect my thoughts and experiences to the more abstract world of software. I started my life in carpentry and joinery so it seems to be where my mind finds it’s foundations when thinking in systems and patterns.

Re: Web developer tool secrets that shouldn’t be secrets

#47

Post by yial »

bondolo wrote: post #44

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

Re: Web developer tool secrets that shouldn’t be secrets

#48

Post by lowercased »

yial wrote: post #47
bondolo wrote: post #44

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.

Re: Web developer tool secrets that shouldn’t be secrets

#49

Post by Mikeb85 »

yial wrote: post #47
bondolo wrote: post #44

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

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

Re: Web developer tool secrets that shouldn’t be secrets

#50

Post by shp0ngle »

iudqnolq wrote: post #19

$() 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

Post reply on HN