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'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 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…
"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.
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.
> 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…
> 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.
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.
In this case TFM is partly composed of >=1 blogs from >1 browser vendors in addition to properties associated with the underlying browser engine which most people don’t directly use or reference by name. No one has actually written T FM.
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
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…
> 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.
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?)
They didn't "copy" the Chromium dev tools, they are the Chromium dev tools. Edge is a Chromium browser, after all.
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.
You should read the manual for the language features and debugging tools you use most. Don’t assume you know everything about Console.log because you use it all the time one way.