4 ms·

Not gonna happen: https://github.com/tc39/faq?tab=readme-ov-file#why-dont-we-just-break-the-web https://github.com/tc39/faq?tab=readme-ov-file#why-dont-we-j...

Not gonna happen: https://github.com/tc39/faq?tab=readme-ov-file#why-dont-we-just-break-the-web https://github.com/tc39/faq?tab=readme-ov-file#why-dont-we-j... Browsers aren't going to break old pages.

Silhouette 3y ago
Browsers have broken old pages on a massive scale on several occasions. Numerous useful pages were effectively lost when they decided to shut down widely used plugins like Flash and Java applets that were mainstays of the interactive web for years. Google/Chrome in particular are notorious for pushing features before they're properly standardised, allowing developers to start relying on them, and then pulling them because they are no longer convenient. A better answer here might be to give the language a version declaration feature so browsers could reliably provide a backward-compatible interpretation of old scripts if necessary. If breaking changes are only made when there is great value in the change and no reasonable alternative then they shouldn't happen often enough for this kind of versioning to become an unmanageable burden.
- bakkoting 3y ago
  There's a big difference between breaking things because they're relying on impossible-to-secure plugins and breaking things because JavaScript developers want to invoke an API in a slightly different way. Regarding versioning, see the immediately preceding question in the FAQ.
  - Silhouette 3y ago
    I read both FAQ answers. I just - with greatest respect - don't find them convincing. The arguments about completely removing the plugins were always questionable. Yes they had security problems. Now the attack surface they represented has largely been moved to the browsers themselves, which also have security problems, often of a similar nature and for similar reasons. Plugins had stopped being a vehicle for drive-by downloads and the like thanks to better browser safeguards like click-to-play long before they were decisively removed. Some of the most popular programming languages in the world behave significantly differently between major versions and have developed effective solutions to manage those differences. Sometimes those are as simple as a command line compiler flag or config file setting to specify a target language version. And of course the libraries used with many languages also frequently have to deal with complex dependency resolutions these days. I do not understand why JavaScript is special and could not adopt a similar model if the will was there.
    - bakkoting 3y ago
      Browsers are much, much better at addressing security issues than Flash or Java applets ever were. There's no comparison. And even if you think that they ought not to have been removed, surely it's clear that the concerns about security for users are a fundamentally different thing than JS developers wanting a different API shape. As to versioning the language: languages like Rust and Go use editions, which allow them to making breaking changes to syntax but not to the standard library, which is what's being discussed here. Indeed Rust has several deprecated-but-unremovable things in their standard library. Python makes breaking changes to their standard library, and then people's code breaks. C++ requires you to specify the version for the entire program, which isn't viable for JS because pages mix scripts from dozens of authors, which all need to interact and to have a coherent view of the world. Not sure what other language you're thinking of. The relatively unique object model in JS, and the fact that the standard library consists of ambient properties, also makes it special; it's harder in JS than it would be in a language like Rust to detect use of a particular feature of the standard library.
diegof79 3y ago
Well there is a standard way to support multiple versions of a JS library: imports. I wonder is there is any proposal for a standard library with a well known URI. A browser with ESM support should be able to provide its internal version or fallback with a polyfill using import maps. Something like: import {groupBy} from “std:arrays” That can be also useful to standardize libs between Node,Deno,Bun without polluting the global namespace… and it’s backwards compatible
replygirl 3y ago
yes, what my comment proposes is a solution that avoids breaking the web, by referring to document.lastModified. in this scenario there's a transition period where only Object.groupBy is available, then after a few years Array.groupBy is also available for any pages modified after the cutoff date. static pages are spared, and servers + library devs have plenty of time to react there is definitely an approach out there that breaks fewer pages than things like the flash EOL broke
- bakkoting 3y ago
  A lot of shipped code is effectively unmaintained even on pages which are otherwise being modified, in many cases by relatively non-technical people (a small business owner contracts a webdev to build a page and show them how to update the content, for example). And in a lot of cases it's not obvious that your code is going to be incompatible. For example the most recent case there was code which was like `function foo(x) { if (x.group) x = x.group; /.../}` where that function was being called with `foo({ group: [...] })` or `foo([...])`. That code breaks if `Array.prototype.group` is added. No one is going to figure that out themselves unless they test on a version of a browser which ships `Array.prototype.group`, and empirically no one does that. Yes, we could find a way to break fewer pages than flash EOL broke. But even just a handful of pages people actually use is too much. No browser wants to ship an update which will break (to pick a relevant example) the website of the government of Brazil, even if they somehow "ought to have" updated their code before that update. Developers are empirically not going to do that update and browsers are not going to punish the users of the pages of those developers by breaking them.

Silhouette 3y ago

Browsers have broken old pages on a massive scale on several occasions. Numerous useful pages were effectively lost when they decided to shut down widely used plugins like Flash and Java applets that were mainstays of the interactive web for years. Google/Chrome in particular are notorious for pushing features before they're properly standardised, allowing developers to start relying on them, and then pulling them because they are no longer convenient. A better answer here might be to give the language a version declaration feature so browsers could reliably provide a backward-compatible interpretation of old scripts if necessary. If breaking changes are only made when there is great value in the change and no reasonable alternative then they shouldn't happen often enough for this kind of versioning to become an unmanageable burden.

bakkoting 3y ago
There's a big difference between breaking things because they're relying on impossible-to-secure plugins and breaking things because JavaScript developers want to invoke an API in a slightly different way. Regarding versioning, see the immediately preceding question in the FAQ.
- Silhouette 3y ago
  I read both FAQ answers. I just - with greatest respect - don't find them convincing. The arguments about completely removing the plugins were always questionable. Yes they had security problems. Now the attack surface they represented has largely been moved to the browsers themselves, which also have security problems, often of a similar nature and for similar reasons. Plugins had stopped being a vehicle for drive-by downloads and the like thanks to better browser safeguards like click-to-play long before they were decisively removed. Some of the most popular programming languages in the world behave significantly differently between major versions and have developed effective solutions to manage those differences. Sometimes those are as simple as a command line compiler flag or config file setting to specify a target language version. And of course the libraries used with many languages also frequently have to deal with complex dependency resolutions these days. I do not understand why JavaScript is special and could not adopt a similar model if the will was there.
  - bakkoting 3y ago
    Browsers are much, much better at addressing security issues than Flash or Java applets ever were. There's no comparison. And even if you think that they ought not to have been removed, surely it's clear that the concerns about security for users are a fundamentally different thing than JS developers wanting a different API shape. As to versioning the language: languages like Rust and Go use editions, which allow them to making breaking changes to syntax but not to the standard library, which is what's being discussed here. Indeed Rust has several deprecated-but-unremovable things in their standard library. Python makes breaking changes to their standard library, and then people's code breaks. C++ requires you to specify the version for the entire program, which isn't viable for JS because pages mix scripts from dozens of authors, which all need to interact and to have a coherent view of the world. Not sure what other language you're thinking of. The relatively unique object model in JS, and the fact that the standard library consists of ambient properties, also makes it special; it's harder in JS than it would be in a language like Rust to detect use of a particular feature of the standard library.

diegof79 3y ago

Well there is a standard way to support multiple versions of a JS library: imports. I wonder is there is any proposal for a standard library with a well known URI. A browser with ESM support should be able to provide its internal version or fallback with a polyfill using import maps. Something like: import {groupBy} from “std:arrays” That can be also useful to standardize libs between Node,Deno,Bun without polluting the global namespace… and it’s backwards compatible

replygirl 3y ago

yes, what my comment proposes is a solution that avoids breaking the web, by referring to document.lastModified. in this scenario there's a transition period where only Object.groupBy is available, then after a few years Array.groupBy is also available for any pages modified after the cutoff date. static pages are spared, and servers + library devs have plenty of time to react there is definitely an approach out there that breaks fewer pages than things like the flash EOL broke

bakkoting 3y ago
A lot of shipped code is effectively unmaintained even on pages which are otherwise being modified, in many cases by relatively non-technical people (a small business owner contracts a webdev to build a page and show them how to update the content, for example). And in a lot of cases it's not obvious that your code is going to be incompatible. For example the most recent case there was code which was like `function foo(x) { if (x.group) x = x.group; /.../}` where that function was being called with `foo({ group: [...] })` or `foo([...])`. That code breaks if `Array.prototype.group` is added. No one is going to figure that out themselves unless they test on a version of a browser which ships `Array.prototype.group`, and empirically no one does that. Yes, we could find a way to break fewer pages than flash EOL broke. But even just a handful of pages people actually use is too much. No browser wants to ship an update which will break (to pick a relevant example) the website of the government of Brazil, even if they somehow "ought to have" updated their code before that update. Developers are empirically not going to do that update and browsers are not going to punish the users of the pages of those developers by breaking them.