Compiling to Javascript or not?

JavaScript is commonly seen as a flawed language. It has plenty of flaws, some of which are more painful than others. One common way that people deal with these flaws is to use another language that compiles to JavaScript and to then write their code in that other language.

At first, this sounds pretty appealing. You get to choose which of a few languages to use to address your complaints with JavaScript. Unhappy with the type system? Try out Dart, TypeScript, AtScript, Elm, or even PureScript. Want a more concise syntax? Perhaps CoffeeScript is your thing. Do you wish you were using a Lisp? Well, there are lots of options there as well, starting with ClojureScript or Parenscript. There are many choices.

My Project

My project involves creating a platform for building tools that is based on Atom Shell and uses a plug-in model to allow users to extend the core platform.

I also have some requirements:

I need access to things that will be coming in future versions of JavaScript (and fairly soon). An example of this is support for working with 64 bit integers (a firm requirement).
Given that we have a single deployment platform (Atom Shell, with …

Looking at Packet Capture and Dissection

For the project that I am working on (not yet disclosed), I was thinking that it would be interesting to be able to integrate a view of what is happening on the network, much like Wireshark and other tools can provide. The view would be more targeted towards what the user was doing, but the overall idea would be the same: capture network traffic and perform some basic analysis on it to display it visually.

This led to some interesting research, which I've decided to discuss here! (For those who feel this is a long post, there's a summary of sorts at the end.)

Capturing Traffic

node_pcap

Given that I'm using Atom Shell to build this application and that uses Node.JS, one of my first thoughts was to take a look at node_pcap. After all, node_pcap was used successfully in tools like htracr, so perhaps it would work well here.

Unfortunately, I ran into a series of issues with node_pcap. For one thing, it wants to run the capture in the same process, and since performing a capture requires putting the network interface into promiscuous mode, it requires elevated privileges. I am not comfortable with the idea that my …

SWIG and JavaScript - Part One

I experiment with a lot of ideas for projects and see which ideas stick, which seem interesting, which require something that I can't provide, etc.

A project that I'm working on now may well be interesting and within my capabilities and the resources that I can muster, but I don't want to identify it specifically yet.

Anyway, this project requires using Node.js to talk to a C++ library with an extensive API. An interesting detail is that this library already has a solid Python API, built via SWIG.

JavaScript and SWIG

Version 3.0 of SWIG began to support JavaScript. It supports using JavaScriptCore or V8 as the JS engine, and Node.js as a specialization of the V8 support.

For now, I have hacked the SWIG interface files from the C++ library to wrap Python-specific portions in #ifdef SWIG_PYTHON so that they can be shared with JavaScript. In the longer term, should this project work out and I decide to upstream the changes to support having JavaScript bindings, I will clean this up and move some things into separate files for each language in a tidier fashion.

In fairly short order, I was able to get a Node …