It’s been 18 months since I first released the editinplace Javascript code. And many months since I’d really done anything new with it.
So I finally put together two things, a new version and new home for EditInPlace. First, the new home, editinplace.org. There’s documentation, a blog, downloads and forums. The main push for me to do this was to try out the forums. I’m still amazed at the number of people contacting me expressing interest in this, so I’m hoping that the forums will provide a better way for people to ask questions and get answers. If nothing else it moves from my inbox and out on the web, where Google can index it for all to see.
Next, a new version, 0.5.0. This is a rewrite based on the 0.3.3 code that uses more Prototype specific features. If you’ve used EIP before you’ll want to review the example.html and save.php files to see how things have changed in the new version. Nothing earth shattering, but it is different. You can get it now at the download page.
Go check it out and let me know what you think.
Tobie Langel pulled out an interesting little JavaScript nugget from the recent Background Music post on the Webkit/Safari Blog:
Some Web pages specify repeating timers with an extremely small timeout. In fact they often use the value 0 to mean “Fire as soon as you can.” Safari 2 does not throttle these timeouts, and so a poorly-constructed page that specifies a repeating timer under 10ms will actually hog a lot of CPU. Aggressive timers were actually a problem in Mozilla for a long time before being fixed, and they are currently a problem in Safari 2. WinIE, Firefox, and WebKit nightlies basically error-correct the badly constructed page and ignore timer values of < 10ms by changing them to be 10ms.
So don’t bother using setTimeout or setInterval for something less than 10ms.
The Javascript library framework Prototype has a new home at Prototypejs.org. With API docs, tutorials and a blog.
Oh, and version 1.5.0 of Prototype is now available for download
Why JSON isn’t just for JavaScript – Simon Willison.
The sweet spot for JSON is serializing simple data structures for transfer between programming languages. If you need more complex data structures (maybe with some kind of schema for validation), use XML. If you want to do full blown RPC use SOAP or XML-RPC. If you just want a light-weight format for moving data around, JSON fits the bill admirably.
What do we lose from not using XML? The ability to use XML tools. If you’re someone who breathes XSLT that might be a problem; if like me your approach when faced with XML is to parse it in to a more agreeable data structure as soon as possible you’ll find JSON far more productive.
Emphasis mine.