JavaScript

You are currently browsing the archive for the JavaScript category.

open web video screencast #3 – creating your own player

March 16, 2009 in Firefox, JavaScript, Mozilla, OGG, Open Web, Video, Web Standards | 17 comments

Chris Double posted about this but I thought it might be worth it to put together a simple video screencast of what this actually looked like in practice. It’s a damn neat idea and opens up all kinds of possibilities. Once again, with video as a first class citizen on the web, what can people dream up?

screencast of open web video in firefox 3.1

February 24, 2009 in Firefox, JavaScript, Mozilla, OGG, Video, Web Standards | 18 comments

I’ve made a screencast to describe some of the new video capabilities and how they can interact with the rest of the open web technologies we’re building into Firefox 3.1. Although I’ve embedded it below with a video tag (with a fallback to vimeo) I strongly suggest that you view the full sized version in either OGG Theora format or Quicktime H.264 for maximum clarity. It’s als up on vimeo.
You can find more information about using video and audio and web workers (threads) on developer.mozilla.org. Also I suggest that you follow the web-tech blog if you want to find out new features as they are added to Firefox. Enjoy!

mobile / arm tracemonkey first numbers

September 12, 2008 in JavaScript, Mobile, Mozilla | 3 comments

Vlad has been doing some of the integration work to get TraceMonkey working on ARM. He’s posted a first set of performance numbers which are more or less in line with the x86 numbers that were originally posted. Here’s the graph we care about:

The ARM backend is about 2,000 lines of code and is still in earlyish stages – but it’s working. It’s a great first step to bring fast JS perf to ARM-based mobile platforms.

the message you should take to your weekend

September 5, 2008 in Google Chrome, JavaScript, Microsoft, Mozilla | 9 comments

A quote from a Microsoft guy:

“I think that the next 18 months we’re going to see a 100 to 1,000 fold speed increase in JavaScript as Google and the guys at Mozilla are going to kick us all in the arse and make our JavaScript jittered,” Microsoft senior program manager Scott Hanselman told the audience, days after Google released its Chrome browser, which features faster JavaScript technology.

[...]

“It’s going to be hard to tell if it’s going to be Silverlight or JavaScript we’re going to use for our applications,” he said. “I think in the end JavaScript is going to be a bigger competitor to Silverlight than Flash is.”

Hell yes, we’re making the web kick ass.

performance, chrome, mozilla and tracemonkey

September 3, 2008 in Google, Google Chrome, JavaScript, Metrics, TraceMonkey, V8 | 17 comments

So, V8. Well-hyped. It’s got a cool logo. And many claims are being made about its performance. But it is not the only kid on the block. As we blogged about a couple of weeks ago, Mozilla has been investing over the last couple of months in a super-fast JS engine as well.

In terms of claims some members of the V8 team have been bragging a little bit about how V8 is “many times faster” than TraceMonkey. In fact, some guarantees may have been made.

Based on the data above, we’re running about 20% faster than V8 on SunSpider. While I’m sure there will be changes to each of the engines in the coming months I think that the claim that “many times faster” is ludicrous on its face and should be tempered by actual data. [ Note that the Google test is recursion heavy, something we're adding to TraceMonkey right now. This explains the gap on that one type of test. See Brendan's post above or John's post below for more details. ]

It’s also important to realize another fact. Google has had a small army of people working on the V8 engine for two whole earth years. We’re about 60 days into TraceMonkey and we’re already starting to match the performance characteristics of V8. As Brendan put it:

What spectators have to realize is that this contest is not a playoff where each contending VM is eliminated at any given hype-event point. We believe that Franz&Gal-style tracing has more “headroom” than less aggressively speculative approaches, due to its ability to specialize code, making variables constant and eliminating dead code and conditions at runtime, based on the latent types inherent in almost all JavaScript programs. If we are right, we’ll find out over the next weeks and months, and so will you all.

If you want data across browsers you should look at this post from John Resig that contains some graphics that give relative performance of various browsers including Safari, Firefox 3.0.1, IE, etc. His overview is great and gives a much wider view of relative browser performance.

Also as a side note because I have your attention. There are some bizarre and incorrect claims made in the comic about garbage collection. Brendan puts things right as a comment in John’s post:

@Ben: Chrome has a nice GC: exact rooting, generational with copying. Single-threaded, too (not an option for SpiderMonkey, which is used in AT&T 1-800-555-1212 and 411 AVR massively multi-threaded services built by tellme.com, now owned by Microsoft!). It definitely helps cut down on pauses and keep memory use flatter.

The Chrome comic book did have one piece of misinformation, though: it said other browsers’ engines use conservative GC, and have false positive problems because they can’t distinguish random integers from pointers into the heap. This is not true of Firefox, IE, or Opera.

We do live in interesting times.

tracemonkey and you

August 25, 2008 in Embedding, Firefox, JavaScript, Mozilla, TraceMonkey | 3 comments

There have been a pile of posts about the TraceMonkey code that just landed in mozilla-central. mozilla-central is the source code repository we’re using in the lead up to Firefox 3.1. Here are some posts if you want to read about it:

The heart of the story is that we’re seeing performance increases on benchmarks of anywhere from 1.8x to 37.5x depending on the benchmark used.

But the thing that most people don’t realize is that you can take advantage of the work that we’re doing in SpiderMonkey in your program as an embedded JS interpreter. It’s a pretty tiny engine, has a relatively stable API and even has useful documentation. John’s post contains four commands that you can use to build the engine. In fact, it’s so short, I’ll re-paste it here: 

hg clone http://hg.mozilla.org/tracemonkey/
cd tracemonkey/js/src
make -f Makefile.ref BUILD_OPT=1
Linux_All_OPT.OBJ/js -j

And you’re in a command line JS interpreter. No fuss, no muss.

Many people don’t realize it but most of what people think of as JavaScript is the browser API, not the JavaScript language. To quote from the JavaScript C Engine Embedder’s Guide:

The word JavaScript may bring to mind features such as event handlers (like onclick), DOM objects, window.open, and XMLHttpRequest. But in Mozilla, all of these features are actually provided by other components, not the SpiderMonkey engine itself. SpiderMonkey provides a few core JavaScript data types—numbers, strings, Arrays, Objects, and so on—and a few methods, such as Array.push. It also makes it easy for each application to expose some of its own objects and functions to JavaScript code. Browsers expose DOM objects. Your application will expose objects that are relevant for the kind of scripts you want to write. It is up to the application developer to decide what objects and methods are exposed to scripts.

The Embedder’s Guide does contain a lot of good information you can use to get started embedding SpiderMonkey into your application. It’s worth a read if you’re looking for a decent scripting engine for your app.

a short future history of JavaScript

August 20, 2008 in JavaScript | No comments

If you have the time I strongly suggest that you take some time and listen to the second edition of the openweb podcast. This episode should really be called the “Brendan show” because he does most of the talking. But if you’re into JS or you’re into programming languages in general it’s worth the listen. There’s lots of discussion of the trade-offs that went into the new ECMAScript Harmony effort and why ES4 and the ES3.1 efforts were rolled up together.

Arun also put up a post on the topic on the Mozilla Standards Blog that’s worth reading. But the podcast is particularly good. Especially if you want to know where the Web is going.

processing + spidermonkey + opengl es + iphone = neat demo

June 2, 2008 in Embedding, JavaScript, Mobile, OpenGL, iPhone | 2 comments

Someone took Mozilla’s SpiderMonkey JS engine, hooked it up to OpenGL ES and shows it off a processing demo on the iPhone. No browser required.

Neat stuff! Thanks for the link, John!

the hidden value of processing.js

May 10, 2008 in Firefox, Freedom, JavaScript, Microsoft, Mozilla, Open Web, Processing, Uncategorized, Video | 28 comments

The ever wonderful John Resig finally posted his totally awesome processing.js code to the web. If you haven’t seen it, you should go take a look. The Wired Compiler blog said “…this might be the most impressive thing we’ve ever seen.” And I agree, but probably not for the same reasons that they cite.

For a long time we’ve seen a niche on the web being filled by proprietary solutions. So-called rich internet graphics have long been the domain of Flash, before that Java (with limited success), ActiveX and now Microsoft is trying to jam Silverlight onto the world. However, each of these technologies suffers from one fatal flaw: they are, as a friend often described, deeply opaque. If you’re a developer for one of these technologies you’re on your own. You have to engage in a huge amount of training, the tools are often expensive or are difficult to use and then you are locked into a very specific platform. The bar for entry as a creator is very high. I think that Brendan would not mind me using his words to describe these technologies: Ivory Towers.

But the web is different. I’ve recently taken to describe the web as the world’s largest open source project because of its inherent transparency. Someone else doing something really interesting? Take a look at the source and copy it. Improve on it. Share it with others. As a developer for the web you aren’t alone. You have the work of thousands of others to draw upon. And the bar for entry is still about as low as you can get: a text editor. The web is smothered with information on how to develop for the web from the simplest HTML to advanced AJAX including everything from the front end to back end server work. It’s a highly democratized process, one that anyone can invest in and learn with no barriers for entry.

So back to processing.js. What John has done (in his spare time!) is to start to expose the capabilities of what we’ve been slowly adding to the platform of the web and give people a way to start to explore what we can really do. Canvas is here and it works. Video and audio have already landed in a couple of other browsers and we’ll have it soon enough. And each of them is exposed in the lingua franca of the web: transparent declarative markup connected by simple interactive scripts that are distributed as source.

We’re already starting to see the results. John released his code on Thursday. By Friday, someone had already duplicated the processing.js environment as a XUL program and someone else already created an editor where you can try out processing scripts directly on the web. That’s in one day after the code was posted on the web.

Just imagine for a second if those sites let people share and display neat little graphical widgets with source where people can try out different objects and learn from each other’s source code. Easy to drop in graphical interactive elements into other sites with the same transparency and zero-barrier to learning we’ve seen from the rest of the web. Think about how fast that stuff might spread on the web, how we might end up with people sharing and learning together and how much better the experience on the web might be in the end. That iterative process is one that needs starting points and what John has done is give us a great starting point.

So the world is changing. And changing quickly. The web is going to win, filling the market niche where Flash and other similar technologies found their hold. And John’s little project can hopefully act as a great catalyst to take us there. Thanks, John!