Showing posts with label Javascript. Show all posts
Showing posts with label Javascript. Show all posts

Thursday, August 17, 2006

Someone write this Firefox plugin

I browse with a lot of Firefox windows open and each with many tabs.
I probably never have fewer than a dozen tabs open across three or
more windows. Often, I'll have 50+ tabbs open, and usually Firefox
does alright. Some web sites, however, behave poorly. Whether Flash,
animated images or most often, JavaScript, they use up CPU when I'm
not looking at them. In some cases, this is legitimate and
reasonable. I like the fact that Gmail checks for new mail and is
always reasonably up to date. However, several sites use CPU for no
good reason. For example, the old BGG menu system (which Scott has
thankfully replaced) called setInterval with a timeout of
30ms. For a menu system. Other web sites are worse.
Unfortunately, isolating this sort of problem is hard when you have 30
tabs open. I can see Firefox using 50% CPU, but why?

So, someone needs to write a Firefox "process monitor". It's not
exactly a standard process monitor, in that JavaScript lacks typical
processes, but it would provide a few things. First, it would provide
a list of current setInterval and setTimeout calls
by origin, original scheduled time and remaining time. Second, it
would provide some ability to pause (or even auto-pause, when not in
the foreground) tabs from using CPU resources. This would make fault
isolation easier and would be useful to say, pause everything other
than Gmail. Finally, if possible, it would provide some estimate of
CPU usage on a per-open-page basis, like a traditional process
monitor. Right now, Firefox pops up the "unresponsive script" warning
at some threshhold, so I'm hoping there's some ability to measure the
usage in a more granular way. I don't know enought about SpiderMonkey
to know how feasible any of this is, but I really need it, especially
as more and more nice JavaScript heavy "Web 2.0" apps appear.

For now, Venkman, the JavaScript debugger is of some assistance, but
not nearly as much as I'd like. Is there some other tool out there
I'm not finding that offers some of this capability? Anyone care to write one?

Thursday, July 7, 2005

Gray TiddlyWiki

Last year, I saw a very cool hack called "TiddlyWiki" which was a
standalone javascript wiki of sorts. It was a very cool hack, but was
missing a number of things that would be necessary to make it truly
useful. I assumed it retained it's status as "just a cool hack".
Little did I know.

Last week, for some reason I found myself thinking about TiddlyWiki,
and ended up looking it up. The author, Jeremy Ruston, had continued
development and turned it into a rather impressive little application.
It was missing a few features I would like, but I figured I could
modify it to do those things. In the process of looking around at the
TiddlyWiki site, I discovered that Steve Rumsby had created his own
adaptation of TiddlyWiki which he dubbed "YATWA" which implemented
most of the features I was looking for.

So, I finished it off, implementing a few more features I wanted and I
present the Gray TiddlyWiki. The
Gray TiddlyWiki has links to Steve's and Jeremy's sites as well as
other relevant stuff. Check out the main href=http://www.tiddlywiki.com/>TiddlyWiki site for basic
information. If you're using greasemonkey, you may want to disable
it, or at least disable the "linkify" script because it causes
TiddlyWiki's to break.

Overall, it makes for a very nice "notebook" application.

Friday, June 24, 2005

Delicious Sort Fixed

The Del.icio.us sort
script I wrote in January recently broke due to some
substantial changes in the format at del.icio.us. I fixed it, so it
works again and fixed the annoying bug about items with only a single
bookmarker. Simply reinstall the script to replace the old (now
broken) one.

Friday, March 11, 2005

Two Script Tweaks

Due to a change at Google Maps, my add waypoint script needed to be tweaked as someone pointed out in my original post about the userscript. It has been fixed and seems to work again.

Additionally, I decided the [DeliciousSort Delicious sort userscript] would be more useful if it were toggleable, so I implemented that, admittedly not extremely neatly, but it works. Reinstall the script if you want the version with "sort" and "unsort" buttons. It still sorts by default.

Wednesday, February 16, 2005

Greasemonkey for Google Maps

Google Maps is very nicely done. If you haven't tried it out, you should. But, there's a couple features it doesn't have that I wish it had. This is where Greasemonkey can really shine. The two ideas: Automatically follow a plotted route and add more address markers to an existing map. Today, someone posted an implementation of a userscript that adds the route following feature to Google Maps. Another Google Maps userscript, this one to generate a map with predefined set of points on it, was also posted.

So, all of this activity inspired me to implement my second idea (since Prakash pleasingly did the first one for me). I present yet another userscript: Google Maps: Add Waypoint. It adds a second text entry box which if an exact address is typed into it, it adds a point on the map. In "local search" mode, there is no description of the point, but in the standard maps mode, the address is shown.

Friday, February 4, 2005

XPath API

XPath is useful. To some extent, it is addressing a problem (XML is
annoying to navigate) that might not be there if XML wasn't
gratuitously over-applied to technical problems, but it does what it does reasonably nicely and clearly. If XML is going to be used as a data description language, XPath is useful to have.

Unfortunately, the XPath API, as defined in href="http://www.w3.org/TR/DOM-Level-3-XPath/xpath.html">DOM Level
3 and as implemented in Mozilla, is not designed for anyone who
actually wants to use it. It's perfectly fine if you want to
look at it and admire it, but if you actually want ot use it, it's
rather annoying. I understand there can be the attitude in API design
that "utility functions" that duplicate existing (more complete, but
more complex) API functions need not be included. Get over it, they
should be included. One or two well conceived utility functions can
dramatically improve usability. Java got a lot better when they added
String.split() rather than having to wade through the irritation of
StringTokenizer. For that matter, an overabundance of utility
functions is, at worst, a documentation issue.

With XPath, you're using it to fetch a node or nodes of an XML
document. You can also use it to count nodes, get strings, etc, but
when it comes down to it, you're identifying nodes in an XML
document. So, if I want to get say, the first image element with a
class of "big" that is nested underneath a div somewhere in an HTML
document, I use the xpath expression:
//div//img[@class="big"] Unfortunately, the API requires that
I call document.evaluate with 5 parameters, two of which are null and
one of which is an annoying long constant name, something like:
document.evaluate(p,context,null,
XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE, null);
Ok, that's a
bit annoying, but it's not so bad, right? I get an array back and I
just take the first element. Wrong. I get an "XPathResult"
back which has its own little iterator interface. So, instead I find
myself using this utility function:



mkgray.xpath = function xpath(p, context) {
var arr = new Array();
var xpr = document.evaluate(p,context,null, XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE, null);
for(i=0;item=xpr.snapshotItem(i);i++){ arr.push(item); }
return arr;
}



I'm hoping there's something in the API I'm simply overlooking that someone will point out to me, but in the meantime, I'll continue hoping for utility methods.

Sunday, January 16, 2005

Userscript: Delicous Sort

Another greasemonkey userscript: Sort del.icio.us pages. It sorts the links on any del.icio.us page by the number of people who have marked it. At some point, I'll probably have the userscript add a button to del.icio.us pages to revert to the usual time based sorting.

Also, I updated my userscripts page to have a brief description of all of my current scripts.

Saturday, January 15, 2005

Greasemonkey 0.2

I am now an "active developer" on the greasemonkey project. I made some fixes to it so it now correctly works with background tabs, frames and iframes. The new release also doesn't blow away your old userscript config like the the old releases did. You can download the new release from greasemonkey.mozdev.org.

Monday, January 10, 2005

Greasemonkey: Interstitial Skipper

I wrote another greasemonkey userscript: yahoo groups interstitial ad skipper. Ok, "skipper" is not quite right, but it immediately moves on to the actual message. If you've used the web interface to Yahoo Groups, you've noticed it occasionally inserts an advertisement before you can view the message. Adblock does a fine job of removing the ad itself, but you're left with an essentially blank interstitial page. This userscript automatically "clicks" on the Continue to message link. This is especially useful when opening several messages into tabs in the background.

Sunday, January 9, 2005

Grease Monkey

Greasemonkey is a plugin
for firefox that lets you run "user scripts" on particular web pages
automatically. When I last played with "bookmarklets" it occured to
me that it would be useful to have the automatically execute some of
these whenever particular pages are loaded. That's exactly what
grease monkey has done. If you install greasemonkey, you should be able to right-click or control-click on the userscripts to install them.

Combine it with href=http://www.w3schools.com/xpath/xpath_location.asp>xpath and
you have a rather nice system for mucking with web pages. For example, slashdot has some really awful color schemes on some pages. I wrote a greasemonkey userscript to fix slashdot's colors. It does its best to change all existing background colors to the default. This might be doable with a cleverly written user style sheet, but given the lack of element classes in the slash HTML, maybe not.

One of the things that bugs me on a lot of web pages is that there's a
lot of unneeded garbage around the edges. In particular, the
following layout is common:





banner
navcontent



A recent article points out that many folks ignore them anyway.
So, I wrote a couple of userscripts to extract the content section and put it at the top. The remaining "shell" of a page is left at the bottom in case you want it. That part ends up looking weird, but the main content is nicely and more clearly positioned at the top of the page. Here are the userscripts: Weather Underground reorganizer and CNN story reorganizer. Or, if you'd rather just remove the CNN side navbar.

I'll probably write some more of these, which I'll post to this section of my blog. I may also create a better userscripts page, which is for the moment a placeholder that links back here.

Other userscripts I know about, other than those on the greasemonkey site:

Thursday, December 2, 2004

Why didn't anyone tell me?

JavaScript isn't awful. Well, it isn't awful anymore. When
JavaScript first came out, freshly renamed from the less misleading
"ActiveScript", it was awful. It was ill-defined, clunky, full of
security holes, and awkward in a great many ways. I wrote it off as a
tool used to make web sites do things they really didn't need to or
shouldn't do anyway. At some point, seemingly around 1999, this changed.

JavaScript is a clever language with an interesting twist on the
"standard" object model of languages like Java or C++. It's got a
relatively clean and useful set of built-in libraries, including the
valuable DOM. It's threading/timing model is a bit bizarre but
surprisingly useful. It interacts with XHTML in powerful ways to
enable some very useful bits of web UI. Through the use of
"bookmarklets" it puts a lot of power back in the browser which, in
the interest of "interactive" web sites has been gradually leached
away.

JavaScript still has it's issues. The three biggest as I see it are:


  • It used to be bad. It really was bad. No DOM. No good documentation. No prototype inheritance model. Bad. First impressions make a big difference.
  • It's mostly used by non-developers. At some level this isn't bad, but it creates the problem that a lot of the JS code out there is awful because the people writing it don't really know what they're doing. It's horrible voodoo code which is unintelligible and barely functional, never mind maintainable or usable by others.
  • Most use of JavaScript is abuse. The most ubiquitous applications of JS are things like popup and popunder ads. Even image rollovers and other stupid UI tricks could be called abuse. Modern browsers (eg, Firefox) address the whole popup issue well, making this abuse less apparent. Unfortunately, a tool that is mostly used for bad things is often assumed to be a bad thing. JavaScript was used for a lot of bad things.


Now, though it's a nice language. It's being accepted more by
developers. It's being used in useful ways. So, if you're like me
and thought JavaScript was an atrocity deserving no attention, look
again. It's grown up a lot. The question remains: "Why didn't anyone
tell me, in the last 5 years, that it was so much better?"

For reference, I highly recommend the Rhino book by O'Reilly.