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

61–70 of 108 posts

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

#61

Post by yepthatsreality »

dylan604 wrote: post #34
yepthatsreality wrote: post #30

Earlier quoted context omitted.

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.

Thanks for answering with an ambiguous answer. Of course I don't know everything about anything. That's why search engines were invented. I mean, even O'Reily doesn't know everything else there wouldn't be other authors! So, which manual am I reading for learning everything there is possible to know about Console.log that will mean I never have to turn to a search engine again (with console related questions)?

Yikes

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

#62

Post by 1vuio0pswjnm7 »

chriscodepo8 wrote: post #60
1vuio0pswjnm7 wrote: post #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…

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

"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.

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

#64

Post by eyelidlessness »

chriscodepo8 wrote: post #59
eyelidlessness wrote: post #25

Earlier quoted context omitted.

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.

Author here. We'd love to know what we can do better. What are you missing at https://docs.microsoft.com/en-us/microsoft-edge/devtools-gui... ? We lately spent a lot of time re-organising the documentation to cover different use cases, like people wanting introductions or in-depth details getting different starting points. The documenation is even available on GitHub to post issues and ask for features: https://githu…

I feel bad if my comment came off overly critical. I did see the Edge dev tools docs and they’re substantially better and more thorough than what I’d seen before. I want to recognize that.

I’d need to spend more time looking through the docs to be specific, but the place my comment came from was seeing both Edge and Chrome dev tools docs with a lot deferred but not cross referenced to Chromium, and both having more depth in their respective blogs than dedicated docs.

Admittedly I became accustomed to referencing the various blogs rather than docs, because that’s where I’ve learned the most about the dev tools across the ecosystem.

I’ll definitely spend more time with the mainline docs and give feedback where I think there’s room to improve. Thank you

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

#66

Post by ano88888 »

Mikeb85 wrote: post #49
yial wrote: post #47

Earlier quoted context omitted.

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.

got to find revenue for prisons

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

#67

Post by dotancohen »

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.

Carpentry is an ancient profession, and still respected to this day. Though modern carpentry is a complex profession akin to engineering, it is colloquially viewed as simple enough for laymen to understand its concepts and tools.

Additionally, carpentry as a hobby is relatively popular both for its practicality and its relatively low bar of entry, with much room to develop and expand.

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

#68

Post by dotancohen »

dylan604 wrote: post #34
yepthatsreality wrote: post #30

Earlier quoted context omitted.

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.

Thanks for answering with an ambiguous answer. Of course I don't know everything about anything. That's why search engines were invented. I mean, even O'Reily doesn't know everything else there wouldn't be other authors! So, which manual am I reading for learning everything there is possible to know about Console.log that will mean I never have to turn to a search engine again (with console related questions)?

  > which manual am I reading for learning everything there is possible to know about Console.log that
  > will mean I never have to turn to a search engine again (with console related questions)?
https://chromium.googlesource.com/devtools/devtools-frontend...

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

#69

Post by wruza »

dylan604 wrote: post #18
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.

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.

Exploratory clicking on MDN can help. For the language itself, a recent official ES paper. When learning yet another programming language seriously, I’m usually skimming through the standard library symbols to see the spirit of it, because stdlib/lang creators usually know both design and rationale. I also clicked through all of the tabs in a developer console in my browser to see what’s useful there. I doesn’t take up much time, and is much more complete. Personally I’ve never understood the value of these blog posts, because their appearance on your horizon is erratic and unpredictable unlike documentation and exploration, e.g. this article brought nothing new to me despite I’m only 2-3 years into javascript/web (out of much longer swdev career which taught me to educate actively), but ymmw.

My absolutely respectful but straightforward advice is: stop relying on blog posts, just go and click where you didn’t. It’s not a secret sacral knowledge, it’s you being anxious of unknowns of your development tool and of scary docs which are actually your friends.

Post reply on HN