You searched for: 'native'

Wednesday, October 15th, 2008

Firefox 3.1 beta: Geolocation, @font-face, Video and Audio, XHR++, and TraceMonkey

Category: Browsers, Firefox

Isn’t it great that a browser point release these days adds so many features? We are starting to see this from Firefox, Opera, WebKit and others, and it is exciting!

The Firefox 3.1 beta 1 release has a slew of features that developers have been craving:

Geolocation

The labs team got Geode out there, and quickly we have seen the addition of the W3C Geolocation API added to the Firefox core. I can test Where Are You with a native implementation.

@font-face

WebKit lead with their @font-face implementation, and getting browser #2 to support it is huge. Now you can load up a font using same-origin rules via simple CSS:

  1. @font-face {
  2.   font-family: "Bitstream Vera Serif Bold";
  3.   src: url("http://developer.mozilla.org/@api/deki/files/2934/=VeraSeBd.ttf");
  4. }

Video and Audio

We now have lots of examples testing out the video and audio tags with support for both OGG Theora and OGG Vorbis.

This is something that the Web really needs to work out. The codec game is far from Open, and with native support we get to do cool things such as integrating media with canvas, svg, and plain old HTML. Take a video, add transparency, and skew it a little…. and add an overlay message.

XHR Updates

XHR Progress Notification

We’ve added a better way to get progress notifications for XML HTTP Requests. We’ve implemented the W3C Draft Spec on progress events. In Firefox 3 the events available on the XHR object were progress, uploadprogress, load, abort and error. For 3.1 we now support the loadstart, progress, load, abort and error events. (uploadprogress is also supported, but is deprecated.)

There’s a great example of the new progress events by Olli Pettay. It’s very simple and does everything in a single script.

XHR Cross-site Access Control

We’ve implemented the draft specification for access-control for cross-site requests.  Web developers have long wanted to be able to get data from one site on another but same-origin restrictions on many types of requests prevent many developers from mashing up content.  This new access control mechanism offers the ability for servers, content and web clients to cooperate to make a lot of new things possible on an opt-in basis.  The spec is complex, and support is new, so if you’re interested reading the spec is probably the best thing to do.  It contains examples and uses cases.

Fast JavaScript VM

An early version of TraceMonkey is here:

Beta 1 does include TraceMonkey, our super-fast JavaScript engine, but it’s not turned on by default.  If you do want to turn it on, go to about:config, set javascript.options.jit.content to True, restart your browser and try it out.

This is an early beta, of course, so there will be issues. Please file bugs if you find sites that don’t work or cause crashes or hangs. The more testing we get, the better it will be when we turn it on.

Phew, good times for browsers == good times for Web developers.

UPDATE

More browser news, Flock 2.0 is out there, providing a very social browsing experience.

Posted by Dion Almaer at 12:01 am
Comment here

++++-
4.6 rating from 30 votes

Friday, October 10th, 2008

IE8 and Standards

Category: Browsers, IE

Anne van Kesteren of Opera Software has updated his post on IE 8 to cover beta 2:

  • XDomainRequest: Microsoft unfortunately continues with XDomainRequest rather than making changes to XMLHttpRequest as other browsers are doing and as is being standardized by the W3C Web Apps Working Group. (Disclaimer: I am the editor of XMLHttpRequest Level 2.)

    Some agreement was made to at least support the same protocol on the server, namely using the Access-Control-Allow-Origin header as per Access Control for Cross-Site Requests. (Disclaimer: I am the editor of that draft too.) However, IE8 only supports * as value for that header, not an origin, e.g. http://annevankesteren.nl (test). Sunava pointed out that was because the W3C WebApps WG was still debating the matter. Here is hoping they will fix the bug as there is agreement on that syntax.

  • HTML5 DOM Storage: localStorage and sessionStorage are now supported. Enumerating through them does not give the results I was expecting (I got “length” and “remainingSpace” back as well, besides the keys) and they still have a remainingSpace member that is not part of HTML5. Given that anything that gives some indication of space is highly vendor specific as it depends on encoding, compression, and type of device, they should really rename it to msRemainingSpace or some such or simply drop it.

    IE8 also supports an event named storagecommit that is not part of HTML5 which tells you when the data has been written to an XML backend format IE8 uses. The event object for used for the storage does not expose key, oldValue, and newValue. The url member is named uri and the source member is null rather than a reference to the Window object. Ouch!

  • ARIA: Aaron Leventhal recently blogged about how ARIA in IE8 is a pain. (Aaron works for IBM making Firefox and Web applications accessible and is a member of the W3C PF WG which standardizes ARIA.) In short, when IE8 renders in super standards mode ARIA will work as everywhere else, otherwise you have to use Microsoft proprietary syntax. So not only do you need to upgrade your application code to be keyboard accessible and ARIA-enabled, you will also need to upgrade it from quirks to standards mode. Alternatively, you could take the easy way out and lock out other browsers. Not nice.

He did admit that he has “only played around with Internet Explorer 8 for an hour so” :)

Posted by Dion Almaer at 5:26 am
18 Comments

++---
2.4 rating from 35 votes

Wednesday, October 8th, 2008

Aptana Jaxer 1.0 RC

Category: Aptana

The Jaxer team has released a release candidate for Jaxer 1.0.

Here a synopsis of all the new features and improvements that have gone into this latest release candidate:

  • Jaxer.Sandbox: HTTP-level control; support readyState, toHTML, waitForCompletion
  • Built-in, extensible dispatching for RESTful and RPC service requests
  • Fast, native JSON support
  • Improved APIs for HTTP Request and Response
  • More flexible handling of application configuration
  • Many bug fixes, smaller improvements, and cleanups

They are moving pretty fast, so are looking for feedback before they wrap up a final 1.0 release.

Posted by Dion Almaer at 5:12 am
3 Comments

++++-
4 rating from 33 votes

Tuesday, October 7th, 2008

IE 8 beta 2 Ajax features

Category: Browsers, IE

Sunava Dutta has detailed the enhancements made to IE 8 beta 2 for Ajax developers including XDR, XDM/postMessage, DOM Storage, offline detection, and more. A lot of great stuff!

XDomainRequest (XDR)

This is an object built from the ground up to make client-side cross-domain calls secure and easy. To reduce the chances of inadvertent cross domain access, this object requires an explicit acknowledgement for allowing cross domain calls from the client script and the server. Additionally, it reduces the need for sites having to resort to the dangerous practice of merge scripting from third parties directly into the mashup page. This practice is dangerous because it provides third parties full access to the DOM. All this comes with the added benefit of improved client-side performance and lower server maintenance costs thanks to the absence of a need for server farms for proxying.

During the Beta 1 timeframe there were many security based concerns raised for cross domain access of third party data using cross site XMLHttpRequest and the Access Control framework. Since Beta 1, we had the chance to work with other browsers and attendees at a W3C face-to-face meeting to improve the server-side experience and security of the W3C’s Access Control framework. As a result, we’ve updated XDR to be explicitly compliant with syntax and directives in the sections of Access Control for requesting simple public third-party data anonymously on the client! (Section 5.1.3 in the Access Control Process Model)

The updates to XDR from Beta 1 allow IE8 to request data from the domain’s server by sending an Origin header with the serialized value of the origin of the requestor. IE8 Beta 2 will only return the response if the server responds with Access-Control-Allow-Origin: *, instead of allowing the XDomainRequestAllowed: 1 header as we did in Beta 1. Other changes include support for relative paths in the open method, and restricting access to only HTTP and HTTPS destinations.

Cross-document Messaging (XDM)

Cross-document messaging is another powerful cross-domain feature that I’ve blogged about in the past. Rather than make a backend request to a remote Web service, this allows sites hosting third-party IFrame-based “gadgets” or components to communicate directly with the parent, without unsafely violating the same site origin policy. This has advantages including improved performance and reliability, as developers don’t have to resort to workarounds that behave differently between browsers and have unwanted side-effects. This technique also removes the need for embedding third-party script in your page, lessening the chance of potential information disclosure vulnerabilities like the disclosure of your sensitive data (such as information in your social network profile) to third parties without your consent.

Beta 2 updates here include moving the onmessage handler from the document object to the window object to better align with the updated HTML 5.0 draft.

window.attachEvent(“onmessage”, HandleMessage);

We also replaced e.URI with e.origin, which is serialized form of “scheme” + “host” + “non-default port”. This is far safer as the URI can carry potentially sensitive information from the origin site that is not needed by the recipient for the decision to grant or not grant access.

if (e.origin == ‘http://www.contoso.com’) 
       
               // process message text     
        }

Finally, the HTML 5.0 draft also mandates that the targetOrigin parameter for the postMessage method now be made a required parameter, as opposed to an optional one. This will make it difficult for developers to make errors by requiring an explicit acknowledgement of the target destination of the message by specifying the origin <URL> or wildcard <*>.

 frameOther.postMessage(“This is a message”, “http://example.com”);

DOM Storage

Today, web pages use the document.cookie property to store data on the local machine. Cookies are limited in capability by the fact that sites can only store 50 key/value pairs per domain. Furthermore, the cookie programming model is cumbersome and requires parsing the entire cookie string for data. While cookies are useful for marking transitions and changes on the client to the server as they are sent with the request headers in chunks of up to 4KB, IE8 brings better alternatives for scenarios involving persisting data on the client and distinctly maintaining sessions in different tabs. The W3C’s HTML 5 DOM Storage objects provide a much simpler global and session storage model for key/value pair string data. Sites can store data for the life of a tab or until the site or user clears the data.

Updates for Beta 2 include changing the name of the persistent globalStorage attribute to localStorage and the removal of the need to specify the domain when writing to the localStorage

// Store a key-value pair.
localStorage.setItem(“FirstName”,”Sunava”);

Finally, we also included improved support of the updated onstorage HTML 5.0 event returned when the storage is changed. We now return the URI when the local storage is changed, so that handlers for pages can know who carried out the latest transaction in the storage space in addition to providing the source to the window of the origin. Furthering the good news, the HTML 5.0 Working Group has incorporated the clear method, which we shipped in Beta 1, into the draft. This essentially allows for script to clear all items accessible in its storage space without having to iterate though the keys.

Connectivity Event

The navigator.onLine property and online/offline events now work on Windows XP as well as Windows Vista. The work to enable this was not trivial, as connection awareness in Windows XP is not quite as advanced as Windows Vista. That said, this will be extremely beneficial for developers, who we believe shouldn’t have to worry about OS differences. The value of connectivity events is particularly appealing when used in conjunction with the localstorage, where data can be cached in case of network loss!

XMLHttpRequest

Introducing the XDomainRequest object in IE8 hasn’t diverted our attentions from constantly tweaking and improving XMLHttpRequest, which will continue to be our flagship object for same-domain communications. Post-Beta 1 energies here have focused on a few bug fixes around reliability and working with the Web Apps Working Group to clarify and improve the draft specification, our compliance with it, and W3C public test cases. A timeout method introduced here in Beta 1 for the convenience of developers is currently being evaluated for adoption in the XMLHttpRequest spec.

// Sets timeout after open to two seconds.
xhr.timeout             = 2000;

ToStaticHTML, to JSON, and fromJSON

What do you do with the strings returned from third parties using XDomainRequest or Cross-document Messaging? In today’s world of increasing script injection and Cross-site Scripting (XSS) attacks, having the option of passing these through a safe parser comes as a welcome relief. As detailed in Eric Lawrence’s post on Comprehensive Protection for IE8 Security, toStaticHTML provides a powerful way of sanitizing your strings by purging potentially executable content.

//Calling:
window.toStaticHTML(“This is some <b>HTML</b> with embedded script following… <script>alert(‘bang!’);</script>!”);

//will return:
This is some <b>HTML</b> with embedded script following… !

In addition, IE8 Beta 2’s toJSON and fromJSON methods provide improved performance as opposed to non-native Javascript deserializers and serializers. Our implementation is based on the ECMAScript 3.1 proposal for native JSON-handling which uses Douglas Crockford’s json2.js API. In addition to the performance benefits of going native, the JSON parser provides a safe alternative to the eval() method, which has been a common and dangerous way to revive JSON objects, and could allow arbitrary script functions to execute.

Posted by Dion Almaer at 7:53 am
6 Comments

+++--
3.2 rating from 54 votes

Regex performance in modern JSVMs

Category: JavaScript, Performance

Based on its performance on the regexes it does handle, WREC (WebKit Regular Expression Compiler) is indeed an awesome design. regexp-dna.js, however, is flawed and exaggerates SFX performance.

We could use nanojit to make a regex compiler for SpiderMonkey that would perform as well as WREC. But I don’t know if it’s worthwhile yet. Regex performance is much less important for today’s web than it is for SunSpider–I hope to link to a report on that in a future post.

That was the conclusion that David Mandelin of the Tamarin project as he looked into how “SquirrelFish Extreme (SFX) is kicking our butts so badly on regexp-dna.js.”

I love David’s posts, as they go into the real meat of the tech:

Technical details: the design of WREC. There are two main ways to implement regular expressions: using a backtracking matching engine, or by transforming the regex to a finite automaton (NFA, aka “state machine”), which does not backtrack. Most Perl-type regex engines, including both SpiderMonkey’s and WREC, follow the backtracking design. I don’t know the exact history of that choice, but at present it is much easier to implement features like group capture and backreferences in the backtracking design. Also, although some regexes scale only if implemented as NFAs, my tests suggest that many simple regexes, including those in SunSpider, are faster with backtracking.

As of this writing, WREC’s implementation strategy is dirt simple (which is a good thing). There are no transformations or fancy optimizations on the regex. WREC simply generates native code that directly implements the backtracking search. Thus, within a single match operation, there are no function calls, no traversals of regular expression ASTs, and few option tests, so almost all of the overhead is eliminated.

WREC’s code is very easy to read, so if you want to know exactly how it works, just read it in WREC.cpp. It’s also great example code for anyone implementing a compiler for a simple language like regular expressions. The basic plan is to parse the regular expression with functions named things like parseDisjunction (the | operator). Those functions directly call functions like generateDisjunction that generate the native code using the same assembler that the call-threading interpreter uses. There’s also the oddly named “gererateParenthesesResetTrampoline”. Inexplicably preserved typo, or watermark to detect copying of WREC code?

Posted by Dion Almaer at 5:57 am
Comment here

+++--
3.9 rating from 12 votes

Thursday, October 2nd, 2008

Symfony Firebug Extension: Firesymfony

Category: Debugging, PHP

Alvaro Videla just wrote in to tell us about Firesymfony, a Firebug extension that provides an alternative to Symfony’s built-in web debug toolbar.

sometimes the toolbar position makes impossible to use some features of the layout of our website, like a link menu on the top right corner. It also happens that while we display a small popup with the resize functionality disabled it’s turns hard to access all the data displayed by the toolbar.

The solution I’ve came up with is to move all the data from the toolbar to Firebug, actually, to port the symfony web debug toolbar as a Firebug extension. This will remove the toolbar from the page html and will show it in a convenient place that almost every web developer is used to.

Taking advantage from the cool new features of symfony 1.2 I started a project to develop a symfony plugin to send the data to the Firebug extension. The later has been smartly called FireSymfony.

Alvaro has another blog post that talks more about the first release.

Posted by Ben Galbraith at 10:58 am
5 Comments

++++-
4.3 rating from 21 votes

Thursday, September 25th, 2008

input type=camera to give us a simple way to integrate to Webcams

Category: Browsers, Component, Firefox, HTML, Mozilla

There are a substantial number of iPhone apps that tie into the builtin native components such as the camera.

Brad Lassey has been hacking on Fennec (the Mozilla mobile browser) as well as Firefox itself to integrate with camera phones and Webcams alike:

I wrapped a video tag, image and a few buttons in xbl and bound it to <input type=”camera” />. When a user hits a website using this tag, he or she currently will see a live video preview and a “take photo” button. When the user clicks the button, the photo is grabbed from the camera and shown to the user in the image element. The image element and video element are in a deck element so only one is shown at a time. After the photo is taken, there is a button that reads “Take another photo,” in case the user doesn’t like the one they just took. Once the user is satisfied, this element works like any other form element and the file can be uploaded to a web service.

After talking to a few people this should actually be bound to <input type=”file” accept=”image/png”/>. Also, it needs some UI design both for what it looks like in content and for a configuration dialog. Finally, we’ll need to think about security and make sure no one can snap a photo of you when you’re not looking your best.

I kinda like having an input type="camera" myself, to be more explicit. It would be cool if you can get access to the image as data (e.g. the value is data:......). I love it.

Posted by Dion Almaer at 6:13 am
9 Comments

++---
2.3 rating from 80 votes

Pi.js: Simple JavaScript Library

Category: JavaScript, Library

Azer Koculu has released his Pi.js framework, which is a lightweight system that includes a minimal set of modules, and the ability to use and provide plugins.

By default you get:

  • pi.env: browser detection
  • pi.get: DOM access
  • pi.util: Extensions to JavaScript (e.g. support currying, includes, viewport config, and more)
  • pi.base: OO subsystem
  • pi.element: Create and modify the DOM
  • p.xhr: Remoting
  • Extensions to native objects such as Array, Function, Number, and String

There are then plugins to provide functionality such as Comet support, and a storage wrapper.

Pi has been used in the excellent Firebug Lite update that Azer worked on.

Posted by Dion Almaer at 6:04 am
6 Comments

+++--
3 rating from 34 votes

Monday, September 22nd, 2008

PhoneGap: “AIR for the iPhone”

Category: iPhone

Dave Johnson calls PhoneGap “AIR for the iPhone” because this nice little hack, first created at an iPhone BarCamp, wraps the Web view with a container. This container gives the view access to APIs available on the device, that may not be available yet via WebKit alone. AIR provides a similar container for Flash and Ajax content on the desktop.

PhoneGap is a free open source development tool and framework that allows web developers to take advantage of the powerful features in the iPhone SDK from HTML and JavaScript. We’re trying to make iPhone app development easy and open. For many applications a web application is the way to but in Safari you don’t get access to the native iPhone APIs, and the that’s the problem we’re trying to solve.

It is written in Objective-C and allows developers to embed their web app (HTML, JavaScript, CSS) in Webkit within a native iPhone app. We’re big advocates of the Open Web and want JavaScript developers to be able to get access iPhone features such as a spring board icon, background processing, push, geo location, camera, local sqlLite and accelerometers without the burden of learning Objective-C and Cocoa.

PhoneGap also has a web app that allows web developers to quickly package their web app into a native iPhone app by providing a URL, a name and icon graphic the web service with automagically create a native iPhone application. We haven’t open sourced that code but we’re going to soon.

PhoneGap was conceived at iPhoneDevCamp II by Nitobi developer Brock Whitten, Rob Ellis, freelance designer Colin Toomey and Eric Oesterle.

There are a few APIs available now, and others pending:

javascript

  1. // Location API
  2. // Feels a little ugly compared to passing in a closure. Using a hard coded name? :)
  3.   getLocation();
  4.  
  5.   //GAP will invoke this function once it has the location
  6.   function gotLocation(lat,lon){
  7.     $('lat').innerHTML = "latitude: " + lat;
  8.     $('lon').innerHTML = "longitude: " + lon;
  9.   }
  10.  
  11. // Accelerometer API
  12.  
  13.   function updateAccel(){
  14.     $('accel').innerHTML = "accel: " + accelX + " " + accelY + " " + accelZ;    
  15.     setTimeout(updateAccel,100);
  16.   }
  17.  
  18. // Camera (pending)
  19.   function takePhoto(){
  20.     var photo = gap:takePhoto();
  21.     return photo;
  22.   }
  23.  
  24. // Vibration (pending)
  25.  
  26.   function vibrate(){
  27.     gap:vibrate();
  28.     return false;
  29.   }

You can take a peak at the open source code on github. For example, here is the code that wraps the iPhone location service:

  1. @implementation Location
  2.  
  3. - (id)init{
  4.   NSLog(@"Gap::Location");
  5.   locationManager = [[CLLocationManager alloc] init];
  6.   [locationManager setDelegate:self];
  7.   return self;
  8. }
  9.  
  10. + (void)startTracking{
  11.   NSLog(@"starting location tracker");
  12.   [locationManager startUpdatingLocation];
  13. }
  14.  
  15. + (void)stopTracking{
  16.   NSLog(@"stopping location tracker");
  17.   [locationManager stopUpdatingLocation];
  18. }
  19.  
  20. - (void)location{
  21.   NSLog(@"location is");
  22. }
  23.  
  24. - (void)log{
  25.   NSLog(@"the location is...");
  26. }
  27.  
  28. - (void)dealloc {
  29.     [locationManager release];
  30.   [super dealloc];
  31. }
  32.  
  33. @end

Posted by Dion Almaer at 7:33 am
5 Comments

+++--
3.6 rating from 24 votes

Saturday, September 20th, 2008

SquirrelFish Extreme: JIT comes to SquirrelFish with extreme results

Category: JavaScript, Performance, WebKit

While Ben and I were talking about JavaScript performance (and other things) at Web 2.0 Expo NYC, Maciej Stachowiak announced SquirrelFish Extreme, the very new and improved version that appears to do very well at SunSpider:

SquirrelFish Extreme:	943.3 ms
V8: 1280.6 ms
TraceMonkey: 1464.6 ms

What makes it so fast?

SquirrelFish Extreme uses four different technologies to deliver much better performance than the original SquirrelFish: bytecode optimizations, polymorphic inline caching, a lightweight “context threaded” JIT compiler, and a new regular expression engine that uses our JIT infrastructure.

1. Bytecode Optimizations

When we first announced SquirrelFish, we mentioned that we thought that the basic design had lots of room for improvement from optimizations at the bytecode level. Thanks to hard work by Oliver Hunt, Geoff Garen, Cameron Zwarich, myself and others, we implemented lots of effective optimizations at the bytecode level.

One of the things we did was to optimize within opcodes. Many JavaScript operations are highly polymorphic – they have different behavior in lots of different cases. Just by checking for the most common and fastest cases first, you can speed up JavaScript programs quite a bit.

In addition, we’ve improved the bytecode instruction set, and built optimizations that take advantage of these improvements. We’ve added combo instructions, peephole optimizations, faster handling of constants and some specialized opcodes for common cases of general operations.

2. Polymorphic Inline Cache

One of our most exciting new optimizations in SquirrelFish Extreme is a polymorphic inline cache. This is an old technique originally developed for the Self language, which other JavaScript engines have used to good effect.

Here is the basic idea: JavaScript is an incredibly dynamic language by design. But in most programs, many objects are actually used in a way that resembles more structured object-oriented classes. For example, many JavaScript libraries are designed to use objects with “x” and “y” properties, and only those properties, to represent points. We can use this knowledge to optimize the case where many objects have the same underlying structure – as people in the dynamic language community say, “you can cheat as long as you don’t get caught”.

So how exactly do we cheat? We detect when objects actually have the same underlying structure — the same properties in the same order — and associate them with a structure identifier, or StructureID. Whenever a property access is performed, we do the usual hash lookup (using our highly optimized hashtables) the first time, and record the StructureID and the offset where the property was found. Subsequent times, we check for a match on the StructureID – usually the same piece of code will be working on objects of the same structure. If we get a hit, we can use the cached offset to perform the lookup in only a few machine instructions, which is much faster than hashing.

Here is the classic Self paper that describes the original technique. You can look at Geoff’s implementation of the StructureID class in Subversion to see more details of how we did it.

We’ve only taken the first steps on polymorphic inline caching. We have lots of ideas on how to improve the technique to get even more speed. But already, you’ll see a huge difference on performance tests where the bottleneck is object property access.

3. Context Threaded JIT

Another major change we’ve made with SFX is to introduce native code generation. Our starting point is a technique called a “context threaded interpreter”, which is a bit of a misnomer, because this is actually a simple but effective form of JIT compiler. In the original SquirrelFish announcement, we described our use of direct threading, which is about the fastest form of bytecode intepretation short of generating native code. Context threading takes the next step and introduces some native code generation.

The basic idea of context threading is to convert bytecode to native code, one opcode at a time. Complex opcodes are converted to function calls into the language runtime. Simple opcodes, or in some cases the common fast paths of otherwise complex opcodes, are inlined directly into the native code stream. This has two major advantages. First, the control flow between opcodes is directly exposed to the CPU as straight line code, so much dispatch overhead is removed. Second, many branches that were formally between opcodes are now inline, and made highly predictable to the CPU’s branch predictor.

Here is a paper describing the basic idea of context threading. Our initial prototype of context threading was created by Gavin Barraclough. Several of us helped him polish it and tune the performance over the past few weeks.

One of the great things about our lightweight JIT is that there’s only about 4,000 lines of code involved in native code generation. All the other code remains cross platform. It’s also surprisingly hackable. If you thought compiling to native code is rocket science, think again. Besides Gavin, most of us have little prior experience with native codegen, but we were able to jump right in.

Currently the code is limited to x86 32-bit, but we plan to refactor and add support for more CPU architectures. CPUs that are not yet supported by the JIT can still use the interpreter. We also think we can get a lot more speedups out of the JIT through techniques such as type specialization, better register allocation and liveness analysis. The SquirrelFish bytecode is a good representation for making many of these kinds of transforms.

4. Regular Expression JIT

As we built the basic JIT infrastructure for the main JavaScript language, we found that we could easily apply it to regular expressions as well, and get up to a 5x speedup on regular expression matching. So we went ahead and did that. Not all code spends a bunch of time in regexps, but with the speed of our new regular expression engine, WREC (the WebKit Regular Expression Compiler), you can write the kind of text processing code you’d want to do in Perl or Python or Ruby, and do it in JavaScript instead. In fact we believe that in many cases our regular expression engine will beat the highly tuned regexp processing in those other languages.

Since the SunSpider JavaScript benchmark has a fair amount of regexp content, some may feel that developing a regexp JIT is an “unfair” advantage. A year ago, regexp processing was a fairly small part of the test, but JS engines have improved in other areas a lot more than on regexps. For example, most of the individual tests on SunSpider have gotten 5-10x faster in JavaScriptCore — in some cases over 70x faster than the Safari 3.0 version of WebKit. But until recently, regexp performance hadn’t improved much at all.

We thought that making regular expressions fast was a better thing to do than changing the benchmark. A lot of real tasks on the web involve a lot of regexp processing. After all, fundamental tasks on the web, like JSON validation and parsing, depend on regular expressions. And emerging technologies — like John Resig’s processing.js library — extend that dependency ever further.

Major kudos to the entire SFX team for pulling this off. Now, to grab a new nightly…

Posted by Dion Almaer at 12:09 am
13 Comments

++++-
4.4 rating from 30 votes

Thursday, September 18th, 2008

SVG working on the iPhone

Category: iPhone, Mobile, SVG

Dylan Schiemann wrote about how disappointing it was that the iPhone didn’t support SVG:

Safari on the iPhone does not currently have support for SVG. Safari 3 beta on Mac and Windows is currently the best browser on the planet for SVG performance, so this is a somewhat disappointing omission. We are hopeful that by the end of the year, the iPhone will receive the Safari 3 upgrade, and along with that native support for SVG. For now, we’ll have to wait on dynamic charting and drawing tools due to no SVG and the lack of mousemove event handlers.

It appears that if you point your iPhone 2.1 browser to SVG content and tests it now works!

Posted by Dion Almaer at 6:41 am
9 Comments

+++--
3.2 rating from 11 votes

Wednesday, September 17th, 2008

V8 Internals by Kevin Millikin

Category: JavaScript

My favourite presentation at Google Developer Day in London yesterday was a dive into the internals of how V8 works by Kevin Millikin, an V8 engineer who has been there and done that by creating Scheme compilers :)

He discussed the key implementation details of V8, including:

  • Hidden classes
  • Hidden class transitions
  • Inline caching
  • Native code compilation
  • Memory management / GC

He shows how the hidden class system is able to watch the “shape” of JavaScript objects with a simple Point example that showed us following the references. In their testing, it turned out that roughly 90% of the JavaScript code that they ran fell into a pattern where they did have shapes that made sense for optimization. Although JavaScript is very dynamic, at runtime it doesn’t act that differently to statically typed languages, which allowed the V8 team to conclude that they could then apply the similar tricks from static VMs such as the JVM (Lars and his team worked on HotSpot) to JavaScript.

When V8 sees code, it makes sure that it marks it, and if seen again if then applies a compilation to native code (there is no IL, no interpreter, straight to machine code). This means that the third time the code is run it is fast. Of course, this is to make sure that it is worth taking the time to compile the code. If it is for init, one-time like work, it doesn’t make sense.

The GC system is a fairly simple generational collector with young and old generations, and some special buckets within the old. The GC is very fast indeed, even though with WebKit it also manages internal objects and resources to keep it clean.

Kevin also shared other interesting points on what JavaScript can run fast, and features such as eval() and with() that result in much slower execution.

The final piece that I found interesting was the fact that the team decided to implement a bunch of the “standard library” side of the JavaScript spec (the objects available) in JavaScript itself.

You can take a peak at the source to see it at work:

javascript

  1. InstallProperties($Array.prototype, DONT_ENUM, {
  2.     constructor: $Array,
  3.     toString: ArrayToString,
  4.     toLocaleString: ArrayToLocaleString,
  5.     join: ArrayJoin,
  6.     pop: ArrayPop,
  7.     push: ArrayPush,
  8.     concat: ArrayConcat,
  9.     reverse: ArrayReverse,
  10.     shift: ArrayShift,
  11.     unshift: ArrayUnshift,
  12.     slice: ArraySlice,
  13.     splice: ArraySplice,
  14.     sort: ArraySort,
  15.     filter: ArrayFilter,
  16.     forEach: ArrayForEach,
  17.     some: ArraySome,
  18.     every: ArrayEvery,
  19.     map: ArrayMap,
  20.     indexOf: ArrayIndexOf,
  21.     lastIndexOf: ArrayLastIndexOf
  22.   });

The reasoning here is to get a turtles-all-the-way-down-like symbiotic loop. As they optimized for the standard library, all execution got faster. As they make the VM faster, it in turn makes the standard library faster.

The really good news, is the fact that there is a lot of headroom to make things a lot faster (ditto for TraceMonkey, SquirrelFish Extreme) so we have only just begun with the next gen JSVMs :)

Posted by Dion Almaer at 9:11 am
3 Comments

+++--
3.7 rating from 23 votes

Aptana Jaxer Benchmarks

Category: Aptana

Jaxer has been out in beta for a while and is nearing its 1.0 release. Many comments on Ajaxian about Jaxer have been about performance benchmarks. Uri Sarid, CTO of Aptana, has compiled some initial benchmarks including comparisons to PHP and Ruby on Rails. (Jaxer comes out in between the two):

We wanted to answer a simple question: how does Jaxer, with its server-side DOM and JavaScript, perform relative to these other popular alternatives?

This was not designed to be an all-encompassing shoot-out, or a detailed study of everything you might want to do in a web app. Instead, we took a few common tasks — making database requests, using JSON, etc. — and implemented them as you might expect in the three platforms. We made enough DB requests and JSON calls and so on to give us a reasonable number of milliseconds to measure. But we also wanted to make the repetitions representative of what you might find on somewhat intensive real-world page, so we’re not making a million DB requests, just a hundred, for instance. And we included one benchmark of serving an almost-static page: the “almost” was to make sure we were measuring the time the platform took to really read through the page, in case it had dynamic content in it. (Otherwise, if the page were truly static, you could always arrange for the web server to serve it without involving the platform.)

The tests include page scraping tests (e.g. mashup work), database performance, file I/O, JSON, and programatical loops.

Posted by Dion Almaer at 8:35 am
3 Comments

++++-
4 rating from 14 votes

Tuesday, September 16th, 2008

Comet and Highly Interactive Websites – Joe Walker, @Media Ajax

Category: Comet, DWR

Joe Walker of DWR fame on Comet at @media Ajax.

Motivation for Comet

Interested in what our friends are up to, even if no-one else cares (as twitter illustrates). And also interested in what systems/things are doing, not just people. Chat (meebo), collaborative editing (google docs), streaming financial data (lightstreamer), async updates (yes.com), online gaming, async server processing (polar rose, i.e. shift processing complexity to the server – note this could be seen as an alternative to Gears-style local processing in some situations).

The web was designed to be connectionless – Comet blatently aims to make it connected.

Performance

Actually does scale. Joe shows the following graph:

Technical

Seven ways (!) to implement Comet.

Long polling – “slow” XHR request. Server doesn’t answer immediately. Special part of HTTP to do this – chunked mode. However, IE “lies to you” – keeps saying it’s got something, but you can’t actually inspect it.

Forever frame – Send text/plain and 4k whitespace to flush IE’s buffer. Flush with script tag for each data block. Must keep restarting to avoid memory leak.

Script tags – Dynamic script blocks, can point to any domain.

WebSockets – HTML 5 standard. Cleaner solution.

ActiveXObject(“htmlfile”) – htmlfile is an activeX control similar to XHR. Normally causes “clicking” noise in browser, but there’s a hack to turn it off in most cases. Obviously, this only works in IE. Most bizzare thing is you get 49 Javascript before garbage collection, leading to hair-pulling moments when you try to work out why your 50th command isn’t executing!

Mime messaging – “What push was built on 11 years ago” – x-multipart-replace. Works really well, though with memory leakage issues, but not in IE and historically not in the other browsers either.

Flash remoting

Forever GIF (bonus technique) – keep sending out new slices of an animated GIF!

Technical Issues

Co-ordination when browser has multiple tabs open to the same server – using window.name or cookies, but better solution is multi-home DNS – each call points to the server using a different name (1.example.com, 2.example.com etc all pointing to the same IP address).

Issues detecting when browser or connection has broken.

Proxies which don’t let the stream go through in real-time – hold on to the chunks for a while before releasing them all at once. Can detect if this is happening from the browser using a timestamp technique.

… so just like with Ajax, we have to come up with hacks, likewise with Comet. Facebook and GMail show it’s possible to work around these problems and get Comet working at scale.

API Styles

e.g. with WebSocket you’re simply posting and receiving data. Event handlers for onOpen, onRead etc. Joe says this will be too low-level in many cases, hence the following styles.

PubSub – e.g. cometd. Low coupling (server-browser separation – Joe describes demo where servers hot-swapped without affecting client), inter-language interop. Good analogy to SOAP, which has gradually shifted from RPC to document exchange.

API – this looks to me like Ruby’s remote JS – server controls what’s happening on the browser. e.g. Effect.shake(“price”) on the server will make the price div shake on the client.

Data Syc API – Keep changing/updating data store. Simplest to understand.

Posted by Michael Mahemoff at 4:27 am
2 Comments

++++-
4.6 rating from 14 votes

Friday, September 12th, 2008

blink at the marquee one more time

Category: JavaScript, jQuery

Remy Sharp gives us a blast form the past for the some Friday fun.

First, he shows his Marquee plugin that gives you the marquee effect. Why would you do this when the marquee tag itself is widely adopted?

Funnily enough, the marquee tag is pretty well supported amongst the browser, but the actual effect is poorly executed natively (which is kind of odd if it’s built directly in to the browser).

You can see how the untouched marquees are jumpy to animate, even in the later browsers such as Firefox 3 and Safari – let alone IE6.

It is simple to use, and gives you hooks to do more:

javascript

  1. // Hello World
  2. $('marquee').marquee();
  3.  
  4. // Adding fun
  5. $('div.demo marquee').marquee('pointer').mouseover(function () {
  6.   $(this).trigger('stop');
  7. }).mouseout(function () {
  8.   $(this).trigger('start');
  9. }).mousemove(function (event) {
  10.   if ($(this).data('drag') == true) {
  11.     this.scrollLeft = $(this).data('scrollX') + ($(this).data('x') - event.clientX);
  12.   }
  13. }).mousedown(function (event) {
  14.   $(this).data('drag', true).data('x', event.clientX).data('scrollX', this.scrollLeft);
  15. }).mouseup(function () {
  16.   $(this).data('drag', false);
  17. });

Or, you could get into a lot of trouble and reimplement blink:

javascript

  1. $(function () {
  2.  setInterval(function () {
  3.    $('blink').each(function () {
  4.      this.style.visibility = this.style.visibility == 'hidden' ? 'visible' : 'hidden';
  5.    });
  6.  }, 1000);
  7. });

Posted by Dion Almaer at 5:32 am
4 Comments

++---
2.6 rating from 49 votes

Thursday, September 11th, 2008

Ian Hickson discusses HTML 5 features, pain points, adoption rate, and more

Category: Standards

Justin James took some time to interview Ian Hickson, HTML Uber Editor, on features, pain points, adoption rate, and more.

A couple of interesting messages come out for me:

  • We want to do this right, and actually specify what should be done, and this takes time. No more vague specs!
  • Although the final spec will take a long time, this doesn’t mean that we won’t see pieces implemented sooner, and in fact we are already seeing that
  • It is hard to guess what people will find contentious, and what will get by:

    HTML5 defines sort-of-new meanings for the b, i, and small elements, which I thought would be really contentious, but really only a few people complained.

    The things that ended up being the most contentious were things I didn’t really expect. At one point, I added a paragraph in the spec that said that we were looking for a royalty-free, patent-unencumbered, and low-submarine-patent-risk video codec, and we received a record number of e-mails on the topic overnight, as every news site on the Web seemed to take this as a sign of the apocalypse.

    Another topic that’s received a lot of feedback is that we dropped acronym in favor of just using abbr, and a lot of people complained, though few could agree on what exactly the two elements would mean if we kept both.

    More recently, there have been two big topics, both on what I consider to be remarkably unimportant parts of HTML, all things considered. The first was with the img element and its alt attribute. HTML4 requires alt but doesn’t give any advice about how to use it. With HTML5, I added a long section that describes how to use it in detail and said that in some cases (e.g., webcams), there might not be any useful replacement text, and so it would be ok in those cases (and only those cases) to omit the attribute. This caused a firestorm of protest from so-called accessibility experts. There were even some people arguing that Flickr (another site that today shows images but doesn’t always have suitable alternative text) should require photographers to always include detailed descriptions of every image they upload.

  • What are the gotchas in HTML 5?

    Most of the “gotchas” in HTML5 are things that we’ve inherited from the legacy of the Web. For example, the address element is for contact information, not any address; the br element shouldn’t be used unless you’re writing something that really has a line break like a poem (generally people should be using p instead of br); and be careful when writing URLs, you have to escape the “&” characters by appending “amp;” after each one.

    We’ve also introduced some unfortunate features of our own, though. One is that, while we’ve made it legal for the a element (used to define links) to contain entire paragraphs and lists, doing so can cause problems in browsers like Firefox that don’t yet implement the HTML5 parser algorithm. Also, while it can contain what we call “flow content,” it can’t be used to wrap individual list items or table rows.

  • Ian really cares about error handling:

    Defining error handling from day one has got to be the most important change that I would ask Tim to make if I could speak to him then. I think we could have avoided a huge amount of the tag soup mess we have now if we had just defined simple error handling from the get-go.

This is just a fraction of the article. You should check it out!

Posted by Dion Almaer at 7:29 am
2 Comments

+++--
3.2 rating from 16 votes