5 ms·

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 A

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?

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?