| Some more JavaScript performance tips |
[23 May 2008|01:21pm] |
12:09 19.05.2008
Some more JavaScript performance tips
Thierry Schellenbach has written up some thoughts about JavaScript optimization for Prototype apps after playing with console.profile() / console.profileEnd() in his Prototype applications.
The core advice is pretty simple:
- Beware of $$ and event binding
- Beware of other Prototype methods (reports a 40 times speed different between innerHTML and element.update)
- Write to innerHTML instead of using document.createElement
- Use for loops instead of for in loops
- Use Array.join instead of += on a string
- Cache variables and functions
- Limit the usage of eval
- Limit the usage of Try Catch statements
- When manipulating the DOM copy the element out of DOM change it and stick it back in
We need more performance data on some of these, especially to track them over time. I have seen the opposite argued for a couple of them ;)
read more at Ajaxian
|
|
| Having a Tamarin trace a Spidermonkey |
[23 May 2008|01:21pm] |
12:15 19.05.2008
Having a Tamarin trace a Spidermonkey
David Mandelin has posted about Tracehydra, which is the idea that the traced based JIT engine that is being worked on as part of Tamarin could be hooked up to Spidermonkey.
Tracehydra would be the fluffy cloud that translates Spidermonkey bytecode to Tamarin IL (or possibly LIR-the details get confusing fast). (In the interest of reducing confusion slightly, I’ll say that IL stands for intermediate language, and is roughly a synonym for bytecode. TT people often refer to their IL as “Forth” because they based the design on Forth or something, but I know nothing more about Forth than that it involves stacks, so that doesn’t help me.)
Specifically, Tracehydra means using Treehydra to translate the Spidermonkey (SM hereafter) C code that interprets each bytecode into C++ that emits equivalent (to the C) Tamarin IL. So I guess it reduces the problem from translating SM bytecode TT IL to translating SM C cases to TT IL-building code. Put that way, it’s not clear this actually helps, but I think SM bytecode is believed to have complex semantics that would be difficult to code in TT IL by hand, and maybe the C in SM has fewer constructs that are easier to translate. Seems possible, anyway.
David then goes on to digg into Tamarin, which is weak on docs (according to him). He walks through the various pieces of Tamarin and explains the ABC bytecode vs. the IL etc. A very nice read, and maybe Tracehydra will be the first form that we see Tamarin in Firefox?
read more at Ajaxian
|
|
| dojox.lang.aspect: More than just interception |
[23 May 2008|01:21pm] |
12:53 19.05.2008
dojox.lang.aspect: More than just interception
Eugene Lazutkin has written a very thorough post on dojox.lang.aspect a module that takes AOP seriously in JavaScript.
As someone who has been to a couple AOSDs (the AOP software conference) and was excited to see AOP on the scene, it is good to see someone who gets it working on the JavaScript side.
Of course, we all get the interception piece. It is very easy to just wrap a method to do something new in a dynamic language such as JavaScript. But the power (and complexity!) of AOP lies in the world of joinpoints, pointcuts and worm holes :)
For these, a dynamic language isn't as helpful. Eugene delves into the world and takes us to the module from first principles. He then builds a timer aspect which can be used to profile an application. Along with a memoizer and other useful cross cutting concerns, you end up with good ole Fibonaci:
JAVASCRIPT:
-
-
var fib = new Fibonacci;
-
-
// we will time the calculations
-
aop.advise(fib, "calculate", aop.timer("fib");
-
-
fib.calculate(15);
-
fib.setOrder(0);
-
fib.calculate(15);
-
-
// now lets use memoization
-
aop.advise(fib, "calculate", aop.memoizer());
-
aop.advise(fib, /^set/, aop.memoizerGuard("calculate"));
-
-
fib.setOrder(1); // set order back to 1 - regular Fibonacci numbers
-
fib.calculate(15);
-
fib.setOrder(0);
-
Memoization got results too:
On my computer with Firefox 3 the calculation of 1-order (regular) Fibonacci number of 15 (987) took ~48ms without memoization and 0-1ms after memoization. The calculation of 0-order Fibonacci number of 15 (32768) took ~1155ms without memoization and the same 0-1ms after. As you can see this technique can work wonders without much investment of time.
Just like with Java, we won't see every developer worrying about pointcuts day to day, but instead, simple usage of existing advice will become very useful indeed.
read more at Ajaxian
|
|
| Webmonkey is back! |
[23 May 2008|01:21pm] |
05:01 20.05.2008
Webmonkey is back!
Webmonkey was a great resource for us when we the Web took off, and it was a shame to see it die out. Today we saw that Webmonkey has been re-born as Conde bought it back and put the content back online.
We have also republished the bulk of Webmonkey’s vast library of tutorials and reference guides on a wiki. With very few exceptions, every page in the tutorials, reference and code library sections of the site is publicly editable. We’re using MediaWiki’s open source software to host the content.
Some new things you’ll notice:
* Articles can be tagged and rated.
* Each page has its own backchannel for comments and discussion.
* Registered users get profile pages where they can talk about their projects and list the sites they’ve built.
* We’re still in the beta phase. Webmonkey is, and will continue to be, a constant work in progress. If you run into trouble, check the FAQ or drop us a line. We’ve set up a wiki page for bug tracking, so if you see something that doesn’t quite look right, let us know.
Welcome back. Now you can join the other Web monkeys out there (from Tamarin to ActionMonkey).
read more at Ajaxian
|
|
| IE 8 and Cross Document Messaging |
[23 May 2008|01:21pm] |
11:04 20.05.2008
IE 8 and Cross Document Messaging
IEBlog has posted about the IE 8 support of postMessage, which is great news.
They link to a MSDN article that discusses the support, and a use case.
Jeff Walden noted that "the interface implemented by the current IE8 beta lags the HTML5 specification by several revisions in backwards-incompatible ways, so if you're going to experiment with this, be aware that what you're doing will break in a future revision of IE8." and detailed the differences.
It appears that only Firefox 3 RC 1 and Webkit Nightly have implemented the current spec.
read more at Ajaxian
|
|
| moo.rd 1.3 released |
[23 May 2008|01:21pm] |
13:01 20.05.2008
moo.rd 1.3 released
The moo.rd team has released version 1.3.1 of the moo.rd extension and seems to be almost a rewrite, nowbased on MooTools 1.2 so it uses the new MooTools syntax and logic.
The team told us about the release:
This release features new components like the Cycle Effects and Cycles Effects which allows to create powerful slide shows based on a particular transition that an user can create or pick out from the default collection (contains about 25).
In addiction we'll found the Glider Class for creating professional slide shows entirely customizable, the Kwick.Menu Class for creating kwick menus, the Kwick.All Class to apply the kwick to each property, the new powerful Fx Effects (now subdivided by "type"), new Native functions, the new Customs which allow to "customize" the browser's behaviours: so we have the custom alert, custom confirm, custom prompt, custom searches and many more.
Finally the new, super powerful Virtual Boxes: the Virtual.Box for creating professional modal image presentations, the Virtual.Ajax for creating modal contents loaded from the server, the Virtual.HTML for creating modal boxes with static content and the respective "single" versions.
In addiction, one important feature can be found in the Download Builder: now the users can include MooTools (full version or needed version) and moo.rd into one script!
read more at Ajaxian
|
|
| Browser cookie restriction research |
[23 May 2008|01:21pm] |
13:53 20.05.2008
Browser cookie restriction research
Nicholas C. Zakas was doing some prep work for his new book when he delved into browser cookie restrictions for the big four browsers:
The most interesting fact I discovered is that Safari places no limit
on the number of cookies that can be set per domain. In fact, you can
set enough cookies on the client to cause a server error as the cookie
header can be too long to parse.
He also found out that:
- Microsoft indicated that Internet Explorer 8 increased the cookie limit per domain to 50 cookies but I've found that IE7 also allows 50 cookies per domain. Granted, this may have been increased with a system patch rather than having the browser's first version ship like this, but it's still more than the 20 that was commonly understood to be the limit.
- Firefox has a per-domain cookie limit of 50 cookies.
- Opera has a per-domain cookie limit of 30 cookies.
- Safari/WebKit is the most interesting of all as it appears to have no perceivable limit through Safari 3.1. I tested setting up to 10,000 cookies and all of them were set and sent along in the
Cookie header. The problem is that the header size exceeded the limit that the server could process, so an error occurred.
So the prevailing knowledge that browsers limit per-domain cookies to 20 is no longer valid. Another interesting inconsistency is how browsers react when too many cookies are set. With the exception of Safari, which sets all cookies regardless of the number, there are two approaches:
- The least recently used (LRU) approach automatically kicks out the oldest cookie when the cookie limit has been reached in order to allow the newest cookie some space. Internet Explorer and Opera use this approach.
- Firefox does something strange: it seems to randomly decide which cookies to keep although the last cookie set is always kept. There doesn't seem to be any scheme it's following at all. The takeaway? Don't go above the cookie limit in Firefox.
The total size of cookies also varies from browser to browser. This is another one that is a little hard to comprehend, but here's what my tests show:
- Firefox and Safari allow cookies with up to 4097 characters, that's 4096 for the name and value and one for the equals sign.
- Opera allows cookies with up to 4096 characters, which is for the name, value, and equals sign.
- Internet Explorer allows cookies with up to 4095 characters, which is for the name, value and, equals sign.
read more at Ajaxian
|
|
| classy_inputs: Rails plugin to add autoclass names |
[23 May 2008|01:21pm] |
14:50 21.05.2008
classy_inputs: Rails plugin to add autoclass names
We all want to use input[type=text] but browser support doesn't seem to quite be there (IE 6?).
This lead James Coglan down the path of creating a teeny Rails plugin, classy_inputs:
Good lord do I ever hate input tags. (YUI hates them too, but I’ll leave that story for another time). All the different types should really have been different tag names, and they are a total pain to use with CSS. As such, I used to end up doing tedious stuff like adding a :class option to every form element when writing Rails templates. A while back, I tried to patch Rails to get it to do this automatically, but its test suite totally baffled me at the time by applying the classes in some places but not others.
So, a quick plugin to stave off RSI:
script/plugin install
http://svn.jcoglan.com/classyinputs/trunk/classy_inputs
With that installed, any input tag created using a Rails view method will gain a class name matching its type attribute. Maybe I’ll have another stab at patching Rails, but I’m not promising anything.
read more at Ajaxian
|
|
| Stack: A native Array wrapper that works |
[23 May 2008|01:21pm] |
15:00 21.05.2008
Stack: A native Array wrapper that works
Andrea Giammarchi has created a native array wrapper that works across browsers. He is excited:
I do not know how many times, during this years, JavaScript Ninjas have tried to subclass the native Array to create libraries over its powerful methods without losing performance. I have finally discovered the way to remove the locked length from Internet Explorer 8, and to solve problems with every other browser.
He ended up with the Stack class:
JAVASCRIPT:
-
-
/**
-
* Choose a name for subclassed Array
-
*/
-
Stack = (function(){ // (C) Andrea Giammarchi - Mit Style License
-
-
/**
-
* Your personal Array constructor
-
*/
-
function Stack(length){
-
if(arguments.length === 1 && typeof length === "number")
-
this.length = -1 <length && length === length <<1>> 1 ? length : this.push(length);
-
else if(arguments.length)
-
this.push.apply(this, arguments);
-
};
-
-
// Solution 1:
-
// Declaration of generic function
-
// with an array as prototype
-
function Array(){};
-
Array.prototype = [];
-
-
// Solution 2:
-
// use the prototype chain to inherit
-
// Array constructor and its native prototype
-
Stack.prototype = new Array;
-
-
// Solution 3:
-
// overwrite inherited length with zero value
-
Stack.prototype.length = 0;
-
-
// Solution 4:
-
// redeclare toString method in this way
-
// to let JScript core feel better
-
Stack.prototype.toString = function(){
-
return this.slice(0).toString();
-
};
-
-
/**
-
* Return and assign subclassed Array
-
*/
-
Stack.prototype.constructor = Stack;
-
return Stack;
-
-
})();
-
read more at Ajaxian
|
|
| Dojo and Zend Framework Integration Released |
[23 May 2008|01:21pm] |
15:01 21.05.2008
Dojo and Zend Framework Integration Released
The Zend Framework aims to be a top notch framework for building next generation Web applications in PHP. Dojo has similar aims on the front-end side, so they decided to join forces to provide an integration layer. If you like the combination you will have a better, tighter, way to build your applications.
What we see in the initial release is:
-
JSON-RPC Server: We are re-working the Zend_Json_Server that has
been in our incubator since, oh, what? 0.2.0? and never released to
actually follow a specification:
JSON-RPC. This
will allow it to work seamlessly with Dojo, as well as other toolkits
that have JSON-RPC client implementations. I have actually completed
work on this, though the proposal is waiting to be approved; if you want
to check it out, you can find it in the
ZF svn.
The original Zend_Json_Server implementation will be abandoned. It was
never fully tested nor fully documented, which has prevented its
release. Additionally, since it implemented its own ad-hoc standard, it
did not provide the type of interoperability that a true JSON-RPC server
implementation will provide. I am excited that we will finally be able
to provide a standards-compliant solution for general availability.
One final note: there are currently two different JSON-RPC
specifications, 1.0 and 2.0. My goal is to support each, though for the
time being, only version 1.0 will be supported, as that is the version
Dojo currently targets.
-
dojo() View Helper: Enabling Dojo for a page is not typically as
trivial as just loading the dojo.js script -- you have a
choice of loading it from the AOL CDN or a local path, and also may want
or need to load additional dojo, dijit, or dojox modules, specify custom
modules and paths, specify code to run at onLoad(), and
specify stylesheets for decorating dijits. On top of this, this
information may change from page to page, and may only be needed for
a subset of pages. The dojo() view helper will act as a
placeholder
implementation, and facilitate all of the above tasks, as well as take
care of rendering the necessary style and
script elements in your page.
-
Form Element implementations: One area that developers really
leverage javascript and ajax toolkits is forms. In particular, many
types of form input can benefit from advanced and rich user interfaces
that only javascript can provide: calendar choosers, time selectors,
etc. Additionally, many like to use client-side validation in order to
provide instantaneous validation feedback to users (instead of requiring
a round-trip to the server). We will be identifying a small group of
form elements that we feel solve the most relevant use cases, and write
Dojo-specific versions that can be utilized with Zend_Form.
(One thing to note: Zend_Form's design already works very
well with Dojo, allowing many widgets and client-side validations to be
created by simply setting the appropriate element attributes.)
-
dojo.data Compatibility:
dojo.data defines a
standard storage interface; services providing data in this format can
then be consumed by a variety of Dojo facilities to provide highly
flexible and dynamic content for your user interfaces. We will be
building a component that will create dojo.data compatible payloads with
which to respond to XmlHttpRequests; you will simply need to pass in the
data, and provide metadata regarding it.
Of course, you can continue to any Ajax library in conjunction with the Zend Framework, and ditto for Dojo.... but why did this match happen?
There are many synergies and similarities between the two projects and their communities, including:
- Licensing and IP: Both projects are very business friendly.
- Design affinity: Similar philosophies, including a strong emphasis on use-at-will architecture.
- JSON format used strongly in both
- Comprehensive Ajax Solution: Dojo has it all
- Standards: "Dojo not only implements published standards, but also drives them"
- Communities and support: Strong communities, with support offerings behind them
And, here is some code from a JSON-RPC demo:
PHP:
-
-
<h2>Dojo JSON-RPC Demo</h2>
-
<input name="foo" type="button" value="Demo" onClick="demoRpc()"/>
-
<?
-
$this->dojo()->setLocalPath('/js/dojo/dojo.js')
-
->addStyleSheetModule('dijit.themes.tundra')
-
->requireModule('dojo.rpc.JsonService');
-
$this->headScript()->captureStart(); ?>
-
function demoRpc()
-
{
-
var myObject = new dojo.rpc.JsonService('/json-rpc.php');
-
console.log(myObject.bar());
-
}
-
<? $this->headScript()->captureEnd() ?>
-
read more at Ajaxian
|
|
| crossdomain.xml misconfigurations galore |
[23 May 2008|01:21pm] |
12:23 22.05.2008
crossdomain.xml misconfigurations galore
Jeremiah Grossman took a fresh look at crossdomain.xml usage and decided to see which top domains had lenient policies in their files, which is now published and updated.
Why is this important?
This week I took a renewed interest in crossdomain.xml. For those unfamiliar this is Flash’s opt-in policy file that extends the same-origin policy to include more sites in the circle of trust. Normally client-side code (JavaScript, Flash, Java, etc.) is limited to reading data only from the website (hostname) in which it was loaded. Attempting to read data from other domains is met with security exceptions.
With crossdomain.xml a site owner may configure a policy to stating which off-domain sites are allowed to read its data (or parts thereof) and the client, Flash in this case, is responsible for enforcement. This feature paves the way for more rich client-side applications. Crossdomain.xml policies are also extremely flexible allowing websites to be defined by IP, domain, subdomain, or everyone (*) under the sun. And this is one area where we potentially run into trouble.
When a hostname is included in the circle of trust you allow them to read all data on the site that the user has access to, this includes any (authenticated) content and (session) cookies. So should a malicious attacker or website owner gain control of a website in the circle of trust (via a server hack or XSS), then they feasibly can compromise user data off that domain. This could easily leads to privacy violations, account takeovers, theft of sensitive data, and bypassing of CSRF protections (grabbing the key ahead of time).
With this understood I was curious just how many prominent websites are actively using crossdomain.xml and generally how they are configured. For sampling I combined the “www” hostnames of fortune 500 with the Global Alexa 500. Of the 961 unique websites in all (and keeping the results to myself for now)…
read more at Ajaxian
|
|
| Firebug 1.2 beta for Firefox 3 RC 1 |
[23 May 2008|01:21pm] |
13:13 22.05.2008
Firebug 1.2 beta for Firefox 3 RC 1
Firebug 1.2 beta is in the wild. The latest beta of the bug your FF3RC will love features:
Enablement UI
- Disable always: when the Firebug UI is not active on any page, the debugger is disabled (minimal overhead)
- Instant on: when the Firebug UI is active, HTML, CSS, DOM views activate (minimal overhead)
- Script panel user-activation: initially disabled or enabled always
- Net panel user-activiation: initially disabled or enabled always
- Bug Icon gray unless some page has Script or Net panel activation
- No Allowed-sites/Disable for Site: no longer needed. The UI for this feature is being refined; overhead tests have not been completed. We are interested in feedback on this UI change.
Javascript Debugging</p>
- Written/cleaned up eval support
- Performance on eval better, easier to support. This feature is complete; Bug reports on javascript debugger welcome.
Net Panel</p>
- Net timing more accurate
- Only real network requests displayed.
- Limit for number of requests (configurable in preferences).
- Additional columns for: request method, status response + text
- Cache tab has expiration time in Net panel
Console</p>
- Redesigned to use events/attribute passing.
tests/console/joes-original/test.html mostly passes
Command Line</p>
- Redesigned to avoid using evalInSandbox.
tests/console/commandLineObjects.html mostly passes
commandLineAPI functions, ok.
DOM Panel</p>
- Works for FF3pre after about 2008041406 (https://bugzilla.mozilla.org/show_bug.cgi?id=425139)
Bug away!
Simon Willison also recently pointed out the command line API that lets you "set a breakpoint at the start of a function with “debug(fn)” and log all calls to it with “monitor(fn)”."
read more at Ajaxian
|
|
| PersistJS: Cross Browser Client-Side Persistent Storage |
[23 May 2008|01:22pm] |
19:46 22.05.2008
PersistJS: Cross Browser Client-Side Persistent Storage
Paul Duncan announced today the release of PersistJS, a client-side JavaScript persistent storage library.
Currently the only reliable cross-platform and cross-browser mechanism for storing data on the client side are cookies. Unfortunately, using cookies to store persistent data has several problems:
* Size: Cookies are limited to about 4 kilobytes in size.
* Bandwidth: Cookies are sent along with every HTTP transaction.
* Complexity: Cookies are difficult to manipulate correctly.
Modern web browsers have addressed these issues by adding non-Cookie mechanisms for saving client-side persistent data. Each of these solutions are simpler to use than cookies, can store far more data, and are not transmitted along with HTTP requests. Unfortunately, each browser has addressed the problem in a different and incompatible way.
Trying to address the need for client-side storage sans browser-specific techniques or browser plugins, Paul has created an abstraction layer that allows developers to use most of the most common client-side storage mechanisms via a common interface. It currently supports persistent client-side storage through the following backends:
- flash: Flash 8 persistent storage.
- gears: Google Gears-based persistent storage.
- localstorage: HTML5 draft storage.
- whatwg_db: HTML5 draft database storage.
- globalstorage: HTML5 draft storage (old spec).
- ie: Internet Explorer userdata behaviors.
- cookie: Cookie-based persistent storage.
Other notables features include:
- Small (9.3k minified, 3k gzipped)
- Standalone: Does not need any additional browser plugins or
JavaScript libraries to work on the vast majority of current
browsers.
- Consistent: Provides a consistent, opaque API, regardless of
the browser.
- Extensible: Custom backends can be added easily.
- Backwards Compatible: Can fall back to flash or cookies if no
client-side storage solution for the given browser is available.
- Forwards Compatible: Supports the upcoming versions of Internet
Explorer, Firefox, and Safari (Opera too, if you have Flash).
- Unobtrusive: Capability testing rather than browser detection, so
newer standards-compliant browsers will automatically be supported.
read more at Ajaxian
|
|
| Soft-hyphens and inline-block; Subtleties in Firefox 3 RC 1 |
[23 May 2008|01:22pm] |
09:30 23.05.2008
Soft-hyphens and inline-block; Subtleties in Firefox 3 RC 1
Kevin Yank has zoomed into the features in the new Firefox 3 RC 1, and explained two subtle ones that can help us as Web developers:
Soft Hyphens
Tucked away in the list of CSS improvements in Firefox 3 is this innocuous-looking feature: “HTML soft hyphens () are now supported.”
Soft hyphens are one of those obscure gems that HTML has always supported on paper, but that no one has taken any notice of because browser support has been spotty. With the imminent release of Firefox 3, however, soft hyphens will be supported by all major browsers including Internet Explorer, Safari, and Opera.
So, what is a soft hyphen, anyway?
A soft hyphen is a character of text that is usually invisible. It signals a spot in the text (usually in the middle of a long word) where it would be acceptable to break the line with a hyphen.
Here you see it at work:
Inline Blocks
Another obscure-but-useful new feature making its way into Firefox 3 after all the other major browsers support it (mostly) is the inline block. When assigned to an element, a display type of inline-block causes the element to be positioned inline (like a span), but the element’s contents are laid out as if the element were a block.
This feature will come in handy in a number of situations in which the float property is currently being used for lack of a better option.
HTML:
-
-
-
-
<div class="caption"></a>A short caption </div>
-
<div class="thumb"></a><img src="thumb1.jpg"/></a></div>
-
-
<div class="caption"></a>A short caption </div>
-
<div class="thumb"></a><img src="thumb2.jpg"/></a></div>
-
-
…
-
</li></ul>
-
The code above gives you:
See it in action.
read more at Ajaxian
|
|
| JavaScript Super Mario Kart |
[23 May 2008|01:22pm] |
11:55 23.05.2008
JavaScript Super Mario Kart
Jacob Seidelin keeps on going, and has created a Super Mario Kart prototype:
It uses the canvas element to do most of the rendering and should work in both FF2, FF3, Opera(9.27 and beta) and Safari 3.1.1. There are a few glitches in Safari in the kart sprites, but other than that it should be playable. Also, if you’re using WebKit nightly builds, make sure you’re using the latest, as some of the recent ones had some canvas problems. I haven’t even considered getting IE support, sorry.
The (minified) code weighs in at about 11 Kb, but unlike the Mario game from last month, this one uses several external image files. This was more a test of how smooth I could get a game like this to feel, anyway, so filesize wasn’t an issue. I think it runs pretty ok, though.
There are a couple of rendering settings you can play with. “Quality” controls how many vertical lines are rendered, “Screen scale” controls the size of the screen (duh). Both trade visual appearance for performance.
Give it a ride.
read more at Ajaxian
|
|
| GUIMark: Another Web application benchmark |
[23 May 2008|01:22pm] |
12:43 23.05.2008
GUIMark: Another Web application benchmark
Sean Christmann has introduced GUIMark, a benchmark for HTML, Flex, Silverlight, Swing, and anything else you port it too.
Sean saw Bubblemark and thought that there was room for a different type of benchmark:
GUIMark takes a different approach by trying to benchmark the types of UI elements common in our Web 2.0 world. This includes things like vector redraws, alpha transparencies, text reflow, bitmap motion, and 9 scale slicing rules. From there I just fill up the render pipeline until it becomes so over-saturated that it becomes easy to visually distinguish which rendering engines are more efficient then others. As a result, the benchmark is more complicated on a visual level and requires a bit more time then Bubblemark to understand the implementation rules. Lastly with GUIMark I’ve tried to get into some of the lower level details behind how rendering engines work and how that’s affected the creation of this project.
You can run the HTML version to see it in action.
The results have been a little strange, with huge differences between Mac OS X and Windows. The Ajax application wins on the Mac!
Sean concluded:
I’ve been surprised with the results so far between WinXP and OS X. On the same machine its very clear which vendors take more advantage of the underlying hardware. The results for the different plugin technologies aren’t too surprising since it’s regularly admitted that most companies spend their optimization time on Windows due to its larger install base. This argument doesn’t hold any water though when comparing html rendering on Safari/Mac against IE /Windows where there’s roughly a 1.6 : 1 advantage to the IE team. I can’t help but wonder if the core apis on the Mac platform are creating any unnecessary roadblocks. I’m also extremely surprised at the rendering speed that Flash is able to pull off on Windows. I developed this benchmark under OS X and after compiling the results I’m considered making the testcase more intensive since Flash is running so fast, but for now maybe the really poor Mac performance will give Adobe something to work on.
It is always nice to see benchmarks, as long as we don’t get too carried away. For one, when you take a look at the application, you will quickly see that it isn’t exactly a “real world application” unless you are building a crazy scaling game ;)
read more at Ajaxian
|
|
|
|
![[info]](http://p-stat.livejournal.com/img/userinfo.gif){kind=small}
vgs_rss's journal
