sorted by: recent | see : popular

Content Tagged with Page + front

I have seen the GWT team working very hard indeed on GWT 1.5, and they must be very happy to see the final release shipped and complete:

GWT 1.5 delivers what we think are an impressive number of improvements, about four hundred issues if you’re counting. We’re also happy that one of those is issue 168, our most-requested feature, Support for Java 5.

The high level new feature sets are:

• Java 5 language support and enhanced JRE emulation
• Performance optimizations and easier JavaScript interop
• Prettier widgets, better DOM, accessibility, and bi-di

You can see a lot of this at work in the showcase area. There you will see all of the widgets and examples that come out of the box, and the community has developed even more for you. In particular, Ray Cromwell has some great real world examples that he shares in his book and talk.

Download GWT and take a look.

John Resig posted on degrading script tags and adding functionality to <script> so you can add a src attribute and a body of code that will be executed one the external script loaded error free:

To make this all work, John shows us a jquery aware version that detects loading and such:

Where this kicks in, is more than just saving a script code block. Steve Souders has been researching different ways to tie blocks of code to scripts and having the optimal ordering for performance. We can tie this learning to John's work, and the developer can choose what they want to do (e.g. when loading don't have the icon moving etc etc).

For years, many of us have been salivating over the idea of JIT'ed JavaScript in the browser. Adobe's JIT'ing Flash VM showed a preview of tremendous speed gains to be had, but we've had to wait until SquirrelFish from WebKit to see anything dramatic happen in the browser.

Until now.

Mozilla just let the cat out of the bag on their new TraceMonkey project. Brendan Eich, Mozilla's CTO, describes it thusly:

I'm extremely pleased to announce the launch of TraceMonkey, an evolution of Firefox's SpiderMonkey JavaScript engine for Firefox 3.1 that uses a new kind of Just-In-Time (JIT) compiler to boost JS performance by an order of magnitude or more. [Emphasis ours.]

There are charts and graphs all over the Web; here's one from Brendan's blog:

As Brendan points out, the benchmarks can be generally quite misleading; the best results are the demos. And, here's a link to Mike "schrep" Schroepfer's blog entry where he put one together in a screencast:

Brendan goes into significant detail on how all of this came about, and notes some key points:

* We have, right now, x86, x86-64, and ARM support in TraceMonkey. This means we are ready for mobile and desktop target platforms out of the box.
* As the performance keeps going up, people will write and transport code that was "too slow" to run in the browser as JS. This means the web can accomodate workloads that right now require a proprietary plugin.
* As we trace more of the DOM and our other native code, we increase the memory-safe codebase that must be trusted not to have an exploitable bug.
* Tracing follows only the hot paths, and builds a trace-tree cache. Cold code never gets traced or JITted, avoiding the memory bloat that whole-method JITs incur. Tracing is mobile-friendly.

For even more details, check out Andreas Gal's detailed blog entry on trace trees.

The first phase of Ajax has been all about leveraging the existing platforms as much as we can. This announcement is a major signpost towards the second phase: improving the existing platforms. We couldn't be more excited.

Brendan puts it in his own understated way:

JS-driven <canvas> rendering, with toolkits, scene graphs, game logic, etc. all in JS, are one wave of the future that is about to crest.

John Resig voices similar sentiments in his excellent blog post on the subject:

[This] means that JavaScript is no longer confined by previously-challenging resource of processing power... I fully expect to see more massive projects being written in JavaScript...

The primary thing holding back most extensive Canvas development hasn't been rendering - but the processor limitations of the language (performing the challenging mathematical operations related to vectors, matrices, or collision detection). I expect this area to absolutely explode after the release of Firefox 3.1 as we start to see this work take hold.

Speaking of Canvas and JS, we've got our own little project we've been hacking this year that we can't wait to try this on... way to go, Mozilla!

Jacob Seidelin finishes up his binary meme with a post on reading image metadata with JavaScript via a library that groks EXIF data.

It tries to detect the format of the image file and then reads the header and pulls out information about dimensions and color depth among other things. If the EXIF data library is included, it will also gather any EXIF tags from JPEG files.

ImageInfo, this library, was inspired by the App Engine app IMG2JSON.

Razor Profiler is a web-based Ajax profiling tool to help web developers understand and analyze the runtime behavior of their JavaScript code in a cross-browser environment. Razor Profiler can be access either online as a service; or be downloaded to run locally, and was created by Coach Wei who has done a lot of work for Nexaweb and Apache.

Razor Profiler Features

Razor Profiler automates JavaScript profiling:

• Automation: no application code change required. Razor Profiler automatically collects all the necessary data and presents them to web developers for analysis.
• Runs on any browser: web developers can profile any JavaScript application on any browser. There is nothing to install on the client side.
• Rich lexical analysis: Razor Profiler presents rich lexcial information about the application, such as file information (number, response status, size, mimetype, percentage, etc), tokens (size, file, percent, count), and functions (size, file, name...), etc;
• Profile scenario recording: Razor Profile enables web developers to selectively record the scenarios that they are interested in. Only recorded scenarios will be used in analysis.
• Call stack analysis: for each recorded scenario, Razor Profiler presents all the call stacks in the order of their occurence. For each call stacks, web developers can drill into it to find out the duration of the stack, all the function calls of this stack and the duration of each call.
• Function analysis: For each JavaScript function in the application, Razor Profile presents the number of times it has been invoked, the duration of each invocation, and the call stacks that invoked this function.
• Data visualization with graphing and charting: Razor Profiler presents top call stacks, top function calls of each stack, top recorded scenarios, etc. using visual charts and graphs to help web developers better understand the runtime behavior of their application. For example, each call stack is visualized as an intuitive Gantt chart.

How Does Razor Profiler Work?

Razor Profiler composes of a server component that runs inside a standard Java EE Servlet engine, and a JavaScript-based client component that runs inside any browser. Once you have Razor server started, you can profile your JavaScript application by entering the start URL of your application into Razor Profiler and run through your test scenarios. Razor Profiler will automatically record data and visualize them for your analysis. There is no client side installation, browser configuration change or application code change required. In order to achieve this, Razor Profiler goes through five different phases:

• Application retrieval: Once a web developer enters the application start URL into Razor Profiler, Razor Profiler client component ("the client") will send this URL to Razor Profiler server component ("the server"). The server performs the actually retrieval of this URL. After additional server processing (such as lexical analysis and code injection, see below), the retrieved content is sent to the client side to be displayed in a new browser window. For the developer point of view, the application is launched and running in this new browser window.
  In this process, Razor Profiler Server is acting like a "proxy server". But it is not really a "proxy server" and there is no need for developers to re-configure their browser proxy settings.
• Lexical analysis: Once the server retrieves the application URL, it performs lexical analysis of the returned content by identifying and analyzing JavaScript files, functions, and tokens,etc. The result is sent to the client for display.
• Code injection: Upon lexical analysis of JavaScript code, the server injects "probe" code into the application's JavaScript sources before returning them to the client. These injected "probes" enable automatic collection of application runtime data, and saves developers from doing so manually.
• Runtime data capture: Once the application's JavaScript code is running on the client side and as developers run through desired profile scenarios, the injected "probes" automcally collect all the necessary data to Razor Profiler Client.
• Data analysis: When the developer finishes recording scenarios and starts data analysis, Razor Profiler client performs analysis of all the collected data and presents the results.

Aza Raskin and the Mozilla Labs team looks like they are having a lot of fun. They have been putting up proposals for new UIs and the latest involves a smarter new tab screen.

Aza discusses how opening a blank screen doesn't really help you. Opera already allows you to have a quick dial screen show up there, but what else can be done?

Often a new tab is opened to do a search, so they can put a search bar right there, and it can be smart enough to search across your own tools and providers (e.g. delicious). I personally don't do this, as I use Apple-K to jump to the search bar in the browser and have the search results open in a new tab.

What I found even more interesting was the context specific smartness. How often do you do this:

• Find an address
• Select and copy the address
• Open a new tab
• Go to maps.google.com
• Paste in the new address

Instead, the new tab selector can be smart and automatically show you the map option. NOTE: there are of course other options such as plugins that find the addresses and give you links to the map.

In the "oh wow, I didn't know JavaScript could do that" category, I just came across a cool new jQuery plugin called jParallax which implements a parallax effect on selected elements. Now, I'm not ashamed to admit not knowing what "parallax" meant so I looked it up on Wikipedia which totally added closure to the concept being implemented. Till then, I just thought that was a really cool effect!

Parallax turns a selected element into a 'window', or viewport, and all its children into absolutely positioned layers that can be seen through the viewport. These layers move in response to the mouse, and, depending on their dimensions (and options for layer initialisation), they move by different amounts, in a parallaxy kind of way.

jParallax includes several options for controlling the effect including setting the animation timing and layer positioning control. The demos can be viewed here.

We also covered Brett Taylor's implementation of a parallax effect last year where he showed how to build parallax backgrounds.

Update: I've added straight links to the demos

Aza Raskin and the Mozilla Labs team have launched Ubiquity the command line tool that they have been talking about for awhile.

Ubiquity is "experiment into connecting the Web with language in an attempt to find new user interfaces that could make it possible for everyone to do common Web tasks more quickly and easily."

The overall goals of Ubiquity are to explore how best to:

• Empower users to control the web browser with language-based instructions. (With search, users type what they want to find. With Ubiquity, they type what they want to do.)
• Enable on-demand, user-generated mashups with existing open Web APIs. (In other words, allowing everyone–not just Web developers–to remix the Web so it fits their needs, no matter what page they are on, or what they are doing.)
• Use Trust networks and social constructs to balance security with ease of extensibility.
• Extend the browser functionality easily.

The screencast explains more:

What is cool about the system, is that it is a platform. If you fancy adding a new command, it is as easy as the following 'date' command:

Fancy a go? Download Ubiquity 0.1.

You have seen this before: /path/to/something.js?v=2, or maybe it used a date or a version control id or some such. The notion of putting the version into the URL so you can aggressively cache and yet quickly push new versions.

There has long been issues with using the querystring as the version. At some point I seem to remember Safari not going a good job caching that scenario and thinking that it was different.

Steve "Neo" Souders has posted about this issue especially as it relates to proxy servers and default configurations:

There’s a section in my book called Revving Filenames. It contains an example of adding a version number to the filename. That’s prompted several emails where people have asked me about tradeoffs around using a querystring versus embedding something in the filename. I wasn’t aware of any performance difference, but in a meeting this week a co-worker, Jacob Hoffman-Andrews, mentioned that Squid, a popular proxy, doesn’t cache resources with a querystring. This hurts performance when multiple users behind a proxy cache request the same file - rather than using the cached version everybody would have to send a request to the origin server.

I tested this by creating two resources, mylogo.1.2.gif and mylogo.gif?v=1.2. Both have a far future Expires date. I configured my browser to go through a Squid proxy. I made one request to mylogo.1.2.gif, cleared my cache (to simulate another user making the request), and fetched mylogo.1.2.gif again. This produces the following HTTP headers:

>> GET http://stevesouders.com/mylogo.1.2.gif HTTP/1.1
<< HTTP/1.0 200 OK

<< Date: Sat, 23 Aug 2008 00:17:22 GMT
<< Expires: Tue, 21 Aug 2018 00:17:22 GMT
<< X-Cache: MISS from someserver.com
<< X-Cache-Lookup: MISS from someserver.com

>> GET http://stevesouders.com/mylogo.1.2.gif HTTP/1.1
<< HTTP/1.0 200 OK
<< Date: Sat, 23 Aug 2008 00:17:22 GMT
<< Expires: Tue, 21 Aug 2018 00:17:22 GMT
<< X-Cache: HIT from someserver.com

<< X-Cache-Lookup: HIT from someserver.com

Notice that the second response shows a HIT in the X-Cache and X-Cache-Lookup headers. This shows it was served by the Squid proxy. More evidence of this is the fact that the Date and Expires response headers have the same values, even though I made these requests 10 seconds apart. For conclusive evidence, only one hit shows up in the stevesouders.com access log.

Loading mylogo.gif?v=1.2 twice (clearing the cache in between) results in these headers:

>> GET http://stevesouders.com/mylogo.gif?v=1.2 HTTP/1.1
<< HTTP/1.0 200 OK
<< Date: Sat, 23 Aug 2008 00:19:34 GMT
<< Expires: Tue, 21 Aug 2018 00:19:34 GMT

<< X-Cache: MISS from someserver.com
<< X-Cache-Lookup: MISS from someserver.com

>> GET http://stevesouders.com/mylogo.gif?v=1.2 HTTP/1.1
<< HTTP/1.0 200 OK
<< Date: Sat, 23 Aug 2008 00:19:47 GMT
<< Expires: Tue, 21 Aug 2018 00:19:47 GMT
<< X-Cache: MISS from someserver.com
<< X-Cache-Lookup: MISS from someserver.com

Here it’s clear the second response was not served by the proxy: the caching response headers say MISS, the Date and Expires values change, and tailing the stevesouders.com access log shows two hits.

Proxy administrators can change the configuration to support caching resources with a querystring, when the caching headers indicate that is appropriate. But the default configuration is what web developers should expect to encounter most frequently. Another interesting note about these tests: notice how the proxy downgrades the responses to HTTP/1.0. This is going to alter browser behavior in terms of the number of connections that are opened. When I’m doing performance analysis I make sure to avoid being connected through a proxy.