Hacker News new | past | comments | ask | show | jobs | submit login

"if the BBC tied all its web apps to one of those third-party libraries and then that library suddenly announced they were dropping support for some minor browser or screen reader the BBC were mandated to deliver to?"

Do you really think that picking up support for an EOL browser would be more time/effort/expense than developing an entirely separate javascript framework? Even given that others using the framework would also be interested in maintaining support?




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.


The argument that its not the BBC's project doesn't hold water, you are using someone else's web server technology (Apache?), someone else's programming language (Java? So, Sun... now Oracle), another company developed the hardware, doubleclick to serve your ads, pulse for your surveys, why not also jQuery for your js library?

You also did not need to branch jQuery, as if you had contributed to it then screen reader support would already be in its core now, or available via plugins. The point is, that with libraries that are truly open source like jQuery, all that work put into glow could have been put into jQuery. No branching necessary.

If jQuery chose to drop support for a browser you felt was necessary, you could have simply not upgraded to the next version of jQuery or complain about it and offer to do the work to make it compatible with those browsers.

Plus you would have been benefiting from the serious testing that the jQuery team puts jQuery through. All that testing and bug fixing is work the Glow team does not need to do, or at least bugs that the Glow team doesn't need to fix themselves.

I've used jQuery as the example here, because I feel its the best choice, but Prototype, Dojo, Mootools, ExtJS, could have also been good choices, though only Dojo of the four has such open contribution to the core as jQuery.

On a side note, something you guys may want to look into is concatenating, minifying, and gzipping your js and css files. It could reduce the js/css file size and number of http requests by as much as 2/3 on your pages.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: