Categories
Around The Web Internet Mozilla Web Development

JavaScript Badges And Widgets Considered Harmful?

Jeremy Zawodny has a great post about common JavaScript usage where he concludes it’s harmful. Whether you agree or not, you have to admit it’s a great blog post. Here comes another long blog post.

Here are some of his claims and my feelings on them:

They’re a hack.

Sure they are, but so is most of the Internet. I’d consider <embed> and <object> to also be hacks. Same with JavaScript in general. It’s a hack to make static HTML feel dynamic. The web is one giant web of hacks (sorry for the lame pun). Anyone in web development knows it. You can’t dispute they are a hack in any way/shape/form. AJAX is also a hack. Does that mean it’s inherently bad? Not at all. Being called a hack in the tech-world isn’t always an insult. Does that mean we would do the same thing if we could start over? Likely not. Does it get the job done? Depending on your project requirements, the answer may very well be “Yes”.

Given that an overwhelming number of overwhelming number of sites that are likely running PHP or some other “dynamic” hosting setup, these least common denominator solutions just feel wrong.

Well, this isn’t 100% correct when you look at things a little closer. While it’s true most sites are “dynamic”, there are many exceptions here. For example, many sites are dynamic but cache some parts of their operation. For example they can use something like reverse proxy (such as Squid Cache) or even Akamai. Would you regenerate an entire page to update 3% of it? Or would use use javascript and update a small script on a non-cached server (or directory) which injects it’s data into the said page? That’s one of the great things about this “hack”. It lets you get away with much more aggressive caching. The only comparable alternative to this is to use an <iframe> which is inferior. It can take a short while for you to bust through all your caching if your somewhat aggressive. I’ve seen Akamai cache for a few minutes. If your javascript isn’t cached, you’ve instantly updated all your pages from a central location, and touched only 1 file in the process.

At the end of the day, this is about cost saving, and using your infrastructure wisely. Generating a page for each pageview, or once per 1,000,000 pageviews is something that at the end of the day has to be analyzed from a business standpoint.

I’m personally a fan of dynamic sites, but understand the need for static content. I personally feel it’s a delicate balance, often dictated by the business at hand, and the requirements of the project.

Search engines…. when it comes to search, these JavaScript and/or Flash creations might as well be invisible.

Also very true. But in the case of Flash, how much real benefit does a search engine get from interpreting a FLV encoded video? Go ahead an analyze that binary jiberish. I’d guess the benefit is close to none. If they wanted they could read the location of the embedded object and use that for some purpose (such as PageRank). As for JavaScript, yes it’s a SEO nightmare and no real workaround (other than scripts that fallback to some sort of <noscript> solution. But it’s well known, so people implementing it accept this. I’d say the damage here is minimal as most of the content in JS Widgets are syndicated content littering the web and don’t have much benefit for searching. Does anyone here feel upset that those annoying, yet popular snap.com popups aren’t google searchable?

Site performance.

Enough said. Again I agree. I wouldn’t blame this so much on JavaScript itself, but on the fact that most of is used to bring in content from other servers. Rather than connect to 1 fast server your connecting in some cases to a dozen web servers for various images, and javascript Your bound to find a slow one in there somewhere. But again, there is a balance. Too many requests on your own server also causes your performance to suffer. If you want a fast site, minimize the number of http requests per page view. This is critical, even for broadband.

Remember, in Firefox 2.0:

pref("network.http.max-connections", 24);
pref("network.http.max-connections-per-server", 8);

That’s 24 simultaneous connections, and no more than 8 for a server. If your site has 60 images, 12 javascripts, 8 stylesheets, and 4 ads in iframes, your performance is going to suffer. Ironically you move images to one host, javascript to another, and html to yet another you’d speed things up (assuming performance is identical). That’s because it’s 8 per host. The real solution is to consolidate requests. Try to not only keep objects small, but use as few as possible.

Hard to skin.

This is mostly intentional on behalf of the provider. It has two purposes:

  1. The goal of these widgets and badges is drop in functionality. They don’t want things to break. Less the implementor controls, the less that can break. Nobody wants to hold someones hands while they get used to the code. This is a good way around it.
  2. They don’t want things like branding to become hidden when it’s skinned.

Implementors accept the above, because they want to quickly gain a feature without the overhead of development.

They’re not secure. Every time you drop a new JavaScript include on your site, you’re giving a third party access to a wealth of information about your site visitors, your content, their clicks, and so on. They can modify the page, snoop on your users, re-write your links, and do all sorts of nasty stuff. Granted, this is rare in practice, but how do you really know that?

Again completely agree, but this may again be the intent in many cases (AdSense, Analytics, etc.). In most other cases, it would often fall under two possible situations:

  1. The site is small and the owner doesn’t really care (most blogs, and MySpace users).
  2. The site is large, and a contract was signed that covers things such as revenue sharing, privacy policy, and how data is shared and used.

Don’t work everywhere.

Again I agree, but will MySpace start to allow users to install Perl/PHP/Ruby/Python scripts to parse XML from third parties? I’d venture that would be even more insecure. JavaScript has at least some sort of sandbox (can’t touch the server’s backend data). Even if it were standardized (in which case everyone shares a generic implementation), which is somewhat of a long-shot at best considering how different many of these services are, the development effort to implement would be substantially more difficult than copy/paste.

Again, business rules tech. Copy/Paste is the best API thus far for implementing a third party product into your own code base. Non-programmers are just as good as programmers when it comes to this API.

Summary
Do I think they are harmful? I won’t be that harsh, I think they have their place. Do I think they are often overused and abused? No question in my mind. Will that change? Not likely.

[Hat tip to both Matt and Alex for pointing to this gem.]

1 reply on “JavaScript Badges And Widgets Considered Harmful?”

Robert, there are almost no HTTP/1.0 servers out there so the relevant pref is network.http.max-persistent-connections-per-server – 2 connections per server. And that is more than enough in almost every case. A typical blog has no frames, only a few scripts and stylesheets, less than 10 images. If you try to use more connections the time to create those connections will eat all the advantage you get from it (not even counting additional server name lookups or server-side overhead).

Now if you insert third-party content on the server side you won’t get much impact on page load times because it is mostly HTML code that can be easily cached and compressed. You don’t need to give up neither server-side caching (caching parts of the page separately isn’t a big deal) nor client-side caching. JavaScript widgets are different, they usually inhibit caching and are sent uncompressed (Netscape 4 compatibility?). Also note that they delay parsing of the page which has a very bad impact on *perceived* page load times.

My conclusion is: these JavaScript widgets are in fact very bad (in particular the security implications). Unfortunately stating this won’t make them go away, as you correctly noted neither content providers nor the majority of bloggers will make an effort to change anything. For my part I don’t use any external scripts on my site even though I use third-party content on a few occasions – it is fetched on the server-side.

Leave a Reply

Your email address will not be published. Required fields are marked *