6 ms·

If it’s not breaking backwards compatibility then what’s the problem with improvements?

akvadrako 9y ago
It obsoletes older browsers. For a while it used to be you could browse the web with almost anything, even a 10-year old Netscape. Now it's the norm that a 4 year old browser isn't supported, because of new APIs and JS syntax.
- Digit-Al 9y ago
  If you haven't updated your browser for four years then you've got a hell of lot more to worry about than if javascript works correctly.
- tcd 9y ago
  Why do people like you feel that's acceptable? Software can work from anywhere between a few hours to a decade before an update is required, and it entirely depends on what you're doing. Websites evolve, and that's the choice of developers around the world. You have no right to complain if you don't keep your software up to date to a reasonable level. If you want to use 4 years old software, you MUST accept things are broken and that it's your fault. Try downloading Firefox 1-10 and see if they work today ;)
  - akvadrako 9y ago
    I'm not necessarily against forcing upgrades because it comes with advantages, but I was explaining the tradeoff. It's one good thing about Apple and if say, domestic power outlets could change every few years, we could get higher voltages, DC, built in networking, more compact connectors, metering features, etc... But if everything operated like the web ecosystem, we might consume 100% of our time and money just on upgrades. And it pretty much guarantees there will only be a handful of vendors, because it's very expensive to stay current.
  - wwweston 9y ago
    > Software can work from anywhere between a few hours to a decade before an update is required All other things being equal, a decade is preferable because time/attention is valuable. Frequent and in particularly non-careful updates can put individuals and in the grip of a form of the red queen problem rather than being able to spend time/attention on new levels of capability. I don't particularly mind some obsolescing of browsers where JS is concerned, and browsers in general have done a remarkable job of retaining backward compatibility. More problematic, though, is the attitude that's more or less every website should be a JS-powered (or, in the future, web-assembly) SPA without any kind of back-end fallback for user agents that don't support it, thus making JS capability the bar for any UA. That's short-sighted, doesn't consider user conditions outside of a narrow range of experience, doesn't consider that there might be user agents other than browsers as commonly understood. If that's all you have the resources to do and how you choose to spend them, that can still be reasonable engineering (though my experience is the benefits of figuring out how to make it work w/o JS first -- if it's possible -- often pays engineering dividends), but I think it's weird it's the default now. > Try downloading Firefox 1-10 and see if they work today ;) Firefox 1-10 would be broken because they're embedded in a set of assumptions about specific non-web platforms, not because many (if not most) websites couldn't reasonably support them as clients. I don't see any reason to import the shortcomings of non-web platforms into the web.
- orf 9y ago
  That 4 year old browser is full of security holes though. Why would anyone want to encourage that?
- jsheard 9y ago
  New syntax can obsolete older browsers, but it doesn't necessarily have to in the age of Babel and Typescript. Babel can already translate ES2018 async iterators and rest/spread into ES5 code that works pretty much everywhere.
  - akvadrako 9y ago
    If you are using babel there is no need for the new browsers to support the new syntax at all.
    - always_good 9y ago
      Sure there are. For example, your bundle size shrinks when targeting newer browsers because more features exist, fewer need to be polyfilled.
      - akvadrako 9y ago
        Then you must prepare two bundles, one for new browsers and one for old. I suppose that's possible, but doesn't seem worth it.
        TomMarius 9y ago
        It is worth it most of the time.
        styfle 9y ago
        You can use <script type=module> to target newer browsers. It’s definitely worth having two bundles because the ES6 and newer is much smaller. And one day, you stop shipping the old ES5 bundle.
- irrational 9y ago
  My view is, if everyone was on an evergreen browser (and didn't do something like turn off the auto updates) then there would be no such thing as a 4-year old (or even 1-year old browser). If I could wave a magic wand I'd have 100% of websites all using cutting edge HTML, CSS, JS features tomorrow so the WWW absolutely breaks for anyone not using an up to date evergreen browser (the lone exceptions being the download pages for Firefox, Chrome, etc.). The sooner businesses, Luddites and grandpas upgrade the better. But that's just my view as a developer who is so sick and tired of supporting browsers that have been out of support for years.
  - Yetanfou 9y ago
    Your view excludes all platforms made before "evergreen browsers" became a thing and will exclude all platforms which the makers of "evergreen browsers" deem too small or unprofitable to support. So thanks, but no thanks. There is enough of planned obsolescence already, no need to add another weapon to the arsenal.
Yaggo 9y ago
The more there's featues, the harder it will be to create new independent implementations, which is not good for openness/competition. The bar is already too high.
tzahola 9y ago
Because these constant "improvements" usually mean two things: 1. The language design is flawed. That is, the desired functionality requires changes to the core language, because it can't be made from existing building blocks. The fundamental language constructs are not universal enough, so new functionality will always require "just one more" special case in the language itself. or 2. People are shoving things into the core language, that should rather be implemented as a library/framework.
- castis 9y ago
  The language design is absolutely flawed, hence the push to make that less so. What things going into core do you think should be a separate framework?
  - tzahola 9y ago
    >The language design is absolutely flawed, hence the push to make that less so. But a flawed language cannot be made non-flawed while keeping backwards compatibility... E.g. JS has now two different ways to write functions, with slightly different semantics. >What things going into core do you think should be a separate framework? An example would be async/await and generators, both which are just a special cases of coroutines. If JS would have coroutines, then these two would just be coroutine libraries.
    - alangpierce 9y ago
      > But a flawed language cannot be made non-flawed while keeping backwards compatibility Sure it can. Just introduce new syntax and discourage use of old syntax, ideally with tooling. For example, `var` is disallowed by any popular lint config, and for most practical purposes, it doesn't exist in JS anymore. The execution environment will still handle it, but it's not an available option when writing code in any professional or non-professional project I work on (because it won't pass lint). Plenty of languages do this: Java raw types, Python old-style classes, goto in lots of languages. Python actually did a breaking change to remove old features, and it's a good example of how breaking changes can cause much more trouble than you might expect.

It obsoletes older browsers. For a while it used to be you could browse the web with almost anything, even a 10-year old Netscape. Now it's the norm that a 4 year old browser isn't supported, because of new APIs and JS syntax.

Digit-Al 9y ago
If you haven't updated your browser for four years then you've got a hell of lot more to worry about than if javascript works correctly.
tcd 9y ago
Why do people like you feel that's acceptable? Software can work from anywhere between a few hours to a decade before an update is required, and it entirely depends on what you're doing. Websites evolve, and that's the choice of developers around the world. You have no right to complain if you don't keep your software up to date to a reasonable level. If you want to use 4 years old software, you MUST accept things are broken and that it's your fault. Try downloading Firefox 1-10 and see if they work today ;)
- akvadrako 9y ago
  I'm not necessarily against forcing upgrades because it comes with advantages, but I was explaining the tradeoff. It's one good thing about Apple and if say, domestic power outlets could change every few years, we could get higher voltages, DC, built in networking, more compact connectors, metering features, etc... But if everything operated like the web ecosystem, we might consume 100% of our time and money just on upgrades. And it pretty much guarantees there will only be a handful of vendors, because it's very expensive to stay current.
- wwweston 9y ago
  > Software can work from anywhere between a few hours to a decade before an update is required All other things being equal, a decade is preferable because time/attention is valuable. Frequent and in particularly non-careful updates can put individuals and in the grip of a form of the red queen problem rather than being able to spend time/attention on new levels of capability. I don't particularly mind some obsolescing of browsers where JS is concerned, and browsers in general have done a remarkable job of retaining backward compatibility. More problematic, though, is the attitude that's more or less every website should be a JS-powered (or, in the future, web-assembly) SPA without any kind of back-end fallback for user agents that don't support it, thus making JS capability the bar for any UA. That's short-sighted, doesn't consider user conditions outside of a narrow range of experience, doesn't consider that there might be user agents other than browsers as commonly understood. If that's all you have the resources to do and how you choose to spend them, that can still be reasonable engineering (though my experience is the benefits of figuring out how to make it work w/o JS first -- if it's possible -- often pays engineering dividends), but I think it's weird it's the default now. > Try downloading Firefox 1-10 and see if they work today ;) Firefox 1-10 would be broken because they're embedded in a set of assumptions about specific non-web platforms, not because many (if not most) websites couldn't reasonably support them as clients. I don't see any reason to import the shortcomings of non-web platforms into the web.
orf 9y ago
That 4 year old browser is full of security holes though. Why would anyone want to encourage that?
jsheard 9y ago
New syntax can obsolete older browsers, but it doesn't necessarily have to in the age of Babel and Typescript. Babel can already translate ES2018 async iterators and rest/spread into ES5 code that works pretty much everywhere.
- akvadrako 9y ago
  If you are using babel there is no need for the new browsers to support the new syntax at all.
  - always_good 9y ago
    Sure there are. For example, your bundle size shrinks when targeting newer browsers because more features exist, fewer need to be polyfilled.
    - akvadrako 9y ago
      Then you must prepare two bundles, one for new browsers and one for old. I suppose that's possible, but doesn't seem worth it.
      - TomMarius 9y ago
        It is worth it most of the time.
      - styfle 9y ago
        You can use <script type=module> to target newer browsers. It’s definitely worth having two bundles because the ES6 and newer is much smaller. And one day, you stop shipping the old ES5 bundle.
irrational 9y ago
My view is, if everyone was on an evergreen browser (and didn't do something like turn off the auto updates) then there would be no such thing as a 4-year old (or even 1-year old browser). If I could wave a magic wand I'd have 100% of websites all using cutting edge HTML, CSS, JS features tomorrow so the WWW absolutely breaks for anyone not using an up to date evergreen browser (the lone exceptions being the download pages for Firefox, Chrome, etc.). The sooner businesses, Luddites and grandpas upgrade the better. But that's just my view as a developer who is so sick and tired of supporting browsers that have been out of support for years.
- Yetanfou 9y ago
  Your view excludes all platforms made before "evergreen browsers" became a thing and will exclude all platforms which the makers of "evergreen browsers" deem too small or unprofitable to support. So thanks, but no thanks. There is enough of planned obsolescence already, no need to add another weapon to the arsenal.

Yaggo 9y ago

The more there's featues, the harder it will be to create new independent implementations, which is not good for openness/competition. The bar is already too high.

tzahola 9y ago

Because these constant "improvements" usually mean two things: 1. The language design is flawed. That is, the desired functionality requires changes to the core language, because it can't be made from existing building blocks. The fundamental language constructs are not universal enough, so new functionality will always require "just one more" special case in the language itself. or 2. People are shoving things into the core language, that should rather be implemented as a library/framework.

castis 9y ago
The language design is absolutely flawed, hence the push to make that less so. What things going into core do you think should be a separate framework?
- tzahola 9y ago
  >The language design is absolutely flawed, hence the push to make that less so. But a flawed language cannot be made non-flawed while keeping backwards compatibility... E.g. JS has now two different ways to write functions, with slightly different semantics. >What things going into core do you think should be a separate framework? An example would be async/await and generators, both which are just a special cases of coroutines. If JS would have coroutines, then these two would just be coroutine libraries.
  - alangpierce 9y ago
    > But a flawed language cannot be made non-flawed while keeping backwards compatibility Sure it can. Just introduce new syntax and discourage use of old syntax, ideally with tooling. For example, `var` is disallowed by any popular lint config, and for most practical purposes, it doesn't exist in JS anymore. The execution environment will still handle it, but it's not an available option when writing code in any professional or non-professional project I work on (because it won't pass lint). Plenty of languages do this: Java raw types, Python old-style classes, goto in lots of languages. Python actually did a breaking change to remove old features, and it's a good example of how breaking changes can cause much more trouble than you might expect.