8 ms·

Chromium/Blink – Intent to Implement: Experimental Framework

54 points by lucideer 11y ago

thristian 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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 11y ago
        We could just ask IT to set up flags on internal applications/users if there was a business need...
  - thristian 11y ago
    The problem with the current system is that you get almost no testing while the flag defaults to off, and then when it defaults to on evetybody starts depending on it. 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.
- michaelmrose 11y ago
  This is one of the most ridiculous ideas I have seen recently and Trump has been in the news since then. Can you imagine not being able to work on a given feature on a given day or having otherwise sane builds of software that behave differently based on the clock?
andrewstuart2 11y ago
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 11y ago
  Something like -webkit-will-be-removed-on-2015-10-17-border-radius:
  - jewel 11y ago
    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.
- owencm 11y ago
jamesrom 11y ago
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 11y ago
  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.
  - jamesrom 11y ago
    The problem is developers expecting experimental features to be around forever. You don't need an API key to set expectations. Using console.warn is enough.
  - simoncion 11y ago
    >> 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 11y ago
greggman 11y ago
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/
xg15 11y ago
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.

54 points by lucideer 11y ago

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 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      We could just ask IT to set up flags on internal applications/users if there was a business need...
- thristian 11y ago
  The problem with the current system is that you get almost no testing while the flag defaults to off, and then when it defaults to on evetybody starts depending on it. 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.
michaelmrose 11y ago
This is one of the most ridiculous ideas I have seen recently and Trump has been in the news since then. Can you imagine not being able to work on a given feature on a given day or having otherwise sane builds of software that behave differently based on the clock?

andrewstuart2 11y ago

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 11y ago
Something like -webkit-will-be-removed-on-2015-10-17-border-radius:
- jewel 11y ago
  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.
owencm 11y ago

jamesrom 11y ago

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 11y ago
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.
- jamesrom 11y ago
  The problem is developers expecting experimental features to be around forever. You don't need an API key to set expectations. Using console.warn is enough.
- simoncion 11y ago
  >> 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 11y ago

greggman 11y ago

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/

xg15 11y ago

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.