In the short term, what you are suggesting may seem to make sense, but with the sheer size and breadth of the BBC website and our business requirements, the longer term picture is completely different. It might take a few months for a couple of talented JS dev's to 'fix' an existing library to add in support for a minority browser for which the BBC has what it deems to be a 'significant enough' user base, plus add extra accessibility features, and screen reader support, etc, which that library doesn't support effectively enough. But that's not the whole story.
What will have happened there is that library will have been branched for the BBC and then that branch needs to be maintained long term such that updates and patched have to be vetted and tested across our whole site before applied so they don't break this backwards compatibility. That starts to become a lot of work.
Plus you also now need to take into account that its not the BBC's project, its somebody else's and the BBC is just using it. For a big company with its own set of business objectives and varied project needs, its a risk to be relying on someone else's product. Its much better for that business to be able to steer its own products and have consistency between them and their road maps.
Please don't get us wrong. We did very seriously consider our approach. Its not a decision we took lightly. We sat down and rationalised all the options, risks and factors. If we hadn't have had some seriously talented JavaScript developers working at the BBC at the time, the decision may have been made for us.
Due to the BBC's public service remit it has to support a very wide range of use cases - many of which fall outside of the accepted norm. For example the BBC has to provide its contents to libraries and schools, many of which have more heavily 'locked down' machines than your typical corporate network, and who do not have the money or time to upgrade their machines. There are a lot of smaller user groups in situations that prevent them from upgrading too. You'd be surprised how many older machine users this equates to. Thus the BBC has to support the thin end of the wedge of web browsers, and the stats we have (unfortunately) back this up.
The Glow team itself is actually a very small team, even in BBC terms (which usually has small teams compared to a lot of companies). Add to this the in-house support they give to all of the other web products in terms of a library and general JS support and you have in effect a net gain in web producing ability - not a loss, so its more effective to do this and thus a more efficient use of BBC funds.
What will have happened there is that library will have been branched for the BBC and then that branch needs to be maintained long term such that updates and patched have to be vetted and tested across our whole site before applied so they don't break this backwards compatibility. That starts to become a lot of work.
Plus you also now need to take into account that its not the BBC's project, its somebody else's and the BBC is just using it. For a big company with its own set of business objectives and varied project needs, its a risk to be relying on someone else's product. Its much better for that business to be able to steer its own products and have consistency between them and their road maps.
Please don't get us wrong. We did very seriously consider our approach. Its not a decision we took lightly. We sat down and rationalised all the options, risks and factors. If we hadn't have had some seriously talented JavaScript developers working at the BBC at the time, the decision may have been made for us.