Badass JavaScript

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!

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! :)

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.

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.

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.

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.

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!

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!

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!

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.