8 ms·

BBC open source their "Glow" Javascript library

107 points by intranation 17y ago

mgrouchy 17y ago
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.
- biaxident 17y ago
  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.
  - akronim 17y ago
    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.
    - biaxident 17y ago
      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.
      - dandean 17y ago
        The BBC has a specific mandate to the British people. If they are not serving them then they are not doing their job.
        pbhjpbhj 17y ago
        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?
- gaius 17y ago
  Indeed - was reinventing the wheel really a good use of my TV tax money?
- andyn 17y ago
  > 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.
rjurney 17y ago
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-mapreduce-toolkit/ http://open.blogs.nytimes.com/2009/05/11/announcing-the-mapr...
- Torn 17y ago
  Agreed. The Washington Times have also released some pretty impressive open-source django apps over at http://opensource.washingtontimes.com/projects/ http://opensource.washingtontimes.com/projects/ it includes django-supertagging which is pretty much the best automated django tagging solution out there!
- pbhjpbhj 17y ago
  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.
dazzawazza 17y ago
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 :)
trickjarrett 17y ago
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 :)
jeresig 17y ago
The BBC's Glow effort has always confused me. They were using jQuery on the main BBC web site a few years back and I ended up chatting with them about it. They mentioned that they were working on their own library since they needed support for Safari 1.3 (if you've ever had to support that browser version, it's miserable - I'm not even sure it could be described as 'functional'). This was a little bit odd since they hadn't actually submitted any tickets or patches requesting that Safari 1.3-related bugs be fixed. 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/browser_support.shtml#history 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/browser_support.shtml#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.
mr_luc 17y ago
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.
hubbardr 17y ago
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".

107 points by intranation 17y ago

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.

biaxident 17y ago
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.
- akronim 17y ago
  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.
  - biaxident 17y ago
    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.
    - dandean 17y ago
      The BBC has a specific mandate to the British people. If they are not serving them then they are not doing their job.
      - pbhjpbhj 17y ago
        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?
gaius 17y ago
Indeed - was reinventing the wheel really a good use of my TV tax money?
andyn 17y ago
> 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.

rjurney 17y ago

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-mapreduce-toolkit/ http://open.blogs.nytimes.com/2009/05/11/announcing-the-mapr...

Torn 17y ago
Agreed. The Washington Times have also released some pretty impressive open-source django apps over at http://opensource.washingtontimes.com/projects/ http://opensource.washingtontimes.com/projects/ it includes django-supertagging which is pretty much the best automated django tagging solution out there!
pbhjpbhj 17y ago
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.

dazzawazza 17y ago

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 :)

trickjarrett 17y ago

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 :)

jeresig 17y ago

The BBC's Glow effort has always confused me. They were using jQuery on the main BBC web site a few years back and I ended up chatting with them about it. They mentioned that they were working on their own library since they needed support for Safari 1.3 (if you've ever had to support that browser version, it's miserable - I'm not even sure it could be described as 'functional'). This was a little bit odd since they hadn't actually submitted any tickets or patches requesting that Safari 1.3-related bugs be fixed. 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/browser_support.shtml#history 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/browser_support.shtml#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.

mr_luc 17y ago

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.

hubbardr 17y ago

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".