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.
After reading Avoiding Bloat in Widgets I’m pondering a re-write of Edit In Place in a similar style so that something like Script.aculo.us could be optionally used to supply transitional effects. So those that are looking for a smoother looking Edit In Place could have it, while not forcing the extra weight on those who don’t want it.
There are a number of other things that I’d like to get hammered out in the Edit In Place code as well. I’m hoping to resume work on it after the new year.
Javascript is starting to remind me of the Perl slogan, “There’s more than one way to do it”.
Douglas Crockford presents “An Inconvenient API: The Theory of the DOM” in a three part video series at Yahoo!. Depending on how you look at things this is either really exciting or really depressing :-)
Javascript has been making a monster come back (in a good way), and I hope that continues.
I’ve been reading through some of the jQuery docs and I’m getting more and more interested. I’m aware of mootools (and Jonathan’s drag and drop example) and the latest updates to prototype. I hope to get around to playing with those as well.
The compressed version of jQuery comes in at impressive 17,587 bytes. I do wonder if there is any slow down in performance. Either way, it is a huge leap from the 45,778 byte uncompressed version of jQuery.
Ryan Campbell investigates the cost of enumerable loops in Prototype. The resulting numbers are pretty dramatic when dealing with larger arrays. One thing to keep in mind though is that for only a few iterations over arrays with a small number of elements then the penalty is probably small enough that it won’t cause problems.
Benchmarks using the various JavaScript libraries is something that I’d expect to see more of. Soon or later someone will post benchmarks between Prototype, YUI and JQuery on various tests. The benefit from having numbers like this is that eventually all libraries will adopt the fastest approach that meets their goals.
I’ve been thinking more and more about JavaScript Object Notation (JSON) lately. If you aren’t familiar with JSON here’s some reading:
Unless I see a serious counter argument, I’m ready to jump on the replace XML with JSON boat. Other proposed ideas based on JSON include JSONRequest (a safer version of XMLHttpRequest) and JSON-RPC (like XML-RPC without the XML).
This leads me to my next thought, should the existing feed formats (RSS & ATOM) be replaced with JSON? I’m not 100% sure that this is the right thing, but I’m giving it serious consideration.