18 ms·

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

by Ovid 17y ago

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.

jeresig 17y ago
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-tests-ready-for-12/ 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/Core/jQuery.noConflict http://docs.jquery.com/Using_jQuery_with_Other_Libraries http://docs.jquery.com/Using_jQuery_with_Other_Libraries
- Ovid 17y ago
  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 http://www.bbc.co.uk/glow/docs/articles/what_is_glow.shtml
  - jeresig 17y ago
    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.
    - codepants 17y ago
      > 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.
      - neaj 17y ago
        > 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.
    - rarepleasues 17y ago
      > 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.
- ZitchDog 17y ago
  Unfortunately, the jQuery.noConflict(true) method breaks almost all plugins.
  - keeganwatkins 17y ago
    >> 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);
jacquesm 17y ago
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 ?
- Ovid 17y ago
  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 http://www.bbc.co.uk/glow/docs/articles/what_is_glow.shtml

by Ovid 17y ago

jeresig 17y ago

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-tests-ready-for-12/ 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/Core/jQuery.noConflict http://docs.jquery.com/Using_jQuery_with_Other_Libraries http://docs.jquery.com/Using_jQuery_with_Other_Libraries

Ovid 17y ago
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 http://www.bbc.co.uk/glow/docs/articles/what_is_glow.shtml
- jeresig 17y ago
  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.
  - codepants 17y ago
    > 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.
    - neaj 17y ago
      > 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.
  - rarepleasues 17y ago
    > 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.
ZitchDog 17y ago
Unfortunately, the jQuery.noConflict(true) method breaks almost all plugins.
- keeganwatkins 17y ago
  >> 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);

jacquesm 17y ago

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 ?

Ovid 17y ago
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 http://www.bbc.co.uk/glow/docs/articles/what_is_glow.shtml