Browser Support for Jquery, Infragistics, Telerik, Component One and other component suppliers.

Would it not be great if web browsers( IE, Firefox, Safari, Google Chrome, Opera) would help to reduce page sizes and bandwidth use?

Many web 2.0 pages are using client side java script and script frameworks offered by component builders, such as Infragistics, Telerik, and Component One to name just a few.

Unfortunately,  many 3rd party components require large downloads (some 500K+) to support only a few lines of code in the developers page.

Jquery is becoming very popular, and has a very lightweight framework, less than 15K when minified or gzipped, but its popularity means that it will be downloaded many times.

I use 3rd party components very sparingly because of the download overhead, but would be much more likely to use them more often if there was not such a huge price to be paid for the infrastructure.

Imagine if the jquery.js script was maintained as part of the browser.

I am sure that John Resig and his team could work out ways of managing version control and give developers a way to specify version requirements and the option to use the browser version or to use a version which is available for download from their own websites.

Taking this further, the browsers could not only manage jquery.js, but many of the third party component provider’s solutions.

Such provision would significantly increase the speed of many websites as well as reduce the total bandwidth usage on the internet.  It would also encourage developers to provide a richer internet experience to their users and make the use of third party components much more acceptable to developers.


5 thoughts on “Browser Support for Jquery, Infragistics, Telerik, Component One and other component suppliers.

  1. I’d love a world where some of the core js libraries out there were built into the browser, I think we all would! But there are still many other ways we can minimize scripts even in third party controls. At Infragistics, we just finished a re-architecture of our grid control and this was one of the callenges we wanted to overcome; by budling our grid with many small JS files, each containing an atomic unit of functionality we. To make files even smaller, compressing them by removing spaces and comments is done on non-debug versions of the scripts. Now instead of downloading a single 500kb script file, there are multiple scripts related to the specific features you’ve enabled. So if you only need 1/10th of the available features, you only have a fraction of the total js required.. I actually just finished a screencast describing the functionality if you’re intersted –

    And if you’re worried about latency and the number of requests, this all works perfectly with Microsoft’s Script Combining functionality, which will take multiple distinct files and pack them together into a single entity.

    Combine all of that with the browsers caching functionality or a CDN so that files can be served up from local servers around the world – and downloading script files becomes a non-issue. Still, I wouldn’t argue if jQuery were to be a default in all browsers..

  2. Thanks for the comment Tony. I do have an infragistics subscription so I am looking forward to your new generation of controls.

    I think if we could start with jquery that would be great. maybe even Microsoft could also add the script manager to IE.

    If Microsoft would take the lead with these two scripts then I am sure that other browsers would follow and the number of scripts and components included in the browsers would continue to grow as each browser would try and claim to support the greatest number of script libraries.

    I have written to various people and you may be able to help influence the outcome here. Just get a few of your MVP’s to have a quiet word in a few ears.

  3. I have experienced the 512KB download, for 1 grid of a certain vendor, regardless if I do server-side or client side binding, the JS download alone is 562KB. Disgusting.

    I’ve given up on ASP.NET AJAX, that whole thing is just a mess.

    We are moving onto JQuery for certain things and JQueryUI as well. These are not small but at least they’re cached. JQuery itself is small but the JQueryUI stuff is still relatively large.

    I don’t think the answer is to distribute these libraries with the browser since that just tightly couples what you can implement on the website with whatever version’s on the desktop, how’d you ever know if your site would work on a given machine?

  4. @Francis

    I did consider the versioning issue. For users who want to keep their sites current then they should update their site to the latest versions.

    The browser would check the metadata in the application to see if it had the required version(the browser may hold several versions), if the borwser did not have the required version stored locally then a normal download would take place.

  5. ComponentOne just launched a new version of their AJAX controls that use jQuery for the core framework. You can even tell the controls to not reference embedded jQuery so that you could point your scripts to a CDN. By using ComponentOne and Microsoft’s CDN you would nearly be getting what you want. It would mean that most of your end users would have it cached on their machine already and would need to download it. Even if they did download it, they would be getting it from the EDGE networks at high speeds.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s