Hi, I'm the guy that built Helium. I'm glad to see you were inspired by my project. I haven't had a terribly lot of time to work on it since it was initially released.
Couple of quick notes about the design decisions I made.
1) Lack of support for IE6 & 7 via querySelectorAll:
Even in January, more and more sites were dropping support for IE6/7. I don't support those browsers either, and I primarily designed Helium to suit my needs first. That being said, it has been my intention to add Sizzle as a dependency, but I haven't done it yet.
2) Why no js library dependencies (i.e. jQuery):
jQuery is an awesome library. But its also a lib that many sites around the web don't use. Additionally, loading a specific version of jQuery into an existing page might conflict with a different version that already lives there. This can easily break a site and therefore cause Helium not to run. It was a considered approach to make Helium self-dependent from any js libraries so it can have broader usage without conflicting with a developer's existing codebase.
3) Why a list of urls instead of spidering:
There is no easy way to spider a site with a client-side script. If you hit a page that doesn't have Helium on it, there's no way for it to continue operating. This kind of tool has to be as automated as possible, since its primary job is to make the developer's job easier.
More importantly, many sites have hundreds or thousands of pages of content but use a handful of page templates. There is no easy way to programmatically determine what these page types are. Therefore, it is much easier to provide a list of sample urls for Helium to run on. It gives the developer specific control over what pages are going to be included in the selector test.
4) Why intended for use on development environments and not production:
By the time your code hits production, it needs to have already been optimized and tested. Therefore, the need to run something like Helium on a production site should mostly be moot. Additionally, when all of the previously mentioned reasons are combined there are certain requirements that have to be met to run a tool like Helium. In order for it to run across a large number of different pages, the js tool has to be included on each page. The easiest way to do this is on a local environment you have control over, rather than a production environment.
I'm glad to see that other people working on this kind of problem too. Multiple competing projects is a great way to encourage us to keep working and improving these tools.
You're correct on both accounts. The existing bugs won't be that hard to fix but I haven't had a chance to do it. I've been sitting on this project for almost 10 months and I figured it's better off being released. It's not doing any good hidden away on my HD.
Hopefully I can find the time this week to fix them.
why not just let the user run cssess only on the actual URL? If you run cssess on a big page you will obtain a long list of URLs and you need to deselect them by hand (leave all checkboxes unchecked and put a "select all" button on top.)
Also you need to filter away "mailto:" links (and all other protocols that don't use CSS.)
Anyway keep up the good job. I've added the bookmarklet on my personal list of day-by-day programming tools.
Couple of quick notes about the design decisions I made.
1) Lack of support for IE6 & 7 via querySelectorAll: Even in January, more and more sites were dropping support for IE6/7. I don't support those browsers either, and I primarily designed Helium to suit my needs first. That being said, it has been my intention to add Sizzle as a dependency, but I haven't done it yet.
2) Why no js library dependencies (i.e. jQuery): jQuery is an awesome library. But its also a lib that many sites around the web don't use. Additionally, loading a specific version of jQuery into an existing page might conflict with a different version that already lives there. This can easily break a site and therefore cause Helium not to run. It was a considered approach to make Helium self-dependent from any js libraries so it can have broader usage without conflicting with a developer's existing codebase.
3) Why a list of urls instead of spidering: There is no easy way to spider a site with a client-side script. If you hit a page that doesn't have Helium on it, there's no way for it to continue operating. This kind of tool has to be as automated as possible, since its primary job is to make the developer's job easier.
More importantly, many sites have hundreds or thousands of pages of content but use a handful of page templates. There is no easy way to programmatically determine what these page types are. Therefore, it is much easier to provide a list of sample urls for Helium to run on. It gives the developer specific control over what pages are going to be included in the selector test.
4) Why intended for use on development environments and not production: By the time your code hits production, it needs to have already been optimized and tested. Therefore, the need to run something like Helium on a production site should mostly be moot. Additionally, when all of the previously mentioned reasons are combined there are certain requirements that have to be met to run a tool like Helium. In order for it to run across a large number of different pages, the js tool has to be included on each page. The easiest way to do this is on a local environment you have control over, rather than a production environment.
I'm glad to see that other people working on this kind of problem too. Multiple competing projects is a great way to encourage us to keep working and improving these tools.