You searched for: 'native'

Wednesday, June 18th, 2008

Our Signal: Page Cloud Visualization of Digg, Reddit, Delicious, Hacker news

Category: jQuery, Showcase

Our Signal

Our Signal takes Digg, Reddit, Delicious, and Hacker News and creates a full page cloud visualization using jQuery.

The size of the box reflects the popularity, and the color lets you know the acceleration of that popularity. If the color is warm, it is on the rise, and vice versa for cool colors.

I like seeing alternative visualizations, but I have to admit I am not a huge fan of tag cloud style views. You?

Posted by Dion Almaer at 10:00 am

2 rating from 39 votes

Friday, June 13th, 2008

Pivot: Swing++ as New Java-based RIA Platform?

Category: Java, UI

And now for something a little bit different on a Friday. Greg Brown from VMWare pointed us to the fruition of nearly a year’s worth of R&D: Pivot, a new GUI toolkit for Java.

While traditionally Java Applets and the Web have mixed together about as well as concrete and peanut butter, the upcoming revised Java plug-in might give a window for Java-based GUI toolkits to be of interest to Web folks.

While Pivot’s source code is still forthcoming, a quick glance at its classes shows an architecture with a strong resemblance to Java’s built-in Swing GUI toolkit, but with many of Swing’s rough edges smoothed out. As a long-time Swing developer, I’d characterize it as attempt to create Swing++.

Similarities to Swing include a light-weight rendering model (i.e., it doesn’t wrap native components), a nearly identical component contract, a very similar system of UI delegates, and a very similar event model. Differences include a cleaner API (by virtue of nixing direct interoperability with Java’s ancient AWT toolkit), different approach to layout, fresh implementations of common GUI components, and a new collections framework (inspired by Java’s collections framework but… different).

Thinlet is another, older alternate GUI toolkit for Java that draws its own components and targets Applet developers (though a new version is under development).

Posted by Ben Galbraith at 7:05 am

3.6 rating from 33 votes

Tuesday, June 10th, 2008

Mascara: Putting lipstick on JavaScript?

Category: JavaScript


Mascara is the latest in a “Write code in X and translate it to JavaScript” system to be launched.

Mascara calls out systems like GWT, Script#, and HotRuby and says…

Mascara has a different approach, because we actually like JavaScript. The core of JavaScript is well-designed, powerful and flexible, and in many ways a more modern design than C# and Java. ECMAScript 4 is not a replacement for JavaScript, rather it is a set of powerful extensions to the base language, while still fully backwards compatible with classic JavaScript.

This means you can keep using all your existing JS-code, or gradually upgrade your code step-by-step to ES4. ES4 is actually specifically designed to allow gradual upgrade from classic JavaScript to ES4.

You can keep using your favorite JavaScript libraries like jQuery, Prototype or YUI and the immense amount of JavaScript code available on the web, while still making your own code more robust and structured by utilizing the ESMAScript 4 type verification and constructs like classes and namespaces.

JavaScript have gotten a reputation for incompatibilities across browsers. This is somewhat unfair, since JavaScript the language is quite consistent across browsers. The incompatibilities are caused by differences in the DOM and CSS implementations, which indeed are frustratingly inconsistent across browser. But that problem is not solvable at the language level, but rather at the library level, where jQuery or the alternatives will hide the browser incompatibilities for you.

So, if you like JavaScript, but want more of it, ECMAScript may be for you.

The generator is written in Python, and John Resig has a good writeup of the features:

  • Type verification
  • Classes and inheritance, constructors, super initializers
  • Static members
  • Type inference from initialization
  • Parameterized types, Map and Vector
  • Union types
  • Structural types
  • Getters/setters
  • Namespaces
  • Nullable types

Time to write JavaScript in JavaScript? Will this type of system be a way to start writing in JavaScript that has it run in older VMs?

Posted by Dion Almaer at 4:25 pm

3.4 rating from 25 votes

Monday, June 9th, 2008

Is “finally” the answer to all IE6 memory leak issues?

Category: IE, Microsoft, Testing, Tutorial

Hedger Wang has been scanning a lot of Chinese blogs lately for solutions to IE6 and memory leak issues. One of the things he stumbled upon is a pretty nifty way of nulling the objects to stop memory leaks by using the try ... finally construct. So instead of this solution which leaks memory:


  1. function createButton() {
  2.       var obj = document.createElement("button");
  3.       obj.innerHTML = "click me";
  4.       obj.onclick = function() {
  5.         //handle onclick
  6.       }
  7.       obj.onmouseover = function() {
  8.         //handle onmouseover
  9.       }
  10.       return obj;//return a object which has memory leak problem in IE6
  11.     }
  12.     var dButton = document.getElementsById("d1").appendChild(createButton());
  13.     //skipped....

You can use the following which doesn’t:


  1. function createButton() {
  2.       var obj = document.createElement("button");
  3.       obj.innerHTML = "click me";
  4.       obj.onclick = function() {
  5.         //handle onclick
  6.       }
  7.       obj.onmouseover = function() {
  8.         //handle onmouseover
  9.       }
  10.       //this helps to fix the memory leak issue
  11.       try {
  12.         return obj;
  14.       } finally {
  15.         obj = null;
  16.       }
  17.     }
  18.     var dButton = document.getElementsById("d1").appendChild(createButton());
  19. }

More demos, proof of concept examples and the “finally” explanation is available on Hedger’s blog: Finally, the alternative fix for IE6’s memory leak is available

Posted by Chris Heilmann at 10:22 am

4.1 rating from 40 votes

Friday, June 6th, 2008

An interview with 280 North on Objective-J and Cappuccino

Category: JavaScript, Library, Podcasts, Toolkit

280 North

As I say in this podcast interview, I got an early look at 280 Slides the application that launched yesterday to much acclaim. People are calling it “Keynote on the Web”, which the team finds very humbling, and hope that one day they have all of the great features (and more!).

As you can hear from the interview I sit down with Ross Boucher, Tom Robinson and Francisco Tolmasky to discuss their new application and how they built it.

I really like these guys. A couple of them worked on cool products at Apple, and it turns out that they started the language and runtime work back at school.

Objective-J is the language that takes JavaScript and makes it Objective (as Obj-C did to C). Lots of square brackets. When the browser gets served .j files, it preprocesses them on the fly. This means that you can do things like, use standard JavaScript in places.

Cappuccino is the port of the Cocoa framework.

The guys talk a little about the toolchain an why they did this, and even how it enables future cool things such as generating a native Mac application from the same code.

We also get into the fun cross browser issues that they work around, and how they are abstracting developers high up, so you don’t have to deal with these issues.

Finally, I was excited to hear that they will be open sourcing the code at shortly (may not be there yet). They are going through the usual issues of choosing a license (Apache2 please?), a source control system (Subversion vs. Git), and documenting the thing ;)

We have the audio directly available, or you can subscribe to the podcast.

The team was very interested in learning what JavaScript developers think (They have heard from Objective-C folk who love it), so let them know in the comments!

Posted by Dion Almaer at 3:41 pm

4.2 rating from 74 votes

Tuesday, May 20th, 2008

moo.rd 1.3 released

Category: JavaScript, Library

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!

Moo.rd 1.3.1

Posted by Dion Almaer at 8:01 am

1.1 rating from 111 votes

Thursday, May 15th, 2008

Flash 10 “Astro” prerelease

Category: Adobe

With Silverlight 2 aimed square at Flash, many of us were interested to see what Flash 10 would have in store for us. We get our first glimpse with the Flash 10 prerelease, code named “Astro”.

I installed the prerelease and recorded the demos so you can take a quick peak:

The biggest feature in my mind, is true 3D:

3D Effects – Easily transform and animate any display object through 3D space while retaining full interactivity. Fast, lightweight, and native 3D effects make motion that was previously reserved for expert users available to everyone. Complex effects are simple with APIs that extend what you already know.

There are other new features too. At a high level:

Custom Filters and Effects – Create your own portable filters, blend modes, and fills using Adobe Pixel Bender, the same technology used for many After Effects CS3 filters. Shaders in Flash Player are about 1KB and can be scripted and animated at runtime.

Advanced Text Layout – A new, highly flexible text layout engine, co-existing with TextField, enables innovation in creating new text controls by providing low-level access to text offering right-to-left and vertical text layout, plus support for typographic elements like ligatures.

Enhanced Drawing API – Runtime drawing is easier and more powerful with re-styleable properties, 3D APIs, and a new way of drawing sophisticated shapes without having to code them line by line.

Visual Performance Improvements – Applications and videos will run smoother and faster with expanded use of hardware acceleration.  By moving several visual processing tasks to the video card, the CPU is free to do more.

If you delve into the release notes you see features such as:

  • Context Menu — Developers now have more control over what can be displayed in the context menu through the use of ActionScript APIs for common text field context menu items, supporting plain and rich text. The clipboard menu provides access to the clipboard in a safe and controlled way, and you can write handlers to paste text.
  • File Reference runtime access — Bring users into the experience by letting them load files into your RIA. You can work with the content at runtime and even save it back when you are done through the browse dialog box. Files can be accessed as a byteArray or text using a convenient API in ActionScript without round-tripping to the server. You no longer have to know a server language or have access to a server to load or save files at runtime.
  • Dynamic Streaming — Always show the best video possible with streams that can automatically adjust to changing network conditions. By changing bitrates, you can keep your user engaged and avoid start-and-stop video. Dynamic streaming provides the best possible experience to the video consumer based on their bandwidth environment. Video streams over RTMP from intended future releases of Flash Media Server can dynamically change bitrate as network conditions change. Quality of Service metrics, exposed via ActionScript and providing real-time network or CPU information, allow developers to take control of the video playback and adjust the streaming experience accordingly. This feature is part of Flash Player 10 but will only be available with intended future releases of Flash Media Server.
  • Text Layout Components — An extensible library of ActionScript 3.0 text components, coming in future to Adobe Labs, provides advanced, easy-to-integrate layout functionality that enables typographic creative expression. Layout and style text with tables, inline images, and column flow through components that are compatible with both Flash and Flex, all while getting the benefits of the new text engine. Rich text components allow designers and developers to flow text and complex scripts, such as Arabic, Hebrew, and Thai, across multiple columns like a newspaper, around tables and inline images, from right-to-left, left-to-right, bi-directionally, or vertically. Selection, editing, and wrapping of text are handled as would be expected for the different layouts.

It is also interesting to put this into context with JavaFX, which was hyped last week at JavaOne (without a release yet). There were some nice demos, such as 3D video globes, and a few people said “Flash couldn’t do that. No decent 3D or hardware acceleration.” The bar keeps rising for all.

Posted by Dion Almaer at 12:18 am

4.5 rating from 37 votes

Monday, May 12th, 2008

Everything you wanted to know about String performance

Category: JavaScript, Performance

Tom Trenka has detailed a great analysis of JavaScript performance across the various browsers. This is important work, and it reminded me of the JVM days where people tried to use pools and such… to find out that they were bad for performance as newer VM technology came out. When you try to be too tricky you can end up in a bad state as new versions try to optimize the common task, and not your trick.

Eugene Lazutkin had a great explanation on Strings in languages:

Many modern languages (especially functional languages) employ “the immutable object” paradigm, which solves a lot of problems including the memory conservation, the cache localization, addressing concurrency concerns, and so on. The idea is simple: if object is immutable, it can be represented by a reference (a pointer, a handle), and passing a reference is the same as passing an object by value — if object is immutable, its value cannot be changed => a pointer pointing to this object can be dereferenced producing the same original value. It means we can replicate pointers without replicating objects. And all of them would point to the same object. What do we do when we need to change the object? One popular solution is to use Copy-on-write (COW). Under COW principle we have a pointer to the object (a reference, a handle), we clone the object it points to, we change the value of the pointer so now it points to the cloned object, and proceed with our mutating algorithm. All other references are still the same.

JavaScript performs all of “the immutable object” things for strings, but it doesn’t do COW on strings because it uses even simpler trick: there is no way to modify a string. All strings are immutable by virtue of the language specification and the standard library it comes with. For example: str.replace(”a”, “b”) doesn’t modify str at all, it returns a new string with the replacement executed. Or not. If the pattern was not found I suspect it’ll return a pointer to the original string. Every “mutating” operation for strings actually returns a new object leaving the original string unchanged: replace, concat, slice, substr, split, and even exotic anchor, big, bold, and so on.

Tom then went on to detail the rounds that he went through:

  • Round 1: Measuring Native Operations.
  • Round 2: Comparing types of buffering techniques.
  • Round 3: Applying Results to dojox.string.Builder.

There are a few surprises here, and Tom later concludes:

  • Native string operations in all browsers have been optimized to the point where borrowing techniques from other languages (such as passing around a single buffer for use by many methods) is for the most part unneeded.
  • Array.join still seems to be the fastest method with Internet Explorer; either += or String.prototype.concat.apply(””, arguments) work best for all other browsers.
  • Firefox has definite issues with accessing argument members via dynamic/variables

Erik Arvidsson reminds us of the reason to use push(): IE6 and it’s really bad GC.

I look forward to the IE 8 / FF 3 results too.

Posted by Dion Almaer at 8:34 am
Comment here

4.3 rating from 18 votes

Wednesday, May 7th, 2008

Wii Darts: Powering Ajax applications with Wii controllers

Category: Games, Java, Presentation, Showcase

Ben and I gave a presentation at JavaOne on what’s new with Ajax. Since this was JavaOne, we skewed a little more than we normally would to Java topics, and one of them was using the new Java Plugin, that has great new features such as being able to take a running applet out of the web page, and having it continue to live after shutting down the browser. Java is running out of process here, which also helps the “Java crashing the entire browser” problem.

Anyway, back to our demo. For some context, last year at JavaOne had us performing Guitar Hero on stage, so we knew that we had to use a gaming console in some way. This year it had to be the Wii, but instead of using the console, we decided to just use the controllers.

Wouldn’t it be cool to control a Web page using the controllers? We thought so, and we set to it. You can talk to the Wiimotes via Bluetooth, so we needed a stack that would allow us to do just that. Java has a bluetooth stack. We could get an applet to talk to the Java stack. Hmm.

It actually took quite some time to test out the various stacks out there. In the end we went with a native system called Wiiuse that a lot of Wii hackers use. There is a wrapper library called Wiiusej that gave us exactly what we needed.

A quick test later and we had an application that was talking between the remote and the program. It turns out that the main controller sees a series of IR lights that are in the Wii sensor bar, and this allows you to simulate the system with any decent IR source. In the presentation room the big lights that shine on stage were strong enough to act as a sensor bar so we won’t even have to use it. We can just point out to the crowd.

Anyway, back to the application. We then wrote a Java class that acts as a state machine for what the remote is doing. It understands the movements, which buttons are pushed, how fast you are moving the device. With this data we could build a simple darts game. With the state machine Java code, and an Applet wrapper that exposed the information, we were ready to get to the Ajax side of the house.

We painted a darts board onto the screen and then had JavaScript start polling the Applet for information via JSObject (As simple as: document.nameofapplet.pollmethod()). This turned out to be more stable than talking the other way, even though it meant we were polling instead of being entirely event driven. When the JavaScript code polled the applet it would pass back a data structure with the data for the coordinates of the remote, and whether the dart had been fired (button A to fire, button B to reload). We would move the dart image on the screen as you move the remote, and when fired we kicked off an animation to fire the dart at the board.

At first, it was all too simple. You setup the shot and it would get the right area every time. Not a fun game. We then decided to add some simple physics to the Ajax game. We took into account the velocity of the throw (if weak it would fall down) and how straight your shot was. If you wiggle around, the dart will not be accurate.

Anyway, this was a lot of fun, and shows that as much as we mock Java applets, if we forget about using them as fancy blink tags, and instead think of them as more extension points, maybe there is life for them.

The video below shows you a demo of the application, the source code with an explanation, and more details.

Posted by Dion Almaer at 6:08 pm

4.4 rating from 37 votes

Tuesday, April 22nd, 2008

Talking about JavaScript 1.7, 1.8 and 1.9 before we get to 2.0

Category: JavaScript

Is this JavaScript that would run in a current browser?


  1. function square_of(x) x * x;
  3. players.sort(function(x,y) y['score'] - x['score']);

Yup. This is JavaScript 1.8 and 1.7, also known as Pythonizing Javascript ;)

Tiago Silveira discusses these lambda expressions, as well as Generators:


  1. function actions() {
  2.   for (f in document.forms) {
  3.     yield document.forms[f].action
  4.   }
  5. }

list comprehensions, let:


  1. function showItems(items) {
  2.   for (let i in items) {
  3.     // the variable i has the scope of this block.
  4.     ShowElement('item_' + i);
  5.   }
  6. }
  7. // Using comprehensions:
  8. showItems([ i for ( i in obj ) if ( i > 3 ) ])
  10. // Using generators:
  11. showItems( i for ( i in obj ) if ( i > 3 ) )

And more.

Then we hear from John Resig that the JavaScript 1.9 planning meeting happened and we really hope for some SPLAT fun gets in as well as his own hope for built-in Function.prototype.bind and a native JSON encoder/decoder. Others were looking for setPropertyIsEnumerable, and Douglas Crockford has his own thoughts.

Posted by Dion Almaer at 8:27 am

3.6 rating from 10 votes

Yahoo! BrowserPlus: Why wait for the news when you have strings?

Category: Gears, Yahoo!

After posting about Yahoo! BrowserPlus, we certainly have more questions than answers, and we could all wait a week or two to learn more.

But, where is the fun in that? Thanks to the fact that Open Source software often normally means that you will find a LICENSE.txt, and the binary itself will have information on what is used, you can sometimes glean information. Oh, and the UNIX strings command can help too ;)

So, armed with enough data to be dangerous (yet totally wrong) we see that:

  • The components seem to be called Corelets
  • There are distribution servers that can serve Corelets. The primary is set to, but you could imagine too
  • There is the notion of “Dynamic Corelets” which leads you to believe that you can get new ones into the system, or that you can use dynamic languages to program the system.
  • OpenSSL is packaged and it appears that you use certificates to make sure the right code is run. It is unknown if you are given SSL primitives to work with, which would be fun
  • A native JSON implementation is bundled, which is probably just to parse the config file, and not exposed to developers
  • There is the notion of an “Upload Corelet” which could mean a way to upload new ones into the system, or a better file upload (please)

If you look in the installation directory, you also see the NSPR which tells us that the system uses the Netscape Portable Runtime:

The Netscape Portable Runtime, or NSPR, is a platform abstraction library that makes all operating systems it supports appear the same to Mozilla. NSPR provides platform independence for non-GUI operating system facilities. These facilities include threads, thread synchronization, normal file and network I/O, interval timing and calendar time, basic memory management (malloc and free) and shared library linking. A good portion of the library’s purpose, and perhaps the primary purpose in the Gromit environment, is to provide the underpinnings of the Java VM, more or less mapping the sys layer that Sun defines for the porting of the Java VM to various platforms. NSPR does go beyond that requirement in some areas and since it is also the platform independent layer for most of the servers produced by Netscape. It is expected and preferred that existing code be restructured and perhaps even rewritten in order to use the NSPR API. It is not a goal to provide a platform for the porting into Netscape of externally developed code.

Ok, not back to just waiting for the real information. Again, it is great to see Yahoo! apparently thinking about how to make browsers do new tricks, which is why I am excited about Gears.

Posted by Dion Almaer at 2:03 am

3.3 rating from 17 votes

Friday, April 18th, 2008

Conform your JSON to ECMAScript 4 with JCON

Category: JSON, Library

Oliver Steele is doing great work, and he has just released a gem called JCON which stands for JavaScript Conformance. It tests JSON values to make sure that they are valid for the new world of ECMAScript 4 type definitions (e.g. new { x:int, y:string }( 3, “foo” ) ).


  1. type = JCON::parse "[string, int]"
  2. type.contains?([‘a’, 1])     # => true
  3. type.contains?([‘a’, ‘b’])   # => false
  4. type.contains?([‘a’, 1, 2])  # => true
  6. // via RSpec
  7. [1, ‘xyzzy’].should conform_to_js(‘[int, string]’)
  8. [1, 2, ‘xyzzy’].should_not conform_to_js(‘[int, string]’)  # 2 isn’t a string
  9. {:x => 1}.should conform_to_js(‘{x: int}’)
  11. // with JavaScript Fu
  12. # this will succeed if e.g. response contains a script tag that includes
  13. #   fn("id", {x:1, y:2}, true)
  14. response.should call_js(‘fn’) do |args|
  15.   args[0].should conform_to_js(‘string’)
  16.   args[1].should conform_to_js(‘{x:int, y:int}’)
  17.   args[2].should conform_to_js(‘boolean’)
  18.   # or:
  19.   args.should conform_to_js(‘[string, {x:int, y:int}, boolean]’)
  20. end

In other JSON news, it appears that new ECMAScript standard will no longer reserve the words:

abstract boolean byte char double final float implements int interface
long native package private protected public short static synchronized
throws transient volatile

And Douglas Crockford says that no browsers reserve them, and thus he is unreserving them from jsLint.

Posted by Dion Almaer at 5:50 am
1 Comment

3 rating from 9 votes

Thursday, April 10th, 2008

Gears and Web Standards

Category: Gears, Standards

Aaron Boodman, co-lead of the Gears team, has written a very thoughtful post on how Gears relates to various Web standards. My analogy was that of a zipper bringing things together:

Back to Aaron’s post which I couldn’t say any better, so I put here for ease of browsing:

Gears is about more than just offline web applications. For example, we recently added desktop shortcut functionality, and we’re working on resumable uploads, a geolocation API, and lots more fun things for the future.

We’ve received some questions recently about how all this relates to web standards, such as HTML5 and those proposed by the W3C. It seems like some people are afraid Gears will try to compete with the web.

Let us put those fears to rest right now: on the Gears team we loves us some web standards. Some of us were web developers stuck in the crossfire of the browser wars, and we deeply understand standards have played a key role in the productivity and creativity of the web over the past 10 years.

We have no desire to create a parallel platform and compete with the web. Anyway, that would be crazy. The web is an unstoppable force of nature. Competing with it would be like entering a shouting match with the wind: you can’t win, and you look pretty silly trying.

Instead, Gears aims to bring emerging web standards to as many devices as possible, as quickly as possible.

Some History

The Gears project started because a group of developers at Google were frustrated by the slow march of web browsers. Competition and standards were producing fantastic results, but it took a long time to get implementations on every browser. In some cases, we still don’t have compatible implementations, years after the standards were finalized. Our first project was to implement APIs that would make offline web applications possible.

Currently, the Gears Database and LocalServer modules are not fully compatible with the HTML5 proposals for the same functionality. This is only because those specs were written after Gears was released, and not because of any desire to be different. In fact, we were involved in the design of both HTML5 specs, and we are currently implementing the proposal for database access.

Going Forward

In many ways, Gears is like a browser without any UI. And just like other browsers, Gears will implement existing standards and rally for changes and additions where they seem needed. For example, we recently proposed our geolocation API work to the W3C WebAPI group.

There are three important differences between Gears and other browsers, however:

  1. Improvements to Gears can be used by developers immediately. Gears is available today on Firefox (for Windows, OS X, and Linux), IE, and IE Mobile. Implementations for more browsers and platforms are in progress. Developers no longer have to wait for every browser to implement new web standards before they can use them, they only have to wait for them to be available on Gears.
  2. Most browser vendors have two groups of customers: users and developers. User-facing features typically get more attention than developer-facing APIs, for a variety of reasons. But with Gears, developers are the only customers. We can focus completely on creating the best possible platform for web development.
  3. Gears is an implementation of web standards that lives inside another browser. For example, the HTML5 Database API might be available to developers through both the google.gears object and the traditional window object. This is OK, and in some ways a good thing. Developers will be able to mix and match the pieces of Gears and native browser implementations that work best.

The Pitch

By implementing emerging web standards, Gears is influencing what the web of tomorrow will look and act like. And since Gears is an open source project, anyone can contribute.

Get involved. You don’t have to be able to code in C++. All that’s needed is some free time and the desire to push the web forward.

Posted by Dion Almaer at 9:03 am

3.8 rating from 8 votes

Tuesday, April 8th, 2008

Web Archeology: Java Pluglet API

Category: Standards

I started a new series of posts on Web Archeology where I look back at old Web tech to maybe divine some inspiration from the future. I am re-posting from my original blog

Stone Henge-esque

Even since Ben and I looked at the notes for the first version of Mozilla that supported XMLHttpRequest, which suddenly took the technology from “Some ActiveX for IE” to “Ajax”, I have been interested in hidden technologies that maybe never made it. In those notes for that release we saw no mention of XMLHttpRelease, but technology such as FIXptr was prominently mentioned.

Also, something interesting about Ajax is exactly the fact that the technology was available since 1997, but didn’t make it big until many more Dilbert calendars later.

This points to the fact that there may be some hidden gems in the past that could also be resurrected in the now! As I look back in time, I thought I would talk about any that interest me in some way. Hence, the Web Archeology set of postings. If there is a technology that I am missing, please let me know!

Today I am going to talk about the Java Pluglet API. This technology is part of the Blackwood project at Mozilla, where it was created in 1999 by Igor Kushnirskiy & Akhil Arora.

Let’s walk back to 1999 for a second. Imagine working on Mozilla in a world where you had to futz with a lot of XPCOM and C++ to build things. XUL came about a way to reach out via more Web-y technology to get work done (XML, JavaScript, CSS, etc). In 1999, Java was a sexy language, and everyone was getting ready for fantastic server side Java with great technology like EJB ;)

What if the Java developers could get in on the browser action and develop rich plugins for Mozilla? This is where the Java Pluglet API comes in. It allows you to do just that, mimicking the C++ side of the house:

It was a conscious design decision to have the Pluglet API resemble its C++ counterpart as much as possible, while being able to reflect all of its functionality to Java, so that Plug-in writers will not have to learn yet another API. This concern, in our opinion, outweighed other alternatives which offered a cleaner, more Java-like look. Support for other Plug-in APIs can be easily added by contributing adaptors.

How you register the pluglet is via mime types. You could create application/wicked-cool and when that comes back from the server, Mozilla will say “hmm, I don’t understand this mime type, Pluglet Engine do you?”

At a high level the idea of writing extensions in Java makes total sense to me. It is obviously cross platform, but still low level enough, with a huge library set to get a lot done.

Isn’t this dead?

Probably? Ed Burns did step up to the plate though and reenergized the project recently. As part of the resurrection you can now interface directly between the Java side and JavaScript itself.

If you squint a little, you see an interesting plugin path for the browser. I often say that I would love for Gears to be made using Java instead of C++!

Dimitri Glazkov pointed to the custom handler support that has been specified in HTML 5, and Ray Cromwell linked to his GWT 1.5 posting as a way to extend the browser using Java.

Posted by Dion Almaer at 8:39 am
Comment here

3.3 rating from 9 votes

Monday, April 7th, 2008

Adobe Releases AIR for Linux, Joins LSF

Category: Adobe

Adobe continues to expand its support for the Linux platofrm by announcing the release of the Adobe AIR runtime for Linux. This expands the ability to deploy AIR desktop applications to the three major operating systems (Windows, OS X & Linux) while still using the standard web technologies developers have become accustomed to.

This release of AIR for Linux will be supported on the following distributions:

  • RedHat Desktop Linux 4
  • RedHat Enterprise Linux v5
  • Novell Desktop Linux 9
  • SUSE Linux Enterprise Desktop 10
  • Ubuntu 6.06

and the following features are available with this release:

  • Runtime/Application Install/Update and Uninstall.
  • HTML Loader with JS support to render HTML within AIR applications.
  • Local Database APIs
  • File system support with support for user folders like Desktop/Documents etc.
  • Desktop Integration with Drag and drop, clipboard support
  • Windowing support with System chrome none/standard
  • Basic transparency
  • Menu support with context menu, menu bar, pop up menus and menu events.
  • Networking
  • Network change detection (Event.NETWORK_CHANGE )
  • System wide idle detection (userIdle Event)
  • NativeApplication APIs
  • Capabilities (OS) API
  • Mouse events
  • Detection of running application (InvokeEvent.INVOKE)

Adobe has posted a FAQ to provide detailed information about this new product release.

Adobe Joins Linux Foundation

In addition to releasing AIR for Linux, Adobe has also joined the Linux Foundation to “collaborate on the advancement of Linux as a leading platform for rich Internet applications (RIA) and Web 2.0 technologies.

“Adobe’s decision to join the LF is a natural extension of its commitment to open standards and open source, which demonstrates its leadership and foresight in the software industry,” said Jim Zemlin, executive director at The Linux Foundation. “Adobe’s membership will contribute to our goal of increasing even more application development on Linux with a specific emphasis on Web 2.0 applications.”

“Adobe delivers key RIA technologies for Linux users, such as Adobe® Flash® Player and now Adobe AIR™, to deploy RIAs in the browser and on the desktop,” said David McAllister, director of standards and open source at Adobe. “The Linux Foundation is a valuable resource, providing a forum where we can work with the community to ensure Adobe RIA technologies are compatible across the Linux software platform.”

This announcement further solidifies Adobe’s commitment to the linux community, having already released server-side products that work natively on the Linux platform.

Posted by Rey Bango at 9:06 am

4.5 rating from 23 votes

iPhone WebKit Goodness: 3D CSS Transforms and ontouch events

Category: iPhone, JavaScript, Library, Mobile

Scripters and Coders 2008

Apple is secretive. I normally don’t mind so much, as they always come through on yet another cool Mac product. If I could know one thing though, it wouldn’t be when the next Macbook Pro is coming out, or when we will see the 3G iPhone. Instead, I wish I knew the attentions in the battle of “what can we develop with on the iPhone”.

We started out with only being able to use JavaScript, and folks like Joe Hewitt quickly mastered the restrictive tools such as meta viewport and co.

Then we got the final word of the iPhone SDK, and the Cocoa developers rejoiced as they went from being the cool kids to the “now you will pay me to help in the land grab yO”.

There was one shoutout to the WebKit lovers. We got ongesture* events.

Now we got a glimpse of new updates for the iPhone Ajaxians:

Safari 3.1 showed us CSS transforms, which are 2D. On the iPhone though, we can now do 3D transforms which means you can do true coverflow through the browser.

The other new thing I found are new touch screen events. We already knew about the ongesture* events, but now there are ontouch* events, and new DOM interfaces Touch, TouchList, and TouchEvent.

This is great progress.

The optimist in me thinks: Wow, WebKit is going to be a first class citizen and Apple will continue to open up more and more of the innards as JavaScript APIs.

The cynic in me thinks: Yeah, they will support it, kinda like how Java is supported on the Mac. One poor bugger has to do all of the work and make people care. In this case, when Apple starts making 30% on all of the native applications, what will their incentive be to help people develop apps using the Web?

The hope is that they realize that the Web is the long term winner, and that they want to win in that market too. Please, Mr. Jobs.

Posted by Dion Almaer at 12:01 am

4.1 rating from 22 votes