
Chromium/Blink – Intent to Implement: Experimental Framework - lucideer
https://groups.google.com/a/chromium.org/forum/#!topic/experimentation-dev/GsPtuFt8XqA
======
andrewstuart2
Yikes.

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.

~~~
mappu
Something like

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

~~~
jewel
This is a great solution, in my opinion. Perhaps it could include the browser
version instead:

    
    
        -chrome-46-faster-font-engine:
    

This will allow any developer to opt in, with an explicit understanding that
when the next browser version comes out the feature will disappear.

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

------
greggman
I'm guessing the problem this is trying to solve

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/](https://infrequently.org/2015/08/doing-science-on-the-web/)

------
thristian
The requirement to register for an API key (presumably with your Google
account) seems a bit weird. Do they expect other browsers to share a Google-
controlled API key service, or do they expect developers to sign up for
multiple developer accounts, or to deal with four radically different systems
for Chrome, Firefox, Edge and Safari?

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.

~~~
scottfr
What is the benefit of something like disabling on Tuesdays?

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.

~~~
lucideer
The benefit would be that - assuming the developer is well aware of this
limitation - it would act as a disincentive to push code relying on the
experimental feature to production.

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.

~~~
scottfr
Doesn't having to ask your users to go to chrome://flags and click the
"Enable" button next to some very scary looking technical text have the same
effect?

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

~~~
newjersey
We could just ask IT to set up flags on internal applications/users if there
was a business need...

------
xg15
I like the general idea of this, but I'm bothered by the "slippery slope"
effect this might cause.

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.

------
jamesrom
No experimental feature is cool enough to require you:

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

You have a problem with burn-in of your experimental APIs? How about you
semver your APIs and console.warn when it's deprecated.

This problem has been solved many times before.

~~~
ubernostrum
_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.

~~~
simoncion
>> This problem has been solved many times before.

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

~~~
ubernostrum
_" All" that needs to be done_

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

~~~
simoncion
> 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.

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.

~~~
ubernostrum
_We 're talking about new features marked as experimental and unstable by the
folks who write and maintain the browser that implements that feature._

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.

~~~
simoncion
> 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.

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.

