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.
I’ve been getting lots of great feedback on Edit In Place. As time permits I hope to fix problems and round out the feature set a bit more. To that end I’ve rolled out version 0.2.1. Here’s a list of what has changed since version 0.2.0:
I’ve updated the example page to include editing a string that starts out empty. The example now has a link to my Edit In Place blog entries, the edit.php source (assuming your web server knows what to do with .phps files) and the main link at the top now goes http://josephscott.org/code/js/eip/.
Two new options have been introduced to format empty strings: empty (which is the css class to apply to empty strings, defaults to .eip_empty) and empty_text (the text to put in place of empty strings, defaults to ‘Click To Edit’). These options are valid for all types (text and textarea).
So go to the example page and click on the grey ‘Click To Edit’ string and you’ll get an empty text box. Type in something and you’ll get the new string instead. Then delete the string and you’ll get the grey ‘Click To Edit’ string again. You can do the same thing with the original text and textarea examples.
I think that I’ve covered the empty string condition, but if you find a bug please drop me a note. Include a patch if you are really feeling generous :-)
For years I avoided Javascript as much as possible. It was a pain to try and support all of the versions of Internet Explorer (IE) and Netscape Navigator. It just was not worth it. As time went on my aversion to Javascript lessened, but I never made the effort to really learn it as a language. I would learn just enough to accomplish a small specific task.
Fast forward to 2005/2006. AJAX has become the buzzword of choice. Some smart folks have learned to deal with most/many of the issues that are still there between IE and (now) Firefox. This has given rise to Javascript libraries, with Prototype being one of the more popular.
After a few brief attempts trying to figure out how to do something useful in Javascript with Prototype I figured my lack of real Javascript skills were just not up to the job. Then Yahoo came out with their Yahoo! User Interface Library (YUI), which got me thinking about Prototype again. After reading through more examples and documentation I was finally able to accomplish exactly what I wanted.
I’m now sold on using Prototype. Sam Stephenson deserves heaps of praise. To help out others who are looking for documentation and examples, here is a list of resources for Prototype.
While trying to debug AJAX I recommend using the Firefox plugin called FireBug. Turn on the “XMLHttpRequest Spy” feature and you’ll be able to monitor all of the AJAX transactions that are going on.
Of course Prototype isn’t perfect, there are still important limitations and issues to keep in mind. For instance, the target platforms for Prototype are (from the README):
Microsoft Internet Explorer for Windows, version 6.0 and higher
Mozilla Firefox 1.0/Mozilla 1.7 and higher
Apple Safari 1.2 and higher
I’m also curious to see how it stacks up against the new Yahoo User Interface Library. Either way this is an exciting time in the land of Javascript.
Along with most folks, I’m thrilled when I see APIs made available for cool services. It seems to me that this what Tim O’Reilly means when using the term Web 2.0. With open and usable APIs others are free to create entirely new “products” by mix and matching APIs from various sources. This is great because it allows so many people to be involved in the process, not just the companies who came up with the original services. The more people involved, the bigger the pool of imagination from which new products and services can emerge.
For the most part, a service is made available (like Google Maps), reaches some level of popularity and then, sometimes much later, an API is made available for others to use. This isn’t always the case, Yahoo!’s My Web 2.0 was announced and then made some initial APIs available on day one. What I haven’t really seen much of is APIs being put out first and letting services grow around them.
So are we going to see API only services in the future? I’m not sure, but I’d argue that API only/focused services are the way to go in the future. Just like job specialization allows companies to scale in ways not possible before, I believe that API specialization would allow the Internet to scale in ways we’ve yet to see. Let’s take a basic example, spell check. Virtually anytime you use a textarea on a web page it would be helpful to offer a spell check feature. When Gmail offered an AJAXified spell check feature we were all impressed and wanted to use it in other places. But who wants to recreate the wheel for spell check every where that it might be handy to have? In part the popularity of AJAX has solved some of this problem, by providing frameworks that make adding such features to web pages easier.
Going down one more layer, what actually does the spell checking? Most languages have hooks into Aspell that allows them to does this. But does everyone who wants to use spell check on their website need to have Aspell installed and working with their language of choice? Why isn’t there a central service providing a spell check API? Why can’t they simply make use of a publicly available spell check API (via REST/SOAP/XML-RPC, etc)? This wouldn’t have to be limited to web pages either, any application could simply talk to the spell check server and get the information it needed.
There’s no reason to only have one spell check server, competition is a good thing and if one was offline for awhile then having others to fall back on would be helpful. For that matter there’s no reason why you couldn’t have a local spell check server just for your company/office, as long at it made use of the same APIs so that client applications would be able to use as a drop in replacement. Imagine being able to enter a URL in Microsoft Word in a settings area and have it make use of your company spell check server, how cool would that be? For better performance caching could be done either at some local network server and/or on the client application. In many ways this is the Web/DNS model all over again, but for APIs.
If we really are going to fully embrace the capabilities that the Internet makes possible I think that specialization at the API level is where things will go.