3/6/15– Jon McKay
Overall, I strongly believe that this change will make for a much more consistent and robust development experience on the Tessel platform. This shift was motivated by a confluence of factors including power consumption, JS/Node compatibility, and budding story for npm modules with binary dependencies.
In addition, the Node.js landscape has shifted. We’ve seen the io.js team fork the Node.js project and start developing new features. We have been fortunate to have an external contributor add relevant Node libraries as submodules, but others must be implemented by hand in Lua. The maintenance and overhead of making sure new Node.js/io.js libraries are consistent with our runtime is yet another uphill battle. For that reason, we’ll be running vanilla io.js on a lightweight distribution of Linux (openWRT). io.js allows us to remain backwards compatible for folks looking to use Node.js, but lets us stay on the leading edge of development.
I still do believe it’s possible to make a nearly compatible runtime, but it’s going to take much more work than we expected and that resource investment would be an unwise business decision.
One consequence of rolling our own runtime is that modules with binary dependencies (the most requested of which has been ws for faster websocket support) are not be able to run on Tessel 1. These modules depend on C/C++ libraries which get compiled on the platform that installed them prior to being able to run them. In order to get these modules to run on Tessel 1, we would need to be able to link them against V8 APIs cross-compiled for ARM Cortex-M3, which would take a ton of development effort. Moving forward, we have a pathway for using these highly requested modules in development. If we use V8, we can stash popular binaries pre-built for Tessel 2’s MIPS architecture and send those over when requested by a project’s package.json.
The Plan For Colony
Colony is the name of Tessel 1’s original runtime. Going forward, Technical Machine will continue making small bug fixes in Colony but will not adding any new features. That being said, some of the Technical Machine team, including myself and Tim, are interested in maintaining and improving Colony at a personal level. We’ve thrown around the idea of getting the runtime on standalone, barebone WiFi chip, using only the onboard flash. We’re not retiring the runtime completely, but rather, putting it on the backburner for now.
So how is this different from Pi/BeagleBone/Insert Linux-based Dev Board Here?
Several people have asked us how we expect to differentiate ourselves from other Linux-based development boards. The Tessel platform is unique in that we believe we can deliver the best developer experience by abstracting away the underlying OS technology and ensuring there is a clear path to production. We still believe that developers just want to push code, build their product, and deploy it - the underlying technology is only relevant if it gets in the way of functionality. In that vein, we continue to have a Heroku-like deployment process of
tessel run on Tessel 2.
In short, the Tessel platform is still the fastest way to prototype an idea and, with Tessel 2, the fastest way to bring it to market.