4 ms·

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 pro

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
    "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 11y ago
      > 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 11y ago
        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.
        11y ago

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
  "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 11y ago
    > 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 11y ago
      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.
      - 11y ago