This post title could be the slogan for much of our field.
In the world of browsers, I think it’s easy to forget that as soon as an API is made available in a browser, it becomes very, very tempting to never change it, because you can rest 100% assured that at least one website relies on that new feature, and will be angry if it goes away or changes. Browser developers have been dealing with the question of how to handle this issue for some time.
More broadly, the concerns of compatibility leave us stuck with systems today that remain bound to the limitations of decades old decisions. Green field projects are rare, and often surrounded by naysayers when they start (because they should have started 10 years ago, and who would use such a thing?) The few times a green field project actually finds some success are serious reasons to be excited (Servo, in the world of browser engines, comes to mind).
This doesn’t have a particular conclusion other than to say, with so many of us privately annoyed or critical of the design decisions of older software that still sees use, I wish more of us would be willing to try out new experiments to improve on the state of the art in some of these areas.
While yes, perhaps we’re not stuck with JS forever, that doesn’t give those that work with the web today any solace as the time horizon for “not forever” is indeterminately long.
I still have to support IE9 for my professional work! A 5+ year old browser that not only does not implement the standards of its time correctly, it’s replete with bugs that require constant workarounds!
I’ve envious of those that can adopt new front-end web tech with a snap of their fingers, but unfortunately as brinker mentions in his comment, green field projects are far and few between.
For the vast majority of us, we’re “stuck with javascript” for the foreseeable future.
Obviously circumstances differ, but we’ve found that there are now a few decent reasons to drop IE support up until IE 11:
Very few people were using it. I highly recommend measuring who’s using what browsers. We found that less than 0.5% of people were outside of (Chrome + FF + Safari + IE11+). And our business works with non-tech-savvy Japanese businesses.
It is impossible to be using IE10 safely anymore. It does not get any more security updates, and all Windows SKUs that still get security patches also have IE11. I understand that there’s IT policy, but having people on IE10 means you cannot truthfully claim “real” security for your users data, because they’re vulnerable to all sorts of drive-bys.
To be honest, at this point we have a bigger problem with people on OS X 10.6 (which no longer gets security updates or CA updates) than with IE. And there aren’t that many people on 10.6.
Your situation might be different if your clients are megacorps, but we’ve found that even for mid-to-large size companies, simply telling them “Hey, we really care about your security, which is why we only support setups with security updates” is enough for the users to get permission to use a better browser.
WebAssembly only solves half the problem though. It breaks the language dependency, but that still leaves an enormous, growing, half-broken API surface that constitutes WebAssembly’s “syscall layer”. To really make web development not a mess, the browser interface needs to just be drawing and input primitives. Everything from HTML rendering up should be browser-independent libraries on top of that.
I am reminded of the Extensible Web Manifesto, which proposes that instead of adding high-level features, browsers add low-level interfaces that could be used to implement the high level features.
The most ambitious offshoot of the idea is that, instead of having native unsandboxed implementation of things like JPEG parsing and CSS layout, browsers would have default JS implementations of those things, so that the sandboxing applied to the JS runtime would end up covering a large proportion of all the code in the browser.
I’ve been saying this for years and people look at me like I’m a lunatic (That’s very likely BTW)! It’s nice to hear it from someone else. I should also add to your list though; the browser should also provide features for isolation; i.e the iframe should be possible to implement. Just drawing and input primitives won’t be enough for that.
Damned if you do, damned if you don’t.
Swift has been making breaking changes that improve the language based on developers' feedback; they’ve just come to a point that they’re comfortable claiming source stability.
Still, it’s a massive headache for developers, and they’re right to complain.
If you fix the problem, the headache of people changing their code to accommodate lasts a few weeks for your current users. If you leave the problem there, that headache is for every user, current and future, forever. Fix the problems. People are going to complain either way, so might as well leave them complaining about a good language, right? :)
This post title could be the slogan for much of our field.
In the world of browsers, I think it’s easy to forget that as soon as an API is made available in a browser, it becomes very, very tempting to never change it, because you can rest 100% assured that at least one website relies on that new feature, and will be angry if it goes away or changes. Browser developers have been dealing with the question of how to handle this issue for some time.
More broadly, the concerns of compatibility leave us stuck with systems today that remain bound to the limitations of decades old decisions. Green field projects are rare, and often surrounded by naysayers when they start (because they should have started 10 years ago, and who would use such a thing?) The few times a green field project actually finds some success are serious reasons to be excited (Servo, in the world of browser engines, comes to mind).
This doesn’t have a particular conclusion other than to say, with so many of us privately annoyed or critical of the design decisions of older software that still sees use, I wish more of us would be willing to try out new experiments to improve on the state of the art in some of these areas.
[Comment removed by author]
While yes, perhaps we’re not stuck with JS forever, that doesn’t give those that work with the web today any solace as the time horizon for “not forever” is indeterminately long.
I still have to support IE9 for my professional work! A 5+ year old browser that not only does not implement the standards of its time correctly, it’s replete with bugs that require constant workarounds!
I’ve envious of those that can adopt new front-end web tech with a snap of their fingers, but unfortunately as brinker mentions in his comment, green field projects are far and few between.
For the vast majority of us, we’re “stuck with javascript” for the foreseeable future.
Obviously circumstances differ, but we’ve found that there are now a few decent reasons to drop IE support up until IE 11:
Very few people were using it. I highly recommend measuring who’s using what browsers. We found that less than 0.5% of people were outside of (Chrome + FF + Safari + IE11+). And our business works with non-tech-savvy Japanese businesses.
It is impossible to be using IE10 safely anymore. It does not get any more security updates, and all Windows SKUs that still get security patches also have IE11. I understand that there’s IT policy, but having people on IE10 means you cannot truthfully claim “real” security for your users data, because they’re vulnerable to all sorts of drive-bys.
To be honest, at this point we have a bigger problem with people on OS X 10.6 (which no longer gets security updates or CA updates) than with IE. And there aren’t that many people on 10.6.
Your situation might be different if your clients are megacorps, but we’ve found that even for mid-to-large size companies, simply telling them “Hey, we really care about your security, which is why we only support setups with security updates” is enough for the users to get permission to use a better browser.
WebAssembly only solves half the problem though. It breaks the language dependency, but that still leaves an enormous, growing, half-broken API surface that constitutes WebAssembly’s “syscall layer”. To really make web development not a mess, the browser interface needs to just be drawing and input primitives. Everything from HTML rendering up should be browser-independent libraries on top of that.
I am reminded of the Extensible Web Manifesto, which proposes that instead of adding high-level features, browsers add low-level interfaces that could be used to implement the high level features.
The most ambitious offshoot of the idea is that, instead of having native unsandboxed implementation of things like JPEG parsing and CSS layout, browsers would have default JS implementations of those things, so that the sandboxing applied to the JS runtime would end up covering a large proportion of all the code in the browser.
I’ve been saying this for years and people look at me like I’m a lunatic (That’s very likely BTW)! It’s nice to hear it from someone else. I should also add to your list though; the browser should also provide features for isolation; i.e the iframe should be possible to implement. Just drawing and input primitives won’t be enough for that.
Damned if you do, damned if you don’t. Swift has been making breaking changes that improve the language based on developers' feedback; they’ve just come to a point that they’re comfortable claiming source stability. Still, it’s a massive headache for developers, and they’re right to complain.
¯\_(ツ)_/¯
If you fix the problem, the headache of people changing their code to accommodate lasts a few weeks for your current users. If you leave the problem there, that headache is for every user, current and future, forever. Fix the problems. People are going to complain either way, so might as well leave them complaining about a good language, right? :)