BBC open source their "Glow" Javascript library(bbc.co.uk)
bbc.co.uk
BBC open source their "Glow" Javascript library
http://www.bbc.co.uk/glow/
61 comments
Glow does support Firefox 3.5, Chrome 2, Opera 10 and Safari 4. We're certainly not going to ignore new versions of browsers until they appear on that list.
At some points, we've been ahead of jQuery when it comes to new browsers. Basically because we were able to quickly patch and release in order to fix high-profile BBC pages. This isn't a criticism of jQuery, but it shows the benefit of us being devoted to the BBC.
The BBC will always have to support older browsers because of our users. I think it would be unfair to ask other libraries to hang back with us (I'd much rather they advanced actually), and I wouldn't want to be using a library that left us behind.
At the moment, our support table is actually closer to other libraries' than it has ever been, that support gap will naturally increase and decrease over time.
We're not trying to steal your thunder at all, although I can see why it may have came across like that. My advice to developers is: use the library which has the most features you require. Whichever you pick, request the features that are missing.
With all the libraries innovating and others taking note, the quality of all libraries increases. Having one library to rule them all doesn't drive things forward, a good example of this is when IE6 was the only major browser, browser development stagnated.
We're not about filling a void in the market, but filling a void at the BBC. We're open sourcing our efforts because we should.
You mention you communicated with us? I'm not aware of this at all.
Having said all this, we're looking at the possibility of using Sizzle in Glow 2.0, although it's a bit vague about which browsers it intends to support. Would be great to know the details!
http://groups.google.com/group/sizzlejs/browse_thread/thread...
Cheers, Jake.
At some points, we've been ahead of jQuery when it comes to new browsers. Basically because we were able to quickly patch and release in order to fix high-profile BBC pages. This isn't a criticism of jQuery, but it shows the benefit of us being devoted to the BBC.
The BBC will always have to support older browsers because of our users. I think it would be unfair to ask other libraries to hang back with us (I'd much rather they advanced actually), and I wouldn't want to be using a library that left us behind.
At the moment, our support table is actually closer to other libraries' than it has ever been, that support gap will naturally increase and decrease over time.
We're not trying to steal your thunder at all, although I can see why it may have came across like that. My advice to developers is: use the library which has the most features you require. Whichever you pick, request the features that are missing.
With all the libraries innovating and others taking note, the quality of all libraries increases. Having one library to rule them all doesn't drive things forward, a good example of this is when IE6 was the only major browser, browser development stagnated.
We're not about filling a void in the market, but filling a void at the BBC. We're open sourcing our efforts because we should.
You mention you communicated with us? I'm not aware of this at all.
Having said all this, we're looking at the possibility of using Sizzle in Glow 2.0, although it's a bit vague about which browsers it intends to support. Would be great to know the details!
http://groups.google.com/group/sizzlejs/browse_thread/thread...
Cheers, Jake.
Thanks for your feedback, Jake - and your note on the improved browser support, that's good to know. I stand corrected.
> Having one library to rule them all doesn't drive things forward, a good example of this is when IE6 was the only major browser, browser development stagnated.
I think that's a poor analogy. Everything stagnated because no one could improve upon IE 6 - it was a proprietary browser which had no way to add in new functionality. This is very different from an Open Source project run by a community of people and companies interested in seeing it improve and strive.
> You mention you communicated with us? I'm not aware of this at all.
I had talked with a member of the team at some post-@Media event (I think it was @Media Ajax, maybe @Media proper). Maybe I'm mis-remembering who exactly but I've definitely chatted with a few people at the BBC about jQuery and Glow.
> Sizzle in Glow 2.0, although it's a bit vague about which browsers it intends to support. Would be great to know the details!
What I mentioned in the post still stands: It supports at least as many browsers as jQuery does. I'm absolutely open to accepting patches to fix any deficiencies in older browsers (same goes for jQuery as well!). I'd love to see Glow utilize Sizzle, definitely contact me if you have any questions or concerns.
> Having one library to rule them all doesn't drive things forward, a good example of this is when IE6 was the only major browser, browser development stagnated.
I think that's a poor analogy. Everything stagnated because no one could improve upon IE 6 - it was a proprietary browser which had no way to add in new functionality. This is very different from an Open Source project run by a community of people and companies interested in seeing it improve and strive.
> You mention you communicated with us? I'm not aware of this at all.
I had talked with a member of the team at some post-@Media event (I think it was @Media Ajax, maybe @Media proper). Maybe I'm mis-remembering who exactly but I've definitely chatted with a few people at the BBC about jQuery and Glow.
> Sizzle in Glow 2.0, although it's a bit vague about which browsers it intends to support. Would be great to know the details!
What I mentioned in the post still stands: It supports at least as many browsers as jQuery does. I'm absolutely open to accepting patches to fix any deficiencies in older browsers (same goes for jQuery as well!). I'd love to see Glow utilize Sizzle, definitely contact me if you have any questions or concerns.
I'm less concerned about jQuery's thunder and more concerned about the BBC's use of public money to fund developers' vanity projects.
How is the time and cost which of building and maintaining Glow outweighed by the level of page degradation that Safari 1.3 and other tiny niche users would have experienced (where it could not be mitigated by other page design considerations) using, for example, jQuery?
How is the time and cost which of building and maintaining Glow outweighed by the level of page degradation that Safari 1.3 and other tiny niche users would have experienced (where it could not be mitigated by other page design considerations) using, for example, jQuery?
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.
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.
It's common for people to see something they don't think directly benefits them and decide it's a waste of the licence fee.
Perhaps you're not tied down to older browsers, so Glow has no benefit compared to other libraries, for you personally.
I'm a fan of the Radio 4 programme "More or Less", a review of stats in news stories. It's audience would seem insignificant compared to reality TV shows and soap operas, should the BBC scrap "More or Less" and reassign its budget to reality TV?
Would you say it's wrong that we support screen reader users, even though their numbers are small? Is time spent helping these users a waste of their licence fee?
No, we're happy to cater for minority users even if it means being behind other libraries. I wouldn't want other libraries to do the same, as they can be the choice for people who don't need the support of old browsers, and they can perhaps be faster and leaner for it.
Perhaps you're not tied down to older browsers, so Glow has no benefit compared to other libraries, for you personally.
I'm a fan of the Radio 4 programme "More or Less", a review of stats in news stories. It's audience would seem insignificant compared to reality TV shows and soap operas, should the BBC scrap "More or Less" and reassign its budget to reality TV?
Would you say it's wrong that we support screen reader users, even though their numbers are small? Is time spent helping these users a waste of their licence fee?
No, we're happy to cater for minority users even if it means being behind other libraries. I wouldn't want other libraries to do the same, as they can be the choice for people who don't need the support of old browsers, and they can perhaps be faster and leaner for it.
But you're missing the point that you could have spent the time you spent developing Glow on extending jQuery to do all of these things that you want Glow to do. Then you would have the benefit of everything that jQuery does plus everything that Glow does... but going down separate development paths is not helping anyone at this point.
Unless Glow is doing something nifty that jQuery is not other then supporting screen readers and older browsers.
Unless Glow is doing something nifty that jQuery is not other then supporting screen readers and older browsers.
Of course the BBC should support screen reader users, and of course it should keep producing quality programming which could not otherwise be made.
This is not a matter of providing something people would otherwise not have access to. Safari 1.3 users would have been able to use the site without Glow, but their experience of it would have been a bit degraded. No doubt less so if a fraction of the time put into developing Glow had been put into finding the best ways to mitigate the page degradation. Safari 1.3 may have had its problems but it is essentially a capable rendering engine for the kind of page functionality the BBC uses. After all the BBC is hardly pushing the envelope for HTML & Javascript technology, nor does it need to in order to deliver its content.
I don't see that there is any serious business case for this amount of development to support this level of refinement for such a small group of users. The fact is that developers are in a luxurious position of following what appeals to their vanities rather than delivering value for public funds.
Someone mentioned the team was small. How many of them are contractors vs permanent? I bet they are not all permies. Even so, one permanent salary for two years is a heck of a lot of money to throw after a project replacing something which is 'good enough' and available for free.
Can you point to pages or features on the BBC site which, without the use of Glow, would render content inaccessible or completely unusable to Safari 1.3 users if jQuery had been used?
This is not a matter of providing something people would otherwise not have access to. Safari 1.3 users would have been able to use the site without Glow, but their experience of it would have been a bit degraded. No doubt less so if a fraction of the time put into developing Glow had been put into finding the best ways to mitigate the page degradation. Safari 1.3 may have had its problems but it is essentially a capable rendering engine for the kind of page functionality the BBC uses. After all the BBC is hardly pushing the envelope for HTML & Javascript technology, nor does it need to in order to deliver its content.
I don't see that there is any serious business case for this amount of development to support this level of refinement for such a small group of users. The fact is that developers are in a luxurious position of following what appeals to their vanities rather than delivering value for public funds.
Someone mentioned the team was small. How many of them are contractors vs permanent? I bet they are not all permies. Even so, one permanent salary for two years is a heck of a lot of money to throw after a project replacing something which is 'good enough' and available for free.
Can you point to pages or features on the BBC site which, without the use of Glow, would render content inaccessible or completely unusable to Safari 1.3 users if jQuery had been used?
I don't want to broaden this too much, but you feel the BBC has to support Saf 1.3 with 0% market share because you don't want to force a software update on those 80 odd people whilst on the other hand transitioning to digital forcing a hardware change/purchase on the entire user base?? Seems a bit of a weak argument.
If indeed (as reading between the lines you appear to suggest) if a javascript framework needs to be hobbled to support screenreaders (good!) and obsolete browsers (bad!) then it may not be right to weigh in with one of the top frameworks. But you asked them first though right?
"More or Less" is great. But if commercial radio had a free-to-air program "Less or More" and the only difference was that you transmit at a frequency that's better for reception on crystal sets then I'd hope the BBC wouldn't bother but would add to the diversity of broadcasting some other way.
If indeed (as reading between the lines you appear to suggest) if a javascript framework needs to be hobbled to support screenreaders (good!) and obsolete browsers (bad!) then it may not be right to weigh in with one of the top frameworks. But you asked them first though right?
"More or Less" is great. But if commercial radio had a free-to-air program "Less or More" and the only difference was that you transmit at a frequency that's better for reception on crystal sets then I'd hope the BBC wouldn't bother but would add to the diversity of broadcasting some other way.
It seems like Glow is YAJSL (Yet Another Javascript Library). After looking through the documentation, it doesn't seem to provide anything that jQuery, Prototype, Dojo, Extjs or Mootools doesn't already provide.
Selectors, DOM Manipulation, Events, Ajax, UI Widgets. At least it looks like it doesn't extend js primitives or DOM elements like Prototype and Mootools. It's sad that the BBC is continuing along this path despite the original reason for it... browser support... being a moot issue at this point. The JS world would be better off if they abandoned their support of their internal library and instead focused on using, supporting, and extending one of the existing open-source libraries.
jQuery is so open to user development and its plugin architecture lends itself nicely to the BBC team being able to add any functionality they feel is missing. I hope they at least consider dropping Glow and taking up jQuery instead.
Selectors, DOM Manipulation, Events, Ajax, UI Widgets. At least it looks like it doesn't extend js primitives or DOM elements like Prototype and Mootools. It's sad that the BBC is continuing along this path despite the original reason for it... browser support... being a moot issue at this point. The JS world would be better off if they abandoned their support of their internal library and instead focused on using, supporting, and extending one of the existing open-source libraries.
jQuery is so open to user development and its plugin architecture lends itself nicely to the BBC team being able to add any functionality they feel is missing. I hope they at least consider dropping Glow and taking up jQuery instead.
As I read it, the point is less about providing more functionality than any existing library and more about tailoring the features that Glow does support to match the very specific requirements of the BBC. (If you happen to think some other library is a better match for your needs then I'm sure the folks at the BBC would urge you use it.) But what would happen 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? They'd end up having to maintain some parallel version modified to match their own particular needs. I hardly see how making the work they've done open source and free for everyone to use they're hurting "the JS world."
"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?
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.
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.
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.
You say we should use the library with the most features. What I want to do is pick a library for our organisation to use for the forseeable future. I can't forsee what features I will require in the future. I'm currently using JQuery because that's the one I hear most about.
Whilst it's very kind of you to give your stuff away, I think it makes life harder for those of us having to choose which Yet Another Javascript Library to use.
Whilst it's very kind of you to give your stuff away, I think it makes life harder for those of us having to choose which Yet Another Javascript Library to use.
I'm a BBC World Wide employee, so the usual disclaimer applies: my opinion isn't that of my employer.
I've been a critic of the Glow library since I learnt about it, not because it's not good code (it is a solid enough framework), but because the javascript-library problem has been pretty much solved by now.
I think that in a large organisation such as the Beeb there's a big tendency to want to do things in-house so changes can be made to code-bases easily, there's a standardised way of implementing funcionality across the org, and it's "signed off" for use by management.
The "signed off" bit I think is the main advantage for the BBC developers, as the politics involved in getting external code installed (even JS) on servers is a very heavy workflow.
I've been a critic of the Glow library since I learnt about it, not because it's not good code (it is a solid enough framework), but because the javascript-library problem has been pretty much solved by now.
I think that in a large organisation such as the Beeb there's a big tendency to want to do things in-house so changes can be made to code-bases easily, there's a standardised way of implementing funcionality across the org, and it's "signed off" for use by management.
The "signed off" bit I think is the main advantage for the BBC developers, as the politics involved in getting external code installed (even JS) on servers is a very heavy workflow.
Agree, a waste of time and licence payers money.
There's another problem at work. We have many different teams at the BBC and if one needs a different version of a popular JS library, they need to ensure that this version can be loaded and not muck up other versions. Glow gives you that, something I'm not aware that any other JS library handles. The BBC Web site is huge and with so many different teams working on different projects, expecting all of them to march in lockstep with the same JS library versions is not realistic.
Disclaimer: though I work for the BBC, any views expressed are my own and not official BBC statements.
Disclaimer: though I work for the BBC, any views expressed are my own and not official BBC statements.
Actually, jQuery has had support for having multiple versions of jQuery working, simultaneously, on the same page since August 2007:
http://blog.jquery.com/2007/08/24/jquery-114-faster-more-tes...
We introduced this functionality back then for precisely the reason you outline: Large organizations, coordinating on a single version of code, can be challenging. It's been working out really well so far. (It should be noted that this release likely happened before the work on Glow was even started.)
More details on the noConflict method can be found here:
http://docs.jquery.com/Core/jQuery.noConflict http://docs.jquery.com/Using_jQuery_with_Other_Libraries
We introduced this functionality back then for precisely the reason you outline: Large organizations, coordinating on a single version of code, can be challenging. It's been working out really well so far. (It should be noted that this release likely happened before the work on Glow was even started.)
More details on the noConflict method can be found here:
http://docs.jquery.com/Core/jQuery.noConflict http://docs.jquery.com/Using_jQuery_with_Other_Libraries
Ah, I didn't know that. jQuery didn't have this support when Glow was started. You can read a full list of reasons at: http://www.bbc.co.uk/glow/docs/articles/what_is_glow.shtml
The section on that page titled "How about contributing to a library?" is especially interesting.
> Perhaps we could have contributed code to an existing library to add support for the older browsers our users had? Many of the libraries had previously supported some of our "problem" browsers, and actively chosen to drop that support.
That's correct - jQuery use to have support for IE 5.5 and Safari 1.3 but support for both were dropped after 1) No significant number of users supported either of those browsers and 2) There were no longer any extra resources to dedicate to supporting them.
> We felt it was unlikely they would be enthused about bringing back old browsers they were probably glad to see the back of!
There would've only been one way to find out: To ask! The BBC was a big user of jQuery back in 2007 and we would've bent over backwards to make sure everyone was happy - especially if they were (apparently) willing to contribute code/patches to help solve existing problems.
Unfortunately we didn't find out until the Glow efforts had already been started - it's just water under the bridge at this point.
It's ok though. The BBC is happy with their set up (which is really all that any organization should look for in a library) and we've all learned a lot since then. C'est la vie.
> Perhaps we could have contributed code to an existing library to add support for the older browsers our users had? Many of the libraries had previously supported some of our "problem" browsers, and actively chosen to drop that support.
That's correct - jQuery use to have support for IE 5.5 and Safari 1.3 but support for both were dropped after 1) No significant number of users supported either of those browsers and 2) There were no longer any extra resources to dedicate to supporting them.
> We felt it was unlikely they would be enthused about bringing back old browsers they were probably glad to see the back of!
There would've only been one way to find out: To ask! The BBC was a big user of jQuery back in 2007 and we would've bent over backwards to make sure everyone was happy - especially if they were (apparently) willing to contribute code/patches to help solve existing problems.
Unfortunately we didn't find out until the Glow efforts had already been started - it's just water under the bridge at this point.
It's ok though. The BBC is happy with their set up (which is really all that any organization should look for in a library) and we've all learned a lot since then. C'est la vie.
> we would've bent over backwards to make sure everyone was happy
Or maybe you wouldn't. I guess it all depends. If you happened to decide the BBC's goals were becoming contradictory to your own then who knows which way you'd bend? The point is YOU would be in a position to say yes or no to their needs, and no offense but to tell a very large company like the BBC, "trust me, I'll make sure you're happy, now build all your web pages on top of my library" is not particularly reassuring.
And I don't think anyone has to be a mindreader to know what you'd say if they submitted a patch that meant you'd have to lose some of the selectors you now support and run more slowly in order to add support for a browser with 1.5% market share.
They looked into it and determined it wasn't cost effective to maintain a parallel fork. Okay, whatever. Their needs are unique and they came up with a unique solution, so what? This isn't a zero sum game.
> C'est la vie.
Indeed. For organizations that don't have to give full support to the same minority browsers that the BBC does, then of course it makes sense to use an off-the-shelf library like JQuery. No one ever suggested otherwise.
Or maybe you wouldn't. I guess it all depends. If you happened to decide the BBC's goals were becoming contradictory to your own then who knows which way you'd bend? The point is YOU would be in a position to say yes or no to their needs, and no offense but to tell a very large company like the BBC, "trust me, I'll make sure you're happy, now build all your web pages on top of my library" is not particularly reassuring.
And I don't think anyone has to be a mindreader to know what you'd say if they submitted a patch that meant you'd have to lose some of the selectors you now support and run more slowly in order to add support for a browser with 1.5% market share.
They looked into it and determined it wasn't cost effective to maintain a parallel fork. Okay, whatever. Their needs are unique and they came up with a unique solution, so what? This isn't a zero sum game.
> C'est la vie.
Indeed. For organizations that don't have to give full support to the same minority browsers that the BBC does, then of course it makes sense to use an off-the-shelf library like JQuery. No one ever suggested otherwise.
> The point is YOU would be in a position to say yes or no to their needs
At the point you felt it wasn't working out, you could simply fork it.
> it wasn't cost effective to maintain a parallel fork
But it's cost effective to write a new library from scratch. Err, right.
At the point you felt it wasn't working out, you could simply fork it.
> it wasn't cost effective to maintain a parallel fork
But it's cost effective to write a new library from scratch. Err, right.
> It's ok though. The BBC is happy with their set up
Who says we are ?
No everyone within the organisation agrees that Glow is wanted or was even needed. Certainly not everyone is happy with how this has come about.
Who says we are ?
No everyone within the organisation agrees that Glow is wanted or was even needed. Certainly not everyone is happy with how this has come about.
Unfortunately, the jQuery.noConflict(true) method breaks almost all plugins.
>> Unfortunately, the jQuery.noConflict(true) method breaks >> almost all plugins.
NOT TRUE, if you know how to write plugins. Using some basic knowledge of Javascript (closures, scope, etc) this is very easy to remedy. The problem is that many are too lazy to avoid using the "$" alias, so plugins are often written to depend on it. If you take your "lazy" plugin and wrap in a closure, you can be sure that it will work even when jQuery.noConflict is called... yes, i can hear it now "but when true is passed to noConflict, even the global JQuery variable gets reassigned..." So? Read the source. It gets reassigned very predictably to _jQuery. So, write your plugins like this if you need to support cases where jQuery.noConflict(true) is called:
(function($) {
$.fn.lazyPlugin = function(opt) { // ... }
})(jQuery || _jQuery);
NOT TRUE, if you know how to write plugins. Using some basic knowledge of Javascript (closures, scope, etc) this is very easy to remedy. The problem is that many are too lazy to avoid using the "$" alias, so plugins are often written to depend on it. If you take your "lazy" plugin and wrap in a closure, you can be sure that it will work even when jQuery.noConflict is called... yes, i can hear it now "but when true is passed to noConflict, even the global JQuery variable gets reassigned..." So? Read the source. It gets reassigned very predictably to _jQuery. So, write your plugins like this if you need to support cases where jQuery.noConflict(true) is called:
(function($) {
$.fn.lazyPlugin = function(opt) { // ... }
})(jQuery || _jQuery);
Since you seem to be well in the know about this whole project, how much of it would you attribute to NIH and how much to actual need ?
I'm not sure since I didn't do any work on it. I just work with many of the people who do.
For the most part, we're loathe to reinvent wheels (honestly, that whole "Perl on Rails" thing was due to a long, complicated mess we had little control over). We also have legal restrictions regarding accessibility which may very well have played a part in this (just a guess, but I wouldn't be surprised). You can read full explanation of our reasons at http://www.bbc.co.uk/glow/docs/articles/what_is_glow.shtml
For the most part, we're loathe to reinvent wheels (honestly, that whole "Perl on Rails" thing was due to a long, complicated mess we had little control over). We also have legal restrictions regarding accessibility which may very well have played a part in this (just a guess, but I wouldn't be surprised). You can read full explanation of our reasons at http://www.bbc.co.uk/glow/docs/articles/what_is_glow.shtml
I'm a BBC client-side developer. For the record, I am not nor have I ever been part of the Glow team. However, I would like to point out, expressing my own view and mine alone of course, that most of the self-appointed experts on the inner workings of the BBC posting comments here appear to have entirely missed the point about Glow.
Firstly, whatever anyone outside the Beeb might imagine, the fact is that BBC developers are obliged to adhere to a tough set of browser support standards imposed on us from above. No Javascript library was available which met these standards. Glow came along to solve this long-standing, highly frustrating problem and has finally freed our developers to get some really useful Javascript-enhanced UIs onto BBC websites. This is its primary purpose. Offering it to the public is a nice extra but it was not the main reason for creating Glow.
Secondly, all this talk of how much Glow costs licence fee payers is nonsense. To my knowledge, much of the work on Glow has been implemented by a very small number of dedicated individuals, often fitting this work around other responsibilities. Glow has already saved many developer hours across the BBC by eliminating duplication of work across a number of teams and by making it a lot quicker and easier to get quality-assured JS enhancements onto our sites. Far from wasting licence fee money, over time, Glow will mean a substantial saving.
Thirdly, I don't really know Jake, but I kind of met him once at a meeting about Glow in its very early days. He struck me as a pretty humble, unassuming person rather than the deranged ego-tripper some of the rants on this page suggest.
Finally, FAO Mr Resig: Without doubt you are a true coding hero to many of my colleagues. However, if you didn't talk to Jake before now, I think you must have been mistaken in believing you had spoken to the Glow team.
Steven
Firstly, whatever anyone outside the Beeb might imagine, the fact is that BBC developers are obliged to adhere to a tough set of browser support standards imposed on us from above. No Javascript library was available which met these standards. Glow came along to solve this long-standing, highly frustrating problem and has finally freed our developers to get some really useful Javascript-enhanced UIs onto BBC websites. This is its primary purpose. Offering it to the public is a nice extra but it was not the main reason for creating Glow.
Secondly, all this talk of how much Glow costs licence fee payers is nonsense. To my knowledge, much of the work on Glow has been implemented by a very small number of dedicated individuals, often fitting this work around other responsibilities. Glow has already saved many developer hours across the BBC by eliminating duplication of work across a number of teams and by making it a lot quicker and easier to get quality-assured JS enhancements onto our sites. Far from wasting licence fee money, over time, Glow will mean a substantial saving.
Thirdly, I don't really know Jake, but I kind of met him once at a meeting about Glow in its very early days. He struck me as a pretty humble, unassuming person rather than the deranged ego-tripper some of the rants on this page suggest.
Finally, FAO Mr Resig: Without doubt you are a true coding hero to many of my colleagues. However, if you didn't talk to Jake before now, I think you must have been mistaken in believing you had spoken to the Glow team.
Steven
I've given this a few weeks' thought -- and I still think it's absolutely bonkers that a team of highly skilled BBC developers have spent more than two years building... a JavaScript library!
Long, rambling response below.
The Glow library is well designed, but why on earth did the Glow developers want to reinvent the wheel? The reason they give -- to support old browsers not covered by existing libraries -- just doesn't make sense.
They didn't want to fork jQuery, but they're happy to build and maintain an entire framework instead?
Why not a BBC operating system and browser while we're at it?
Glow's ultra-niche-browser-support argument is specious. The BBC has far more pressing accessibility needs than JavaScript support for Safari 2 -- which is what the Glow team cite. According to http://marketshare.hitslink.com, Internet Explorer 5.0 market share is around 0.04% -- which Glow only gives partial ('level 2') support to -- and Safari 2 share doesn't even rate in the top 40 browsers, i.e. Safari share is below 0.03%. In fact, it looks like other frameworks already have better browser and platform coverage anyway: the best Glow can offer is that "our support table is actually closer to other libraries' than it has ever been".
The BBC's comment on www.bbc.co.uk/blogs/bbcinternet that "we merely felt it wasn't for us" sounds like a very poor reason for spending a huge amount of effort and budget on not collaborating with jQuery.
The Glow team also claim that "we need to ensure critical bug fixes, new features etc are released on a schedule we can control". This doesn't make sense. Features are added and bugs are fixed on other JavaScript frameworks, by thousands of volunteers. In practice, production versions don't tend to have 'critical bugs': they have minor glitches, or miss relatively unimportant features. Unless Glow becomes a dominant JavaScript framework, which is highly unlikely, it will never be as reliable as other frameworks, because it will never have the same level of resources for bug fixing, testing, and feature development.
They also state that "we needed a library that could sit alongside other potentially incompatible versions without namespace collisions or CSS styles clashing", but what is the evidence that this happens in other frameworks?
Outside the BBC, who exactly will use Glow? The Glow team themselves say that Glow "has been (so far) developed with the BBC's page templates in mind, and some modules may have issues outside of them". Why on earth would I want to use Glow on my site then? And if it's only ever used on the BBC, why will anyone want to get involved in development?
Now the BBC is stuck with a massive code maintenance nightmare for many years to come, for every new and legacy hardware platform, operating system, operating system version, browser, browser version -- and all the individual OS and browser configurations that make frameworks a pain to maintain.
...and what about the 6% of browsers that don't have JavaScript, or have JavaScript disabled? All core BBC content and navigation must be accessible without JavaScript anyway, as stated in section 2.1 of the Future Media Standards and Guidelines: 'Our users MUST be able to get the core editorial proposition irrespective of the level of JavaScript support in their browser.' In other words, by BBC policy, JavaScript must only ever be an embellishment and not a core part of editorial content.
...and I'd like to know specifically what is not working in these old browsers anyway. I bet there are plenty of more pressing bugs and JavaScript accessibility problems: take a look at bbc.co.uk and there's bound to be something that doesn't work. It's highly likely that specific old-browser problems could have been sorted out case-by-case if really necessary, with a patch or plugin to existing frameworks. There was never any need to fork an existing library, let alone build a whole new framework.
JavaScript libraries such as YUI, jQuery, Dojo and Prototype are all far more mature than Glow. The BBC could have standardized on any one of them. All have excellent APIs, extremely high production values, and thousands of contributors -- including some of the world's very best programmers. Do Glow have a Douglas Crockford or John Resig on the team?
Glow seems to have started life as an old-fashioned, in-house project, and now the BBC is attempting to open-source it in order to dodge the problem of maintenance -- even though the best external developers are unlikely to contribute to Yet Another JavaScript Framework. This is a reputation-damaging, wasted opportunity: the BBC could have set a healthy precedent collaborating with outside developers and software projects. As John Resig says of jQuery, existing framework developers would have bent over backwards to cooperate if the BBC had contacted them. Instead, the BBC stays a closed shop, and developers coming to the BBC will have to throw away their skills in jQuery (or whatever) and learn Glow from scratch.
It's healthy to have a market for alternative JavaScript libraries. But at a time when the BBC is under tight scrutiny and intense political and budgetary pressure, why waste precious resources trying to compete when others will do it for free?
...and no doubt the BBC will now get flamed endlessly for spending two years wasting licence fee on an irrelevant project.
Long, rambling response below.
The Glow library is well designed, but why on earth did the Glow developers want to reinvent the wheel? The reason they give -- to support old browsers not covered by existing libraries -- just doesn't make sense.
They didn't want to fork jQuery, but they're happy to build and maintain an entire framework instead?
Why not a BBC operating system and browser while we're at it?
Glow's ultra-niche-browser-support argument is specious. The BBC has far more pressing accessibility needs than JavaScript support for Safari 2 -- which is what the Glow team cite. According to http://marketshare.hitslink.com, Internet Explorer 5.0 market share is around 0.04% -- which Glow only gives partial ('level 2') support to -- and Safari 2 share doesn't even rate in the top 40 browsers, i.e. Safari share is below 0.03%. In fact, it looks like other frameworks already have better browser and platform coverage anyway: the best Glow can offer is that "our support table is actually closer to other libraries' than it has ever been".
The BBC's comment on www.bbc.co.uk/blogs/bbcinternet that "we merely felt it wasn't for us" sounds like a very poor reason for spending a huge amount of effort and budget on not collaborating with jQuery.
The Glow team also claim that "we need to ensure critical bug fixes, new features etc are released on a schedule we can control". This doesn't make sense. Features are added and bugs are fixed on other JavaScript frameworks, by thousands of volunteers. In practice, production versions don't tend to have 'critical bugs': they have minor glitches, or miss relatively unimportant features. Unless Glow becomes a dominant JavaScript framework, which is highly unlikely, it will never be as reliable as other frameworks, because it will never have the same level of resources for bug fixing, testing, and feature development.
They also state that "we needed a library that could sit alongside other potentially incompatible versions without namespace collisions or CSS styles clashing", but what is the evidence that this happens in other frameworks?
Outside the BBC, who exactly will use Glow? The Glow team themselves say that Glow "has been (so far) developed with the BBC's page templates in mind, and some modules may have issues outside of them". Why on earth would I want to use Glow on my site then? And if it's only ever used on the BBC, why will anyone want to get involved in development?
Now the BBC is stuck with a massive code maintenance nightmare for many years to come, for every new and legacy hardware platform, operating system, operating system version, browser, browser version -- and all the individual OS and browser configurations that make frameworks a pain to maintain.
...and what about the 6% of browsers that don't have JavaScript, or have JavaScript disabled? All core BBC content and navigation must be accessible without JavaScript anyway, as stated in section 2.1 of the Future Media Standards and Guidelines: 'Our users MUST be able to get the core editorial proposition irrespective of the level of JavaScript support in their browser.' In other words, by BBC policy, JavaScript must only ever be an embellishment and not a core part of editorial content.
...and I'd like to know specifically what is not working in these old browsers anyway. I bet there are plenty of more pressing bugs and JavaScript accessibility problems: take a look at bbc.co.uk and there's bound to be something that doesn't work. It's highly likely that specific old-browser problems could have been sorted out case-by-case if really necessary, with a patch or plugin to existing frameworks. There was never any need to fork an existing library, let alone build a whole new framework.
JavaScript libraries such as YUI, jQuery, Dojo and Prototype are all far more mature than Glow. The BBC could have standardized on any one of them. All have excellent APIs, extremely high production values, and thousands of contributors -- including some of the world's very best programmers. Do Glow have a Douglas Crockford or John Resig on the team?
Glow seems to have started life as an old-fashioned, in-house project, and now the BBC is attempting to open-source it in order to dodge the problem of maintenance -- even though the best external developers are unlikely to contribute to Yet Another JavaScript Framework. This is a reputation-damaging, wasted opportunity: the BBC could have set a healthy precedent collaborating with outside developers and software projects. As John Resig says of jQuery, existing framework developers would have bent over backwards to cooperate if the BBC had contacted them. Instead, the BBC stays a closed shop, and developers coming to the BBC will have to throw away their skills in jQuery (or whatever) and learn Glow from scratch.
It's healthy to have a market for alternative JavaScript libraries. But at a time when the BBC is under tight scrutiny and intense political and budgetary pressure, why waste precious resources trying to compete when others will do it for free?
...and no doubt the BBC will now get flamed endlessly for spending two years wasting licence fee on an irrelevant project.
"The Glow library is well designed, but why on earth did the Glow developers want to reinvent the wheel? The reason they give -- to support old browsers not covered by existing libraries -- just doesn't make sense."
Real reason :- They are spending their time and their money and the best people to decide how to spend both are the people who "own" both the time and money.
I guessSome devs managed to convince a manager(with budgeting authority) that this was a good idea.
Not that that's a bad thing. In general, I am all in favour of people reinventing wheels sometimes. Every reinvented wheel often fits local circimstances better, (omits unneeded functionality/generality etc) and is a good learning experience, if nothing else. Monoculture sucks.
So "why did they do it ? " is largely an exercise in rhetoric ... except for your key point ( I upvoted you btw)
"But at a time when the BBC is under tight scrutiny and intense political and budgetary pressure, why waste precious resources trying to compete when others will do it for free?"
The fact that they spent public money to do this is far more dubious. That said, large organizations waste a tonne of money on utterly trivial things - a few programmers salary for a couple of years (or whatever the time frame was) is likely to be small beans, relatively.
Real reason :- They are spending their time and their money and the best people to decide how to spend both are the people who "own" both the time and money.
I guessSome devs managed to convince a manager(with budgeting authority) that this was a good idea.
Not that that's a bad thing. In general, I am all in favour of people reinventing wheels sometimes. Every reinvented wheel often fits local circimstances better, (omits unneeded functionality/generality etc) and is a good learning experience, if nothing else. Monoculture sucks.
So "why did they do it ? " is largely an exercise in rhetoric ... except for your key point ( I upvoted you btw)
"But at a time when the BBC is under tight scrutiny and intense political and budgetary pressure, why waste precious resources trying to compete when others will do it for free?"
The fact that they spent public money to do this is far more dubious. That said, large organizations waste a tonne of money on utterly trivial things - a few programmers salary for a couple of years (or whatever the time frame was) is likely to be small beans, relatively.
Don't get me wrong: I'm a huge fan of reinventing the wheel.
Google did this -- and people asked why on earth we might need a new search engine when we already had AltaVista and the rest.
It's just that, in my opinion, as you point out, not what the BBC should have done in this case. (And thanks for upvoting me!)
Google did this -- and people asked why on earth we might need a new search engine when we already had AltaVista and the rest.
It's just that, in my opinion, as you point out, not what the BBC should have done in this case. (And thanks for upvoting me!)
OK, I've listened to both sides. I can understand the need at BBC for support for most of their legacy users up to a point (schools with old computers and stuff like that). What I fail to understand is why start a framework from scratch? Couldn't you guys at BBC contribute legacy support to some of the frameworks (be it jquery or some other) or fork it and do what you need? Isn't that a more rational use of resources?
My bottom line is that, as a publicly, tax funded organisation this is a total waste of time (and money). Other, open source frameworks are, at the very least, good enough.
Hiding some individuals ego trip behind the stated good of "inclusivity" is weak and unconvincing. The glow framework bespeaks egos run rampant and an IT department with a budget beyond its remit.
I worked for a consultancy that produced video on demand to rival iPlayer for a 10th of the budget in a quarter of the time. I've worked at government funded orgs too, and even though the consultancy was greedy, grasping, rapacious, dishonest and generally incompetent at least they had to contend with genuine market forces.
The BBC reeks of cronyism, old boyism and general too cool for schoolism. I'm glad they open sourced it but what use is it to anyone?
I feel not unlike a Red Top reader caught in some issue related rant but that bottom line is rearing up at me like a moon from the smug wasters at the beebs IT dept. In the words of "Annoyed" of Froom, "Why oh why oh why, BBC, did you waste the licence fee on this half-baked, ill conceived, masturbatory effort when you could of used JQuery and knocked out your code in 1/10th of the time? (And then made a nice episode of Caedfell)?"
(You may have to have be a UK citizen, raised on main stream TV in the last 30 years to understand the Points Of View reference)
Hiding some individuals ego trip behind the stated good of "inclusivity" is weak and unconvincing. The glow framework bespeaks egos run rampant and an IT department with a budget beyond its remit.
I worked for a consultancy that produced video on demand to rival iPlayer for a 10th of the budget in a quarter of the time. I've worked at government funded orgs too, and even though the consultancy was greedy, grasping, rapacious, dishonest and generally incompetent at least they had to contend with genuine market forces.
The BBC reeks of cronyism, old boyism and general too cool for schoolism. I'm glad they open sourced it but what use is it to anyone?
I feel not unlike a Red Top reader caught in some issue related rant but that bottom line is rearing up at me like a moon from the smug wasters at the beebs IT dept. In the words of "Annoyed" of Froom, "Why oh why oh why, BBC, did you waste the licence fee on this half-baked, ill conceived, masturbatory effort when you could of used JQuery and knocked out your code in 1/10th of the time? (And then made a nice episode of Caedfell)?"
(You may have to have be a UK citizen, raised on main stream TV in the last 30 years to understand the Points Of View reference)
Russelldb: "I'm glad they open sourced it but what use is it to anyone?"
I'll bet they can include "using Glow in a large corporate environment for 2 years" as a requirement on all dev jobs in the new media arm that have to be advertised outside too. Nice move.
code-monkey manager: 'we need pay increases to retain talent because devs with Glow familiarity can't be found anywhere' ...
Probably a bit over-cynical.
I'll bet they can include "using Glow in a large corporate environment for 2 years" as a requirement on all dev jobs in the new media arm that have to be advertised outside too. Nice move.
code-monkey manager: 'we need pay increases to retain talent because devs with Glow familiarity can't be found anywhere' ...
Probably a bit over-cynical.
Pretty much the same happened around CMS in the Netherlands broadcast sphere, I always figured that it must be really comfy when your paycheck is based on taxation and not on some kind of competitive success.
If you're a business and your opponent can leverage an existing solution vs you hacking out your own in the basement you'll find out the hard way that this was not a very smart move.
If you're a business and your opponent can leverage an existing solution vs you hacking out your own in the basement you'll find out the hard way that this was not a very smart move.
I think the two libraries should combine and call themselves GlowQuery.noConflict(!yippee);
On a serious note, I can see the frustration the beeb had and why they made Glow. But I agree with John Resig as far as saying that there's already a fragmented market.
Hopefully there will be positive dialogue between the BBC and the wider community and we can continue to make the web a better place. I know I'll still be using jQuery, but I also reckon I'll have to learn Glow if I ever want to get some work there, which isn't a huge deal, but something we all have to live with regardless of what we do on the web. Constant change and development.
On a serious note, I can see the frustration the beeb had and why they made Glow. But I agree with John Resig as far as saying that there's already a fragmented market.
Hopefully there will be positive dialogue between the BBC and the wider community and we can continue to make the web a better place. I know I'll still be using jQuery, but I also reckon I'll have to learn Glow if I ever want to get some work there, which isn't a huge deal, but something we all have to live with regardless of what we do on the web. Constant change and development.
Yeah, I don't really get it. Going through their code, docs, it doesn't seem to really offer anything new. I commend them for the open source, but in the end: meh.
gotta say there seem to be a lot of bashing of bbc and not a lot of talk about the actual code, the efforts made by the bbc to make glow are entirely understandable where i'm sitting ( in a bbc office )
the code itself is easy to use which is all we can ask for , and it takes care we have a quick response from the glow team (as anyone who has bothered to join the list will of found out) it has done everything that as a bbc employee i have needed it to do and done it in a fully accessible and degradable way. these are the things that are most important to the bbc, as we have a charter to make it accessible to all, regardless of how small the minority is.
maybe you should check out the library and use it before you criticise it as "just another javascript library" after all that is how jquery started out and look at it now :-)
the code itself is easy to use which is all we can ask for , and it takes care we have a quick response from the glow team (as anyone who has bothered to join the list will of found out) it has done everything that as a bbc employee i have needed it to do and done it in a fully accessible and degradable way. these are the things that are most important to the bbc, as we have a charter to make it accessible to all, regardless of how small the minority is.
maybe you should check out the library and use it before you criticise it as "just another javascript library" after all that is how jquery started out and look at it now :-)
I think it is unfair to roll out a new JS library when Jhon is working so hard to do the "BEST" at most popular, easy, great jQuery.
We will not let you fall John EB
We will not let you fall John EB
I think it's a bit funny that so many here seem to just naturally assume that by creating their own library the BBC have therefore denied JQUERY another badge for their homepage. @adradesign, have you ever considered the possibility that they actually would have gone with moo, or prototype or yui or one of the many other alternatives instead?
this is exactly the wrong answer. i guess you are trolling.
Sounds to me like the whole Perl thing all over again where the BBC weren't happy with the standard version so decided to write their own - which meant they could't patch it with standard Perl.
Either that or some department needed to justify their budget or be cut. Typical BBC bureaucracy and a waste of us licence payers money.
Either that or some department needed to justify their budget or be cut. Typical BBC bureaucracy and a waste of us licence payers money.
Almost as hilarious as their multi-language 'MVC' approach that they were discussing implementing for a couple of years, I wonder if it's been done yet.
I recall them wanting to use php for their views and some weird concoction of Java / Perl / Ruby / Python for everything else.
I recall them wanting to use php for their views and some weird concoction of Java / Perl / Ruby / Python for everything else.
And they're doing it again with the move to the new technology platform Forge - monkeypatching ZF so that is just a little bit different and writing their own PHP templating language Spectrum. BBC FM&T has a bad case of the NIH.
Completely disagree here. I have worked at the beeb through the good and bad times (arcane scripting languages built on top of mod_perl), there has been a recent and very fast transition to using much more open industry standard technologies.
I've been working on the new platform since it was released and 99% of the time have been using pure ZF code. Not sure who makes the tech decisions where you are but I'm seeing no indication of NIH.
I've been working on the new platform since it was released and 99% of the time have been using pure ZF code. Not sure who makes the tech decisions where you are but I'm seeing no indication of NIH.
Its so nice to see traditional media releasing open source tools like this. See also the New York Times release of their map reduce toolkit http://open.blogs.nytimes.com/2009/05/11/announcing-the-mapr...
Agreed.
The Washington Times have also released some pretty impressive open-source django apps over at http://opensource.washingtontimes.com/projects/
it includes django-supertagging which is pretty much the best automated django tagging solution out there!
The Washington Times have also released some pretty impressive open-source django apps over at http://opensource.washingtontimes.com/projects/
it includes django-supertagging which is pretty much the best automated django tagging solution out there!
Everything the BBC codes that is not restricted by outside licenses should be available to anyone in the UK who pays license fees and wants it. Open Sourcing is hardly a great gesture when the public have paid for it already.
Since I paid for this (as a license fee payer in the UK) I'm glad it's been opened. You don't need to thank me :)
I look forward to the day they send me Blu-rays's of my tv programs as well :)
I look forward to the day they send me Blu-rays's of my tv programs as well :)
Well. I just looked through Glow, and ...
Yeah.
Anyway, to salvage something from this: all I want out of these "frameworks" are ways to do DOM work based on CSS selectors.
jQuery, prototype, dojo ... all I want is $(..)
Anyhow, I was in the middle of ripping down dojo's query.js, which is the standalone CSS3 select/query part of dojo, so I could just deal with that without the rest, and I stumbled across DOMAssistant.
I've only been using it a couple of days now, but it's less painful than the other frameworks, because it pollutes my head less.
It's basically just A) the fastest and most complete CSS2.1 and CSS3 selectors (currently fastest slickspeed), and B) a minimal framework where everything is accessible off of $() and $$().
The 'whole' thing is 9k gzipped, too.
Anyway, there are probably a ton of very useful things that jQuery/prototype/effects.js/mootools do that all-day js wonks know like the back of their hands; I like DOM assistant for the querying, though.
Yeah.
Anyway, to salvage something from this: all I want out of these "frameworks" are ways to do DOM work based on CSS selectors.
jQuery, prototype, dojo ... all I want is $(..)
Anyhow, I was in the middle of ripping down dojo's query.js, which is the standalone CSS3 select/query part of dojo, so I could just deal with that without the rest, and I stumbled across DOMAssistant.
I've only been using it a couple of days now, but it's less painful than the other frameworks, because it pollutes my head less.
It's basically just A) the fastest and most complete CSS2.1 and CSS3 selectors (currently fastest slickspeed), and B) a minimal framework where everything is accessible off of $() and $$().
The 'whole' thing is 9k gzipped, too.
Anyway, there are probably a ton of very useful things that jQuery/prototype/effects.js/mootools do that all-day js wonks know like the back of their hands; I like DOM assistant for the querying, though.
I think the more exciting part of this is to see another media company releasing open source code. As it's been said, the JS library is becoming a crowded space and perhaps it would have been better for them to contact another library and see about integrating into it.
I think we're going to see the beginning of meta libraries. Code which links up multiple libraries. Maybe you grab a few libs from moo, prototype and jquery, and then layer Glow on top?
Useless side note: When I was planning my own blogging engine I was going to call it 'Glow' so I definitely like the name at least :)
I think we're going to see the beginning of meta libraries. Code which links up multiple libraries. Maybe you grab a few libs from moo, prototype and jquery, and then layer Glow on top?
Useless side note: When I was planning my own blogging engine I was going to call it 'Glow' so I definitely like the name at least :)
All these arguments about BBC should have just used jQuery are non-starters.
There are plenty of off the shelf website production systems on the market, for instance. If you think a JS team should only ever use a library, I presume all your websites are created in Drupal using built in templates.
Software you produce yourself does exactly what you want with no bloat. jQuery is excellent, but there will always be gaps in it for any given organisation. Additionally there will be bloat. Sizzle is fantastic software, but my guess (based on actual observations) is that 90-95% of the selectors it is given in the wild are of the '#someid' or 'tag.classname' type. These can be handled with 20 lines of code, but Sizzle is closer to 1000. Many libraries contain code to support use on both standards compliant and quirks mode web pages, but if you only ever code in one of these, that extra code is useless.
Then there is the issue of dependency. External dependencies are one of the weakest points of any software product. You can't directly fix bugs or fill functionality gaps, so you must either branch the product or work around the issues. Both approaches cause pain when wishing to upgrade to the next version (a decision which may be forced on you by the supplier's support levels) by either having to re-engineer the patch or check compatibility of the workaround. Yes, you can submit bugs or patches, but you cannot control when, or even if, these will end up in a released version. Even if your bug is fixed, you may still have to re-engineer your codebase, because the fix may break your workaround.
If your organisation has the resources to produce a piece of software itself, it should. That organisation will end up with a product that does exactly what is required with no bloat, will avoid the pain of external dependencies, and will have team of people on board which provides a centre of excellence for that technology. For organisations much smaller than the BBC, these benefits will probably outweigh the small cost saving of using a JS library like jQuery. For the BBC, it's a "no-brainer".
There are plenty of off the shelf website production systems on the market, for instance. If you think a JS team should only ever use a library, I presume all your websites are created in Drupal using built in templates.
Software you produce yourself does exactly what you want with no bloat. jQuery is excellent, but there will always be gaps in it for any given organisation. Additionally there will be bloat. Sizzle is fantastic software, but my guess (based on actual observations) is that 90-95% of the selectors it is given in the wild are of the '#someid' or 'tag.classname' type. These can be handled with 20 lines of code, but Sizzle is closer to 1000. Many libraries contain code to support use on both standards compliant and quirks mode web pages, but if you only ever code in one of these, that extra code is useless.
Then there is the issue of dependency. External dependencies are one of the weakest points of any software product. You can't directly fix bugs or fill functionality gaps, so you must either branch the product or work around the issues. Both approaches cause pain when wishing to upgrade to the next version (a decision which may be forced on you by the supplier's support levels) by either having to re-engineer the patch or check compatibility of the workaround. Yes, you can submit bugs or patches, but you cannot control when, or even if, these will end up in a released version. Even if your bug is fixed, you may still have to re-engineer your codebase, because the fix may break your workaround.
If your organisation has the resources to produce a piece of software itself, it should. That organisation will end up with a product that does exactly what is required with no bloat, will avoid the pain of external dependencies, and will have team of people on board which provides a centre of excellence for that technology. For organisations much smaller than the BBC, these benefits will probably outweigh the small cost saving of using a JS library like jQuery. For the BBC, it's a "no-brainer".
Another JavaScript library, this space is already crowded and from what I can tell, there nothing available in Glow that isn't available in other popular libraries.
Maybe being backwards compatible to IE 5.5 is important enough to switch to this I don't know.
Maybe being backwards compatible to IE 5.5 is important enough to switch to this I don't know.
> this space is already crowded
"Cambrian Explosion" springs to mind.
Javascript libraries, Web frameworks and CMS's all seem to have this theme where the perceived difficulty of rolling your own is less then bending something existing to your will.
"Cambrian Explosion" springs to mind.
Javascript libraries, Web frameworks and CMS's all seem to have this theme where the perceived difficulty of rolling your own is less then bending something existing to your will.
I can understand why backwards compatability is important for an organisation such as the BBC. But at the same time it would be really nice if these larger organisations were encouraging people to upgrade their browsers where possible.
But not so nice if you're a paying user (via the license fee) and upgrading means a new OS or computer. I think their mandate is to work for their paying users, ahead of helping web developers.
But the web is worldwide, how many readers of BBC news are from outside the UK? And not every UK citizen has to purchase a license.
They've recently been trying to encourage everyone to make the switch to digitial TVs. I'm sure it's a lot easier to get people to upgrade their browser than buy a new television.
They've recently been trying to encourage everyone to make the switch to digitial TVs. I'm sure it's a lot easier to get people to upgrade their browser than buy a new television.
The BBC has a specific mandate to the British people. If they are not serving them then they are not doing their job.
We're talking mainly bells and whistles (progressive enhancement) via Glow not basic access to data.
That said BBC produce a lot of content for the web that not everyone can get (people don't all have computers), several digital radio channels (not everyone has digi-radio), several digi-TV channels (a lot can't even get the signal, many don't have the hardware).
So the BBC aren't worried about large scale access issues, why worry so much about obsolete browsers?
That said BBC produce a lot of content for the web that not everyone can get (people don't all have computers), several digital radio channels (not everyone has digi-radio), several digi-TV channels (a lot can't even get the signal, many don't have the hardware).
So the BBC aren't worried about large scale access issues, why worry so much about obsolete browsers?
Indeed - was reinventing the wheel really a good use of my TV tax money?
Now, I should take a step back and mention that some people are just set to be framework authors. They see a problem and want to write their own framework that matches their mental model. This isn't a bad thing - I certainly did that when I wrote jQuery (decided not to use Prototype back in 2005 and wrote my own instead) and the BBC guys are of the same ilk. It's important to realize that the BBC's Glow effort is less about filling a specific void in the market and more about them wanting to write and run their own framework. In an organization as large as the BBC this scale does tend to make its own brand of sense.
If you look through the timeline for when changes were made to the level of browser support, v3.3 shows when support for Safari 1.3 was dropped to "Level 2" (a.k.a. "The web page must be functional in a gracefully degraded state.") - this was in September of 2008 (long before the public release of the library, today).
Timeline: http://www.bbc.co.uk/guidelines/futuremedia/technical/browse...
If you look at the support table for which browsers they support (the important ones are Level 1) it's interesting to note that they actually support less browsers on less platforms than most other libraries. For example, jQuery supports Firefox 3.5 (on Windows, OSX, Linux), Chrome 2 (on Windows), Opera 10 (on Windows and OSX), and Safari 4 (on Windows and OSX) in addition to the browsers listed in Glow's Level 1.
Support Table: http://www.bbc.co.uk/guidelines/futuremedia/technical/browse...
In the end I think some seriously short-sighted planning went into the creation of Glow. When I was talking with some of the guys at the BBC who were working on it (before they were using it internally) I asked them: "Don't you think that you will have dropped support for Safari 1.3 before you end up finishing and releasing the library? Writing a framework isn't trivial, it's going to take a while and Safari 1.3 is already effectively dead." (At the time Safari 1.3 had a 0% marketshare.)
And now, sure enough, here we have yet another JavaScript library that does similar, but not quite the same, things as every other library - with worse browser support, less uptake, less documentation, and more fracturing of the community.