3 ms·

People often forget two things: - Virtually none of these changes are breaking, by design. If you prefer the web of 1998, then as a web developer by and large

by _bxg1 7y ago

People often forget two things: - Virtually none of these changes are breaking, by design. If you prefer the web of 1998, then as a web developer by and large you can pretend that's still the world we live in. - HTML itself has actually been a very small fraction of the "HTML5" (a silly marketing term) rapid iteration over the past decade. CSS has grown dramatically in power, and JS is hardly even the same language (which is good, because it was barely a real programming language at the beginning). But HTML itself is not dramatically different; most of what it's gotten are a handful of native replacements for things people had been implementing in JavaScript on a regular basis.

kevingadd 7y ago
"not breaking" is an aspirational goal, not remotely a fact. When browser vendors decide to ship a breaking change (and make no mistake, they do this multiple times a year - probably dozens to hundreds) they have to run live experiments to gather data on how many commonly-visited sites use a feature they're going to change or a quirk they're going to remove. Typically if the value is like 1% or above the change is killed unless it can be made compatible, but they will go ahead even if it's over 0%. 1% may sound small to you, but web browsers are used by like... a billion people? More? And 1% of a billion is a pretty sizable number of people. Pretend if you want, your stuff will probably break eventually. If it's simple enough it won't break and then you can go on with your life - that's certainly the goal of browser developers. At the moment you start using the DOM or other JS APIs exposed by browsers the odds of your stuff breaking in the next decade go up, especially if you're using things that aren't like 5-year-old parts of the spec. The shelf life of most JS-heavy webapps is like 2 years in my experience.
- _bxg1 7y ago
  I'm really not sure what kind of changes you're talking about. They certainly don't do what you describe at the API level. Maybe you're just talking about bugs? I have encountered a few browser regressions over the years but they're always for really exotic use-cases of relatively new APIs, and they always get fixed in the next release. I've been working on a suite of highly complex JS-heavy tools for the past 2.5 years, and the problems that have stemmed specifically from browser bugs in that time are a vanishingly small number. Probably less than five.
- bzbarsky 7y ago
  1% is _way_ higher than the acceptable breakage thresholds I've seen browsers use. Usually it's more like 0.003% or less. This can still be a significant number, of course...
- notatoad 7y ago
  > When browser vendors decide to ship a breaking change (and make no mistake, they do this multiple times a year - probably dozens to hundreds) can you share an example of a breaking change to HTML that a browser has intentionally shipped in the last year?
- underbluewaters 7y ago
  This is not remotely true anymore. I can remember times when browser updates broke site functionality, but that was a decade ago (longer?) when we were still coding for specific bugs in Internet Explorer 6.
deleted 7y ago
[deleted]

by _bxg1 7y ago

kevingadd 7y ago

"not breaking" is an aspirational goal, not remotely a fact. When browser vendors decide to ship a breaking change (and make no mistake, they do this multiple times a year - probably dozens to hundreds) they have to run live experiments to gather data on how many commonly-visited sites use a feature they're going to change or a quirk they're going to remove. Typically if the value is like 1% or above the change is killed unless it can be made compatible, but they will go ahead even if it's over 0%. 1% may sound small to you, but web browsers are used by like... a billion people? More? And 1% of a billion is a pretty sizable number of people. Pretend if you want, your stuff will probably break eventually. If it's simple enough it won't break and then you can go on with your life - that's certainly the goal of browser developers. At the moment you start using the DOM or other JS APIs exposed by browsers the odds of your stuff breaking in the next decade go up, especially if you're using things that aren't like 5-year-old parts of the spec. The shelf life of most JS-heavy webapps is like 2 years in my experience.

_bxg1 7y ago
I'm really not sure what kind of changes you're talking about. They certainly don't do what you describe at the API level. Maybe you're just talking about bugs? I have encountered a few browser regressions over the years but they're always for really exotic use-cases of relatively new APIs, and they always get fixed in the next release. I've been working on a suite of highly complex JS-heavy tools for the past 2.5 years, and the problems that have stemmed specifically from browser bugs in that time are a vanishingly small number. Probably less than five.
bzbarsky 7y ago
1% is _way_ higher than the acceptable breakage thresholds I've seen browsers use. Usually it's more like 0.003% or less. This can still be a significant number, of course...
notatoad 7y ago
> When browser vendors decide to ship a breaking change (and make no mistake, they do this multiple times a year - probably dozens to hundreds) can you share an example of a breaking change to HTML that a browser has intentionally shipped in the last year?
underbluewaters 7y ago
This is not remotely true anymore. I can remember times when browser updates broke site functionality, but that was a decade ago (longer?) when we were still coding for specific bugs in Internet Explorer 6.

deleted 7y ago

[deleted]