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?
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.
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.
On average I would say, this is because the average SO answer about some API call, is usually way better, than the average doc.
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.
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.
No, but something along that line. It is actually very hard, to do so in a consistent way, that is fun and useful.
Viewing it? No. You’re viewing the rendered source code when you load the page?
https://arstechnica.com/tech-policy/2021/10/missouri-gov-cal... is probably what was being referenced.
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?)
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.
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.
The mentioned vs code connection - and it seems, I cannot just edit edge dev tools with edge, something I can do in chrome.
There's also this guideline:
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
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.
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
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.
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.
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.
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?
In the JS console:
$0Very handy for quickly evaluating or operating on an element you're looking at :)
Also, $1 is the previously selected element, $2 is the one before that, etc.
I’m actively moving some projects I inherited from Promise APIs to async/await for this reason.
It preserves the call stack as soon as you use ‘await’ instead of ‘[promise].then’?
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.
monitorEvents(elt)
hugely helpful when debugging event-driven systems like htmx or hyperscript
It would be nice if this made live expressions or something instead of filling up the console.
$() 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
const add = (a, b) => (
a + b
);
const add = (a, b) => (
console.log('adding', { a, b }),
a + b
);
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
This will work in C too. The keyword here is the "comma operator": https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
That's pretty great
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.