Menu

Subscribe

javascript

JSNES: JavaScript Nintendo Emulator

Ben Fisherman’s JSNES runs entirely in the browser using nothing more intrusive than JavaScript. It apparently manages real-time performance within Chrome, but it works (if not playably) on an iPhone. I wish the screen was resizable and that it supported iPhone compatible controls, but both of those assume that browser performance will improve enough to […] » about 100 words

Browser-Based JSON Editors

JSONLint, a JSON validator, was the tool I needed a while ago to be able to play with JSON as format for exchanging data in some APIs I was working on a while ago. And now I like JSON well enough that I’m thinking of using it as an internal data format in one of my applications, especially because it’s relatively easy to work with in JavaScript. Or, at least that’s the promise.

What I’ll need is an easy way to manipulate the contents of a simple array, and these JSON editors may give me a start.

The Braincast JSON editor was the first I found, but it doesn’t allow creation/expansion of the JSON. Katamari‘s JSON editor seems to work and has a lot of features and a post 2005-looking interface, but that doesn’t make it simple. Worse, I don’t think it’s available for me to re-use, modify, or extend in my projects. Thomas Frank‘s JSON editor, on the other hand, does have the features I need and a GPL license. That’s the place to start.

Extra: a JSON diff.

Steve Souders On Website Performance

Steve Souders: 10% of the problem is server performance, 90% of problem is browser activity after the main html is downloaded. He wrote the book and developed YSlow, so he should know.

JavaScripts are downloaded serially and block other activity. Most JavaScript functions aren’t used at OnLoad. We could split the JS and only load essential functions up front, and load all the rest later. How much might that help? He says 25% to 50%. This quickly gets complex, but he’s got a simple plan that considers three questions:

  • Is the script URL on the same host as the main HTML?
  • Should the browser indicate it’s busy, or not?
  • Does script execution order mater?

And at that point things started to get too interesting to take publishable notes. I clearly need to pay more attention to this guy.

Stats he mentioned without being specific about the source:

  • Google: 200ms longer download time cut revenue by 20%
  • Yahoo: 100ms of latency costs … big.

Detecting Broken Images in JavaScript

We’ve become accustomed to link rot and broken images in nearly all corners of the web, but is there a way to keep things a bit cleaner? K.T. Lam of Hong Kong University of Science and Technology came up with this sweet trick using jQuery and readyState to find and replace broken images: jQuery('span#gbs_'+info.bib_key).parents('ul').find('img.bookjacket[@readyState*="uninitialized"]').replaceWith('<img src="'+info.thumbnail_url+'" […] » about 200 words

Sweet jQuery

Matty discovered jQuery at The Ajax Experience, and his enthusiasm has rubbed off on me. jQuery makes coding JavaScript fun again. Well, at least it makes it possible to write code and content separately. And that means that sweet AJAXy pages can be made more easily, and it sort of forces designers to make them […] » about 100 words

Ryan Eby’s Pursuit of Live-Search

Ryan Eby gets excited over LiveSearch. And who can blame him? I mention the preceding because it explains the following: two links leading to some good examples of livesearch in the wild.

Inquisitor is a livesearch plugin for OS X’s Safari web browser. It gives the top few hits, spelling suggestions where appropriate, and links to jump to other search engines.

Garrett Murray’s ManiacalRage is an interesting blog on its own, but he’s also doing some good AJAX on his search interfaces. Look first at the archive search. But also take some time to appreciate the new content search. Sure, you’ll have some complaints, but it’s his site and not yours and there are some ideas there that are pretty interesting and useful.

50+ Ways Good HTML Can Go Bad

Via Brad Neuberg: RSnake’s XSS (Cross Site Scripting) Cheatsheet: Esp: for filter evasion. Limitations on cross site scripting (XSS hereafter) have been troubling me as I try to write enhancements to our library catalog, but the reasons for the prohibition are sound. Without them I could snort your browser cookies (RSnake lists: “cookie/credential stealing/replay/session riding” […] » about 200 words

Plan C: Signed JavaScripts

The Mozilla docs on JavaScript security give a hint of hope that signed scripts will work around the cross-domain script exclusions that all good browsers enforce. But an item at DevArticles.com throws water on the idea: Signed scripts are primarily useful in an intranet environment; they’re not so useful on the Web in general. To […] » about 300 words

Plan B: Remote Scripting With IFRAMEs

I have plans to apply AJAX to our library catalog but I’m running into a problem where I can’t do XMLHttpRequest events to servers other than the one I loaded the main webpage from. Mozilla calls it the “same origin policy,” everyone else calls it a cross-domain script exclusion, or something like that.

Some Mozilla folks are working on a standard to address the problem, but it could be quite a while before browser support is common enough to build for it.

So Plan A was to use simple AJAX with XMLHTTPRequest. Plan B comes from this crazy suggestion at Apple’s developer site: Remote Scripting with IFRAME. It looks like different functions are subject to different restrictions, so the theory is that a JavaSctript loaded in a page in a hidden IFRAME can call functions from the parent page and do pretty much everything we’ve come to expect of XMLHTTPRequest. Here’s an example they offer.

Crazy as it is it works, and it gets around some cross-domain script exclusions for some browsers, but it still gets trapped by Mozilla.