Live data from Hacker News

Web developer tool secrets that shouldn’t be secrets

christianheilmann.com

11–20 of 108 posts

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

#11
"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

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

#12

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…

Perhaps true. I would extend this to say that RTFM by attaining drips through blog posts that summarizes the M would lead to good competent developers over time, but this exclusive approach would create knowledge gaps (or “secrets”) that would make them excellent developers if they had RTFM otherwise.

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

#13
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 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.

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

#14
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 straight to a web search.

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

#16
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…

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.

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

#17
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…

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

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

#18

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.

I want to learn all there is to know about JS. Which/what manual should RTFM? Should I read it front to back completely before attempting to write my first bit of code? Before writing any php, should I read every single word written on php.net?

Docs for programming languages are not written like a book to be read starting with the first page through to the last. Kind of like the bible.

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

#20
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

Post reply on HN