As far as I can tell, the only meaningful thing this adds is the ability to require developer registration in order to use experimental APIs.

> The ultimate goal is to enable experimentation and iteration on pre-standardization APIs, in a way that gathers meaningful feedback, but without burn-in of the APIs.

I'm not sure what's broken about the "experimental" label except that it can't trace usage back to specific developers. If it's experimental, it will probably break or disappear. "Burn-in" doesn't have to be a problem if you actually iterate and yank or change stuff. API keys don't solve anything that code removal doesn't solve (aside from developer tracking).

Want to curb "developer abuse" of vendor prefixes? Remove the API. Train developers to understand that experimental features are experimental by actually following through. If you don't want users to think the browser is at fault, maybe alert the user to that fact. "Oops, looks like this website's developers were a bit careless with their code. Sorry about that; some people like to take big risks and it stinks that you the user had to suffer for it."

If you really want to ensure that only specific devs are allowed to use some features, presumably to limit impact on users and loss of browser market share, then just ship those devs a custom release. Protect usage of the whole browser with a key, if you want.

Personally, I'd rather we leave things open to experimentation (with an established and valid understanding they may break) over locking it down to devs willing to give you their phone number so you actively approach them for feedback and turn off the tap on a per-developer basis if you so desire.

[Full disclosure: I work on this project]

    -webkit-will-be-removed-on-2015-10-17-border-radius:

    -chrome-46-faster-font-engine:

console.warn can be used to give a URL where developers can go to give feedback.

Originally we had prefixed APIs. webkitAudioContext for example. The idea was the prefix would be removed. Unfortunately the problem was thousands of websites would use the prefixed API. Now you can't remove the prefixed version without breaking many many sites. Worse, there's even arguably an incentive for other browser to add someone else's prefix because they want their browser to run all those same sites.

So, a couple of years ago the browser vendors all agreed, no more prefixes. They'll put all the new stuff behind flags that developers can opt into. The problem with that is no one uses them. The users aren't going to set the flag so no devs have any reason to try out the APIs. There's no re-world usage to see that the APIs work, to see what issues come up.

So, there's this one. Select a few special devs, let them use the features, enable those features for their domain only. Real users get to use the features with no work on their part. It solves the problem to some extent. The devs know the feature might not last. They're also signed up to get notification if the feature is going to change or be removed. And, I guess their motivation is to one up their competitors.

And that last part is the whole problem with this proposal. Unless any dev can sign up then only special "chosen" devs get the competitive advantage. That feels wrong for some reason. I don't have a better solution to suggest though.

edit:

-- ugh --

I suppose I should have clicked the link which said all of this

https://infrequently.org/2015/08/doing-science-on-the-web/

Last time I heard something like this discussed, one of the suggestions was "browsers automatically disable support for experimental features on Tuesdays", which should allow people time to experiment but should prevent them from depending on it in production. Also, it's a simple rule that can be shared through the web development community by word-of-mouth[1], and many browser vendors can share it without having to coordinate infrastructure, etc.

[1]: Obviously this wouldn't be the only way to share it, but when one developer can turn to another and say 'why doesn't this work' and get a one-sentence answer that contains an accurate model for predicting future occurrences, it's a lot more likely for that model to be reliably propagated via Stack Overflow, Twitter, the random mailing-lists-reformatted-as-web-forums content farms that crop up in search results, etc.

Isn't it simpler and just as effective to put the feature behind a configuration flag that is off by default and the user must manually turn on in the browser preferences? Both Chrome and Firefox already use this mechanism.

With a time-delimited system rather than a flag-delimited system, people con try things out without having to learn about flags. More importantly, they can set things up on a staging server or in a beta environment, then distribute the link to potentially non-technical stakeholders and testers without having to include detailed instructions on setting flags.

The hope is that this will lead to better feedback about medium and large scale deployment of new features, instead of only lone-web-developer feedback.

It would however introduce a lot of hassle in testing the feature - being unable to work on a particular branch for all of every Tuesday. A better approach might be disabling it for an hour or two daily at 4am local time, or for 5 minutes per-hour, etc.

I can't imagine asking users (either public or internal) to do that.

Right now, the proposal is to strictly timebox the experiments and to implement procedures that discourage participants from relying on the experimental features.

However, timebox or not, what this framework does is to put in place a system for granting API access based on privilege. Once this system is standardized and accepted, what keeps it from being abused?

At the simplest, certain experiments could be extended for "infinite" time at the request of big-name participiants if the features are particularly valuable. One of the browser vendors could decide to open up registration for everyone but keep the new feature permanently registration-only. In the most extreme case, this could cause an "app-storisation" of the web.

Another point that might cause trouble is the current distinction by origin (and not, say, top-level browsing context). Participiants could "smuggle features out of the lab" by building a JS library with a hidden iframe and selling/offering it to third-parties of their choosing.

  1. To register
  2. To Use an API key
  3. To detect support for (and presumably fallback)
  4. To provide feedback for

This problem has been solved many times before.

Not on the Web, it hasn't. Deprecating experimental features and even just fixing bugs has been difficult to impossible for a long time; "pay the contractor once to set it up, then leave it unchanged for a decade" is a depressingly common approach to setting up a site, and leads to angry site owners and even larger numbers of angry users when suddenly a behavior the site shouldn't have relied on is changed or removed.

> Not on the Web, it hasn't.

The Web doesn't require some radically new way of developing software.

The webdev community appears to be -slowly- realizing that those nerds back in the 1990's (and 80's and 70's and...) might have actually known a thing or two about developing software, and are finally learning from some of the lessons learned way back when. :)

"All" that needs to be done is for the browser makers that matter [0] to agree to aggressively alter experimental features as needed, remove them whenever they deem necessary, and widely and repeatedly advertise this policy and make it abundantly clear. Hell, even Microsoft has the backbone to break users of undocumented or experimental APIs.

[0] That is, everyone but Apple.

"Those nerds" aren't the ones calling the shots. The decisions are being made by the same people who want the company's original 1970s COBOL application to keep running until the heat death of the universe. "Those nerds" would rewrite the thing if they were allowed to, but they're not.

The Web has the same problem with ancient deployments that management thinks should just keep working unchanged for decades. The problem hasn't been solved for the Web, and also hasn't been solved in other fields, hence you still see listings for COBOL programmers.

Neither Google nor Mozilla have COBOL applications from the 1970's.

Given what I've heard from people who work on Chrome say about the people who work on MSFT's browser, MSFT has recently also become very interested in making software development for a web browser easier, better, and safer.

> The Web has the same problem with ancient deployments that management thinks should just keep working unchanged for decades.

We're talking about new features marked as experimental and unstable by the folks who write and maintain the browser that implements that feature. As I said in a previous comment, even Microsoft has the backbone to break in-the-field software that makes use of undocumented or experimental APIs.

We're not talking about changing or removing XMLHttpRequest. We're talking about changing or removing blink-experimental-webgl-blink-tag-over-web-rtc-ea59f01.

And when the manager says "deadline is next week", and the new and EXPERIMENTAL and UNSTABLE (gasp) feature is the only way to get it done, you use it.

Now, good luck getting permission to go back and clean up technical debt.

I fail to see how a manager's failure to understand that you cannot rely on features that are subject to breaking change or removal at any time, without warning is Google's, Microsoft's or Mozilla's problem.

> Now, good luck getting permission to go back and clean up technical debt.

If your site breaks because the experimental feature that your manager forced you to use was radically changed or removed -as per the widely advertised, well-known policy regarding experimental features-, and your manager doesn't give you permission to fix the mess he forced you into, you -as the programmer- have nothing to worry about. This is clearly a failure of management. :)

Will that stop this manager from yelling at you? Probably not. Will this stop you from getting fired? Maybe not. But, seriously: If you get fired because your manager ignored your expert recommendation that his plan would lead to disaster, and -a little while later- his plan leads to disaster, you were working for a very unreasonable boss. It would only be a matter of time until you were fired for some other equally stupid reason.

If -on the other hand- you commit to doing something that you later find out is not possible, and you don't own up to your mistake, whatever fallout comes from the stupid things you do to cover up your mistake is your own damn fault.