Following the development of a bespoke JavaScript engine for embedded systems, the decision was made by the team behind Tessel to adopt io.js for their latest product innovation, the Tessel 2.

Evolution from Tessel 1 to Tessel 2

Over the course of nearly two years, Tessel was developed as a microcontroller powered by JavaScript and compatible with Node.js. The team embarked on creating a specialized runtime that converted JavaScript into Lua, which then ran on a Lua VM. This approach was designed to enable JavaScript functionality on a Cortex-M3 processor. Despite pride in their runtime achievements and appreciation for community contributions, the move to io.js running on V8 was seen as more closely aligned with the community’s immediate needs.

This transition was believed to significantly enhance the consistency and stability of the development experience on the Tessel platform. Several factors motivated this shift, particularly concerns regarding power consumption, JS/Node compatibility, and the integration of npm modules with binary dependencies.

Power Consumption Concerns

The choice between utilizing an existing runtime like V8 (usually on Linux) or developing a unique one was crucial for running JavaScript and Node. Initially, the creation of a unique runtime aimed to deploy JavaScript on an ARM Cortex M3, striving for lower power consumption and real-time IO capabilities. However, optimizing Tessel’s power efficiency proved challenging due to several factors, especially the power draw of the CC3k WiFi chip and the 32MB SDRAM. Proactive strategies like efficient WiFi chip management and limiting JavaScript execution could only partially mitigate power usage, indicating that for low-power applications, WiFi and JavaScript might not be the best choices. This led to the conclusion that the benefits of Linux + V8 outweighed those of a less mature RTOS, given the need for higher power.

JavaScript and Node.js Compatibility Issues

A significant incentive for adopting V8 was to ensure compatibility with JavaScript and Node.js/io.js. Efforts to accommodate JavaScript’s nuances within their custom runtime faced numerous challenges, underscoring the complexities of aligning JavaScript with Lua’s slightly different semantics. Moreover, the evolving Node.js environment, marked by the io.js team’s branching off, added to the complexity. Ensuring new Node.js/io.js libraries’ compatibility with their runtime required substantial manual effort, highlighting the continuous challenge of maintenance and library consistency. Therefore, running io.js on a streamlined Linux distribution (openWRT) was chosen to provide backward compatibility with Node.js while staying at the forefront of development.

Binary Dependencies Dilemma

The design of the original runtime meant that Tessel 1 could not support modules with binary dependencies, such as the highly requested ws for improved websocket functionality. These modules rely on C/C++ libraries compiled at installation, necessitating a significant level of development effort for compatibility with the ARM Cortex-M3. The decision to leverage V8 enabled the pre-compilation of popular binaries for Tessel 2’s MIPS architecture, facilitating their use in development projects.

Future of Colony Runtime

Colony, the runtime for Tessel 1, was decided to receive only essential bug fixes from Technical Machine, with no new features planned. However, certain team members expressed a personal interest in continuing its development, potentially adapting it for standalone WiFi chips using onboard flash storage. While not completely abandoning Colony, the focus was shifted towards other developments for the time being.

Differentiating from Other Linux-based Development Boards

Questions arose about how Tessel would differentiate itself from other Linux-based development platforms. The unique proposition of Tessel lay in its commitment to offering the best developer experience by abstracting underlying OS complexities and ensuring a smooth path to production. The technology underpinning the platform was positioned as a concern only if it impeded functionality. Thus, with Tessel 2, the platform maintained a simple, Heroku-like deployment process through tessel run, reinforcing Tessel’s position as the quickest route from prototype to market.

In summary, the transition to Tessel 2 and io.js marked a pivotal step in the team’s mission to streamline and enhance the development experience on their platform.