Add non-normative text clarifying what this actually does

[domenic]

In particular, that this doesn't necessarily affect devtools, and won't help you protect your code in some DRM-like fashion.

[caridy]

Although I don't think DRM-like fashion protection is off the table, I do think that something like this could help devtools greatly. One of the biggest challenges today for library and framework authors is the fact that their code gets in the way of debugging user-land code, forcing developers to step into framework/lib code that they don't understand or care most of the time.

I believe this proposal should open the door for devtool to offer the ability to skip stepping into certain functions while still providing an option for enabling that, similar to the sourcemap vs no-sourcemap configuration, which is an option that a framework developer can enable if needed.

[getify]

@caridy

IIUC devtools (at least in chrome) offer "blackboxing" so a dev can skip stepping into a script (like a framework) while debugging.

[caridy]

@getify "blackboxing" requires dev (consumer) intervention (filtering files/bundles or right click on individual files in the devtool UI to blackboxing them), I'm talking about frameworks (providers) having a way to signal what to should be hidden by default unless the dev (consumer) decides to step into it. The real question with respect to this proposal is whether censoring could be considered the same as blackboxing, maybe it is a good-enough approximation.

[getify]

The real question with respect to this proposal is whether censoring could be considered the same as blackboxing

From my perspective, the real question is who should get to control this decision in how devtools works? I think it should be the end-developer.

[michaelficarra]

@getify Nobody is suggesting taking away the control from a devtools user in any of these threads. @caridy is just suggesting a signal for default behaviour given by the file instead of devtools currently always defaulting to stepping through all sorts of support code. I think that sounds like a good idea, though it requires no changes to this proposal.

[ljharb]

Generally that’s always who has control inside dev tools - i believe that’d be up to each browser to implement, though, just like other dev enhancements like source maps.

[getify]

Nobody is suggesting taking away the control from a devtools user in any of these threads.

Well, in another thread several folks strongly asserted this proposal had nothing to do with censoring devtools at all, only runtime code. So it seems like mixed messages here.

How am I supposed to know what implications this feature has and doesn't have if that message keeps changing? I've read the proposal a dozen times, and it says nothing at all, either way, about devtools. This thread looks like it was intended to track exactly this fact, that some clarity on the proposal's (intended) affect to devtools needs to be added.

Moreover, what mechanism do you envision where a framework would censor their own code from devtools "by default", but then a devtools user would be able to say, no ignore that censoring, I want to step through the framework?

One could imagine, for example, that a censored function would "default" to being blackboxed, but a devtools user could un-blackbox it if they want. That's fine. But obviously a devtools user might want that overriding of the default to be persistent instead of resetting every time. So it's not just about defaults, it's also about perceived control (or lack of it) that devtools users have.

My point is, there's a lot of nuance and not yet a lot of clarity on this detail. And I think these things are pretty critical to understand.

[caridy]

I think "default" behavior for censored functions in devtools is the key here. And yes, @michaelficarra is absolutely correct, no changes are required to the proposal since TC39 should not attempt to give recommendations about devtools.

To provide a concrete example, at salesforce we use membranes (via proxies) for data produced by our platform, we have thousands (from our millions registered developers) that rely on this platform to create components, etc. They have absolutely zero interested on membranes, for them they are just objects, and we, as platform, has absolutely zero interested on them looking into what our proxy traps are doing. But blackboxing means that all those developers will have to learn how to enable blackboxing, and what scripts to add to it, etc. If we censor those functions (which we plan to if this lands), should the devtool just automagically add those to the blackboxing? I think that makes a lot of sense. And sure, end-developer can always configure the devtool differently, that's just fine.

[michaelficarra]

Moreover, what mechanism do you envision where a framework would censor their own code from devtools "by default", but then a devtools user would be able to say, no ignore that censoring, I want to step through the framework?

You know how you can enable blackboxing for a script and disable blackboxing for a script? You use that, just like you do today, except it starts off in the blackboxing state.

[getify]

@michaelficarra you restated exactly what I said in the very next paragraph. But you didn't answer this part:

But obviously a devtools user might want that overriding of the default to be persistent instead of resetting every time.

In your mind, how strong is this default? Does it re-censor (blackbox) the file every time I refresh the page? What about if the framework file changes, does it reset to being blackboxed even though I un-blackboxed the previous version of that file?

[michaelficarra]

@getify This is an issue you should take up with any devtools implementer who implements @caridy's suggested defaulting behaviour in a way you don't like. Why is some imaginary devtools UX decision relevant to this proposal? You're turning what would've been a small helpful note that contributed to the rationale of this proposal into FUD yet again. Nobody has ever suggested that any control is being removed from users.

What you are complaining about is similar to what devtools commonly do today with rendering resources differently based on their Content-Type. You can always view the resource as text, but they've decided that most of the time the user wants to view the resource as suggested by the server-provided metadata. @caridy simply pointed out that the proposed directive is more metadata so devtools could be more helpful if they wanted to.

[getify]

You're turning what would've been a small helpful note that contributed to the rationale of this proposal into FUD yet again.

You may not agree with the concerns I have (with the overall proposal and with specific points in specific threads), but I would ask AGAIN for you (and others) to stop turning to personal attacks by questioning by efforts as acting in bad faith.

FTR, I prefixed that question with "In your mind" because I was specifically directing my question at you, not trying to generalize to a discussion of all devtools teams/features. Motivations of authors (and those who advocate for them) are relevant, as far as I'm concerned.

---

Also, I didn't speak up on this thread until I saw this:

I believe this proposal should open the door

I read that as @caridy saying this proposal, and the spec text it ends up promoting, should have specific wording (normative, non-normative, whatever) about the intent of this feature in terms of affecting devtools. Since the proposal doesn't have that wording in it yet, I believe it's reasonable to debate whether that should be the case.

That's not FUD. It's my concern, and I am debating it.

[michaelficarra]

Yes, I am concerned that some people would be acting in bad faith with their contributions, and it is hard to distinguish your contributions so far from those. You've been continuing to set up a straw man that we've had to fight and redirect resources from the topics being discussed. The authors and contributors to this proposal are aware of your concern about end user control over how programs are run and inspected. We also need to understand that, while the changes to the language in this proposal may influence devtools developers, we do not have direct control over any decision that they make. Please do not direct those specific concerns to us here.

[domenic]

This is a long thread, but I want to be clear that ECMAScript language proposals have no impact on devtools UX, and speccing devtools UX is out of scope for this proposal.

[domenic]

I've posted a pull request attempting to clarify this in https://github.com/domenic/proposal-function-implementation-hiding/pull/19. Thoughts welcome.