Kent Johnson has released YPulse a simple open source wrapper for the YUI Animation library that makes creating highlight fades and pulsing button glows a bit easier.
Passpack notified me about their new library to support Host-Proof Hosting (HPH) development (touched on earlier). The library allows anyone to set up HPH on their own infrastructure. It's mostly a browser-side library powered by JQuery, focused on transferring encrypted data, and there's also some sample server-side PHP code.
I think the most important part of HPH is that it provides users with real-world data privacy, it's not just a theory, it works now. I'd love to see the pattern get some traction with SaaS providers, but it's not the most obvious system to implement. To this avail, we've just released an MIT/LGPL library for creating Host-Proof Hosting applications: http://code.google.com/p/passpack/
Host-Proof Hosting is the pattern whereby the server knows nothing about the user's data, because the browser ensures it's kept encrypted each time it goes over the wire. It's been practiced in the real world for a couple of years now, but has received some extra attention lately. Clipperz, a Passpack competitor, recently mentioned interest from Richard Stallman in its advocacy for "zero knowledge web applications".
The Zero Knowledge Web Application as-is, is a theory. This is not to say that there couldn’t be a future where it might become a credible solution for privacy, but until that happens, it is inappropriate to ask people to trust a theory with just too many inconsistencies.
Updated after clarification from Passpack - the library is for any server infrastructure, not an API to communicate specifically with Passpack's servers. They say such an API is on the radar.
Posted by Michael Mahemoff at 1:45 pm Comment here
ShiftZoom 1.0 is the latest tool from Christian Effenberger that allows you to add zoom and pan functionality to oversized images on your webpages. It uses unobtrusive javascript to keep your code clean. Requires no plugin/extension or any other external resource!
It works in all the major browsers - Mozilla Firefox 1.5+, Opera 9+, IE 6+ and Safari. Works also on older browsers supporting images & createElement & getElementById, else it'll degrade and your visitors won't notice a thing.
Kyle Simpson has announced a new family of opensource projects called flensed and the first project being flXHR which "utilizes javascript+flash to create a complete, literal drop-in replacement (by being API identical) for the native browser XHR (Ajax) communication mechanism. However, flXHR uses Flash Player's security model to enable direct cross-domain communication, and also has a number of other very helpful extensions."
http://flxhr.flensed.com/code/tests/flxhr-4.html
There are a number of demos which illustrate how it easy it is to take the API-compatible flXHR and swap it to any of your favorite JS frameworks (Dojo, Prototype, YUI, ExtJS, etc) in place of its usage of native XHR... once the simple adapt/swap happens, everything else about the framework library communication works the same, because flXHR speaks the same familiar protocol and API, and so it really is what I like to call "set it and forget it" good.
Hasn't this been done before?
There have been several other attempts at similar things before, including SWFHttpRequest, FlashXMLHttpRequest, Fjax, and F4A. However, all those fell short of the mark in different ways. On my site, there are comparison charts and detailed FAQ's which show how flXHR stands up to these predecessors, and exceeds them in very important and powerful ways. I believe flXHR has accomplished its goal, which was to be *the* complete solution for SWF-based Ajax calls as an identical API-compatible drop-in replacement for native XHR, not to mention many helpful improvements including robust error callback handling, timeouts, and convenience configuration functions, to name a few.
The websites were collected from the Alexa US Top 100 and the Webware Top 100 Web Apps. The frameworks we looked for were Prototype, JQuery, MooTools, Yahoo! UI Library, Dojo, ExtJS and MochiKit.
They talk about the various sites that use each framework, and even some that use multiple (e.g. Digg using Prototype and jQuery) and they conclude:
Prototype turned out to be the most-used framework in this survey, with JQuery not far behind. It was also interesting to see that several sites are using the Yahoo! UI Library. We had imagined that this number would be lower and that far more websites would be using Prototype and JQuery.
It should be noted that this survey doesn’t necessarily give a 100% complete picture since we only looked at the homepage of the websites. We also didn’t log in to any websites. And of course, we didn’t look for every single Javascript framework out there.
I asked Peter Alguacil how they decide if a site uses a library, and he updated the article:
We made a list of websites consisting of the Alexa US Top 100 and also Webware’s Top 100 Web Apps (minus actual applications such as Firefox and Skype). Using a special tool we then looked at all the websites after specific keywords to identify the frameworks.
For example, for Prototype we looked for the strings “prototype.js†and “/prototype†which should cover most variations of including the framework, unless the word “prototype†has been completely removed.
We also manually checked all sites that were found to contain references to the frameworks we tested for. In the case of the Yahoo! UI we excluded sites that only used its CSS framework and not any Javascript.
A lot of people will do things like, combine prototype.js with their_app.js and create my_app.js as a compressed and/or minified munging of everything. This means that it won't be counted. It would be cool to also add checks for JavaScript objects (e.g. run a site with Rhino and check for the "Prototype" object.
John Leach has created a very cool new open source project called Frizione (Italian for Clutch).
Frizione is a "JavaScript development, testing and deployment environment. It comprises a library agnostic set of tools for any type of browser based JavaScript development, which coincidentally has Gears support."
You run Frizione as a Web server and it gives you a set of services:
Compressor Service
The compressor service takes a JavaScript file and removes comments and
unnecessary whitespace. This can be a destructive operation in that the original
JavaScript file can be overwritten, unless the -o option is specified – you have been
warned.
To invoke the service, send a POST request to /run_compressor, appending the
absolute JavaScript file path, with respect to the /Clutch root directory, as part of
the URL. Clutch will then compress the JavaScript file. Additional request parameters
can be set to modify the behaviour of the compressor, using the YUICompressor
command line options.
Fixture Service
The fixture service allows you to write text to hard disk. When sent a POST, the
service writes the POST data to the file specified in the URL, optionally modifying the
contents with parameter values specified in the POST request, using ERB.
To invoke the service, send a POST request to /run_fixture, appending the
absolute output text file path, with respect to the /Clutch root directory, as part of
the URL.
Join Service
The join (or concatenate) service uses ERB to join together a list of text files,
producing a single concatenated file. Each file can contain include commands
which contain relative URLs to other files to be included at the point of the include
command itself. This process can also be repeated within the included files (nesting).
To invoke the service, send a POST request to /run_join, specifying the absolute
text file path, with respect to the /Clutch root directory, as part of the URL. Clutch
will then create the joined (or concatenated) file. The to request parameter is
required to set the destination absolute URL of the resulting joined file.
JSLint Service
The original lint program analysed C source code for potential (and subtle)
malpractices likely to lead to run-time bugs. Modern C compilers now provide
sufficient syntactic and semantic checking that lint is now rarely required or used.
Fortunately for JavaScript programmers, Douglas Crockford has built a lint program
specifically for JavaScript, in JavaScript, called JSLint. Finding and removing
potentially poor code before unit testing is an essential process, at least for me.
Unfortunately, cutting and pasting code to the web page can itself be error prone.
Clutch alleviates this problem by creating static HTML pages that read in your
JavaScript code, which can then be analysed locally by JSLint. You only need create
the static HTML page once for each JavaScript file you wish to analyse.
To invoke the service, send a POST request to /run_jslint, specifying the absolute
JavaScript file path, with respect to the /Clutch root directory, as part of the URL.
Clutch will then produce a static HTML file under the /jslint folder, which
automatically loads the JavaScript file into the JSLint page. You may then wish to add
a link to this static HTML file in the /jslint/index.html page.
Test Service
The test service creates a run/view pair of static HTML files for a given JavaScript
file. The reasons for using two HTML files is explained in the 'Unit Testing' section
below.
It can also provide functionality similar to the join service. It can use ERB to join
together a list of JavaScript files, producing a single concatenated JavaScript file, but
only if the to parameter is specified.
To invoke the service, send a POST request to /run_test, specifying the absolute
JavaScript file path, with respect to the /Clutch root directory, as part of the URL.
Clutch will then create the two static HTML files.
The Unit Test Framework
The framework follows a similar pattern to the well known JUnit Java testing
framework.
Create your test methods in a plain JavaScript object, then wrap that object in a
clutch.unittest function call, as shown in the first example above. All functions
in your test object which begin with test will be executed by the unit test
framework, but the order of function execution is not guaranteed.
Before a testxxx function is executed, the unit test framework will execute a setUp
function in your object. After a testxxx function has been executed, the unit test
framework will execute a tearDown function in your object. Clutch provides a
default no-operation function for setUp and tearDown if none are defined in your
object.
As I say in this podcast interview, I got an early look at 280 Slides the application that launched yesterday to much acclaim. People are calling it "Keynote on the Web", which the team finds very humbling, and hope that one day they have all of the great features (and more!).
I really like these guys. A couple of them worked on cool products at Apple, and it turns out that they started the language and runtime work back at school.
Objective-J is the language that takes JavaScript and makes it Objective (as Obj-C did to C). Lots of square brackets. When the browser gets served .j files, it preprocesses them on the fly. This means that you can do things like, use standard JavaScript in places.
Cappuccino is the port of the Cocoa framework.
The guys talk a little about the toolchain an why they did this, and even how it enables future cool things such as generating a native Mac application from the same code.
We also get into the fun cross browser issues that they work around, and how they are abstracting developers high up, so you don't have to deal with these issues.
Finally, I was excited to hear that they will be open sourcing the code at objective-j.org shortly (may not be there yet). They are going through the usual issues of choosing a license (Apache2 please?), a source control system (Subversion vs. Git), and documenting the thing ;)
The team was very interested in learning what JavaScript developers think (They have heard from Objective-C folk who love it), so let them know in the comments!
Nexaweb has released a new product that build on Dojo, dojo.E:
dojo.E provides developers with the ability to use an XML based markup language to add in their Ajax behaviors. Markup whether — XML, HTML or CSS — simplifies development by allow developers to convey in simple text format what they would otherwise need to convey in code. Markup also provides a great abstraction layer that separates the implementation from the usage.
This release, which is an Apache style open source project itself, consists of two pieces:
dojo.E Markup
dojo.E Markup allows developers to describe their dojo components using a simple markup language that translates directly into dojo classes. For example declaring a button in dojo would be done one of two ways;
The xModify syntax above tells the dojo.E runtime to append a “
{0}
†tag to the dojo SortList component. The select statement in this case is a XPath statement and not a CSS selector. In the actual sample this snippet above is wrap with a “Macro†which allows the developer to parameterize the “{0}†and execute the xModify snippet when the developer clicks the “Add†button.
You can play with this in a live editor that shows samples such as a todo list:
I just got to announce the Google AJAX Libraries API which exists to make Ajax applications that use popular frameworks such as Prototype, Script.aculo.us, jQuery, Dojo, and MooTools faster and easier for developers.
Whenever I wrote an application that uses one of these frameworks, I would picture a user accessing my application, having 33 copies of prototype.js, and yet downloading yet another one from my site. It would make me squirm. What a waste!
At the same time, I was reading research from Steve Souders and others in the performance space that showed just how badly we are doing at providing these libraries. As developers we should setup the caching correctly so we only send that file down when absolutely necessary. We should also gzip the files to browsers that accept them. Oh, and we should probably use a minified version to get that little bit more out of the system. We should also follow the practice of versioning the files nicely. Instead, we find a lot of jquery.js files with no version, that often have little tweaks added to the end of the fils, and caching is not setup well at all so the file keeps getting sent down for no reason.
When I joined Google I realised that we could help out here. What if we hosted these files? Everyone would see some instant benefits:
Caching can be done correctly, and once, by us... and developers have to do nothing
Gzip works
We can serve minified versions
The files are hosted by Google which has a distributed CDN at various points around the world, so the files are "close" to the user
The servers are fast
By using the same URLs, if a critical mass of applications use the Google infrastructure, when someone comes to your application the file may already be loaded!
A subtle performance (and security) issue revolves around the headers that you send up and down. Since you are using a special domain (NOTE: not google.com!), no cookies or other verbose headers will be sent up, saving precious bytes.
This is why we have released the AJAX Libraries API. We sat down with a few of the popular open source frameworks and they were all excited about the idea, so we got to work with them, and now you have access to their great work from our servers.
Details of what we are launching
You can access the libraries in two ways, and either way we take the pain out of hosting the libraries, correctly setting cache headers, staying up to date with the most recent bug fixes, etc.
The first way to access the scripts is simply be using a standard <script src=".."> tag that points to the correct place.
For example, to load Prototype version 1.6.0.2 you would place the following in your HTML:
You will notice that the version used was just "1". This is a smart versioning feature that allows your application to specify a desired version with as much precision as it needs. By dropping version fields, you end up wild carding a field. For instance, consider a set of versions: 1.9.1, 1.8.4, 1.8.2.
Specifying a version of "1.8.2" will select the obvious version. This is because a fully specified version was used. Specifying a version of "1.8" would select version 1.8.4 since this is the highest versioned release in the 1.8 branch. For much the same reason, a request for "1" will end up loading version 1.9.1.
Note, these versioning semantics work the same way when using google.load and when using direct script urls.
By default, the JavaScript that gets sent back by the loader will be minified, if there is a version supported. Thus, for the example above we would return the minified version of jQuery. If you specifically want the raw JavaScript itself, you can add the "uncompressed" parameter like so:
Today we are starting with the current versions of the library, but moving forward we will be archiving all versions from now onwards so you can be sure they are available.
Here I am, talking about what we are doing in two short slides:
The Future
This is just the beginning. We obviously want to add more libraries as you find them useful. Also, if you squint a little you can see how this can extend even further.
If we see good usage, we can work with browser vendors to automatically ship these libraries. Then, if they see the URLs that we use, they could auto load the libraries, even special JIT'd ones, from their local system. Thus, no network hit at all! Also, the browser could have the IP addresses for this service available, so they don't have the hit of a DNS lookup. Longer lived special browser caches for JavaScript libraries could also use these URLs.
The bottom line, and what I am really excited about, is what this could all mean for Web developers if this happens. We could be removed of the constant burden of having to re-download our standard libraries all the time. What other platform makes you do this?! Imagine if you had to download the JRE everytime you ran a Java app! If we can remove this burden, we can spend more time flushing out functionality that we need, and less time worrying about the actual download bits. I am all for lean, but there is more to life.
Acknowledgements
I want to acknowledge the other work that has been done here. Some libraries such as jQuery and Dean Edwards Base were already kind of doing this by hot linking to their Google Code project hosting repository. We thought this was great, but we wanted to make it more official, and open it up to libraries that don't use our project hosting facilities.
Also, AOL does a great job of hosting Dojo already. We recommend using them for your Dojo needs, but are proud to also offer the library. Choice is good. Finally, Yahoo! placed the YUI files on their own CDN for all to use.
Jeff Watkins is updating his MVC library, Coherent, and is wondering if he should add declarative syntax for child widgets. Currently, you have to write a lot of init() setup code, but instead he would like to do something like:
, JavaScript
