Badass JavaScript

A showcase of awesome JavaScript that pushes the boundaries of what's possible on the web, by @devongovett.

[badassjs]

WebKit.js: It's happening for real, with Emscripten's help

Remember that April fools post I wrote a couple years ago on WebKit.js? That someone had ported the entire WebKit rendering engine to JavaScript so you could browse while you browse? It was going to solve all our compatibility woes. That one was vaporware, but now it's actually happening for real.  Trevor Linton is porting WebKit to JavaScript via Emscripten.  The real WebKit.js is here.

It's an early build and there's no demo yet, but you can go see the massive output file it produced, meaning it actually does compile.  The goals of the project are

Produce a renderer in pure JavaScript that supports rendering to WebGL/Canvas contexts.

Develop frameworks for image/webpage capturing and automated web testing (similar to PhantomJS).

Develop a framework for prototyping CSS filters, HTML elements and attributes.

Experimental harness for pure javascript rendering performance.

Develop a javascript based browser in nodejs (just for fun).

Those are interesting goals. I have no idea how realistic or practical they are, but its a great showcase of the power of Emscripten to compile just about anything these days.

Currently a lot is not working yet, but its interesting to see the vaporware of two years ago become reality today.  Go check it out on Github, and try your hand at getting various WebKit features working.

[badassjs]

glsl-transition: iPhoto like slideshow transitions using WebGL

glsl-transition is a project from Gaëtan Renaudeau which provides a very flexible and extendable way to use WebGL shaders to create iPhoto like slideshow transitions.  It has a promise-based API, supports easing functions, and supports any GLSL fragment shader you can write.

The project is from the same author as slider.js, which is a general purpose slideshow framework for JavaScript.  slider.js supports WebGL transitions, as well as Canvas 2d and CSS transitions as well, in an extendible way, with a whole bunch of built in transitions that come with the library.  I'm not sure if glsl-transition is planned to be used by slider.js (it isn't at the moment), but it provides only support for WebGL transitions obviously, and is a bit lower level, though it still has a pretty nice API.  glsl-transition provides no built-in transition effects, however there are a number of examples in the Github repo.

It's obviously meant to be an extendible library, making it fairly easy to write your own transition effects.  You just have to implement a WebGL fragment shader with a couple special uniforms that will be filled by the library for you, including the starting image, the ending image, the progress in time, and the resolution.  The library will automatically render the transition using your shader as needed, controlled by a timing function.

glsl-transition provides support for not just bezier easing functions, but any function that takes a parameter t as a linear time, and it returns an easing value.  If you want a bezier curve, there is a library for that which returns compatible easing functions, and supports some built-in commonly used easing functions.  If you're interested in how this works, the author wrote a really good article about implementing bezier curve easing functions.  Apparently it was good enough that even Apple is using the code from that article on their Mac Pro website.

I'm glad to see WebGL taking off.  We still have a little way to go on mobile, but WebGL support is now fairly widespread on modern desktop browsers with even Microsoft supporting it in IE11. Only Safari is left with it turned off by default.

You can check out glsl-transition on Github, and a nice demo with lots of example transitions.

[badassjs]

ogv.js: An Ogg Theora and Vorbis Video Decoder in JavaScript

Brion Vibber has been working on ogv.js, an Ogg video player in JavaScript, supporting both audio and video. We've seen video codecs in JavaScript before, such as Broadway (H.264), Route9 (WebM/VP8), and more but mostly without audio support to go along with it. We have audio codecs in JS too, just not combined with video yet. That changes with ogv.js.

You can check out the demo, which runs in all modern browsers, but best in Firefox from what I've seen, thanks to asm.js optimizations.  I got about 23 FPS at about 40% CPU usage.  Of course, Firefox and Chrome already support Ogg video natively, so the primary targets of the project are Safari 6+ and IE 10+.  Ogv.js is an Emscripten compile of libogg, libtheora, and libvorbis.  It's actually a fork of a project I started to bring Ogg Vorbis audio to the Aurora.js suite of audio codecs.  However, at this point, I'd be hard pressed to find any of my code in the project.

The video decoding process actually starts with a streaming HTTP implementation, which allows videos to start playing before the entire file has been downloaded.  Unfortunately, there isn't a good streaming XHR API cross browser, so they use a combination of Microsoft's MSStreamReader API for IE 10+ (hopefully going to become standardized?), Firefox's proprietary moz-chunked-arraybuffer, and binary strings (ouch!) for Chrome and Safari.  This allows much increased perceived performance, since decoding can happen as the file is being downloaded.

Once the video stream has been received, it is fed into the C wrapper around libogg, libtheora, and libvorbis for decoding.  Then the audio goes to the Web Audio API (which means no IE support at this point), and the video is rendered in a canvas element.  At this point, the project is just using a simple 2d canvas for rendering pixels, but they say in the readme that a WebGL implementation could be used in the future.  I've seen huge performance increases (up to 20%) by moving the colorspace conversion (the last step of decoding) to the graphics hardware, which can do it in parallel, so I'm looking forward to seeing this.

Parallel decoding in web workers is also being considered, since decoding both the video and audio on the main thread can make for some stutters on slower machines (read: mobile).  Support for seeking is also on the roadmap.

Video decoding in JavaScript is an interesting problem, and not something on would have expected a few years ago.  But, it seems like people keep trying it, and with each attempt, we get better.  JavaScript performance keeps increasing, especially with things like asm.js, and the new SIMD API (more on that soon!).  One by one we're checking off the things on this list.  Who knows how practical it really is, especially since HD video or anything large still basically kills any system, and on mobile it can drain your battery really quickly.  But its a good benchmark for performance, and it's darn cool anyway!

You can check out ogv.js on Github, and a demo as well.

P.S. I hope you like the new site design, it should be much more readable on mobile thanks to the responsive layout. Let me know what you think!

[badassjs]

TraceGL: A JavaScript Codeflow Visualization and Debugging Tool using WebGL

Rik Arends has just released TraceGL, an interesting JavaScript codeflow debugging tool using WebGL for its UI rendering.  Described as "an oscilloscope, for code", TraceGL is an improvement on the familiar step debuggers that can be found in browser dev tools like Chrome, Firebug, and now Firefox itself.

TraceGL works by instrumenting all of your code so it knows when calls took place, and all of the boolean logic that determined which code path to take.  Then it visualizes all of this, using WebGL for performance, showing you a high level overview called the "mini map" in the top left, a log of function calls in the top right, the call stack in the bottom left, and finally the code for the function in the bottom right.

As your code runs, TraceGL visualizes all of this data in real time.  The mini map is useful to see the ebbs and flows of the code, i.e. where the stack gets deeper and shallower again.  In this way, you can see where events are being processed, like mouse or keyboard events in the browser, or HTTP requests in a Node.js application, and then get to a section of the potentially very long call stack very quickly.  TraceGL even works over asynchronous events, unlike most step debuggers, which means that these operations are still shown as part of a single call stack under their originating calls, rather than as separate events.

Here is a video showing TraceGL in use:

TraceGL can instrument both browser based and Node.js applications, and integrates with various editors so that double clicking a line can open your favorite editor.  An interesting aspect of the UI is that it is written entirely using WebGL, apparently for performance reasons.  Of course, all of the text rendering (most of the UI) must have been done in a 2d canvas and then uploaded to WebGL as a texture since WebGL has no native text rendering capabilities, but clever rendering tricks like only re-rendering what has changed can make things fast.  And once the textures are on the GPU, moving them around, scaling them, etc. using shaders is very fast.

I think we're probably going to see more and more WebGL user interfaces soon.  We've seen a lot of 3D stuff written on top of WebGL, and it is certainly good for that, but I'm betting that normal 2D user interfaces on the web will start being written with it too, just thanks to its great performance characteristics.  HTML and CSS is great for documents and applications, to a point, but for web apps to compete with native on performance, hardware accelerated UIs on top of WebGL will be important.

Of course, building user interfaces using WebGL means that any text rendering that is done won't be selectable, copyable, or accessible to screen readers without lots of additional work, so I can see frameworks being developed to facilitate this.  I've already been working on and off on something similar to Apple's Core Animation framework on top of WebGL (not public yet), and other interesting 2D frameworks like Pixi.js have been released recently.  Especially with WebGL's likely support in Internet Explorer 11, I think the age of WebGL user interfaces is upon us, and it's  exciting!

You can check out TraceGL on their website.  It costs $15 to buy, but not all good tools are free and it's nice to support good developers, so give it a shot and let me know what you think in the comments!

[badassjs]

Link: Excellent Article Clarifying Mozilla's asm.js Project by John Resig

John Resig has written an excellent article clarifying some of the questions that have arisen over the past few weeks regarding Mozilla's asm.js project. If you haven't heard of it already, asm.js is a highly optimizable subset of JavaScript designed mostly for compilers like Emscripten. I wrote an article about it a few weeks ago when the spec was first released right here on this very blog, so check that out if you want some more introductory details.

John's article talks about some of the use cases for asm.js, some of the common misconceptions about it, and finally includes a question and answer section with Mozilla's compiler engineer David Herman, who is one of the authors of the asm.js specification. It's definitely a good read, so check it out!

I think asm.js will be really important over the coming months and years, and I'm excited to see other browser vendors already getting on board. I got even more excited about it when I saw Mozilla and Epic Games' demo showing the Unreal Engine running in the browser at very good performance, thanks to Emscripten and asm.js last week.

I'm looking forward to trying out asm.js myself very soon as well, especially for the JavaScript audio codecs that I worked on as a part of Audiocogs (née Official.fm Labs). Unfortunately, asm.js isn't really designed for human authors so it would be a very big task to convert one of our existing codecs to use it. However, it is very promising for new ports, and I've already starting playing around with using Emscripten to compile libogg and libvorbis to JavaScript to use with the Aurora.js framework. It will be interesting to see the performance and code size differences between the hand ports we've done and the Emscripten generated ones. Now I just have to find the time to actually do it! :)

[badassjs]

An Iron Man Like 3d Hologram Controlled by Leap Motion and Three.js

The Leap Motion is a very cool piece of technology.  It's a small $80 box that you can put on your desk to control an ordinary computer using hand motions.  It's extremely accurate, allowing for very fine motor control using all of your fingers.  If you haven't seen it, be sure to check it out.  I'm definitely getting in line for one to play with myself.

Robbie Tilton has put together an amazing video demo showing a Leap Motion controlling a Three.js rendered 3d hologram of the earth.  It is projected on a 4-sided prism, and while it's not quite as good as what Tony Stark has in Iron Man, it's still pretty darn cool.  And it's controlled by JavaScript!  Check out the video, embedded below.

As you can see, the four sides of the earth image are projected onto a table and then onto the four sided prism, giving the hologram-like effect.  Thanks to tools like Three.js and WebGL, this can all be done quite simply using JavaScript.  Now imagine your web apps projected onto a hologram and controlled using Leap Motion.  Will you build the next JARVIS? 😃

I have no doubt that there will be many more amazing demos like this as developers get their hands on the Leap Motion, which is slated to ship in May of this year for $80.  If you have a great idea, you may even be able to get early developer access by signing up on their site.

[badassjs]

Rawson.js: A JavaScript Camera RAW File Viewer Ported with Emscripten

Rawson.js, by Franz Buchinger, is a JavaScript renderer for RAW image files in the browser.  It uses an Emscripten port of the dcraw C library to JavaScript to render in a canvas element.  Rawson.js can also extract metadata from RAW images, as you can see in the demo.

Thanks to the dcraw C library, Rawson.js enables viewing of RAW images from over 500 different cameras and many file types.  The thing about RAW files is that each manufacturer has their own file format, and libraries and viewers must be updated when new cameras are released.  This is why you will sometimes see operating system updates and other program updates for RAW image support ever now and again.

Rawson.js is currently a bit slow, especially for large images.  The image shown in the screenshot above is almost 30MB and it took about 30 seconds to render on my system.  I have found it to be a lot faster in Firefox Nightly thanks to asm.js I think, so try it there if you can.  It sounds like they are perhaps working on a smarter renderer for the next version of Rawson, that doesn't have to render the whole image at 100% quality before displaying anything.  My suggestion is to only render the visible parts, perhaps in parallel using Web Workers (which they should use in any case) in tiles if possible.  They've also mentioned using the embedded JPEG previews in many RAW files to speed up initial rendering while the real thing is processed.

Once it is sped up a bit using some smarter rendering techniques, I think Rawson will be very important for browser based photo editing applications, since many professionals only work with RAW files for their quality.  You can check out the source on Github, the project page, and the demo.

[badassjs]

Parallel.js: A JavaScript Multicore Processing Library Using Web Workers

Parallel.js is a very nice looking wrapper around JavaScript Web Workers making some interesting applications of multicore/parallelized processing in JavaScript much easier.  Usually with Web Workers, you must write a totally separate script and load it into the worker thread.  This isn't very convenient in some cases, especially when you need to share code between the main and worker threads.  Parallel.js solves that problem and provides a nice API abstraction to perform common tasks.

Parallel.js allows you to spawn a worker containing one or more functions, defined in your parent thread rather than as a separate file.  You just pass the function names and some arguments to call the function with, and Parallel.js will spawn a worker thread, run the function with the passed arguments, and send the result back to the main thread asynchronously using a Promise based API.

There is also a MapReduce API for processing large datasets that will split the data into chunks to be processed in parallel by an arbitrary number of worker threads.  When all of the processing is complete, the result is merged back together and returned to the main thread.

As web applications do more of their processing on the client side, we will need to take advantage of the multicore machines that modern systems have in order to maintain a good user experience.  As a rule of thumb, we never want to do a lot of processing on the main UI thread since the user will notice the lag.  Web Workers are great, but in general quite difficult to use.  I'm glad to see libraries beginning to make things easier in this department.

As always, you can check out Parallel.js on Github and its website.

[badassjs]

Holla: A Sugary API Abstraction for WebRTC Voice and Video Calling in the Browser

I posted about PeerJS recently, which is a nice API on top of WebRTC for peer-to-peer networking of arbitrary data.  However, one of the main selling points for WebRTC is its voice and video calling support.  Holla is a JavaScript library that aims to make working with WebRTC's voice and video calling APIs much easier.  WebRTCs APIs are pretty low level and not something everyone wants to deal with directly, so a nice API abstraction is very much welcome.

Like PeerJS, Holla has both a client and a Node.js server component.  The server helps broker the peer-to-peer calls between clients with usernames.  Once usernames are registered, the clients can make voice or video call requests as well as send chat messages to other client usernames.  On the other end, the second client can either answer or decline the call, and then send the video stream to a <video> element to be displayed.  The API looks really simple to use, and thanks to WebRTC will make pretty much anyone able to build their own Skype in a couple minutes.

The demo allows you to declare your username and then call and chat with other usernames, and shows the power of the API to do a lot with a very small amount of code.  It's a simple demo, and it only works in Chrome and Firefox Aurora so far, I think, but I'm looking forward to future widespread adoption of WebRTC.  You can see the code for the demo on Github to get a feel for the niceness of the API, and then look at the rest of the code for the client and server to see what it's doing for you.

WebRTC is the way of the future and it's good to see adoption and 3rd party library abstractions already being created.  As always, you can find the code for the library and its demo on Github.

[badassjs]

asm.js: A Low Level, Highly Optimizable Subset of JavaScript for Compilers

David Herman, Luke Wagner, and Alon Zakai (also the developer of Emscripten) of Mozilla have been working on the asm.js spec, which aims to be a subset of the JavaScript language that can be highly optimized after you have opted in.  It is designed mostly for compilers like Emscripten to target, but the best part is that it's backwards compatible with the existing JS syntax since it is a strict subset.  This means that asm.js code will still run on older browsers, although not in the optimized path taken in enhanced JS engines.

You opt-in to using asm.js by including the "use asm"; string at the top of your file or individual function, just like you opt into strict mode with "use strict";.  Once you've done that, the ahead-of-time (AOT) optimizing compiler will kick in in supported engines, looking for type annotations and validating the code to make sure it really is optimizable.  The type annotations are interesting, and not similar at all to other attempts like Microsoft's TypeScript since they must be backwardly compatible with normal JavaScript.  Instead, asm.js uses existing JavaScript operators as type hints, for example +a would annotate the a variable as a double.  a|0 would annotate it as an integer.

Once the engine has determined that the code is valid asm.js, it can compile it ahead of time and not have to worry about deoptimizing later on, runtime type checking, garbage collection, and bailouts.  There is no garbage collector since memory manually managed in a large HEAP typed array, using malloc and free like functions.  All of this obviously makes programs much faster since there is simply less work for the JavaScript engine to do while running your program since it has done it all ahead of time.  This will allow JavaScript programs to get closer to native code speed, and for certain classes of applications in the browser, this will be important for the platform.

If all of this sounds a bit tedious to write, I would agree, although it's far from the worst syntax we could have.  However, it isn't really targeted at human authors, but compilers like Emscripten, Mandreel, LLJS, or perhaps even TypeScript which can generate the cleverly backwards compatible but not terribly clear type annotations for you from another existing language like C, or a new language like LLJS or TypeScript.  Emscripten already generates valid asm.js output and was one of the main impetuses behind the the project, and Firefox will be landing their asm.js optimizing compiler in the near future.  The benchmarks look very impressive indeed.

These are exciting times for JavaScript application performance, and asm.js can only help.  It definitely seems like Mozilla's response to Google's Native Client (NaCl) project, which actually runs compiled code on the web in a sandboxed environment.  Since asm.js is actually a subset of JavaScript that is backwardly compatible, I see it as a much more likely winner in the highly optimized code space on the web.  NaCl is not available anywhere right now, but asm.js is already available everywhere even though no engines have implemented official support.

Be sure to check out the asm.js spec, David Herman's prototype asm.js validator on Github (written in JS!), and Emscripten developer Alon Zakai's presentation about Emscripten, asm.js and the future.  I'm looking forward to watching all of these projects as they develop!

[badassjs]

Qt GUI Toolkit Ported to JavaScript via Emscripten

We have seen a lot of projects get compiled to JavaScript via Emscripten, including LLVM itself, but nothing quite as complicated and impressive as emscripten-qt, a port of the Qt cross platform GUI toolkit to JavaScript using Emscripten.  Qt already works on many platforms natively including most desktop operating systems and some mobile ones as well, but thanks to Emscripten it can now work in the browser directly.

There are a ton of demos that you can check out showing Qt apps compiled to JavaScript and running in the browser.  For example, the app I screenshotted and included above is a rich text word processor supporting various fonts and text styles, alignments and PDF generation.  Thanks to Emscripten's File API, you can even open and save documents from a virtual filesystem and access generated PDFs from that filesystem via a link outside the app.

All of the rendering of these apps is done in one large canvas element, which you'd think might be slow, but it turns out that at least for all of the demos I tried, it's actually really fast and responsive.  Of course, Qt has its own image generation routines built in so it's using the canvas as basically a way to blit pixels to the screen and nothing more.  It's pretty much the only way this could possibly work, without rewriting large parts of Qt itself, and it turns out that it works pretty well.  They have an "experimental renderer" that you can enable, that is supposedly faster but I haven't seen much of a difference.

Let me just make this clear: the only canvas method emscripten-qt is using for rendering is putImageData.  Nothing else.  All text, paths, gradients, and all UI components are all rendered by Qt to pixels before even making it to the canvas.  And it's still pretty darn fast and smooth.  I think this is both a confirmation that entirely canvas based UI toolkits could be possible as well as a showcase for the power of Emscripten to make use of already written and optimized code on the web.

You can of course, check out the source code for emscripten-qt and the long list of demos I linked to above.  If any of the projects compiled by Emscripten so far show that Emscripten is ready for the wild, Qt is it.  I can't wait to see what will come next.  I joked last April fools day about a WebKit being ported to JavaScript, and now honestly I'm not sure it's that far off!

[badassjs]

PeerJS: A Peer to Peer Networking Library in JavaScript using WebRTC

I just caught wind of PeerJS, a project that makes peer to peer networking using the new WebRTC browser APIs easier.  WebRTC is extremely cutting edge and the library currently only works in Chrome Canary and Dev Channel, so take this with a grain of salt but it is exciting to see cutting edge libraries like this.

PeerJS actually consists of two parts: the client side script that communicates with other clients using WebRTC, and a Node.js server component that brokers the connections between the clients.  The server keeps track of each client that is currently online so that the clients can become aware of each other.  Once the clients know about each other, they can connect directly thanks to WebRTC's RTCPeerConnection API, which allows sending arbitrary data between clients with an API very similar to the WebSocket API.  Both binary and textual data will be supported, but right now only text is working.

PeerJS wraps all of this up in a nice API, and they even provide a free server for you to use with an API key if you don't want to run your own.  They also handle all of the complexities of working with the WebRTC API including handshaking, temporary binary string encoding until browsers implement sending binary data directly, and of course the actual server brokering of connections.  WebRTC handles the actual networking complexities for you, including NAT traversal, UDP and the actual peer-to-peer connections themselves.

The API looks really easy to use.  You can check out a peer to peer chat demo using PeerJS online, and its source on Github as well.  However, as I mentioned at the top of this post, the library currently only works in the Canary and Dev versions of Chrome 26, and Firefox apparently doesn't work yet.  It is exciting to see WebRTC coming along, both in terms of live video and audio transmission as well as arbitrary data.  WebRTC is a major undertaking for browser vendors, but I think it will create some great opportunities for browser based apps in the future.

One of the things that might be made possible with WebRTC and a library like PeerJS is a browser based BitTorrent client.  Previously it has been pretty much impossible because the only protocols supported via JS have been WebSockets and HTTP.  I'm not entirely familiar with the details of WebRTC, but it sounds like it will give developers much more networking flexibility.  I'm not sure what the security restriction are. Same domain wouldn't really apply here, so I guess it would probably just ask the user's permission, as it should.  Let me know if this I'm mistaken, but I think a BitTorrent client could be an feasible possibility.

You can check out PeerJS on Github, and find the documentation and demos on their website.  I'm looking forward to seeing the future of WebRTC as it is implemented in browsers and demos and libraries start to make use of it!

[badassjs]

Node.js Source Map Support for Better Compiled JavaScript Debugging

Evan Wallace, who's work I've covered several times before has been working on a module to add source map support to Node.js.  Source maps will be really important for debugging compiled to JavaScript languages like CoffeeScript, as well as for debugging minified or concatenated production JavaScript.

As their name implies, source maps provide a mapping from the compiled code the browser is running to the original source files.  This way, when errors occur, the stack traces can display the correct line and column numbers from the original source.  They can go even further than that, giving correct information in profilers, consoles, and more.  You can find a good tutorial about source maps over on HTML5 Rocks.  So far, they have been implemented in the Chrome Dev Tools, and Firefox is working on getting them implemented as well.  As for compiler support, the main CoffeeScript compiler still lacks support for source map generation, but the CoffeeScriptRedux compiler has support.  Microsoft's TypeScript language also has support, and both Google Closure Compiler and UglifyJS2 can generate source maps for minified JavaScript as well.

As for Node.js support, there isn't any built in.  The Node core developers aren't really big fans of compile to JavaScript languages as far as I can tell.  There is an open bug on the Node Github project to add support, but it's 7 months old and hasn't gotten much traction.  Luckily, it doesn't have to be in Node core to work, and so Evan Wallace wrote this module to add support in user land.

To use it, you just require the source-map-support module from npm, and like magic all of your stack traces will now contain correct line numbers.  It uses V8's handy Stack Trace API to capture errors and rewrite their stack traces just before they are thrown and printed out if not caught.  It also uses Mozilla's source-map module to do the actual source map parsing and mapping.  That module can also be used for source map generation, and CoffeeScriptRedux does just that.

Anyway, if you have been itching for source map support in Node.js like I have, go check out source-map-support on Github and npm, and start debugging better.  Source maps can solve 90% of the issues people have had with compile to JS languages, so I'm glad to see them arriving in both the browser as well as Node.js.

[badassjs]

IDBWrapper: A Cross Browser IndexedDB Wrapper for Offline Web Apps

Jens Arps has been working on IDBWrapper, a JavaScript library that wraps the IndexedDB API and makes it much easier to work with.  IndexedDB is very low level and perhaps one of the hardest browser APIs to deal with, so various wrappers are necessary to make it useful to most people.

IndexedDB is a JavaScript API found currently in Firefox, Chrome, and IE10 that implements a client side data store for web applications.  It stores data locally similar to localStorage, but can store much larger chunks of data and is asynchronous and much faster.  It was created after Mozilla refused to implement the now dead WebSQL spec over interoperability concerns of the unspecified SQL language itself.  At the time, all browsers implementing WebSQL used the opensource SQLite project so interoperability wasn't a concern, but Mozilla feared that non-opensource browsers would have to use a different SQL implementation and that there would be differences.  The options were either to specify the entire SQL language in the WebSQL spec or scrap it all together and come up with a new spec.  Obviously, they chose the latter and now we have IndexedDB.  In my opinion it is a terribly designed API and we lost a lot of power when we lost SQL, but I suppose JavaScript libraries can help make up for this.

IDBWrapper is trying to do just that, making simple stuff like setting, getting, and deleting one or all records really easy, and making more complex stuff like queries simpler.  It also deals with several cross browser inconsistencies (ironic, after what I just wrote about WebSQL, right?).  IDBWrapper has been around since sometime in 2011, but just hit a 1.0 release, so I thought I'd mention it here.

You can find the code for IDBWrapper on Github, the up to date documentation, and two older blog posts that describe the API as more of a tutorial.  Although the IndexedDB is kinda ugly by itself, libraries can help just like they have with many other ugly web APIs like the DOM in the past.  Ugly or not, IndexedDB will be important in bringing offline web apps to the masses.

[badassjs]

Using WebGL for High Performance JavaScript Heatmaps

Florian Boesch has been working on webgl-heatmap.js, a library for rendering heatmaps using JavaScript and WebGL.  As he explains in his blog post about it, he was looking at other heatmap drawing libraries out there and found that they weren't fast enough.  Most other libraries were just using regular old 2d canvases, but he found that when you have hundreds of thousands of points to draw, keeping performance high is very difficult.  That's why he turned to WebGL, to let the massively parallelized graphics cards in modern computers do much of that hard work for him.

You can check out a live demo and see for yourself that it is indeed quite smooth.  In his own tests, he says you can draw around 500,000 data points per second with 10,000 per frame without a hitch.  This is pretty impressive and shows the importance of WebGL to the web platform (*cough* Microsoft *cough*).  We're only just getting started.

One possibility for this libraries usage is some sort of realtime heatmap of a website or app's user mouse movements.  The user mouse movements would be recorded and sent via Web Sockets to an admin app where they could be rendered on a heat map in real time.  Having good performance is critical when you have lots of users on a site all at once.

Anyway, this looks like a simple to use library that could have some interesting applications.  Check out the demo and the code on Github.

[badassjs]

Cutting Edge Standards: Canvas Blending Modes & Winding Rules, SVG OpenType Fonts, & Balanced Text

There have been a number of interesting cutting edge standards proposals that I've seen out there recently and thought worth sharing.  Several of these come from Adobe, which seems to really be investing themselves in the web platform recently.  They're the ones behind the CSS regions and exclusions features that will offer really beautiful magazine-like text layout (e.g. flowing around non-rectangular shapes) in the browser.

Blending Modes

Adobe has also been working on some other improvements to the web platform, including several to the Canvas element, including Photoshop like blending modes.  The blending modes have been added to the canvas context's globalCompositeOperation property, which had previously only been used for Porter-Duff compositing modes (e.g. sourceOver).  Adobe has also added blending modes to CSS for HTML content, with separate blending modes for foreground, background, and shadows.  You can check out the compositing and blending specification for more info.

Winding Rules

As for winding rules, this was actually one first implemented by Mozilla for the PDF.js project.  Previously, there had been no way to specify a winding rule for canvas like you could for SVG content.  Winding rules change how shapes are drawn when they are self intersecting, as you can see in the above image.  So Mozilla added support for a fillRule property to canvas elements, and it was subsequently adopted by the standard.  I believe WebKit has also implemented the feature, though I'm not sure.  However, Adobe has a new proposal to change it from a property to an additional argument to the fill, clip, and path hit testing methods instead.  They go over why, in this blog post.

SVG OpenType Fonts

Another really interesting recent standards proposal is Mozilla's addition to the OpenType font specification for SVG glyphs.  OpenType is pretty much the industry standard font format at this point, and it has great support for complex language shaping and advanced typographic features.  Currently it supports glyph definitions in two simple formats: TrueType and PostScript.  Mozilla is proposing to add a third glyph type, which is SVG.  This means that you could define each glyph in the font to be an SVG document.  And since SVG can contain color and even animated content, you could have animated color glyphs in fonts.

I'm not sure how I feel about animated glyphs, but color would be really useful, specially with the rise of Emoji characters over the last few years.  Usually Emoji fonts are just bitmaps which means they aren't really scalable to any size.  Since SVG is vector based, it that problem can be solved.  If added, this proposal would probably also remove the need for the SVG fonts spec, which has been around for a while without much browser support since it doesn't have very good advanced typographic support.  It will be interesting to see where this goes.  Mozilla has already implemented it in Firefox (though it is disabled by default), and I expect it will be utilized in other places as well.

Balanced Text

Finally, Adobe has a proposal for to allow balanced text layout support in browsers for better readability.  Typically, browsers use a simple greedy algorithm for wrapping text, by continually adding words until a line is too long and then wrapping to the next line.  This works fairly well for left aligned text, but for centered text it doesn't look to good to have a long line followed by a really short line.  Adobe is proposing a CSS text-wrap property with a balanced value to control the algorithm that the browser uses to wrap text.  They even have a jQuery Plugin that implements the feature in current browsers.

Specifications and proposals are moving ever quicker on the web, so I thought I'd take a minute to share some of them with you.  These weren't necessarily directly JavaScript related, but it's all the web so I thought it was worth it.  Can't wait to see them implemented and more new ones to come along: that's progress!

[badassjs]

Verold Studio: A Realtime WebGL-based Collaborative 3D Editor in the Browser

Ross McKegney, CTO of Verold, a Toronto based startup working on brining 3D experiences to the web submitted their browser-based collaborative 3D editor and it looks pretty awesome.  It allows 3D artists to import 3D object files (specifically OBJ, Collada, or FBX files) into their web interface and then collaboratively edit scenes and finally share or embed them.

The editor works in real time, much like Google Docs but for much more advanced 3D resources instead of just documents.  You can edit materials, lighting and other effects all in the browser, and all collaboratively in real time so your changes immediately show up for everyone else editing the project at the same time.  This is really powerful, and I think we're going to see lots more collaborative apps in the future especially with the rise of Node.js.

You can try out the editor yourself, and as you can see it feels very smooth.  You can look at some of the public projects available from the main screen to see what is possible.  If you create your own project, you first upload a model file exported from another tool, and then adjust the materials, textures, lighting, fog, and several other parameters.  Finally, you can create an embed code for your project and put it on a website.  The user just clicks the "Go 3D" button and it turns the static image into a user manipulatable scene.

One example given in their introduction blog post would be for a car company's website, where the user could get a better feel for the car by manipulating it in 3D rather than just looking at pictures or relying on a plugin like Flash.  You can try out the car demo on that blog post, and check out a video of the editor in action.

I'm told the editor is built using a combination of great JavaScript projects, including Three.js, Node.js, Backbone.js, Socket.io and more.  It's pretty interesting, although not opensource, but you should check it out your yourself.  Oh, and pester Microsoft until they add WebGL support to Internet Explorer as well.  I think it's going to be a big deal.