Matthew Buchanan had a little fun and created a Timelapse CSS example that lets you walk through the process of how a browser would put together a page if it was a human artist:
When building website templates, I’m constantly switching between a view of my CSS code and a view of the page I’m working on in a browser. At my most fevered I’m switching from one to the other after every couple of amendments, to ensure my additional rules are having the intended effect. Over time, were I to record this incremental buildup, it would paint a reasonably good picture of my approach to converting a design comp to a CSS layout.
With this in mind, I thought it might be useful to try to capture the process automatically and then play it back. I’ve seen this done using a collection of manual screen captures, but that didn’t seem a particularly elegant or easily reproducible solution.
As a proof of concept I cobbled together a (stylistically unsound) function to traverse the stylesheets of the current page (in reverse order) and remove a property from each rule every tenth of a second.
Sometimes it is interesting to see that knowledge from the 10,000 B.C. period of web development can be used in new ways to create - to play it safely - interesting ideas.
Each window in a browser has a name property which became pretty much useless when we stopped using pop-up windows and tried to make them communicate with each other by name.
There is a cross domain flag in sessvars, but although it defaults to false, this just sees to that you don't get any other sites window.name garbage inside your sessvars by mistake. The actual data you set will be available for other scripts on other domains to look at – and also to anyone able to type javascript:alert(window.name) in the browser's address bar
An open source set of tools for persistence and distributed computing using intuitive standards-based JSON interfaces of HTTP REST, JSON-RPC, JSONPath, and HTTP Channels. The core of the Persevere project is the Persevere Server. The Persevere server includes a Persevere JavaScript client, but the standards-based interface is intended to be used with any framework or client.
The Persevere Server is an object storage engine and application server
(running on Java/Rhino) that provides persistent data storage of dynamic
JSON data in an interactive server side JavaScript environment. It is
currently in beta, and boasts a very solid feature set that should
interest JavaScript, Dojo and Ajax developers:
Create, read, update, and delete access to persistent data through
a standard JSON HTTP/REST web interface
Dynamic object persistence - expando objects, arrays, and
JavaScript functions can be stored, for extensive JavaScript persistence
support
Remote execution of JavaScript methods on the server through
JSON-RPC for a consistent client/server language platform
Flexible and fast indexed query capability through JSONPath
Comet-based data monitoring capabilities through HTTP Channels
with Bayeux transport plugin/negotiation support
Data-centric capability-based object level security with user
management, Persevere is designed to be accessed securely through Ajax
with public-facing sites
Comprehensive referencing capabilities using JSON referencing,
including circular, multiple, lazy, non-lazy, cross-data source, and
cross-site referencing for a wide variety of object structures
Data integrity and validation through JSON Schema
Class-based data hierarchy - typed objects can have methods,
inheritance, class-based querying
Pluggable data source architectures - SQL tables, XML files,
remote web services can be used as data stores
Service discovery through Service Mapping Description
OpenKM is a multi-platform application for document management based on GWT, JBoss, and Jackrabbit (the content repository API).
Version 2.0 has been released, which you can test drive to see the application-style interface. The new features in 2.0 include: the previsualization of multimedia elements as images and videos, an improved an rewritten administration interface, a centralized management of templates, an exclusive area to allow users to store their private documentation, a tool for massive import and output data from ZIP files, searches by date ranks as well as translations to more languages.
However, one of the more relevant functions to mention is the indexing of the most common types of files: text, Office, Office 2007, OpenOffice, PDF, HTML, XML, MP3, JPEG, etc.
Are child selectors slower than more simple brethren? This is a question that Jon Sykes sought out data for after he read the work of Jim Barraud.
His conclusion?
The skinny is that child selectors are a major performance issue.
This seemed to make sense, but to me I needed some sort of proof rather than just being told it's that way by someone, so over the last two days I've tried two approaches to see if I can replicate the issue.
The first one was rather a half-assed idea that afterwards seems fundamentally flawed as a benchmark.
The tests show that there is slow down using child selectors over direct class name declarations in IE6, IE7 and Safari 3. Safari 3 being the most impacted by child selectors. Firefox 2 has some impact, and Firefox 3 doesn’t seem to be impacted at all.
That said, this is a very extreme test, it is not often you’d have 20,000 class definitions in a single page or that all of them would use 4 levels of child selector.
Piotr Dachtera took his 64pola.pl, and created a scalable version using Comet. Dylan reports it as "a Jetty-powered Comet app that uses dojox.cometd on the client-side. It’s a solid implementation that shows chess moves in real-time, and to date is the best all-around Comet game I’ve seen that is live to the world."
Mathieu Nouzareth then commented that Cafe.com, a Flash based gaming platform also uses Jetty and Comet techniques (compared to AMF etc).
Tom Trenka has detailed a great analysis of JavaScript performance across the various browsers. This is important work, and it reminded me of the JVM days where people tried to use pools and such... to find out that they were bad for performance as newer VM technology came out. When you try to be too tricky you can end up in a bad state as new versions try to optimize the common task, and not your trick.
Eugene Lazutkin had a great explanation on Strings in languages:
Many modern languages (especially functional languages) employ “the immutable object” paradigm, which solves a lot of problems including the memory conservation, the cache localization, addressing concurrency concerns, and so on. The idea is simple: if object is immutable, it can be represented by a reference (a pointer, a handle), and passing a reference is the same as passing an object by value — if object is immutable, its value cannot be changed => a pointer pointing to this object can be dereferenced producing the same original value. It means we can replicate pointers without replicating objects. And all of them would point to the same object. What do we do when we need to change the object? One popular solution is to use Copy-on-write (COW). Under COW principle we have a pointer to the object (a reference, a handle), we clone the object it points to, we change the value of the pointer so now it points to the cloned object, and proceed with our mutating algorithm. All other references are still the same.
JavaScript performs all of “the immutable object” things for strings, but it doesn’t do COW on strings because it uses even simpler trick: there is no way to modify a string. All strings are immutable by virtue of the language specification and the standard library it comes with. For example: str.replace(”a”, “b”) doesn’t modify str at all, it returns a new string with the replacement executed. Or not. If the pattern was not found I suspect it’ll return a pointer to the original string. Every “mutating” operation for strings actually returns a new object leaving the original string unchanged: replace, concat, slice, substr, split, and even exotic anchor, big, bold, and so on.
Tom then went on to detail the rounds that he went through:
Round 1: Measuring Native Operations.
Round 2: Comparing types of buffering techniques.
Round 3: Applying Results to dojox.string.Builder.
There are a few surprises here, and Tom later concludes:
Native string operations in all browsers have been optimized to the point where borrowing techniques from other languages (such as passing around a single buffer for use by many methods) is for the most part unneeded.
Array.join still seems to be the fastest method with Internet Explorer; either += or String.prototype.concat.apply(”", arguments) work best for all other browsers.
Firefox has definite issues with accessing argument members via dynamic/variables
Craig Riecke, Rawld Gill, and Alex Russell, along with the Pragmatic Programmers themselves have been kind enough to give the Ajaxian community some exclusive extracts from the Mastering Dojo beta book.
What do we have on the docket?
First, we have details on the Dojo DOM Apis. Specifically, the author takes us through a challenge involving interview questions and manipulating the DOM for them. We end up seeing code that uses dojo.query, and class addition such as:
dojo.addClass(node, (i % 2) ? "lightBand" : "darkBand");
});
}
It then delves into the intricacies of dojo.query and beyond.
Secondly, we have Ajax the Dojo way which takes us on a trip down dojo.data and dojox.Grid lane... two differentiating features that Dojo comes with. The chapter builds a wishlist system using these features.
There is a lot lot more in the book, which the table of contents covers for you. There are 400 pages of material here that cover the huge variety that exists within the Dojo community.
Thanks to the authors and the editor for sharing this with us.
Flickr, Viddler, Qik, Pownce and Revision3 are the first services to support oEmbed, an easy way to allow embeding media from a certain URL in a third party site.
oEmbed is a format for allowing an embedded representation of a URL on third party sites. The simple API allows a website to display embedded content (such as photos or videos) when a user posts a link to that resource, without having to parse the resource directly.
This means that if you for example find a nice photo on flickr, you can take the URL and easily turn it into embed-able data:
John Resig has completed 7 months of work to produce a port of Processing, the "programming language and integrated development environment (IDE) built for the electronic arts and visual design communities", which aims to teach the basics of computer programming in a visual context, and to serve as the foundation for electronic sketchbooks. One of the stated aims of Processing is to act as a tool to get non-programmers started with programming, through the instant gratification of visual feedback."
The first portion of the project was writing a parser to dynamically convert code written in the Processing language, to JavaScript. This involves a lot of gnarly regular expressions chewing up the code, spitting it out in a format that the browser understands.
The language includes a number of interesting aspects, many of which are covered in the basic demos. Here's a brief selection of language features that are handled:
Types and type casting - Type information is generally discarded, but becomes important in variable declaration and in casting (which is generally handled well).
Classes - The full class system is supported (can be instantiated, etc. just fine).
Method overloading and multiple constructors - Within classes you can have multiple method (or constructor) definitions - with the appropriate methods being called, based upon their signature length.
Inheritance - Even classical-style inheritance is supported.
Note: There's one feature of Processing that's pretty much impossible to support: variable name overloading. In Processing you can have variables and functions that have the same name (e.g. float size = 0; float size(){}). In order to support this there would have to be considerable overhead - and it's generally not a good practice to begin with.
The Processing API
The second portion of the project is the full 2d Processing API. This includes all sorts of different methods:
Shapes drawing
Canvas manipulation
Pixel utilities
Image drawing
Math functions
Keyboard and mouse access
Objects (point, arrays, random number generators)
Color manipulation
Font selection and text drawing
Buffers
Congratulations to John, and I look forward to seeing some fantastic visualizations in the browser thanks to this work.
Last, but never least, is Alex Russell of the Dojo Toolkit and SitePen. In Alex's five minutes of video footage for our JavaOne talk, he explained how Dojo enables you to built fantastic, responsive applications for everyone. The everyone piece revolves around accessibility too, which is core to Dojo thanks to work from Becky Gibson and others on the team.
The Dojo grid and charting packages are very rich these days, and continue to get better. Alex also noted in a separate discussion how there are subtle advantages to the charting package such as being able to print the darn things out nicely. Other flashier products may not allow that minor feature.
