4 ms·

Entertaining flag name! React team seems to really have set a precedent with their "dangerouslySetInnerHTML" idea. Or did they borrow it somewhere? I'm just

Entertaining flag name! React team seems to really have set a precedent with their "dangerouslySetInnerHTML" idea. Or did they borrow it somewhere? I'm just curious about that etymology, of course the idea is not universally helpful: for example, for dd CLI parameters, it would only make a mess. But when there's a flag/option that really requires you to be vigilant and undesired the input and output and all edge cases, calling it "dangerous" is quite a feat!

wrxd 5mo ago
I’m pretty sure this comes from Claude code’s --dangerously-skip-permissions
- saulpw 5mo ago
  which sounds like it came from React's "dangerouslySetInnerHTML", per the comment you replied to.
  - brabel 5mo ago
    I think people used similar prefixes for a long time. For example, Haskell has had `unsafePerformIO` since the 90's... and MSFT's Hungarian notation was also similar, though it used abbreviations for things like "unsafe" (not "dangerous"). Perhaps React was the most famous case of using "dangerously" though.
    - culi 5mo ago
      "unsafe" seems quite different from the "dangerously [...]" phrasal template. I don't think it's a stretch to suppose it was inspired by React. Still waiting for this one to catch on: React.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED https://github.com/reactjs/react.dev/issues/3896 https://github.com/reactjs/react.dev/issues/3896
      - urbandw311er 5mo ago
        This is sometimes exposed in front end browser code and I had an actual (non technical) end user email our support team last month asking if it was something they should be concerned about! God knows how they found it, I suspect everyone is now an AI-enabled expert at these things…
        culi 5mo ago
        Oh I've stumbled upon it myself while coding. You can ctrl/cmd-click into any React type and it will take you to its explicit source definition. I'm not sure if it's still the case but they used to have all of the types organized into a single file. Since I was the go-to TypeScript person at one job I had I made sure to familiarize myself with every type (less than you'd expect)
        moritzwarhier 5mo ago
        The point of that scary flag name was the stance that source maps should never be deployed in production. There are stances that say they should, browse a large SPA with complex working source maps enabled, DevTools open, cache disabled and a long session (relevant because of HMR in dev), and you can see why this matters. Browsers only fetch and process source maps in a development environment in production, that's why this flag name exists. That being said, I still have a hobby project with an (in my opinion) sensible (at the time) Webpack configuration, and glossed over this being in the minified bundle, after 1-2 days at the time. But if my hobby project would have been something production-relevant, I'd have continued to hunt down this artifact. I think, with Vite et al this should not appear anymore in current JS bundles ready for prod, so the name is apt. But the underlying problem is still a neverending source of frustration: minification is (by definition, when it's statically verifiable), not equipped to change object property names without provoking breakage.
        culi 5mo ago
        I don't think it ever appeared in JS bundles. I'm just saying it's available to any dev in their IDEs with a simple ctrl+click

wrxd 5mo ago

I’m pretty sure this comes from Claude code’s --dangerously-skip-permissions

saulpw 5mo ago
which sounds like it came from React's "dangerouslySetInnerHTML", per the comment you replied to.
- brabel 5mo ago
  I think people used similar prefixes for a long time. For example, Haskell has had `unsafePerformIO` since the 90's... and MSFT's Hungarian notation was also similar, though it used abbreviations for things like "unsafe" (not "dangerous"). Perhaps React was the most famous case of using "dangerously" though.
  - culi 5mo ago
    "unsafe" seems quite different from the "dangerously [...]" phrasal template. I don't think it's a stretch to suppose it was inspired by React. Still waiting for this one to catch on: React.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED https://github.com/reactjs/react.dev/issues/3896 https://github.com/reactjs/react.dev/issues/3896
    - urbandw311er 5mo ago
      This is sometimes exposed in front end browser code and I had an actual (non technical) end user email our support team last month asking if it was something they should be concerned about! God knows how they found it, I suspect everyone is now an AI-enabled expert at these things…
      - culi 5mo ago
        Oh I've stumbled upon it myself while coding. You can ctrl/cmd-click into any React type and it will take you to its explicit source definition. I'm not sure if it's still the case but they used to have all of the types organized into a single file. Since I was the go-to TypeScript person at one job I had I made sure to familiarize myself with every type (less than you'd expect)
        moritzwarhier 5mo ago
        The point of that scary flag name was the stance that source maps should never be deployed in production. There are stances that say they should, browse a large SPA with complex working source maps enabled, DevTools open, cache disabled and a long session (relevant because of HMR in dev), and you can see why this matters. Browsers only fetch and process source maps in a development environment in production, that's why this flag name exists. That being said, I still have a hobby project with an (in my opinion) sensible (at the time) Webpack configuration, and glossed over this being in the minified bundle, after 1-2 days at the time. But if my hobby project would have been something production-relevant, I'd have continued to hunt down this artifact. I think, with Vite et al this should not appear anymore in current JS bundles ready for prod, so the name is apt. But the underlying problem is still a neverending source of frustration: minification is (by definition, when it's statically verifiable), not equipped to change object property names without provoking breakage.
        culi 5mo ago
        I don't think it ever appeared in JS bundles. I'm just saying it's available to any dev in their IDEs with a simple ctrl+click