Helium.js - discover unused CSS on your site | Hacker News Reader

Helium.js - discover unused CSS on your site

github.com

63 pointsgeuis13 comments

There is a Firefox extension called dust me selectors that accomplishes the same thing. I have been using it for years.

I had problems with that after some Firefox version upgrade, and haven't looked into it after.

I kept expecting someone to make this extension as part of Firebug.

Aussie band Gerling had a song called 'dust me selecta' - i wonder if one served as inspiration for the other?

Neat and all, but why is this written in JS? CSS selector support is great in html parsers (nokogiri, for instance.) Seems like a hassle to add the script tag, onload, etc. just for a run-once-and-only-in-dev kind of script.

That's why your developer CMS/framework/tool-chain should just generate that script take for -DDEBUG builds of your web app (#+debug in my case ;-)

I already do that with Firebug Lite, to make IE suck less.

I upvoted because this is a good question that other folks will have, and I wanted to provide my motivations.

Finding the unused css selectors among several stylesheets among dozens of pages is tough. Before I wrote Helium, I tried many other attempts. This included:

Google Pagespeed exports: There's a cool feature of this Firefox extension that lets you export a json-encoded file showing all kinds of stats about the page. This includes a section of unused css selectors. The problem is that there is no way(currently) to pass it a list of urls to load, check, and produce a final report. At one point, I exported over 40 individual reports and struggled for several days to write a Python script to parse the results out. While this was a perfectly valid way to solve the problem, one of the big issues I found was the amount of time it took to generate the reports. It was a vary manual process.

Cross-browser support: There were only 2 projects that I found that came close to the kind of data exports that I needed, Pagespeed and DustMe Selectors. They were both Firefox-only tools, and don't help when trying to analyze any other browsers. It will only take a minimal amount of work and testing to get it running in IE8, so that's next. It will eventually also work in older IE versions, but that is going to take more work.

Existing solutions just don't work(at least for me): In particular, I'm talking about DustMe Selectors. I monkeyed with this tool for 2 full days and could never get it to work correctly. The absolutely vital component I needed was the ability to get reports on many different pages. Once I figured out how to get it to read a sitemap XML formatted file of my links, I could never get it to finish a full report. I let it run all night and came back the next day and it was just hung up. I spent a 2nd day and each test would just hang, no matter what I did. I really wish it had worked as advertised, because it would have saved me a lot of time.

Client-side tool: I thought about this problem for a long time. Yes, there are server-side tools like the ones you mentioned. However, to be truly accurate a tool like this needs to be able to analyze pages as they are actually rendered in the browser.

So these are the main reasons that I built Helium.

What would be really awesome if this tool could run in the background somehow and log selector usage. The reason for that is that on dynamic pages, the original HTML served doesn't really reflect all the selectors that are actually used on the page.

Its incredibly important to web developers to be able to test IE, too. Helium needs a lot of extra work to support the older Internet Explorer browsers to patch around the missing features required. It will get done.

I cannot see why you should develop this for IE. This tool is no going to be used by end users. Developers are going to have Chrome/Safari or Firefox installed in their machines. Are there so many IE CSS hacks used in websites?

Because IE has "special needs". Very often different stylesheets or even different markup is served for IE. This could be circumvented by faking IE with the user-agent string but ideally it would just support IE out of the box.

I guess you are correct. It is incredibly painful to know that even tiny developer tools should support IE.

This is a nice tool. Waiting for the XML sitemaps support.

Deadweight is a very well written Ruby script that performs the same kind of task. Give it a try:

http://rdoc.info/projects/aanand/deadweight

What about those of us that use add CSS classes dynamically, based off user events? I could definitely use a tool like this, my CSS sheets get long very fast.

Reply on news.ycombinator.com