On 27 July 2017 at 12:07, Mark <m...@heyimmark.com> wrote: > I think it is a mistake to assume that a developer has a right to always > have optimal performance without requiring anything to get it. It almost > sounds like you're saying that there should be no cost to the consumer for > choosing not to evolve with the language. >
In an ideal world, I would agree. But that's not how the game theory works out on the web. What Brendan already pointed out wrt breaking sites also applies to performance regressions: if Joe User observes that a website suddenly got notably slower with a new version of their browser then they will blame the browser. That effect is further elevated by tech reviews often performing measurements with hopelessly outdated benchmarks. So no browser vendor can afford significant regressions, unless they have an urge to look bad in public perception. > > Things we buy into in life (not just a coding language) will depreciate in > value and will require either an upgrade or a replacement or significant > maintenance and, if not done, the consumer will suffer the consequences of > choosing to remain stagnant. And the longer the stagnation, the greater the > change needed to put the consumer in the same (or better) position they > were in before the depreciation got so bad. > > That said, I'm still struggling to see a real need to remove older JS > features. > > On Thu, Jul 27, 2017 at 5:44 AM Andreas Rossberg <rossb...@google.com> > wrote: > >> On 27 July 2017 at 11:00, Mark <m...@heyimmark.com> wrote: >> >>> It has already been mentioned that there is likely no performance >>> degradation when adding new features. >>> >> >> That is not always true. For example, ES6 has caused some notable >> performance regressions for ES5 code initially, due to extensions to the >> object model that made it even more dynamic. The new @@-hooks were >> particularly nasty and some cases required substantial amounts of work from >> implementers just to get back close to the previous baseline performance. >> Parsing also slowed down measurably. Moreover, many features tend to add >> combinatorial complexity that can make the surface of "common cases" to >> optimise for in preexisting features much larger. >> >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
