In GWT 1.5 the build process is internally divided into two phases, compilation, which creates JavaScript from Java, and linking, which takes the JavaScript and other resources produced by the compilation phase and packages it for deployment. I wanted to understand a bit more about the linking process after seeing Bob Vawter talk about Resource Bundles and Linkers in GWT at the Google I/O conference. To try and help me do that I’ve created a linker that you can include in you build process to create a sort of manifest file listing which generated JavaScript file applies to which permutation of browser, locale etc.

To create a linker and have it called during the build process you need to do four things

• Create a class that implements com.google.gwt.core.ext.Linker
• Add a LinkerOrder annotation to the class to define whether the linker should run before the primary linker, after the primary linker or instead of the primary linker. You’re allowed as many linkers before and after the primary as you like but only one primary linker.
• Define and add the linker in a <module>.gwt.xml file.
• Include the new class in the classpath when running the gwt compiler.

The 1.5 RC1 build provides three different primary linkers that produce three different ways of packaging the compiler output for loading by the browser. The standard linker produces the familiar <module>.nocache.js file that loads the correct <strong name>.cache.html for the target browser. This is the linker that is added in Core.gwt.xml and so is the default linker that is used. Also provided are a cross site linker that creates a <module>-xs.nocache.js and a single script linker. You use the cross site linker if you need to host the GWT generated artifacts on a separate domain from your main site, for example if you use www.mysite.com for serving dynamic content and put all the static stuff, including JavaScript, on static.mysite.com. The single script linker can be used when the compilation process always creates a single JavaScript file that is applicable to all permutations.

Scott has updated SoundManager2 with some nice new features.

The biggest is the update to support Flash 9, which brings with it:

• multiShot properly allows play() to be called multiple times on a sound object, creating desired "chorus" effect. Will call onfinish() multiple times, but whileplaying() etc. are called only for the first "play instance" to avoid complications.
• New soundSpectrum and peakData sound features (spectrum graph / "VU" meter-style data) available
• Sounds can be actually unloaded ("null" MP3 no longer needed to cancel loading of an MP3), but URL cannot be changed without destroying and recreating the related Flash sound object. The Flash 9 version does this to maintain API consistency.

Give it a download but remember the disclaimer that Scott himself puts on the software:

Not every button, link, element or paragraph on the web needs to zoom, move, change colour and be noisy, repetitive and annoying all at the same time. Use your own discretion!

Sites which automatically start playing background sound, and/or don't have volume or mute controls are the kind of things you should avoid building. As a developer, gentle reader, you may eventually find yourself in such a situation. Please do your part in enhancing the web with sound if you use SM2, while at the same time keeping it audibly usable. :)

I want to create a shim that implements the Gears Audio API that is currently being talked about in the community:

Mario Heiderich has released qUIpt, a library that uses the window.name property to store away useful data, in this case JavaScript.

How does it work?

• It checks for the contents of window.name while your page is being loaded.
• If there's nothing inside the window.name cache the JS files defined by you are fetched via XHR
• The same happens if the users enters your site for the first time of his current browser session or if document.referrer is off-domain or empty
• After that the contents of window.name are being evaluated
• If the user requests the next page on your domain the JS files are directly taken from window.name - no more requests necessary

You can check out an example of it at work

There is a bold goal at the beginning of the document (why is the doc a PDF/.doc and not just HTML!!!):

Make ASP.NET Ajax the first-class choice for all Web 2.0 developers

They are going to be catching up with richer CSS selection and DOM manipulation:

We have got some animation going on:

What else?

• Accessibility
• Drag & Drop
• Client-side Controls and Behavior
• Interoperability: OpenAjax hub support
• Tooling, tooling, tooling

This is possible as the JavaScript is running on the server, and this server is running on Windows. You can download the source code to check it all out.

During a recent webinar to promote the upcoming Black Hat briefings in Las Vegas, a group of hackers announced the creation of a hybrid file that can potentially bypass a browser's same origin policy. They created a GIF file that also happens to be a JAR file ( a "GIFAR" file). Once uploaded onto a web site, and assuming the web server runs a JVM, it allows one to run a malicious java applet on someone else's web server.

Details were not provided, since the hackers claim that Sun is still working on a patch. For more on hybrid (image) files as attack vectors, go to minute 41:23 of the webinar.

IE8 and Trustworthy Browsing

At first they set the scene:

This blog post frames our approach in IE8 for delivering trustworthy browsing. The topic is complicated enough that some context and even history (before we go into any particular feature) is important, and so some readers may find this post a bit basic as it’s written for a wide audience. In previous posts here, we’ve written about IE8 for developers: the work in standards support, developer tools, script performance, and more. In future posts, we’ll write about IE8 for end-users (beyond the benefits of improved performance, activities, and Web Slices). This post starts a series about trustworthy browsing, a topic important for developers and end-users and everyone on the web. By setting the context and motivation with this post, the next posts that dive into the details of IE8 will build on this foundation.

Trustworthy refers to one of our overall goals: provide the most secure and most reliable browser that respects user choice and keeps users in control of their machine and their information. For reference, Microsoft’s framework for Trustworthy Computing in general spans four areas: security, privacy, reliability, and business practices.

IE8 Security Part III: SmartScreen® Filter

For Internet Explorer 8, we’ve built upon the success of the Phishing Filter feature (which blocks over a million phishing attacks weekly) to develop the SmartScreen® Filter, a replacement that improves upon the Phishing Filter in a number of important ways:

• Improved user interface
• Faster performance
• New heuristics & enhanced telemetry
• Anti-Malware support
• Improved Group Policy support

IE8 Security Part IV: The XSS Filter

The XSS Filter operates as an IE8 component with visibility into all requests / responses flowing through the browser. When the filter discovers likely XSS in a cross-site request, it identifies and neuters the attack if it is replayed in the server’s response. Users are not presented with questions they are unable to answer – IE simply blocks the malicious script from executing.

With the new XSS Filter, IE8 Beta 2 users encountering a Type-1 XSS attack will see a notification.

IE8 Security Part V: Comprehensive Protection

As we were planning Internet Explorer 8, our security teams looked closely at the common attacks in the wild and the trends that suggest where attackers will be focusing their attention next. While we were building new Security features, we also worked hard to ensure that powerful new features (like Activities and Web Slices) minimize attack surface and don’t provide attackers with new targets. Out of our planning work, we classified threats into three major categories: Web Application Vulnerabilities, Browser & Add-on Vulnerabilities, and Social Engineering Threats. For each class of threat, we developed a set of layered mitigations to provide defense-in-depth protection against exploits.

Ratproxy is a semi-automated, largely passive web application security audit tool. It is meant to complement active crawlers and manual proxies more commonly used for this task, and is optimized specifically for an accurate and sensitive detection, and automatic annotation, of potential problems and security-relevant design patterns based on the observation of existing, user-initiated traffic in complex web 2.0 environments. The approach taken with ratproxy offers several important advantages over more traditional methods:

• No risk of disruptions. In the default operating mode, tool does not generate a high volume of attack-simulating traffic, and as such may be safely employed against production systems at will, for all types of ad hoc, post-release audits. Active scanners may trigger DoS conditions or persistent XSSes, and hence are poorly suited for live platforms.

• Low effort, high yield. Compared to active scanners or fully manual proxy-based testing, ratproxy assessments take very little time or bandwidth to run, and proceed in an intuitive, distraction-free manner - yet provide a good insight into the inner workings of a product, and the potential security vulnerabilities therein. They also afford a consistent and predictable coverage of user-accessible features.

• Preserved control flow of human interaction. By silently following the browser, the coverage in locations protected by nonces, during other operations valid only under certain circumstances, or during dynamic events such as cross-domain Referer data disclosure, is greatly enhanced. Brute-force crawlers and fuzzers usually have no way to explore these areas in a reliable manner.

• WYSIWYG data on script behavior. Javascript interfaces and event handlers are explored precisely to a degree they are used in the browser, with no need for complex guesswork or simulations. Active scanners often have a significant difficulty exploring JSON responses, XMLHttpRequest() behavior, UI-triggered event data flow, and the like.

• Easy process integration. The proxy can be transparently integrated into an existing manual security testing or interface QA processes without introducing a significant setup or operator training overhead.

What about other solutions?

There are numerous alternative proxy tools meant to aid security auditors - most notably WebScarab, Paros, Burp, ProxMon, and Pantera. Stick with whatever suits your needs, as long as you get the data you need in the format you like.

That said, ratproxy is there for a reason. It is designed specifically to deliver concise reports that focus on prioritized issues of clear relevance to contemporary web 2.0 applications, and to do so in a hands-off, repeatable manner. It should not overwhelm you with raw HTTP traffic dumps, and it goes far beyond simply providing a framework to tamper with the application by hand.

Ratproxy implements a number of fairly advanced and unique checks based on our experience with these applications, as well as all the related browser quirks and content handling oddities. It features a sophisticated content-sniffing functionality capable of distinguishing between stylesheets and Javascript code snippets, supports SSL man-in-the-middle, on the fly Flash ActionScript? decompilation, and even offers an option to confirm high-likelihood flaw candidates with very lightweight, a built-in active testing module.

Last but not least, if you are undecided, the proxy may be easily chained with third-party security testing proxies of your choice.

OpenLaszlo 4.1 is a major release bringing full support for both the DHTML/Ajax and the SWF/Flash platforms. It also includes over 800 bug fixes and a significantly improved documentation suite.

OpenLaszlo 4.1 has been fully-qualified across the following browser/platform combinations: Safari3/OSX, Firefox2/OSX, Internet Explorer 7/WinXP, Firefox 2/WinXP, and Firefox 2/Linux. We have tested the full suite of demos, samplers, and example applications with the requirement that, when possible, DHTML applications behave the same as their SWF counterparts.

OpenLaszlo 4.1 is now the recommended release for all developers on all platforms, and current users of OL 3.x and 4.0 should investigate upgrading to this new release.

Preliminary support for SWF9 is included in this release but has not been enabled in the developer console.

At the same time, the team announced 500,000 downloads. Congrats!

When you think about plugins in many environments, you have strict contracts through interfaces that you have to implement. With jQuery, you can just add on to the jQuery prototype, normally seen through the alias $.fn.

James shows the simple example of:

I read this as the power of the simplicity, but John Resig, again in his three parter saw it a little different, I think by thinking too much about the title :)

I will contend that such a thing as plugins exist and are logically distinct from "random JavaScript code that manipulates other JavaScript code" as long as the following points are met:

1. There have to be explicit points upon which a plugin can attach. James notes the most common one in jQuery (jQuery.fn) but we have tons more - events, animations, selectors - all over the board for developers to snap in to.
2. Even more importantly: Those points have to be documented or, at the very least, be under some sort of agreement that they will be treated like a normal piece of the user-facing API. In jQuery we treat all plugin extension points as "user-facing API" and only ever change them in major releases (if at all) and always provide an alternative for authors to use.
3. Finally, there has to be some sort of repository for navigating these plugins. This is a huge differentiator. Simply referring to "code in the wild" as plugins doesn't really cut it if there's no commitment to hosting them and keeping their documentation and examples alive.

Brad Neuberg showed a project, SearchTools, that added local search via Gears, and had a custom Dojo that wasn't Dojo in a very small package.

Alex Russell has taken this further and explained how he got Dojo to 6k by implementing a stub loader, so many of the functions were lazy loading stubs instead of full method bodies.

His use case was mobile, or small embedded devices in general:

On an iPhone with a clean cache the stubbed-out dojo.js cut in half the time required to load and evaluate. Sure, it’ll take more time on the network when parts of the toolkit are actually used (say, in response to a click event), but for mobile device scenarios, it’s going to be hard to beat the flexibility and speed of the stub loader when pulling Dojo into a page.

The post really wasn't about Dojo per se, but John Resig parsed the sentence: "Even so-called “lightweight” libraries like jQuery" and in one part of a three part post hit back:

The way it's worded you would assume that you were paying a large, up-front, cost to using jQuery when, in fact, there is very little overhead. jQuery has been shown to be the fastest loading JavaScript library for non-cached code and considerably fast for cached code.

If we ignore the frameworks and think of the meta-point it is a lot more interesting.

I think it's an interesting way to think about temporally organized data (I could see RSS feeds navigated through some similar mechanism, with the z-axis being time and the x- and y-axes being some kind of similarity measure), and further display that graphical presentation is not the sole domain of Flash.

• Generates HTML 5 markup (with data-* fields), including CSS classes
  with the property type.
• Based on prototype
• An ever-growing list of (progressive-enhancement) web components,
  including: multiple file upload, tabs, menus...
• Dead-simple javascript validation library with i18n support.
• ...which mimics the process at the server, in case javascript is disabled.

Just give it a try at the demo. Try introducing invalid input, and check the sources by clicking the "View source" link at the top right of the page. Everything in the demo should work with javascript disabled, including multiple file upload.

The framework also includes a libraries repository which pulls debug/optimized javascript from the google CDN:

This snippet of code would translate into this, if development is disabled:

Or this if not:

More details about the framework are at the reference guide. Ignacio would be grateful for any feedback!

Velocity, the performance conference, also showed the interest in making the Web faster, as many tools were announced to help out us devs. We also saw a lot of cool uses of Canvas/SVG, as developers delve low level and see that they actually work very well.

So, we sit at the crux of two paths. On the one hand, browsers are getting faster and faster and adding great new technology for us (including small things like CSS variables. finally!). On the other hand, we are creating more compelling user experiences (e.g. 280 Slides, Mobile Me). These forces work with each other. As we do cooler apps that push the boundaries, the browsers have to come back with better performance and tools to match. Expectations are changing, and we need to match them.

Here is the full roundup:

Browsers

• Flipping out over Safari
• IE 8 beta 2 coming in August
• X-UA-Compatible: IE=EmulateIE7
• Mozilla Week: From Client (Firefox 3) to Server (Weave) to Mobile (Fennec)
• Opera gets proactive and helps you fix your code
• Browser Memory Footprints; Watching with real usage
• Browser News: IE, FF, Safari, and Opera

Standards

• New in standards: Acid4 and HTML 5 update
• W3C Progress Events 1.0 Working Draft
• OpenAjax Alliance white papers on Mobile Ajax and recent browser advances

Performance

• SquirrelFish: Details on the new
• SquirrelFish: Technical excitement
• String Performance in IE: Array.join vs += continued
• Is "finally" the answer to all IE6 memory leak issues?
• Jiffy Firebug Plugin: Fine grained calculation of performance timings
• YSlow now has Firefox 3 support
• Rendering performance in Canvas compared to SVG and VML
• Clientperf: Simple Client-Side Rails Performance
• KITE: Keynote's Internet Test Environment
• A Technique For Lazy Script Loading
• Velocity Conference Videos and Slides

JavaScript

• An interview with 280 North on Objective-J and Cappuccino
• Steve Yegge on Server Side JavaScript
• Javascript HTML Construction Benchmark
• The fight for cross domain XMLHttpRequest
• eval('foo=a', obj.fn); How you aren't private in Firefox
• Google Analytics after onLoad and document.write for XHTML
• Johnson: Wrapping JavaScript in a loving Ruby embrace, and ARAX
• Gaia Widgets 3.0 "Glory"
• Audible Ajax Episode 27: SproutCore with Charles Jolley
• SproutCore: Being talked of as a Flash killer? Really?
• Apple, SproutCore, and Coherent
• modules.js: A New Stand-alone JavaScript Module Loader
• Mascara: Putting lipstick on JavaScript?
• Validanguage 0.9: More form validation
• SymbolicWeb: Ajax and Comet with Lisp
• dragtable: drag-and-drop reorderable columns for an HTML table
• Pingdom checks on JavaScript usage on top sites
• ensure: on demand resources
• Algebraic Data Types in JavaScript

ExtJS

• Leveraging Ext JS on the Server via Jaxer
• WiiExtJS: Building Ajax apps that run on the Wii Opera browser

Dojo

• Badging Flickr with Dojo
• Dojo Firebug Lite: Beyond console.log
• Nexaweb announces dojo.E markup and runtime
• A Double Dose of Dojo
• Dojo gets AIM API Support from AOL
• Working with Web Services with ease; dojo.data and the WikipediaStore

YUI

• YUI Autogrid: Correctly resize the grids

MooTools

• MooTools 1.2 Released
• CNET Updates the Clientside MooTools Plugin Repository

jQuery

• jQuery UI 1.5: Effects, API, and Themes
• jQuery Release 1.2.6: Performance Improvements and Dimensions Plugin Added to Core
• Implementing infinite scrolling with jQuery
• jQuery Selectors Refcard Now Available
• Preloading Images with jQuery
• jsTree: jQuery-based JavaScript tree component

Gears, AIR, and more

• Gears 0.3 Released, and Google I/O videos on Ajax related content available
• Frizone: JavaScript dev, test, and deployment environment
• Frank Sinatra, Flash, and Ajax: Deckmyplace.com
• flXHR: Flash based XHR from flensed
• SEO and RIA get closer together with Flash indexing news
• Fluid.app gets another new build

Design: CSS, SVG, Canvas

• Yahoo! Design Stencil Kit 1.0
• Using CSS transforms to Build a Coverflow Effect
• Mozilla Experiments with Applying SVG Effects to HTML
• Coda Slider Effect
• Algorithm Ink: Algorithm-driven Painting with Sharing and On-line Editing
• Photo Collages with Canvas
• CSS General Sibling Combinator in action
• CSS Variables are .... here!
• ShiftZoom: Zoomify your oversize images
• MooWheel and MooCirclePack for visualizations
• Hypno trip down the fractal rug
• Our Signal: Page Cloud Visualization of Digg, Reddit, Delicious, Hacker news
• Processing and Obsessing

Showcases

• Addressbook History goes into the cloud with App Engine
• Endpoint Resolver: JavaScript Library to hunt for Location redirects
• Acrobat.com: PDF and Flash sitting in a tree
• crossdomain.xml, Java, and JNLP
• Canvas Quest: Rogue like RPG game
• Yet Another Web 2.0 Button Generator
• PodiPodi: Enso / Quicksilver for the Web
• 72photos: Proto/Scripty Photo Sharing Site

Utilties

• NitobiBug: Cross browser debugging
• JavaScript Protocol Fuzzer
• JSON Diff Released
• TileStack: HyperCard for the Web

To go further Google uses the SWF Searchable work from Adobe to be more of a 'human' actor on the application.

This is what it doesn't do:

1. Googlebot does not execute some types of JavaScript. So if your web page loads a Flash file via JavaScript, Google may not be aware of that Flash file, in which case it will not be indexed.
2. We currently do not attach content from external resources that are loaded by your Flash files. If your Flash file loads an HTML file, an XML file, another SWF file, etc., Google will separately index that resource, but it will not yet be considered to be part of the content in your Flash file.
3. While we are able to index Flash in almost all of the languages found on the web, currently there are difficulties with Flash content written in bidirectional languages. Until this is fixed, we will be unable to index Hebrew language or Arabic language content from Flash files.

This is good news for all rich applications. One of the common worries when it comes to richer application development is "what do search engines see" and we sometimes see people go back to the simpler world just to make that happier. With the search engines stepping up themselves, we can go back to writing applications that make sense for our human users, and hope that the computers catch up. Of course, we always have to do so in a practical way.

This Web 2.0 / GWT example allows to draw on an infinite canvas and to see others changes immediately. It works like Google Maps: Use the "Move" cursor to walk around the canvas

Time for graffiti.

The above code code is all you need to know. It will open a TCP connection to hostname:port, and will send the data “Hello World”. Any data the server sends back will be alerted with the onread handler.

The exact mechanism behind this innovation is pretty straightforward: Orbited is a router and firewall for incoming TCPSocket connections from the browser. It uses Comet techniques to establish bi-directional communication with the browser, then forwards all data over a raw TCP socket to the end point. Configuration allows access control enforcement so that the TCPSocket can only be connected to pre-approved end-points, so that the Orbited server isn’t an open relay.

While this presents a paradigm shift in the way developers are tackling real-time, web-based applications today, it’s actually a return to the original method of writing network applications. Instead of writing applications based on web frameworks and throwing a Comet server in the mix, you can simply use the client-server architecture where the browser is the client, and the server is an arbitrary TCP server.

Updates include:

• New data format
• Text can now be hovered over, in addition to the dot
• Images can be added for each item

You can see the popular Twitter example
(thanks to Augsto Becciu, creator of TweetWheel).

Also, MooCirclePack has just been released:

MooCirclePack is another stunning visualization library that brings circle packing to JavaScript. It is great for data that can be represented by size (eg: an alternative to a bar graph), or data that can be represented amorphously.

There is a non-Ajax demo, and an Ajax one.

WebKit now has an experimental implementation of CSS variables:

You can test this feature using a WebKit nightly

Test cases

Once again, via Dylan Schiemann.