You searched for: 'native'

Monday, December 24th, 2007

WebKit gets native getElementsByClassName

Category: Browsers, Performance, WebKit

getElementsByClassName has always been a pain in the arse for us developers. Why it wasn’t implemented natively across the board is something that browser folk can chat about. Not having it available has caused hacks, workarounds, and bugs.

Firefox and Opera support the beast, and now Webkit has joined them:

The advantages of a native implementation are clear:

  • No additional JavaScript library files required
  • Clearly specified and consistent behavior
  • Blindingly fast

How fast? Let’s have a look at WebKit’s shiny new implementation. For testing purposes I wrote a simple benchmark allowing comparison between three different methods for getting elements by their class names. The first is the new native getElementsByClassName, and the last two are both from prototype.js; one uses XPath, and the other is a straight JavaScript/DOM implementation.

Posted by Dion Almaer at 6:06 am

4.4 rating from 35 votes

Tuesday, September 25th, 2007

JS-CTYPES: Calling out to native code from XUL

Category: Firefox, JavaScript, Library

Mark Finkle has ported Python’s ctypes to JavaScript, and has created JS-CTYPES which allows you to declare and call exported methods from binary/shared libraries from Mozilla’s privileged JavaScript. The idea is to make dealing with XPCOM simpler.

You end up with code like this:


  1. const nsINativeType = Components.interfaces.nsINativeType;
  3. function msgbox() {
  4.   var library = Components.classes[";1"]
  5.                           .createInstance(Components.interfaces.nsINativeLibrary);
  6."user32.dll"); // Load the shared Windows DLL
  8.   var messageBox = library.declare(
  9.       "MessageBoxW",          // name of the exported method
  10.       nsINativeType.INT32,    // return type
  11.       nsINativeType.INT32,    // parent hwnd (its a Window's thing)
  12.       nsINativeType.WSTRING,  // Unicode message string
  13.       nsINativeType.WSTRING,  // Unicode title string
  14.       nsINativeType.INT32     // bitflag for buttons to show
  15.   );
  17.   var ret = messageBox(0, "This is the message", "Msg Title 1", 3);
  18.   alert(ret);
  20.   // You can reuse the method
  21.   var ret = messageBox(0, "This is another message", "Msg Title 2", 3);
  22.   alert(ret);
  23. }

Of course, John Resig is working on FUEL which aims to make it easier to create add-ons easier:

FUEL is a JavaScript Library designed to help developers build extensions using terminology and interfaces that are familiar to them. FUEL is new in Firefox 3 and will be backported to Firefox 2 as well.

FUEL is about making it easier for extension developers to be productive, by minimizing some of the XPCOM formality and adding some “modern” JavaScript ideas. We want to start with areas that will provide the most benefit.

Posted by Dion Almaer at 6:43 am
1 Comment

3 rating from 21 votes

Friday, July 6th, 2007

iPhone Native Looking Skin

Category: iPhone, Mobile

The default look of a web page is pretty bad. Simple white background with ugly black lettering. Nothing nice.

With the iPhone though, it doesn’t look half as bad, and now, thanks to Joe Hewitt (again) there is an even better base.

You can simply use his native looking navigation skin to make your applications look and feel like a native iPhone application.

The magic sits in:

  • iphonenav.js: The JavaScript handles getting rid of the browser url bar, the back button (Safari finally supports changing the hash nicely!), changing based on the orientation, swiping a page across, and more.
  • iphonenav.css: The CSS makes the standard elements look like real iPhone elements thanks to magic like “-webkit-border-image: url(iPhoneButton.png) 0 8 0 8;”

There is still more to do of course. It would be great to give developers simple access to the red deletes, the blue buttons, the twisty round deletes, and more. This allows anyone to build an app that will look decent and just like the iPhone apps that users are used too.

Thanks again Joe!

Joe\'s iPhone Skin

Posted by Dion Almaer at 12:55 pm

4.1 rating from 78 votes

Wednesday, April 11th, 2007

JSLT: A JavaScript alternative to XSLT

Category: JavaScript, Library

Rik Arends has created JSLT, a pure JavaScript replacement for XSLT.

JSLT is a browser based templating language like XSLT, but instead of
using XML to encode the template logic, it uses normal Javascript with a
few extensions. You can transform XML with it or just template with
javascript variables. The JSLT processor parses the template using
a recursive tokenizing parser and generates javascript code for fast
dynamic (re-)execution. The general structure is:
templatetemplate{inline-xpath}template. All code is available
under the LGPL license.

You can visit a real-time example page that recompiles on each keystroke.

If you almost liked XSLT, and like JavaScript, maybe JSLT is for you.

Posted by Dion Almaer at 6:34 am

3.6 rating from 38 votes

Friday, March 9th, 2007

JavaScript Native Interface (JSNI) in GWT

Category: Google, GWT, JavaScript, Library

I have recently had quite a few people talking about how they like GWT but with they could get out of the Java box to delve into JavaScript for some low level work.

The assumption was that you cannot do this with GWT and that if you run against the abstraction barrier you are hosed.

There is actually a way to embed your own JavaScript directly.

JSNI has a similar name to JNI but isn’t as hairy, although it does have a creative hack.

To implement JSNI the GWT team overloaded the term native and used it for their own good:

  1. public static native void alert(String msg) /*-{
  2.   $wnd.alert(msg);
  3. }-*/;

Take a close look. Sneaky huh? The $wnd variable is your link to the window object, and if you need the DOM you simply use $doc.

The piece of JSNI that looks a little like JNI is how you access Java methods and fields directly from JavaScript.

Before you run off and start writing reams of JavaScript code, remember why you are using GWT in the first place, and use this as a last resort.

Posted by Dion Almaer at 10:01 am

3.7 rating from 44 votes

Monday, November 27th, 2006

Google Docs and Spreadsheets Team: Web native matters

Category: Editorial

Richard MacManus linked to a Gizbuzz interview of Jen Mazzon and Sam Schillace of the Google Docs and Spreadsheets team (both ex-Writely).

Nothing ground-breaking, but it is interesting to hear about their thoughts on Ajax:

Browser compatibility issues – like the early graphic Web

Next was a question about browser compatibility issues and how that affects D&S – and indeed the future of rich web applications. Sam responded that “it is definitely an issue […] these apps are all cutting edge – it kind of reminds me of the early days of the graphical web, when you couldn’t count on the browsers to render tables correctly […]”.

But he thinks it’s “just growing pains” and it’ll take about a year to sort those issues out.

Also on the question of whether Ajax is better than Flash and Laszlo etc, Sam thinks that Ajax is currently more web native.

It’s about being Web native, not cloning desktop apps

Later in the interview, Jen stresses that they’re “not trying to clone desktop apps”. They want to be familiar to people, “but we’re trying to do something that’s actually more native to the Internet, more usable on the Internet.”

Sam says they’ve had a lot of feedback that people like the fact they’re not trying to copy desktop apps. He said “copying the existing stuff just feels irrelevant to us – we’re not trying to copy, we’re trying to re-invent.”

Both Jen and Sam re-affirmed that collaboration and sharing is their main focus with D&S, as well as being web native – rather than trying to compete on features with desktop apps.

If you were asked “why is Ajax a better fit for some apps than Flash?” what would you say? Do you agree? Does the open web matter? What if Adobe fully opened up their format?

Posted by Dion Almaer at 9:25 am

3.9 rating from 16 votes

Monday, November 6th, 2006

Meebo Update: Now more like a native app?

Category: Chat, Showcase

Meebo Logo

Meebo made a huge splash when it came onto the scene. It was an example of a real world app inside the browser, in this case chat. From that we started to see chat everywhere :)

It also had the side benefit to proof that people would trust their passwords into a meta service like this, but that is another issue.

Meebo just had a large update that they call release XX: one giant leap.

With the pop-out feature you can see that it is hard to tell the difference between meebo and a native app.

Here is meebo and Adium side by side:

Meebo Update

What’s New

1) New visual design – Sandy and I were Photoshop newbies when we first designed meebo and we’ve been itching for an updated look. We’re thrilled to show off David’s latest work!

2) Pop outs – click on that little icon in your IM window to “pop” the window out of the main meebo browser (don’t forget to disable any pop-up blockers you have for

3) Drag and drop buddy list management – Harry A. wrote, “I’d like a way to easily consolidate and manage groups.” Mike C., Frank R., and Rafael F. agree. The ability to move buddies between groups has been our most popular feature request for a while. Enjoy!

4) Skinning – we understand a few of you might be attached to the meebo’s first look and feel. If you are feeling nostalgic, we’ve introduced the ability to switch back to the old skin – just go to the preference area and select the ‘Classic’ skin. Keep an eye out for more skins in the future.

More good stuff…

* Individual sign on and off – now you can manage your screen names one-by-one. Just click on the drop-down menu in the left-hand console area.

* Localization – In addition to Bangla, Creole, Esperanto, Iloko, Jawa, Latin, Malagasy, Marathi, Mongolian, Nias, Swiss German, Thai, Uzbek support – we’ve also translated other parts of the UI such as buttons, menus, and links. The language updates dynamically based upon your location and preference too. Thai looks really good on the new front page!

* Updated Chat Logs – Chatlogs just got a facelift. Power-users (like Sandy and Andreas) will appreciate the new design and speedier loading times.

* AIM Profiles – This has been one of the top three requests for many weeks. AIM users, check out the ‘Set Profiles’ in the console area. Mark recently got engaged, guess what he announced in his profile this week! Congrats!

* Optimization – We’re always trying to make meebo better and faster. Those of you with very large buddylists, like user rnbmelody, will appreciate the new performance enhancements.

Posted by Dion Almaer at 5:29 am

4.2 rating from 30 votes

Tuesday, August 15th, 2006

IE 7: Are transparent PNGs using Native support?

Category: Browsers, IE

There was a big hubbub when we found out that IE 7’s XHR support isn’t really native.

Jose Jeria did some poking around to see if transparent PNG support is native or not:

While developing an intranet for IE 6 only (yes, trust me, it sucks) I noticed that it was not possible to combine certain filters. Transparent PNG:s were used for buttons that needed to look disabled. A combination of the AlphaImageLoader with the Alpha filter should have done the trick, but it didn’t seem to like this combination. It should have looked like this:

But IE failed rendering the PNG with opacity applied to it, and instead it rendered it like this:

This must be a bug in IE’s filter implementation. So what I did next was to test the same image with opacity applied to it in IE 7, since they now claim they have native transparent PNG support. But… the results were exactly the same. Which makes you wonder if it’s not just the same filter as in IE 6 being applied under the hood

Posted by Dion Almaer at 11:39 am

4 rating from 43 votes

Friday, July 28th, 2006

IE7 XMLHttpRequest – Native or Not?

Category: IE, XmlHttpRequest

MS announced this week that IE7 will be pushed as a high-priority update, so we can expect it to be popular pretty quickly. Reader Shawn Lauriat brought our attention to the question: How native is IE7’s XMLHttpRequest?

The IE team have promoted the new IE7 as including native XMLHttpRequest. This is the case, insofar as you can instantiate an XHR using new XMLHttpRequest(). More importantly than the syntax, XHR will still work when ActiveX has been disabled (unlike IE6 and below).

On the other hand, Shawn notes that some issues exist. Some have pointed out that its more of a native facade than a native Javascript object. Specifically:

  • xhr.prototype fails. Indeed, it’s reported that any dynamic member creation fails (e.g. xhr.callId = 25; an idiom that can be useful for Call Tracking). If this is still the case, it’s not the behavior of a native object and it’s not consistent with other browsers.
  • It’s also worth pointing out that IE has an option to disable native XHR. (Aside: can we switch to positive terminology already – “enable” rather than “disable” … it’s hardly a secret of HCI that options should be stated in the positive :-/). The XHR option is, reasonably enough, motivated by security. Although it sounds like XHR will default to enabled (sorry, “not disabled”), it’s still a reality that some users will be continue to be lost if you rely on XHR. Don’t throw out that IFrame just yet!

IE7 XHR – Native or Not?

Posted by Michael Mahemoff at 2:42 pm

4.1 rating from 51 votes

Tuesday, June 6th, 2006

Ajax on IE 7: Check native first

Category: IE, Tip

I would hasten a guess that there is a lot of code out there that starts off with:


  1. /*@cc_on
  2.         @if (@_jscript_version >= 5)
  3.                 try {
  4.                         xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
  5.                 } catch (e) {
  6.                         try {
  7.                                 xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
  8.                         } catch (E) {
  9.                                 xmlhttp = false;
  10.                         }
  11.                 }
  12.         @else
  13.         xmlhttp = false;
  14.         @end @*/
  15.         if (!xmlhttp && typeof XMLHttpRequest != "undefined") {
  16.                 try {
  17.                         xmlhttp = new XMLHttpRequest();
  18.                 } catch (e) {
  19.                         xmlhttp = false;
  20.                 }
  21.         }
  22.         return xmlhttp;

and what is wrong with this? Well, apart from being pretty verbose, in the world of IE7 we should be invoking XMLHttpRequest() first and having the ActiveX control done only if window.XMLHttpRequest isn’t around to play.

Posted by Dion Almaer at 8:55 am

3.6 rating from 37 votes

Thursday, April 27th, 2006

Javeline DeskRun: Run Ajax Apps as Native Windows Programs

Category: Library

Javeline has announced Javeline DeskRun. DeskRun wraps your Ajax application up, allowing it to be deployed as a simple windows exe. It also gives you local file system access, caching, and more.


  • Internet application on the desktop
  • Package your web application inside a single executable
  • Behaves exactly like a regular Windows application
  • Access to the local file system, start menu and system tray
  • Full control over the application appearance, including title bar and icon
  • Deliver the same application to the Internet and the desktop without alteration
  • Develop applications that can work online, offline or intermittent

Posted by Dion Almaer at 9:52 am

3.8 rating from 78 votes

Tuesday, October 11th, 2005

Weighing up the Rich Client alternatives

Category: Articles

Alexei White has given his opinion on the various rich client technologies out there (Ajax, XUL, XAML, Applets, Flash, and SVG) giving pros and cons to them.

He then attempts to answer “Why Ajax now?”:

Ajax is a natural choice for four reasons:

  • 1. It solves current business problems.
  • 2. Platform independance.
  • 3. Skill-set comformity.
  • 4. Network effects.

Has he got it right?

Posted by Dion Almaer at 9:48 am

3 rating from 5 votes

Wednesday, September 14th, 2005

IE 7 has XMLHttpRequest as native component. NOT ActiveX.

Category: IE

This is good news from IEBlog:

IE 7 implements a native XMLHTTPRequest object for Javascript applications, instead of requiring an ActiveXObject to be created. This also means XMLHTTPRequest will function on machines that have ActiveX disabled. We’ve providing support for International Domain Names we’ve also done some thoughtful work to prevent spoofing of URLs by using similar characters from other languages.

And, now people are already wanting XSLTTransformer and more :)

If you love the Web Developer Toolbar in Firefox, it is coming to IE world too:

Finally, in recognition of the need for great web developer tools, we are just about to beta a Web Developer Toolbar that provides web developers with rich object model and visual tools which will help them design standards-based HTML and CSS web pages. This feature will be delivered as an add-on for IE6+.

Posted by Dion Almaer at 4:04 pm
Comment here

3 rating from 5 votes

Monday, August 29th, 2005

Internet Explorer Has Native Support for Persistence and Saving Session Across Page Loads Without Cookies

Category: Articles, IE

Brad Neuberg has written up a lot on the state of state in the browser :)

Saving Session Across Page Loads Without Cookies, On The Client Side

This is a mini-tutorial on saving state across page loads on the client side, without using cookies so as to save large amounts of data beyond cookies size limits.

He discusses two ways to deal with session state in the client:

  • Method number one is to use an iframe in some special ways. First, this iframe must exist on page load, Then, whenever you wish to record state that you want to save, you must write that state into the iframe
  • The other session approach I’ve found is a crazy hack that I saw used for something else, in Danny Goodman’s book JavaScript and DHTML Cookbook. Danny was looking for a way to pass data between frames, and he found that you could persist data by saving them into hidden text fields. This is a beautiful (and scary) hack that is a solution to our session state. All the browsers I have tried (IE, Firefox, and Safari) persist any text you put into a form field, even if they are hidden. To save state, then, we can simply write it into hidden form fields!

Run a demo

Internet Explorer Has Native Support for Persistence?

How the heck did I miss the existence of non-cookie persistence features in Internet Explorer since IE 5? This is from MSDN:

“Persistence enables authors to specify an object to persist on the client during the current and later sessions using Dynamic HTML (DHTML) behaviors. Persistence allows Microsoft Internet Explorer 5 and later to retain Web page information, styles, variables, and state. For example, a collapsible list of links within a table of contents can remain expanded to the user’s choice upon leaving and later returning to the page. Or, a search engine query form can retain the last-used searchstring.

Posted by Dion Almaer at 3:36 am

4 rating from 7 votes

Tuesday, March 22nd, 2005

Ruby on Rails 0.11 includes native Ajax support

Category: Ajax, Ruby, Screencast

Rails 0.11.0 is out on the street and I’m especially proud of the Ajax support we’ve been able to include. Instead of trying to soften the blow of doing client-side Javascript libraries as many others are doing, we’ve gone ahead and more or less removed the need for hand-written client-side javascript entirely.

This is done by off-loading the creation of DOM elements to the server side, which returns complete constructs that are then injected live through innerHTML. While this method is slightly more verbose than just peddling data across the wire, it’s immensely easier to develop.

And especially the ease of development is critical to the success of Ajax. I used the old style of hand-crafting the DOM on the client-side with Ta-da List and was quite disillusioned at the mess of browser differences and the sheer effort it took. Basically, each sliver of Ajax was a project in itself.

With Honey, though, I’ve been all over the new Ajax style that Rails affords. And what a difference it makes! It’s basically no harder to make something Ajaxed than it is not to, which means that the decision is based on whether its a good fit for the user interface — not on whether we have time to another Ajax project.

It is indeed very cool how they have taken out the need to really WRITE dHTML in your apps.

Read more about this release at: Rails 0.11.0: Ajax, Pagination, Non-vhost, Incoming mail

Check out the movie, which shows you how to setup a form to use Ajax in Rails.

Posted by Dion Almaer at 12:52 pm

3.7 rating from 7 votes

Saturday, December 10th, 2011

HipHop Virtual Machine for PHP

Category: PHP

Facebook Software Engineer and HipHop for PHP team member Jason Evans provides details on Facebook’s move to a new high-performance PHP virtual machine. Described by Evans is ”a new PHP execution engine based on the HipHop language runtime that we call the HipHop Virtual Machine (hhvm).” He sees it as replacement for the HipHop PHP interpreter (hphpi). He continues:

We have long been keenly aware of the limitations to static analysis imposed by such a dynamic language as PHP, not to mention the risks inherent in developing software with hphpi and deploying with hphpc. Our experiences with hphpc led us to start experimenting with dynamic translation to native machine code, also known as just-in-time (JIT) compilation … we developed a high-level stack-based virtual machine specifically tailored to PHP that executes HipHop bytecode (HHBC). hhvm uses hphpc’s PHP>AST implementation and extends the pipeline to PHP>AST>HHBC.

He estimates the hhvm bytecode interpreter is approximately 1.6X faster for certain Facebook-specific benchmarks, with still better performance in the offing. But, as described in his blog post on the PHP compilation innovations, there is still work ahead. You can view HipHop-related information at GitHub.

Posted by jvaughan at 9:15 pm

3.2 rating from 263 votes